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

[David Olofson]

On Sunday 27 August 2006 19:42, Sam Lantinga wrote:
> > Once the transform is done, the rest of the pipeline will concist 
of 
> > process_straight() calls, where you just do something with *src 
> > and/or *dst and write the result to *dst++; repeat for 'pixel'. 
> > Doesn't get any simpler than that, I think.
> 
> I'm going even simpler for SDL 2D.  I'm supporting blending options,
> but no rotation, for maximum speed.  Once you get into rotation and
> texel interpolation, you're better off going directly to 3D.

Yes, I pretty much agree with you on this - but there is still this 
problem with Direct3D vs OpenGL.

If Direct3D would just die and go away very quickly, there would be no 
problem, because OpenGL would be the only viable option for 3D and 
"advanced 2D". OpenGL is fine by me, and there are plenty of 2D 
engines, wrappers and whatnot for OpenGL, for those who don't have 
the time or motivation to learn OpenGL.

As it is, however, there is no way to avoid Direct3D if you're serious 
about supporting the Windows platform. Go for OpenGL only, and your 
potential user base is cut in half, or worse. (Unfortunately, I have 
yet to see any reliable figures here.)

Actually, software rendering and support for targets without OpenGL or 
Direct3D is just a "might be nice to have around" thing IMHO. Though 
I can certainly see uses for software rendering with transforms, 
blending and whatnot, on it's own, or together with accelerated 3D, I 
realize that one size just does not fit all. For real time rendering, 
you need something fast - be it awfull looking, if that's the only 
way it can work. For "pseudo real time" background rendering, you'd 
need something pretty fast and reasonably good looking, or there 
isn't much point, really. And for off-line rendering, you're probably 
better off pulling in MesaGL, or even a serious raytracing engine. 
(These days, you can probably use either to render still backgrounds 
"page by page" in a game - sort of like The Last Ninja series did it 
on the C64, only upgraded to current graphics standards...)


Anyway, I can certainly see why you don't want to go beyond the 
current feature set of SDL 1.3. However, I (and many others) still 
need to deal with this OpenGL vs Direct3D issue, and most of us just 
don't want to, or simply cannot, implement our own backends for both.

So, maybe the most sensible way is to have SDL explicitly support both 
OpenGL and Direct3D from the application side? Are there technical 
problems with doing this for Direct3D the way it's done with OpenGL?

This would allow the implementation of one or more portable "advanced 
2D" oriented SDL add-on libraries that do what we need, over OpenGL 
as well as Direct3D (the libs will of course have to support both 
natively), without polluting the SDL core.

Software rendering may or may not be implemented, though as far as I'm 
concerned, I don't think a generic software implementation of the 
class we could realistically implement as Free/Open Source software 
would be of very much use to anyone. It pretty much boils down to 
rolling your own application tuned rasterizer for speed, or pulling 
in Mesa for rendering quality, I think...

(As to the add-on library, I would personally rather see that we focus 
our efforts on a single implementation. It should be just as lean and 
mean as SDL, and do only what it really has to do. "Nice to have" 
features can be put in further optional add-on libraries if desired.)


> One of the things I'm trying to do is avoid per-span function
> overhead. I did a bunch of performance testing with SDL 2D blitters
> a way back, and per-span function overhead was about 10% speed
> reduction.

Well, compared to generic single function blitters, that's still 
pretty fast...

Of course, a run time native blitter generator will probably be 
unbeatable in performance (AFAIK, that's how any software 3D engine 
actually usable for real time gaming does it these days) - but that's 
not an easy thing to implement, and would certainly not make the code 
easier to port. (Well, I suppose you could throw in support for using 
an external or embedded C compiler...)


> So my 2D feature set is shaping up to this:
> * color fill
> * color blend (?)
> * copy blit
>   * optional pixel format conversion
>   * optional constant alpha source modulation
>   * optional constant color source modulation
>   * optional blend operation
>   * optional destination rectangle scaling
> 
> I haven't ever found a need for solid rectangle blending, is it
> useful?

Well, as I grew up with 8 and 16 bit hardware, I have plenty of ideas 
as to how to shape things like that into interesting effects - but 
for modern looking games? No. Nice to have, but unless we're talking 
polygons, it would only be useful in a few special cases.

Now, polygons with per vertex color and blending; that could be 
seriously useful for GUI effects, in-game effects, shaped fades and 
all sorts of interesting stuff. I think getting rid of this 
rectangular restriction of the 8 and 16 bit eras makes a world of 
difference to the usefulness of things.


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