[SDL] SDL 1.3 and rendering API state management

[David Olofson]

On Monday 04 September 2006 21:29, Antonio SJ Musumeci wrote:
> My thoughts exactly. Xorg, GStreamer, etc don't provide plugin 
> interfaces for the developers health. SDL provides cross platform, 
> video/audio output (and possibly input) API. Hiding away valuable 
> hardware capabilities is a complete waste of resources. Who cares if
> you use an accelerated backend if all you can do is standard blits.

Anyone who needs some serious frame rates in higher resolutions? ;-)


> Alpha blending, rotation, scaling (or simple geometry drawling)...
> those are all basic things done in just about every game in the last
> 10 years. Why must you jump through hoops or reinvent the wheel to
> use them in SDL?

Well, that's exactly my point.

I'm implementing a rendering API suitable for 2D by modern standards, 
that will render over OpenGL, Direct3D and a software rasterizer. I'm 
doing this because there is no way, ever, that I'm going to have 
Direct3D code in my actual application code if I can help it (it's a 
hack for a single platform that I hardly use), and because I want to 
keep commonly used low level rendering code in one place, accessible 
through the same API.

Nice and handy and generally useful for all sorts of stuff in the now 
so popular gray zone between 2D and 3D? Well, if it won't be, I won't 
have much use for it either...! :-D

Now, I can just hack my in-house rendering lib directly over OpenGL 
and Direct3D, and be done with it. This is the standard solution for 
SDL 1.2 applications that do 2D over OpenGL. (A few use 
glSDL/wrapper. Most don't support Direct3D.) My rendering lib would 
not be able to run over the SDL 1.3/2.0 "opengl" or "d3d" renderers 
(so SDL 2D calls won't work), nor would it be able to use SDL managed 
textures. When used, it becomes the only way to access the display, 
maybe short of the 3D API it's currently using for rendering.

Alternatively, I can try to make this lib integrate nicely with SDL, 
so people can use it as a rendering API extension for SDL, without 
essentially replacing/breaking the standard SDL video subsystem. Same 
features, same performance, same everything - except code that uses 
the standard SDL rendering API still works.

To me, the difference is minimal, as I'll have to implement everything 
that the SDL 2D renderers do anyway, and then some, so implementing 
SDL_RenderFill(), SDL_RenderCopy() etc would be trivial. I might even 
save some work by having SDL set up the display and manage the 
textures.


//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  --'