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

[David Olofson]

On Sunday 27 August 2006 22:36, Torsten Giebl wrote:
> Hello !
> 
> 
> > I dunno'... Ok performance in 3D games, considering the feature
> > set and output quality, but unless there are shortcuts triggered
> > by simpler transformations (for which I see no reason, considering
> > it's really meant for 3D), I don't see how this could ever come
> > close to the frame rates you get with the SDL 1.2 software
> > blitters. 
> 
> Do you want to have basic 2D GDI like or do
> you want to have HW Surfaces and that things ?

Anything that delivers serious frame rates when doing full screen 
scrolling and that sort of stuff. That generally means full 
acceleration, no matter what hardware you're on. (Powerful CPUs are 
no good when video subsystems are not designed for software 
rendering.)


> Two ways :
> 
> 1. With a compat. header it maybe no problem
> to compile an executable with SDL 1.2 and 1.3.

That would be very handy for some things. Probably unparallelled 
portability with SDL 1.2, and multiple window support, serious 
acceleration and stuff on the most popular platforms with SDL 1.3.


> 2. The SDL 1.2 2D drivers could be added to SDL 1.3.
> As every 3D code naturally has to check if the spec.
> 3D API OGL or D3D is available.

Yeah, as soon as we start talking 3D, there is probably no sensible 
way of getting around that...

We could implement a new, portable Clean3D API over both OpenGL and 
Direct3D, but that would be implemented the same way - as an add-on 
library for SDL 1.3/2.0. Then it would of course be very easy to 
implement *truly* portable 2D-over-3D engines over that API...


> > Yeah... So, I suppose some kind of well defined way of plugging
> > extensions in without messing up SDL rendering would be a sensible
> > way of doing it. (Unlike glSDL, where you're not really supposed
> > to mess with the OpenGL state while using glSDL.)
> 
> That was my hope that SDL supports a transparent way of rendering.
>
> SDL inits 3D. In my mainloop
> I do all my 3D calls and as a last call before SDL_Flip
> i call for example SDL_Do2D or whatever, it blits the 2D stuff.

Well, yes and no. I still believe that an application should use only 
one API for rendering. You have to wrap any API in higher level code 
anyway, and dealing with multiple APIs just complicates that part. If 
you're doing a 3D game, you have to learn one or two 3D APIs anyway, 
and wrap them - so you may as will use them for the occasional 2D 
overlays as well.

Now, there are exceptions: GUI libs and the like. They generally get 
by just fine with an SDL 1.2 style rendering API, and they are indeed 
very usable with any SDL 1.2 2D backend, so it doesn't really make 
sense to force them to support OpenGL, Direct3D or whatnot, just to 
be able to use them in 3D applications.

I was really thinking in terms of a "half private" API, intended for 
add-on libs that want to cooperate intimately with SDL backends - but 
such an API would have a lot in common with what you need to support 
normal SDL 2D rendering over 3D anyway, so perhaps the distinction is 
irrelevant?


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