[SDL] SDL 1.3 and rendering API state management
david at olofson.net
Mon Sep 4 15:06:02 PDT 2006
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
//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