[SDL] glSDL backend

Gaetan de Menten gedeonlecanard at gmail.com
Fri Jan 7 07:15:01 PST 2005


Ok, I finally took the time to test this. 

The patch applied cleanly and the two games I tried worked (but very
slowly at first -- something like 3fps).

I guess this is normal (and due to my system) but every time I run a
program with the glSDL backend, I get the following message:
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
(just below the "glSDL videoinit" message)

Concerning my own game, it worked slowly too until I replaced all the
SDL_SWSURFACE with SDL_HWSURFACE. After I had done that, it worked at
a pretty decent speed.

I found one problem though: It seems like, on surfaces with a
colorkey, calling SDL_SetAlpha without the SDL_SRCALPHA flag has no
effect (instead of setting the surface as opaque).

I use the following code:

	int flags = Surface->flags & SDL_RLEACCEL;

	if (alpha<255)			// (*)
		flags |= SDL_SRCALPHA;

	if (SDL_SetAlpha(Surface, flags, alpha)) {
		fprintf(stderr, "SetAlpha failed: %s\n", SDL_GetError());
		exit(1);
	}

When I use an alpha of 255 with the above code, the sprite isn't
opaque as it should.

If I comment the (*) line or if I don't use colorkey with my sprites,
the problem disappears. As far as my tests go, the problem seems
unrelated to the RLE encoding (happens whether the surfaces are
encoded or not).

I hope this helps...

And now I got some questions about hardware surfaces. I never bothered
to use them since I read somewhere they can be slower than software
surfaces in some cases. Since I'd like get the best of both worlds, is
it okay to just test if we got an hardware surface for the screen, and
if it's the case use hardware surfaces everywhere, and if it's not use
software surface everywhere? Or are there other pitfalls with hardware
surfaces?

For info, most of my surfaces have "static" contents.

-Gaetan.




More information about the SDL mailing list