[SDL] resizing SDL opengl window

Will Childman c7liu at uwaterloo.ca
Mon Jan 24 19:11:06 PST 2005

Gaetan de Menten wrote:

>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)
You don't seem to have 3d acceleration correctly setup. You should load 
the dri module in your X configuration file.

>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.
Well, if you configure accelerated OpenGL on your machine, you might get 
a bigger speedup.
For now, it is probably falling back to software rendering.

>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).
The semantics when mixing colorkey and alpha is explained in large 
detail in the SDL_SetAlpha manpage.
It depends on the format of the source and destination surfaces, not 
only on the flags that are set.

>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
I think we have most of the pitfalls described there :
And yes, most of the advice there also applies to non-glSDL situations.


More information about the SDL mailing list