Persistent "render data" for each drawable object in game

[ghost]

Right now engine gathers drawing lists on each render pass.
See: prepare_room_sprites, add_to_sprite_list, add_thing_to_draw, put_sprite_list_on_screen, and so on.
As you may notice, there are actually two or three separate lists, and data is passed between them before finally sent into GraphicsDriver using virtual DrawSprite call per each item.

This is relatively not slow, but still extra work done each frame, which is often redundant, because it will likely have to draw same sprites again next frame.
The only benefit of this seems to be that it's guaranteed to be always up-to-date if any of the sprite property changes.

Similar thing is done to "sprite batches": they are reinitialized each frame from scratch.

I propose to consider instead have a uniform "render data" struct per each drawable object that would contain:

• DDB (texture);
• sprite's transform
• any additional render properties.

Such struct may be either a part of game object struct, or a separate data, whichever is more convenient. But it has to be persistent, and put into the persistent render list.

• added to render list when object becomes visible; alternatively: added when object is created but has a flag telling whether it is enabled;
• removed from the list when object becomes not visible; alternatively: set flag when it simply gets invisible, and remove only when object itself is removed from the scene.
• ideally, the list is structured in such way that it can be passed into the GraphicsDriver class without any modifications.

Sprite Batch configuration may also be made persistent. As batches correspond to the render layer, such as room viewport, ui layer, etc, such layers may have linked render data structs, and treated as "drawable objects" as well.

If #967 is implemented, this is going to be not a list, but a tree, or array of arrays. (Actually, it may be array of arrays anyway, because of the sprite batches)

IMPORTANT: as this data is assumed to be persistent, engine has to correctly update it when game object's image changes.

[ivan-mogilko]

A while after writing the original ticket, it's yet not clear for me whether it's a good idea to make a persistent list passable into the graphics renderer directly, with persistent sprite batches (nodes), and so on.

But I'm certain in regards of having a separate and persistent "drawable object" for the drawn game elements. Having such data struct would solve two problems:

1. Having a uniform graphical data for each drawn 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. If all necessary data (temporary buffers etc) would be contained in one place and handled same way, that would reduce code duplication and make maintenance easier.
2. Not placing such data into the "game object" classes, will keep them strictly "logical" structs, disconnected from the graphical representation.

This list of "drawable objects" could be a simple std::vector, extended as necessary. The game classes would only have a trivial reference to the list's element, preferrably just an index. When the game object is about to be displayed it is assigned a drawable's list element. This vector's elements are not erased, but marked as "unused", so to keep all the indexes intact. The next game object will be assigned a first found free "drawable object".
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 ]

[ivan-mogilko]

Closed in favor of #2628