search

drkibitz / pixi.js

Super fast HTML 5 2D rendering engine that uses webGL with canvas fallback
Other
8 stars 1 forks source link

More details on using this with node #1

Closed jamesandres closed 10 years ago

jamesandres commented 10 years ago

Hi @drkibitz,

I'm very interested in the initial direction of this fork. I've built the code, ran the tests, and read through the bunnies test (https://github.com/drkibitz/node-pixi/tree/master/test/functional/example-1-basics).

  1. It would be awesome to have a short working example of the functionality this project provides when running in node. eg: Will it work with node-webgl? Can I make server-side renders (eg: to capture as PNG).
  2. A compatibility matrix with standard Pixi.JS would be great too. eg: The CanvasRenderer appears to be missing it's render() method. I'm not sure if this is a bug or a feature..
  3. I'm keeping an eye on https://github.com/GoodBoyDigital/pixi.js/issues/307. Is there other developments in this space? Will this remain an indefinite fork of Pixi.js?

Overall, npm install pixi and modularization of the codebase is a huge win for my projects. Thank you!

drkibitz commented 10 years ago

Thanks for the compliments, here are my replies:

  1. Currently using in node is not very useful. Basically you can load modules without an error, but as soon as you call methods on them I'm not sure. Browserify was where I spent most of my focus on this iteration. The first thing I wanted to do with node compatibility was get the tests to run there too. The idea would be to architect node-pixi in such a way where it does not assume the browser in any sense, and provides an API to set needed references in order to change the environment, it's not there yet sorry.
  2. There is a render method here https://github.com/drkibitz/node-pixi/blob/master/src/pixi/renderers/canvas/CanvasRenderer.js#L84. What kind of errors are you seeing and for what? A compatibility matrix would be good, but I think I would need help with that. In the future the project could differ greatly, but if compatibility is important, it could be provided with a compatibility wrapper module.
  3. There hasn't been any public development beyond what you see in that thread. They sound like a couple of very busy engineers, but I'm sure it will happen, and be amazing. I just had a realization, I already had all of the work in this fork done, and now I think having a clean tested codebase is more important than features and right now. We have a lot of similar points of view, but one thing I don't agree with is the kind of cryptic responses using the royal "we" about everything that is going on what seems like "behind the scenes". Don't get me wrong, they are very open about what they are doing, but sure would like to have some code review processes in place, even for the maintainer(s). I also have my own thoughts about what a rendering API should be. This is from a lot of experience with design, animation, 3D rendering, flash programming, game programming, data visualization, etc.. I don't believe the Flash display list is bad, but it can be more finely tuned (you would still probably use a rendering library in ActionScript to make up for shortcomings). Basically I want a 2D engine that works like a 3D one. The use of Cameras, Scenes, and Viewports instead of renderer.projections, Stages, and renderer.views. I could probably go on and an on here, but the short answer is no, it is not an indefinite fork.

Side note If you are interested, I also have a very rudimentary port of Pixi.JS into Haxe/OpenFL that I used for this, https://github.com/drkibitz/openfl-bunnymark.

jamesandres commented 10 years ago

Okay, thanks for your thoughts on this. Looking forward to what progresses in this space :)