Add Drawable system interface in the engine; hide object sprite / texture preparation behind

[ivan-mogilko]

This is written after my own comment in an older ticket.

The code that gathers object textures for drawing right now is a bit too "open", and also duplicates a lot of things between different object types (character/objects and overlays for instance).

The idea is to create a Drawable system interface, separated from the runtime object classes, that would hide any manipulations to sprites and textures, and prepare a list of textures to render before passing into the graphics renderer.

1. Each runtime game object will register in the Drawable system and acquire a "drawable id". This "id" will connect this game object to its drawable representation inside the draw system. When to register is an open question, and the choice may be purely a matter of convenience. It may happen either when an object is created, or when the object is first drawn on screen.
2. Drawable system will maintain a persistent struct per a registered object, containing a uniform graphical data for each element. This is specifically important for software renderer, as it often requires its own approach to preparing a "texture". Right now there's a multitude of bitmap and texture arrays made for objects, characters, guis etc.
3. When we construct a scene, we run a list of game objects, and pass their graphical properties to the Drawable system (position, z-order, transformation, effects like tint, etc). What Drawable system does to these is not a game object's business after that.
4. The reason to why not have the same data inside a game object itself is to keep them as strictly "logical" structs, disconnected from the graphical implementation. This may have a benefit even if we finally get a proper class hierarchy for the game objects:
   • cleaner separate parts of code related to rendering;
   • less dependencies for game object classes;
   • easier to split processing into multiple threads.
5. Internally "drawable objects" may be stored in a vector, where elements are not erased, but invalidated (for performance sake). This would require to also keep a list of "free indexes", so that these gaps could be filled by new objects. The order of elements in such list is going to be undefined. The z-sorting is done separately, when preparing sprite batches and final texture lists for passing into the renderer.

 [ Game Object 1 ]                     [ Game Object 2 ]
 [ * drawable ID ] --------       -----[ * drawable ID ]
                          |       |
 [ list of drawables ]    V       V
 [  ][  ][  ][  ][  ][  ][x ][  ][y ][  ][  ][  ][  ][  ][  ][  ]
 
 
 
 [ list of drawables ] ===> [ z-sorted list of textures ] ===> [ graphic renderer ]

[ericoporto]

Uhm, I remember the GUI Control Slider has both a handle and the slider "rail" itself, if the drawable ID is meant to uniquely identify the drawable, it may be reasonable to imagine a game object may have more than one drawable - from what I remember only the slider has such a case. I don't know if this matters though, in the description it looks like things always happen in the same direction, it doesn't look like the reverse drawable ID to game object is necessary, so it should be alright.

[ivan-mogilko]

Perhaps in some future, but GUI controls are drawn whole by their own functions right now.