[SDL] glSDL backend

Gaetan de Menten gedeonlecanard at gmail.com
Sun Jan 9 16:44:40 PST 2005

On Sun, 09 Jan 2005 23:26:29 +0100, Stephane Marchesin
<stephane.marchesin at wanadoo.fr> wrote:
> Gaetan de Menten wrote:
> >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.

I got the Nvidia closed source drivers and they explicitly say not to
load the dri module, but I guess this is pretty much off topic...

> >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 think you misunderstood what I said... I was probably unclear but I
really think there is a problem... The semantics are what I thought
they were, and even if I got the semantics wrong (I don't think I do),
you'll have to explain me how a call to "SDL_SetAlpha(Surface, 0,
255)" can result in an alpha blended sprite...

Again, it looks like the call is totally ignored (the previous alpha
value is used) when
the SDL_SRCALPHA is not present, instead of IN THIS CASE (alpha = 255)
"setting up" the surface as opaque.

Btw: this problem is, of course, only present with the glSDL backend
and not in any  other backend I tried (otherwise I wouldn't have
reported it as an answer to your mail).

> >[...]
> >Or are there other pitfalls with hardware surfaces?

> I think we have most of the pitfalls described there :
> http://icps.u-strasbg.fr/~marchesin/sdl/glsdl.html
> And yes, most of the advice there also applies to non-glSDL situations.

I had already read that page since you mentioned it in your first
mail... (it's a pretty nice page, btw). But I think some pitfalls of
hardware surfaces are not mentioned.   Isn't there a problem with lost
surfaces on the DirectDraw backend (or something like that)?


More information about the SDL mailing list