[SDL] 2D API evolution (SDL 1.3/2.0)

[David Olofson]

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