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

[David Olofson]

On Tuesday 15 August 2006 19:43, Sam Lantinga wrote:
[...]
> > 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 ?".
> 
> Very few, unfortunately.

It would be interesting to have a rough idea of the figures here. Most 
platforms have one or more of these limited 2D backends, but how many 
of the systems completely lack accelerated scaling, rotation etc?

How large a percentage of the potential entertainment/multimedia user 
base are still using such machines now? (Perhaps one should also 
consider that people who really can't afford, or don't care, to 
upgrade their computers probably aren't as likely to buy commercial 
games either. So, if you're trying to sell something, is there any 
point in considering these users at all?)

What's the situation going to be like in a year or two?

Before deciding what is worthwhile and what isn't, one should probably 
at least try to get some idea of the value of full or partial 
software fallback performance in terms of potential market share.


Now, if we forget about the commercial side of things, and just aim at 
having SDL 1.3/2.0 run on "anything", is this *really* something that 
has to be desided/dictated by SDL? Or can it be left to developers to 
decide which features to require on a per-application basis?

I would say, yes!

Theoretically, SDL 1.3/2.0 doesn't even have to implement the most 
advanced features in all  backends. That said, even a dog slow 
quick'n'dirty software fallback is a lot more useful than nothing at 
all, and not all that much work to implement, and can be improved and 
optimized later on, so I don't really see a valid reason to step away 
from the "all features must be implemented" requirement. Just saying 
it might not be the end of the world to change the rules a little.


> If any of you have been following the SDL 1.3 API redesign, you'll
> see that I've been wrestling with these issues myself.  As David
> mentioned, the basic question comes down to:
> 
> What features are expected in today's 2D API, and at what point is
> it easier to simply use use 3D instead?

Although one cannot completely disregard the implementation side, I 
think Bob Pendleton pretty much defines the metric here:

	"The value here is that you spend most of your time
	 using the API, not learning the API. This is very
	 important to those of us who want to spend out time
	 writing applications rather than spending our time
	 reading yet another set of documents."

I suppose the current situation with OpenGL vs Direct3D, we cannot 
disregard the fact that some people will have to learn and use not 
one, but *two* 3D APIs, when they exhaust the capabilities of the SDL 
2D API.

Regardless, there is quite a step from SDL 2D to either of OpenGL or 
Direct3D. Keep in mind that many developers have no experience with 
3D graphics at all, so it's not quite as simple as "just use OpenGL 
or whatever you prefer".

Of course, one can always counter that with various "if you want to 
make money" and "bleeding edge" cliches, or just blaming stupid users 
for not installing proper drivers, but I don't see how any of that 
improves anything for anyone. I thought the idea was to simplify the 
development of multimedia applications... If you don't want that, why 
use an intermediate library at all? :-)


> My focus with SDL 1.3 has been to redesign the API to take advantage
> of 3D hardware acceleration, while providing a feature set that is
> still fast using existing 2D APIs.
> 
> Here are a set of useful features, and whether they're fast or slow
> in different environments:
> 
> Feature:        3D hardware:    2D hardware:    2D software:
> Pixel Upload    Slow*           Slow            Fast
> Copy Blit       Fast            Fast            Fast
> Alpha Blit      Fast            Impossible*     Slow
> Scale Blit      Fast            Impossible*     Slow
> Rotation        Fast            Impossible*     Very Slow
> 
> * With some exceptions, depending on hardware and drivers
> 
> I've taken the approach of supporting the first four features, since
> they can be implemented relatively fast on existing 2D drivers, and
> are blazingly fast on today's 3D hardware.
> 
> The entire design is flexible, at this point, but the focus is to
> keep things fast and simple.

Any particular reason why the line is drawn between "Slow" and "Very 
Slow"? (I mean, that is really rather relative...)

I really rather like the idea of having something like 2D quads. :-) 
Rotation and various other distortions can be implemented over this 
as conveniency functions, so an explicit rotation feature isn't 
really needed, I suppose.

Further than that, though (perspective correct transforms and stuff), 
is clearly 3D land, IMHO - perhaps mostly because that's where even 
"simple" software fallbacks aren't all that simple any more, and not 
very useful either. Lots of work for something that can, at best, be 
used only for off-line rendering. And of course, we're no longer 
talking about a simple API. Better pull in software Mesa or something 
to do that.


> Feel free to take a look at the API so far in SDL_video.h:
> http://www.libsdl.org/tmp/SDL-1.3.tar.gz (and .zip)
> Currently there are drivers for OpenGL, Direct3D, GDI, and software
> surfaces.

Reading headers with great interest. I'll see if I can build it and 
play around with it some later.


> Also note that most of the existing SDL 1.2 API has been
> reimplemented on top of the 1.3 API, and can be found in
> SDL_compat.h and SDL_compat.c. 
> 
> BTW, nice to see you again, David. :)

Well, it's nice to be, uhm, alive again. :-)


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