I’ve been thinking about 2D rendering APIs every now and then, and I
usually come to the conclusion that if you want more than the SDL 1.2
2D API, you’re better of using OpenGL. (If you’re into massive
blending and transformation effects, and don’t care much about non
hardcore gamers running MS Windows, I still maintain this position.)
However, using OpenGL as the rendering API for a "mostly 2D"
application has several issues;
* OpenGL is not the safest bet for 3D acceleration
on all systems. Some operating systems favor other
APIs, and there are 3D accelerators for which there
are no OpenGL drivers. Implementing OpenGL over
other 3D APIs has proven to be far from trivial, and
AFAIK, there are no seriously usable Free/Open
Source, or even free-as-in-beer solutions at this
point. (Any progress here lately?)
* OpenGL is not available at all on some platforms -
even some that provide some, but not all features
that are more or less required for accelerated
OpenGL. (Consoles and handheld devices, mostly.)
* OpenGL is overkill if you basically just need a
supercharger on the rendering backend of the SDL
1.2 2D API.
* Software OpenGL implementations are usually
(always?) too slow for real time applications -
especially on the low end systems that tend to be
the ones lacking hardware accelerated OpenGL! The
OpenGL API is not designed to support the shortcuts
that custom software rasterizers for games need to
take to achieve playable frame rates. Meanwhile,
most of these shortcuts aren't even relevant to
"mostly 2D" applications in the first place.
* Implementing a "mostly 2D" application directly
over OpenGL can result in an application that is
hard to adapt to software rendering, or less
advanced (than OpenGL) accelerated rendering APIs.
(Of course, any porting job is complicated when
hard to implement features are missing on the
target platform...)
What I’m thinking is basically something like a subset of OpenGL,
aimed at 2D rendering with basic transforms and blending. Like the
current SDL API, it should be easy to understand and use, and
(relatively speaking) easy to implement in software as well as over
various 2D and 3D rendering APIs.
An alternative to building higher level features into the SDL API to
allow the backends to accelerate them, is to provide a generic
"Backend Extension Interface", so that add-on libraries can plug into
explicitly supported backends to cooperate with them more intimately.
However, I’m worried that such a solution would do more harm than
good;
“I’m using SDL_PrimitivesA which works great with
OpenGL and software - but I need to use the API
incompatible SDL_PrimitivesB instead to get
acceleration with Direct3D!”
Maybe it’s better to just agree on a feature set, implement software
fallbacks for it, and then keep any accelerated implementations
inside SDL. Full acceleration could actually still be provided by
plugins, to keep the main SDL lib lean and mean, but I have a feeling
it’s not worth the effort.
I was inspired to write this part because I’ve found various extended
versions of glSDL/wrapper with rotation, scaling, accelerated drawing
primitives and whatnot. Stuff that isn’t too hard to implement in
software, and that is trivial to implement over OpenGL, Direct3D and
probably some 2D APIs. Stuff that is pretty much mandatory these
days, when most 2D games are implemented directly over Direct3D, and
even casual gamers expect the kind of look and feel that fully
accelerated 2D can provide.
(The vast majority of these games are developed using various RAD
tools with integrated support for Direct3D, and in some cases, Linux
and/or Mac versions that transparently use OpenGL instead. However,
these tools are not Free/Open Source, and many developers don’t care
much for the language most of these tools use: BASIC. Also, it can’t
be right when the Free/Open Source community is missing something
that is considered standard in the rest of the world. 
That is, now there are applications that either rely on OpenGL to run
at all, or have separate backends for “plain” SDL, but still use a
slightly extended version of the SDL 2D API when rendering through
OpenGL.
Technically, this could be classified as abuse of glSDL/wrapper, as in
"They should be writing their own, proper OpenGL wrapper instead!"
However, I believe it is more useful to take this as a hint as to
what programmers expect from a 2D API today.
The current situation with the new SDL 1.3 backends, various versions
of glSDL/wrapper, people writing their own 2D layers over OpenGL
and/or Direct3D etc is causing confusion, duplication of effort and
portability issues. Now I’m headed there myself, trying to decide
whether to rely entirely on OpenGL, implement support for both OpenGL
and Direct3D and perhaps a software fallback, or maybe investing that
time in SDL 1.3/2.0 instead, or…?
What are the plans for the 2D API of SDL 1.3 and/or 2.0?
//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 --’
