Every game needs to render graphics. The Rendering2D package that comes with the GameBuilder Engine is a simple rendering framework designed to let rendering components coexist.
The rendering architecture is built on two halves. The first half is the scene and the second half is the spatial manager. These halves are independent. You can use either, one, or none in your game.
The spatial manager provides a way to place objects in space and perform queries on them. The scene lets you place and draw visual objects like sprites. Scenes also support some queries, mostly the ones needed in order to implement picking.
Bitmaps vs. DisplayObjects
At the fundamental level of Flash graphics, there are two ways of displaying graphics to the user. The first is to create an individual DisplayObject to represent each "sprite", or moving graphic, on the screen. The second is to create a single BitmapData canvas that you draw ("blit") all of your other images to each frame. There is no one "right way" to do this, so Rendering2D is flexible enough to support both. DisplayObjectScene lets you use DisplayObjects, and BitmapDataScene composites to a Bitmap. When you are using a BitmapDataScene, there is a direct copyPixels based path available to objects that implement the ICopyPixelsRenderer interface and it will automatically convert it to the right kind of output. See ICopyPixelsRenderer.
GPU Rendering via Starling
There is now a new way to render objects in flash and it is via the new stage3D apis. We decided to use the open-source Starling framework which is very similar to the original flash display list. All GPU renderers in the GameBuilder Engine extend from the Rendering2D package but have a gpuObject on them. This is the internal Starling renderer that is used to render a texture to the GPU. We want to keep consistency with all existing apis and just add a GPU rendering layer to the engine. All Rendering2D classes are mirrored in the new Starling2D package with just "G2D" at the end.
So if you just search and replace all of your existing renderers and add "G2D" all your existing code should work right out of the box.
Modifiers and filter effects have been disabled for GPU renderers for now but we will be integrating that functionality in the future as well.
Draw Layers And Sorting
An important part of the rendering architecture is the draw layer system. Each renderable component is required to implement a property called layerIndex, which controls on which draw layer it is shown. This allows manual control of sorting, by grouping drawable items onto overlapping layers. Layers are drawn in ascending order, starting with layer zero. This means that anything on layer 0 will be on the "bottom", and things in higher layers will be drawn on top of lower layers. There can be any number of layers, and they do not have to be contiguous (ie you could have only layers 0, 1, and 10).
For example, in a platformer, you might assign layer zero to distant background elements, layer one to nearer background elements, layer two to platforms in the world, layer three to powerups, layer four to enemies, layer five to the player, and layer six to feedback elements like scores or damage effects. That's just an example; you can use layers however you like.
DisplayObjectScene implements no intra-layer sorting by default. The draw order of two items in the same layer is undefined. You can implement your own sorting by specifying a sort function on the layer's drawOrderFunction field.
**Note: In GameBuilder studio you can assign multiple renderers to the same entity on the same layer. If you want to specify the order in which those renderers are drawn you need to change the renderOrder property on the DisplayObjectRenderer which is a secondary sort for renderers on the same layer.
How Rendering Works
The rendering process is very simple. At the start of each frame, the DisplayObjectScene sorts its layers, then each layer has the opportunity to update the draw order of its renderables. The DisplayObjectScene uses DisplayObjects and Flash's renderer to display the scene, so finally any necessary changes are pushed into the DisplayObjects on the stage.
If you are using the BitmapDataScene, then the main difference is that drawing is done manually onto the BitmapData using the BitmapData.draw method. In addition, renderable objects can optionally implement the ICopyPixelsRenderer interface, in which case they will be called every frame to draw themselves onto the BitmapData.
Implementing a Drawable Component
Any component which wants to be drawn should inherit from DisplayObjectRenderer or one of its subclasses.