[SDL] SDL 1.3 and rendering API state management

David Olofson david at olofson.net
Sun Sep 3 10:53:41 PDT 2006


On Sunday 03 September 2006 19:34, Torsten Giebl wrote:
[...]
> I can image a plugin system like in XMMS, GIMP or other apps.
> But it is hard for me how such a system could be used in SDL.
> 
> How is the state problem solved here ?

State is really only an issue when multiple independent "actors" 
manipulate the same context of a state machine style API.

If you run both an SDL internal renderer and a bunch of add-on library 
functions over the same OpenGL or Direct3D context, the problem is 
that you essentially have two "plugins" running in parallel, trying 
to output to the same "device".

Most of the time, however, plugins run in series with the backend, 
and/or other plugins, and shared resources are accessed through 
interfaces that are designed for concurrent access (unlike OpenGL and 
Direct3D), so this situation is avoided.


> I look at how SDL inits the states
> and copy these settings in my code ?

Only if you're going to implement a new renderer over OpenGL or 
Direct3D. As long as you can do what you need without bypassing SDL, 
you're fine just using the SDL API.


> What about people that do not use 3D ?

They just use the core SDL 2D API. ("opengl", "d3d", "software" and 
other renderers.)

Or, if they want polygons and stuff, they pull in SDL_Advanced2D and 
set up the display with one of the extra renderers provided 
("a2d_opengl", "a2d_d3d" and "a2d_software"). Then the core SDL API 
works as usual, but there are a bunch of extra rendering calls 
available as well.


> What about bugfixes in the SDL code ?

Well, tough luck! ;-)

If you're maintaining an extended SDL renderer, you get to maintain 
some 200-400 extra lines of code per supported target API. OTOH, you 
don't have to track subtle changes in the renderers in the SDL core 
to ensure that your extended renderer still works with each new 
version of SDL. If your renderer works, it works, period.

So, this might actually make maintenance *easier*. Slightly more code, 
but it's all yours, and there's no one else randomly fiddling with 
your target context.


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'




More information about the SDL mailing list