Performance

[rynti]

There seems to be some sporadic framerate issues with Rygal, especially noticable at the beginning when starting a flash target. I'm not sure if and how much Rygal is responsible for those issues, but they should definitely be checked out.

[rynti]

After playing a little bit around with NME and various targets, I found out that we should definitely implement different rendering systems for the various platforms.

Here is a diagram of a benchmark I ran with the different drawing techniques on the targets Flash and Windows:
http://d.pr/i/1FlC

Finally I came up with 3 major rendering systems to allow maximum performance on all platforms:

• The current system (Using copyPixels) for the flash target
• Display lists for HTML 5
• drawTiles for Windows

After those systems are implemented, we can test further platforms and see what's running best on them.

Now I'd like to go a little bit more in detail about the rendering systems:

copyPixels

This is the current rendering system. It uses "blitting" to display objects on screen, which means Rygal creates one bitmap that has the size of the game and every texture/sprite gets drawn on that bitmap. This method is a little bit faster on Flash than the traditional display lists, it however has the disadvantage that it can't handle rotation.

Display list

This is the default rendering system of NME (And Flash). It basically consists of display objects that can be added to the stage, thus being drawn there. To implement this system in Rygal, one would have to rebuild the DisplayObject-hierarchy inside the GameObject-tree (Which is quite similar to the default display list model), so for instance a Sprite contains a hidden nme.display.Bitmap that will be added to the stage as soon as it gets added to the game. This is the fastest possible way of drawing in HTML 5 and has the advantage of being able to transform (Rotation, scale, etc.). It's however not able to use correct zooming (When tranforming), as rotations may result in "subpixels", so for instance in a game with 4x zoom (So one game's pixel consists of 4x4 visual pixels) where there is a sprite that is rotated, the pixels of the sprite may not always fill one whole "game-pixel", which looks quite bad in Pixelart-games.

drawTiles

NME introduces the class Tilesheet that may be used for drawing a spritesheet. However, it has one particular method that revolutionized performance in NME: drawTiles. This is a single method that is able to draw an arbitrary number of tiles from the spritesheet. It takes an array as a parameter where are all target positions, accompanied by optional transformation data. It is able to draw ridiculously fast on C++ targets like Windows, thus being the most useful performance enhancement.
There are, however, two disadvantages about this method:

1. It's not able to draw multiple textures in a single run of drawTiles, thus it's creating a few problems about correct draw order. To solve this problem you'd have to call one drawTiles per objects with the same texture that are directly behind one another. As this may decrease the performance, maybe a way for the programmer to declare specific game objects to have an important draw order so it will only use that more complex way of drawing tiles when really needed.

   Another way of making sure that drawing order is always correct would be to use one single texture for the whole game. This way, drawTiles would only have to be called once thus increasing the performance even more. This could be either done by the programmer himself (Using a prebaked TextureAtlas) or such a TextureAtlas could be generated in runtime by Rygal. The latter one however may be too slow when the game is using too many textures. It would also have to recreate the atlas as soon as a new texture is being used or an old one is being removed.

2. It may be difficult to implement this in the current GameObject-tree-structure. A possible way would be to let Canvas have an internal manager for those Tilesheet-things.

[rynti]

Even more performance increase would be gained when using Stage3D on the flash target, let's see if we could implement that as well.

[aduros]

It might help to look at Stage3DDrawingContext and BitmapDrawingContext in Flambe. DrawingContext is an interface that appears to be equivalent to Rygal's Canvas.

[rynti]

Gonna implement the drawTiles method soon as it will hopefully reintroduce HTML5 support as well:
https://twitter.com/singmajesty/status/267318860506607616