[SDL] SDL 1.3 and rendering API state management
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
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