2d game: optimal performance and right SDL usage?

Hi guys,

I’ve more or less completed the concept phase of my little game and get a proof of concept with SDL2 on the screen. However, I followed different tutorials to get there and the code is not really clean. More important I still got SDL methods mixed, like Surfaces and Textures. I noticed that by my current use I’ll probably get performance problems once I draw a lot mire, so I better sit down on my bum now and get it right.

Currently I have one surface where I blit all the sprites in their right animation phase to. A Google search hinted at using “streaming textures” for things like sprites that change in every frame.

Could someone please confirm or deny that this is the right way to do it and I got it right:

 Stop using surfaces alltogether and use textures. By this way I will use hardware acceleration and video ram.

 Using textures and SDL_RenderPresent will automatically use double buffering and switch between buffers.

 Have one "normal" texture for static elements like playing field and static UI elements

 Use streaming textures for changing elements like sprites and changing UI elements like numbers/status

 Assemble everything to one big texture with SDL_RenderCopy and then use SDL_RenderPresent

Is this the right way to go?

Thanks and regards

[…]

Stop using surfaces alltogether and use textures. By this way I will use
hardware acceleration and video ram.

Yep. (IIRC, surfaces are now all software at all times, with no
locking, so rendering them to anything will invariably require them to
be uploaded for each blit.)

Using textures and SDL_RenderPresent will automatically use double buffering
and switch between buffers.

Yes.

BTW, you should probably use the SDL_RENDERER_PRESENTVSYNC flag as
well. Basically, the only time you shouldn’t use vsync is when
you’re not expecting your game to keep up with the display refresh
rate (typically 60 Hz, but can be 120 or higher on a gaming screen),
and feel that tearing is better than dropping all the way to 50% of
the refresh rate.

Have one “normal” texture for static elements like playing field and static
UI elements

Might be an idea to split it into multiple textures if there are large
transparent areas. Modern GPUs optimize alpha rather well, but there
may still a per-pixel/texel cost, even for 100% transparency.

Use streaming textures for changing elements like sprites and changing UI
elements like numbers/status

Not generally! Unless you’re actually doing live software rendering,
you don’t actually modify the sprite textures. You just switch between
frames stored in separate textures, or in “palette” or "atlas"
textures, where you select sprite frame using the source rect.

The same typically goes for text, numbers etc - though if there’s a
lot of that, it might be worthwhile to “cache” it in a streaming
texture.

Speaking of streaming textures, you may want to look into
SDL_SetRenderTarget() to get that hardware accelerated, but keep in
mind that that’s not always supported, and it’s not necessarily faster
in every use case! For example, if you’re doing lots of plain blits,
single pixels or similar, the SDL software renderer, or custom
software rendering code, may well be faster, despite the texture
upload overhead.

Assemble everything to one big texture with SDL_RenderCopy and then use
SDL_RenderPresent

Well, sort of - except the normal (display) target of SDL_RenderCopy()
isn’t really a texture, although it sort of actually is, on the
driver/GPU side. Terminology nitpick. :-)On Tue, Aug 4, 2015 at 12:07 PM, Murenius wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

Thanks a lot for this answer at length! I’m much more motivated refactoring all that code now that I know the direction is right :slight_smile: