SDL, Software double buffering

[Phil Steinmeyer]

On a slow machine, the slowest part of my game is calling SDL_UpdateRects()

I'm currently using software mode for both full screen and windowed mode.

It appears that when I do my UpdateRect, there's a synchronous lag, because SDL must wait for the vertical synch, then it must do a memcpy of the screen's pixel data.

Would it be possible to eliminate the wait for synch and/or the memcpy wait by setting up software modes to allow double buffering, combined with a simple flip? Is this just a potential feature that SDL is missing (and that perhaps I could add), or is my logic wrong and there would be no gain to be had here?

[Screwball]

Are you locking your surface before you do an update rect then unlocking after ?

As far as double buffering have you set:

screen=SDL_SetVideoMode(x,y,32,SDL_HWSURFACE|SDL_D OUBLEBUF);

Then use the function:

SDL_Flip(screen)

[sparkyboy]

Hi Phil,
I'm no expert in these matters, and have never used SDL, but this is what I presume is the case.

The default SDL drivers do not allow you to use the vertical retrace period as a timing mechanism( or any other use!! ;) , so your problem is not one of the VBL.
What could be a problem is the consequence of locking and unlocking surfaces.In other words, you should lock a surface ONCE blit everything and then UNLOCK.The locking and unlocking of surfaces is what takes an age for directx!! ;)

Here's a little insight by someone who seems pretty good in getting smoothe animation:

http://www.devolution.com/pipermail/sdl/2001-July/037121.html

Here's his site with some good examples:

http://olofson.net/examples.html

As regards to including a 'WAIT VBL' function in SDL, well since its possible with Directx and you get the source to SDL of course you could implement it yourself.Don't forget to share it though with the rest of the community!

The only problem is that refresh rates vary so much and sometimes the retrace interrupt is disabled on the card.That's why on the PC, the VBL isn't a reliable form of timing............Oh for the days of the AMIGA eh!!! :D

All the best


Mark

[Rainer Deyke]

Actually you should never blit to or from a locked surface in SDL. Bad things happen if you try. Lock the surface when you need direct access to the pixel data, but unlock it again before blitting.

[1EyedJack]

As Phil mentioned in his post he is using software surfaces, and to my understanding you do not have to use locking/unlocking when you use softwaresurfaces (Please correct me if I am wrong). Also in David Olofsons example mentioned above, softwaresurfaces are used and there is no locking/unlocking of surfaces in the code.

Using SDL_HWSURFACE|SDL_DOUBLEBUF and SDL_Flip would cause a considerable performance decrease also on fast systems (~30 FPS on an AMD Athlon 2200 with radeon 9600). Please also note that the flag SDL_DOUBLEBUF does only work with hardwaresurfaces.

If you want to do doublebuffering with softwaresurfaces you have to create an additional softwaresurface in your code that will serve as the second buffer.