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

[René Dudfield]

Has anyone had a look at tinygl?

It's really small, and there is a port to SDL.  It uses floats
internally, so isn't very good for eg ARM platforms.

The source forge page is down at the moment...
http://sdl-tinygl.sourceforge.net/

There's the fixed point, GPL klimt too.
http://studierstube.icg.tu-graz.ac.at/klimt/


On 8/28/06, David Olofson <david at olofson.net> wrote:
> 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  --'
>
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
>