|
Viewing 1 to (30 Total) stage3D based drawTiles implementation (ALPHA) |
Total Posts: 11
Joined: August 12, 2012
|
After much confusion and frustration, I now have a working implementation of drawTiles that can use stage3D when published for flash 11.2+.
To use this class, you need to make a couple of changes - it's not a 'turnkey' solution - there are a couple of difference, due to the way stage3D works. The first thing is that you need to use the com.asliceofcrazypie.TilesheetStage3D class instead of the nme.display.Tilesheet class (for other platforms, it behaves identically to a standard tilesheet). Secondly (and most significantly), stage3D content is rendered underneath the standard display list, rather than it's depth being controlled with the graphics object as it is with the standard drawTiles implementation. The graphics object simply gets ignored. Whilst it is possible to render stage3D graphics into a bitmapData, which could then be drawn into the standard display list, the performance of this is catastrophically bad, and makes the whole thing pointless.
It also required the 'starling' library, which is available on haxelib (it was that or port the AGALMiniAssembler myself.)
Also, you will need to call the init method on the tilesheet object after instantiating it, which has one required method, stage - this must be a reference to the stage object. I'd recommend leaving stage3DLevel on 0, and antiAliasLevel currently gets ignored.
Next, you need to class the static method TilesheetStage3D.clear() to clear the graphics (clearing the graphics object does nothing to the stage3D content), and call the static method TilesheetStage3D.render() once you're ready to render the graphics to screen. Bear in mind that both these methods apply to ALL tilesheets, and only need to be called once to update all tilesheets. Here's a simple example:
#if flash11
TilesheetStage3D.clear();
#end
//put all drawTiles calls
#if flash11
TilesheetStage3D.render();
#end
As it says in the title, this is very much an alpha release. It's not been heavily tested, and I know it doesn't properly handle various errors, including the loss of the context3D when the user's machine goes to screensaver. Also, I've never done any 3D programming before, so it's possible that this is a pretty poor implementation (I don't know what's fast, what's slow, etc).
If anyone has any comments/advice, etc please let me know.
Tags:
Posted on August 12, 2012 at 10:26 AM
|
|
|
Total Posts: 218
Joined: September 15, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
That's very interesting! I'll definitely give it a try and write my expirience and suggestions
Posted on August 13, 2012 at 4:36 AM
|
Total Posts: 218
Joined: September 15, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
My first suggestion is to move from Starling dependency to HxSL (Haxe shader language). I'll try to help with it tomorrow.
The second proposition is to create repository for this project (on github, bitbucket or google code).
Posted on August 13, 2012 at 6:43 AM
|
Total Posts: 11
Joined: August 12, 2012
|
Re: stage3D based drawTiles implementation (ALPHA)
I'm not at all familiar with HxSL - I will take a look at this when I get a chance.
I have created an online repository on google code:
http://code.google.com/p/tilesheet-stage3d/...
Posted on August 13, 2012 at 8:44 AM
|
Total Posts: 85
Joined: November 19, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
This looks awesome, I'm currently using drawTiles everywhere in my application and my flash performance is quite poor at full screen. Hoping this will help. I'll try this out later this week and post my results.
Posted on August 14, 2012 at 9:39 AM
|
Total Posts: 2147
Joined: August 25, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
We have a compatibility script in nme.display.Tilesheet that helps provide drawTiles for the Flash target, but the performance is not ideal.
If the code for using Stage3D instead can be compact enough, and require few enough dependencies, this may be a good candidate for replacing our Flash-based implementation. Your work to support drawTiles on Stage3D could be integrated officially into NME when targeting Flash.
Posted on August 14, 2012 at 1:35 PM
|
Total Posts: 11
Joined: August 12, 2012
|
Re: stage3D based drawTiles implementation (ALPHA)
That would be awesome - I'd love to contribute to NME!
However, I cannot see any way to get around the limitations of stage3D that I described above (mainly needing a different clear method, needing a render() call and being drawn underneath the rest of the displaylist) - although it may be possible to remove the need for the init call.
Posted on August 14, 2012 at 2:18 PM
|
Total Posts: 2147
Joined: August 25, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
I can't see any way to get around the "underneath everything" limitation, either, but with a little bit of work, I think it could be alright.
I wonder if there is an easy way to tell if one display object is over or under another object? This would provide a hierarchy, so even if it is at the bottom, at least multiple drawTiles calls are layered properly. The position of each layer and scale could also be influenced by the parent display objects if that is taken into account with the native API.
What would the performance be like if you had a static Event.ENTER_FRAME loop, where each drawTiles call registered with a parent render method, which handled the layering, drawing and clearing automatically?
Posted on August 14, 2012 at 2:21 PM
|
Total Posts: 11
Joined: August 12, 2012
|
Re: stage3D based drawTiles implementation (ALPHA)
Ah, nice idea - I like it! That probably wouldn't be too slow, although I'm not sure how you would work out the depth in the hierarchy from a graphics object. I had considered automatically clearing and rendering using enterframe listeners, but wasn't sure if that was a good plan, as it wouldn't match the behaviour of the standard drawTiles - but it might be a good compromise,
Posted on August 14, 2012 at 3:02 PM
|
Total Posts: 2147
Joined: August 25, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
If you matched the object position and layering, it would be as close as we could hope to come to a single API.
Flash is based in 2D, so when they added 3D they created a separate context below the 2D rendering. NME is 3D, so there is no reason to create an artificial separation between the two.
If we felt there was an issue with full compatibility, we could still implement the drawTriangles/drawRect version as an option, but my feeling is that most people will migrate to the drawTiles API when they want to get the best performance possible. Having a Stage3D-based render loop would make a huge difference in bringing Flash closer to the performance NME enjoys on native targets. It isn't as good, but its as good as we'll get on Flash Player.
I suppose the layering could be determined by crawling up the display list, checking for common parents, and seeing where they diverge. Perhaps that could be cached somehow. I think most people use a single object to handle drawTiles calls, but this check would be nice.
Posted on August 14, 2012 at 3:48 PM
|
Total Posts: 261
Joined: September 08, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
Actually a correct direction would be to implement all (or most) of the Graphics API in Stage3D.
Posted on August 14, 2012 at 4:22 PM
|
Total Posts: 2147
Joined: August 25, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
That's an idea. Unfortunately, that complicates things because we are then looking to overwrite an existing API.
I think it would be a bad idea to automatically reimplement graphics objects into Stage3D, because of the unintended consequences. I also think it would be a bad idea to create a "Sprite3D" or "Graphics3D" class, since that would clutter the API for the native targets, which I think need to take first priority.
We have the benefit of a separate nme.display.Tilesheet class which gives us a clean opportunity to extend the functionality of Flash without stepping on one of the existing APIs. If we wanted to implement the standard API more fully in Stage3D, would it not make more sense to leverage Starling at that point?
Perhaps there is an option I am overlooking. I like the idea of providing an accelerated path for standard graphics calls, but unfortunately due to the inflexibility of Flash Player, I'm not sure if there would be a nice way to do that, without creating an optional third-party library to implement "3D" versions of standard objects.
Posted on August 14, 2012 at 4:31 PM
|
Total Posts: 2147
Joined: August 25, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
I apologize if the sound of the words I wrote above didn't sound warmer 
With Flash, we basically have an option between a new API call (like Graphics3D or drawTriangles3D) or divorcing ourselves from the standard Flash version of a class, and implementing our own.
When we try to implement a different version, we run all kinds of unintended problems ("Object 'Graphics' is not of type 'flash.display.graphics'")
I think that nme.display.Tilesheet is clean and adds nicely to the standard API, but I would hate to add the clutter of less elegant API endpoints, just to work around the limitations of Flash. Otherwise I love the idea of having all Graphics calls implemented.
Posted on August 14, 2012 at 4:36 PM
|
Total Posts: 2147
Joined: August 25, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
Wait a second --
I just had an idea. I learned recently that Haxe externs allow for inline methods. What if we overwrote the standard Haxe extern definitions for key Flash classes?
In the end, it would look something like this:
extern class Graphics { inline function drawTiles (...) {... } inline function drawTriangles (..., useStage3D:Bool = false) { ... }
}
I wonder if it would be possible to use an 'inline' method with the same name as a real method in Flash, then to call the real method inside our fake version?
Posted on August 14, 2012 at 4:39 PM
|
Total Posts: 261
Joined: September 08, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
I suppose it would be better to go with another API which can be effectively be translated into either Stage3D or drawTiles & co. That would be for 2D only obviously.
This API would be limited enough to be really crossplatform, and for instance the C++ implementation would draw everything in the root container's Graphics to match the constraint of Stage3D being in the background. The Stage3D side could certainly be dependent on Starling: the library is light enough and they did a good optimization job.
Posted on August 14, 2012 at 4:45 PM
|
Total Posts: 2147
Joined: August 25, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
NICE!
It works 
package flash.display;
@:final extern class Graphics { inline function drawRect (x:Float, y:Float, width:Float, height:Float):Void { trace ("Hello World!"); untyped this["drawRect"] (x, y, width, height); } }
Posted on August 14, 2012 at 4:47 PM
|
Total Posts: 2147
Joined: August 25, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
This could be very interesting...
http://www.joshuagranick.com/blog/2012/08/14/changing-the-flash-ap/...
Posted on August 14, 2012 at 7:32 PM
|
Total Posts: 548
Joined: October 07, 2011
|
Re: stage3D based drawTiles implementation (ALPHA)
Hi,
Yes, I think you maybe need to not think of it as a graphics method (nme implementation), a bitmap method (copy pixels) or a stage 3d method (new method). These are all implementation details. You need to take a step back and think of it as a "rectangular areas for drawing sprites". Then make a whole new class for this.
Possibly set the background (either nothing, because we know the tiles will fill the area, or solid colour or a bitmap or a display objects(for display object we can render-to-bitmap once)).
So rather than messing around forcing stuff into graphics.something, start fresh.
This is the gm2d.blit Viewport concept.
mViewport = gm2d.blit.Viewport.create(400, 300);
mViewport.worldWidth = 640*2;
mViewport.worldHeight = 640*2;
mViewport.x = 40;
mViewport.y = 10;
addChild(mViewport);
Now "addChild" assumes that viewport is a DisplayObject - for a stage, we could use something like:
mViewport.setReferenceObject(this);
In the nme/copyPixels case, this could be "addChild", but in the stage3d case, if could use the scaleX/xcaleY/x/y of this object to remap its viewport..
The rest of the api:
mMapLayer = mViewport.createGridLayer(grid);
mPlayerLayer = mViewport.createLayer();
mPlayerX = 48;
mPlayerY = 48;
mPlayerLayer.addTile(mTiles[3],mPlayerX,mPlayerY);
Makes no reference to graphics or copypixels or anything - developers do not care about these details.
Hugh
Posted on August 15, 2012 at 12:29 AM
|
Total Posts: 4
Joined: March 20, 2012
|
Re: stage3D based drawTiles implementation (ALPHA)
It's really awesome!
Posted on August 15, 2012 at 6:02 AM
|
Total Posts: 11
Joined: August 12, 2012
|
Re: stage3D based drawTiles implementation (ALPHA)
So, it seems this discussion has moved on a bit since I last posted - on the subject of a fully stage3D based display list implementation, I agree entirely with singmajesty, and I agree that the logical conclusion if we want a cross-platform hardware accelerated graphics API is to start from scratch.
However, from my point of view, the key question is - is it worth me carrying on work on my stage3D drawTiles implementation? I'm guessing it is, as any new rendering system is not going to appear overnight.
My personal priorities on this initially are making it stable, if possible simplifying the implementation and making it work as much like it does in CPP as possible. Also, as zaphod mentioned at the start of the thread, using HxSL would be good - Is there anyone who has any knowledge/experience of this that could lend me a hand? And finally, I suspect there may be some performance benefits to be had, but it would help if anyone with more knowledge of what's fas and what's slow could maybe give me some pointers.
Also, I don't think anyone has actually come back with any concrete feedback yet - I'd love to hear what peoples experiences using this are (even if it's 'didn't work'!)
Posted on August 16, 2012 at 5:39 AM
|