Re: stage3D based drawTiles implementation (ALPHA)

Hi,

Glad it's working for you, and getting it on haxelib is great - that's something I've been meaning to look into for a while, I will definately check that out - thanks!

One question: is there any reason that it doesn't support drawing on nme.display.Shape and only work with sprite?

Do you think it is possible (and a good idea) to use the graphic (provided to drawTiles) element's position, rotation, scale, blendmode, etc. to alter stage3d calls?

Re: stage3D based drawTiles implementation (ALPHA)

thanks for that - I have just made the fixes you have pointed out, and will be checking them in shortly.

As for not working - I'll PM you with some questions.

Re: stage3D based drawTiles implementation (ALPHA)

So, I think I'm ready to call TilesheetStage3D beta. I have made several changes to improve performance, made it gracefully handle context loss, and done as singmajesty suggested earlier:

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?

Re: stage3D based drawTiles implementation (ALPHA)

I've just committed an update to the google code repo that has some changes. Firstly, I've re-arranged the structure of the repo to have a samples directory, and added a simple sample of the drawtiles in action, implemented to work cross-plaform.

I have also made some behind-the-scenes changes to allow some further changes (such as handling loss-of-context errors) in future. But the main difference is that you no longer have to call the init method on every spritesheet that gets created - there is just a single static init method This method can optionally take a callback argument, which gets called once the stage3D initialisation has completed. You currently cannot create a tilessheet (in flash11) until after this initialisation has been done. I believe it will be possible to 'hide' this slight delay were this to be integrated into NME as a whole, meaning this would no longer be required.

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'!)

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,

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.

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/...

Re: Stage3D support for cpp target

If anyone is interested, I have approached this problem from a different direction, and have written an implementation of drawTiles that in flash uses stage3D for the rendering. This gives an (almost) completely consistent approach to getting hardware accelerated graphics rendering across almost all platforms. More information, and the source can be found here:

http://www.haxenme.org/community/forums/general-discussion/stage3d-...

stage3D based drawTiles implementation (ALPHA)

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.