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

[Stephane Marchesin]

David Olofson wrote:
> 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?)
>
>   
Microsoft will be shipping their highly criticized "opengl-over-directx" 
in windows vista. I see this as some form of progress.

> 	* 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.)
>
>   
How long before all these devices feature OpenGL-ES ?

> 	* 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...)
>
>   
There was the recent Xglx buzz, and the issue that some drivers had no 
OpenGL acceleration at all (and sometimes the hardware is not able to 
provide it) was raised. One possible solution that was proposed was 
providing some "2D only" subset of OpenGL which only accelerates the 
minimal requirements for 2D usage.

> 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.
>
>   
I guess the real question is then "how many systems are there out there 
with hardware accelerated 2D rotation/scaling/whatever, but no 
OpenGL/Direct3D support ?".
If these end up being a fair amount, it might be worth designing an API 
for that use. Otherwise, layering on top of these 2 APIs is sufficient...

Stephane