SDL2：渲染引擎​​设计

Question

I am creating simple game rendering engine based on SDL2 library. My design looks similar to this ASCII graph.

DrawTarget     RenderTarget
    |                |
    |                |
    +---> Window <---+

DrawTarget is an abstract class for draw target suitable to SDL_Surface blitting. RenderTarget is and abstract class for render target suitable to SDL_Texture. Window is derivated class managing SDL_Window, SDL_Renderer and all draw and rendering functions.

Renderable
  |  |  |
  |  |  |
  |  |  +-> Player
  |  |         ^
  |  |         |
  |  +----> Animation
  |            ^
  |            |
  +-------> Texture

Renderable is everything, which could be rendered to the screen or another RenderTarget. Texture is SDL_Texture implementation. Texture should not know its own position. Animation has a private Texture member allowing set up of animation frames. Animation itself should not known the render position. Player has a private Animation member. Player should know the current position.

In this time, I have one SDL_Renderer per window and pass it all around Textures, Animations etc. Texture is with knowledge of SDL_Renderer render itself to the screen. But I do not think calling Texture->draw( x, y ) all the time is efficient and cache friendly.

I like the way SFML renders. All renderable object have draw method, which just calls the window's draw method. I would like to implement similar system.

This will break my requirement some Renderable objects know their render position, some do not.

For example class Player should not have render( x, y ) method, because it knows its position. On the other hand, Texture class should not have render( void ) method, because it does not its position.

My ask is following: How to design SDL2 suitable render engine with as little overhead as possible?

Answer 1

Answering your question of: "My ask is following: How to design SDL2 suitable render engine with as little overhead as possible?"

A quick explanation of a scalable, lazy renderer scheme for minimizing SDL2 renderer overhead:

A "layer" consists of all the textures that have the same z attribute. Layers are marked as invalid whenever a texture in that layer is modified. Layers are managed when the renderer runs, which is at a set framerate. The max layer and the highest invalid layer are kept track of. The renderer starts at the highest invalid layer and ends at the max layer. Each layer is set as the renderer target and cleared. The previous layer is then copied to the current layer. Then it iterates through each texture in the layer, redrawing those marked invalid, and copies each texture on top of the current layer. The result is that the previous layer is the background while the current layer drawn on top of it. This texture is cached and invalidated when the layer is marked invalid. After running through any invalid layers, set the render target back to default (null), copy the highest texture to the screen, and present.

In a 2d with layers user interface type of environment, the above is scalable and lazy. On my low end Celeron n2830 my test applications idle at 0% cpu usage. It more or less stayed that way even when I added a hundred test layers. Since it only draws from what layer changed upwards, and all changes are enqueued at a reasonable framerate, very little work actually ends up being done. Iterating through the invalid layer to the max layer appears asymptotically friendlier then iterating through all layers every run. Running the renderer at a set interval and doing all the drawing then helps to save time because it will ignore excess changes that wouldn't have been seen anyways. It's been worth it to use some application code to avoid having to draw stuff and copy textures. Those tend to take longer then a few if checks and attribute lookups.

note that this design was intended for 2d with layers, like a user interface. some principles may not neccessarily work well in other environments.

Also the above only supports textures and not surfaces. Mixing the two was for me not worth the complexity. Getting the sdl2 renderer to draw to a particular texture took some figuring out, but serves my needs well enough alone. If you mix the two it appears difficult to avoid some additional work. Plus textures benefit from a gpu, which adds to efficiency wins in terms of cpu time.

In my system, window objects have a draw method. This method enqueues draw operations with the renderer instead of drawing them immediately. Window objects have an area attribute. To support objects that do not have an area attribute, maybe you could apply a wrapper that does around your object that does not. That way when prompted for an area it can still provide one, even though it doesn't have one internally. Or maybe use a table that maps your object to an area, or a method call of whatever object does track its texture. I'm not sure of the nature of that limitation.

Note that this draw method is a hybrid approach of objects drawing themselves and the renderer drawing objects. The objects appear to draw themselves, while the renderer actually does the work.

In short:

• textures are signficantly faster then surfaces
• enqueue draw and copy operations for batch processing
• cache textures when they are drawn
• cache layers after copying all textures to them
• use the caches to avoid rendering all but the invalid layers to max layer

Answer 2

It seems to me what you are saying is that you want entities to only know their position, but for rendering you want it to be completely separate. Every entity will need to store some kind of rendering data. I would say you should look at a component based entity system. There are different classes for position, renderdata, input etc. Try Component Based Entity System