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

[David Olofson]

On Tuesday 15 August 2006 16:20, Stephane Marchesin wrote:
> David Olofson wrote:
[...]
> > 	* 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.

Well, it's certainly better than no OpenGL at all, but it still means 
OpenGL applications will run at half speed compared to native 
Direct3D applications (according to the rumors... Any facts here?) 
unless the user installs real OpenGL drivers.

Though this is certainly better than "Doesn't work!", it doesn't 
exactly make me feel good about relying on OpenGL when the major part 
of the potential user base is on Windows.


> > 	* 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 ?

Not long, I suppose, provided these high end handheld 3D devices 
really catch on...


[...]
> 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.

Certainly sounds like a better idea than inventing yet another 2D API. 
A backend like glSDL would probably be able to use something like 
that with minimal changes.


And... Next thought: Is there some "2D" OpenGL subset like that 
around, that comes with a Free/Open Source wrapper for Direct3D? (A 
software fallback implementation over SDL wouldn't hurt either, 
though...)

Providing that as a built-in or add-on OpenGL substitute for "advanced 
2D" for SDL might be a better alternative than extending the SDL API 
halfway to 3D... The obvious advantage is that it already *is* 
OpenGL, so it'll Just Work(TM) if you load a real OpenGL lib instead, 
and it would be very easy to "port" an application designed for the 
subset up to "real" OpenGL if desired. And it would probably be 
slightly easier to scale an application down from full OpenGL to the 
subset, than porting it to a different API.

Maybe I just need more caffeine, but this OpenGL subset idea almost 
makes sense to me... ;-)

Well, the obvious disadvantage is that people would still have to 
learn (some of) OpenGL even if they just want to do "advanced 2D". 
And the SDL API is already there, it's easy to learn, is very handy 
for off-line and background software work, and only needs a few minor 
extensions. So... Which way makes most sense?


[...]
> 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...

I think OpenGL and Direct3D will cover the vast majority of systems, 
including some of the latest consoles and handheld devices.

I'm not sure about those not covered by these APIs, though... Some 
platforms are not really viable targets for SDL anyway, because they 
don't allow Free/Open Source software. Others don't provide anything 
of interest that can really be squeezed into a portable API. 
(Hardware sprites and multilayered hardware scrolling displays with 
blending, for example.)

Now, if we're going to somehow provide a portably "advanced 2D" API, 
it probably doesn't really matter much if we change and/or extend the 
SDL 2D API, or define a subset of OpenGL - it's just an API either 
way. Either one will work just fine with both OpenGL and Direct3D. 
Either one will be about as easy/hard to implement in software. It's 
mostly a matter of ease of learning, ease of use, ease of porting 
to/from other APIs and things like that.

Now, OpenGL might not be very suitable for fast software rendering, 
but a 2D oriented subset is a quite different matter. Even though the 
API appears to be the same, an implementation of a 2D subset can 
assume lots of things that a full 3D implementation cannot. So, maybe 
it's not that bad, after all, even considering a software fallback 
requirement...?


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