As much as I’d seriously love to do so, it’s unfortunately out of my hands - I received serious investment from a third party which gave me the time to do the project, and all of the rights to the stage3d portion of the code are theirs. However, that doesn’t stop me from providing advice about my experiences with developing it if someone wanted to take up the reigns and push this forward 
Not only that, but some of the code in there is frankly embarrassing!
Since i saw this i became interested in stage3D.
I’ve played a bit in my own and i think is relativly easy to create the support for stage3D. Would you like me to try to make it? And also, if it’s made, should FP support the graphics the way it’s done now?
What would be the difference? The main reason for supporting both is the fact that flash sites don’t like Stage3D for advertising reasons. If nothing changes I’m sure it is fine. We just need some sort of switch.
If you’d like to contribute to FlashPunk, that’s great! Just fork the repo and submit a pull request when you’re ready for us to take a look at it.
I’m not really sure how Flash handles Stage3D without specific rendermode support. If it has an automatic fallback, that’s fine. If we just have two versions of the library (one software-rendered and the other using Stage3D), that’s fine, too. It’s also fine if you want to try to put it all in the same library.
Now that I’ve written it out, it wouldn’t be a terrible idea to have separate libraries targeting separate render modes, but it might make sense to have them in the same library to make using a software-fallback more convenient.
I’m thinking about doing something in the engine constructor like
public function Engine(width:uint, height:uint, frameRate:Number = 60, stage3D:Boolean = true, fixed:Boolean = false)
So you could enable/disable it easaly.
What do you think about it?
Changing parameter order is never acceptable, especially when the new parameter is the same type as the one it replaces. Consider:
super(640, 480, 60, true);
Right now this will create a new Engine running in fixed-framerate mode. With your new parameter added, it’ll instead create a new Engine running in variable framerate mode, with Stage3d mode enabled instead.
Backwards compatibility is crucial unless you’re explicitly changing the API.
Oh OK. I didn’t thought about that (I’m not used to make/change APIs ).
BTW, I have in hold a push request. Can i make another one or i have to wait until that one is resolved?
Edit: I did a new brach and reversed to the last commit before that modifications.
I have a general question regarding rendering pipeline in Stage3D. Will it (or does it in Stage3dPunk) allow to overwrite render methods and use net.flashpunk.utils.Draw.as?
There’s nothing to prevent the Draw class from working. It won’t be as efficient since you’re uploading vertices every frame (though that might be normal for Stage3d anyway), but it’s certainly possible. What I do in my C# engine is just add vertices for each line to an array every frame and draw that vertex array during the render step.
Overriding render methods should be possible too, and the API should be designed with the possibility in mind.
In Stage3D you have to upload the mesh every time (and also upload the program that the video card uses).
Another thing to be careful with is the fact that if two or more faces are in the same plane (in this case it is the plain z = 0) the first to render is the one that will be finally shown. That makes me think. Maybe i will implement a way to change the z so you can have different render priorities.
More a less. I’m making the code and i already implemented the layers but be able to modify a value for that directly may be a good thing to do (it’s a Number so can be used in mathematical functions). I have to create that variable anyway so allow the user to modify it isn’t that bad.
I would caution you against changing the API too much if you hope for this project to become part of Flashpunk proper. Including a z property in addition to the layer property is just being redundant; it would be far better to abstract render depth away and set z based on the layer.
Besides, there’s no good reason for the depth/z value to be a Number in orthographic rendering. All you need to know is if object A should be below object B, and integers work well enough for that.
BTW, I had to create a render3D function in the Graphic becouse how different it is. It also alows you to have a BitmapData and continue using the render function to render there. Is it OK?
Copying:
Thanks for working on the Stage3d version. This is just an “attaboy”. 3d is a bit over my head at this point. But I was wondering can you reuse any of the stuff from StarlingPunk? https://github.com/asaia/StarlingPunk
He did a ton of work but there are some basic differences. The sprite sheet was one of the major pains. I’m pretty sure for mobile having the assets on one sheet is better for performance but that means you need to buy software to make the sheets and corresponding xml file.
I’ll only add the stage3D initialization and render functions. Everything else will be exactly the same as our loved FP.
That would be so awesome if you could do that, Copying. FP would finally be up to date with things.
I’m currently using HaxePunk and it’s nice but there’s a few things that don’t work the way they should. (Screen smoothing currently doesn’t work properly in HXP, and I don’t know when they will get around to updating it.)
We’re talking about Stage3d and FP in the wrong topic. Created a new one for anything to say about it.