[SDL] blit performance

[David Olofson]

On Wednesday 20 February 2002 14:37, Alexandre Courbot wrote:
[...]
> > So when an OpenGL display mode gets initialized, all SDL hardware
> > surfaces should be created as 2D textures and blits would be done
> > with textured quads. Software surfaces should stay in system memory
> > and be copyed into textures when blitting.
>
> Exactly. You could also take advantage of accelerated alpha-blending,

glSDL does that...


> or apply anti-aliasing to the final rendered image.

Now, that's *really* hard to get right. I know some ways to do it in an 
OpenGL application, but I don't think it's at all possible to get right 
without extra info from the application.

The problem is the edges of images... Clamp? Wrap? Smooth? "Leak" from 
the edge of some other surface?

The answer is that it depends on how the image is used in the game.


Of course, there is FSAA - but I can't really see how it would apply here 
- in fact, you even have to disable interpolation to get correct 
results!


> Needless to say how
> fast it will be with a good video card.

It is indeed! :-)

Someone reported KoboDeluxe doing several hundred fps even in the higher 
resolutions, on some GeForce card. Even my G400 (*) can sustain more than 
playable frame rates in 640x480 and higher.


(*) which is a pretty slow card, actually - but it still beats the crap
   out of all other cards I've seen WRT high resolution signal quality.
   I have yet to see another card capable of driving a high end monitor
   in resolutions higher than 1600x1200. nVidia chips suck in that area -
   *real* bad at that!


> > In a non-OpenGL display mode everything should of course function as
> > normal, with DirectDraw / X11 / and the rest.
>
> Right. Problems might occur if the programmer uses OpenGL functions
> along with the OpenGL backend, maybe. But I'm not even sure myself.

Well, that could be solved, but it would involve pushing/popping the 
matrix around every single OpenGL accelerated SDL call... Maybe provide 
an optional flag to enable that, or add function calls to explicitly 
switch between SDL and OpenGL "modes"? (The latter would be much more 
efficient.)


> > But perhaps such a system is already planned for SDL 1.3?
>
> No idea. I don't even know whether plans for 1.3 started or not.
> Anyone?
>
> David Olofson once made a quick hack to use OpenGL rendering within SDL
> for his Kobo Deluxe game. It's not exactly a backend, as it's included
> with Kobo sources and redefines some SDL functions in practise. But it
> worth a look anyway. You can get Kobo source at
> http://olofson.net/skobo/. Then try ./configure --help for the args to
> pass to use the hack. (SDL must be built with OpenGL capability of
> course). He mentions it here:
> http://www.libsdl.org/pipermail/sdl/2001-December/040562.html (the rest
> of the thread is quite interesting, too)
>
> If we could start hacking this around, it would be nice.

Well, it's already LGPLed, so...


> Would be
> better if we could have someone who knows a bit SDL's internal
> structure, as it's not documented as far as I know. And we'd have
> to mess with SDL's guts to make it a backend.

Yeah. That's the major reason why I haven't done it already.


> So, interested?

I'll help, of course. :-)


//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'