Update

Well, today I got sorta stumped on a really interesting way of doing
fullscreen code that turns out to be fairly complicated, but allows the
window manager to control your focus. I will take a look at it later
when I’ve had some more time to think about it.

I think I got the Heroes 3 demo working, in the course of trying to fix
SMPEG when playing mono MP3 files on a stereo output. Stephane’s simple
fix works, it was some other memory corruption that was causing the
crash in Heroes 3. It needs more Q/A, but hopefully it works now. It
seems a bit more sluggish than the old version, Stephane, can you look
at it?

I helped Jim get his very nice dynamic GL loading patch integrated into
SDL 1.1. The semantics are - if you build SDL to dynamically load GL,
you must query the function pointers for all of your GL calls, but you
can specify a particular GL driver at runtime. If you build SDL not to
load GL dynamically, you must link with GL, and it must be the .so
version of the library, not the .a version of the library. In both
cases, you can explicitly query SDL for GL function pointers, including
GL extensions.
This code will be in the CVS snapshot tonight.

I found the cause of the Gaia Controller pollution bug in CivCTP - the
pollution reduction is specified as a negative number in the data file,
and then is subtracted from the pollution. Doh! This appears to be in
the Windows code as well, and we’ll verify that tomorrow.–
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Oops. That was a Loki internal update.

:slight_smile:
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Heh.

Speaking of off-topic,

Mebbe I should post my “true believer” story to the SDL mailing list.

–Cliff
@Clifford_T_Matthews

Sam Lantinga wrote:

Oops. That was a Loki internal update.

Finally! Trade secrets that I can run with… although I don’t think I
could get more than burger for them.

Sam Lantinga wrote:

I helped Jim get his very nice dynamic GL loading patch integrated into
SDL 1.1. The semantics are - if you build SDL to dynamically load GL,
you must query the function pointers for all of your GL calls, but you
can specify a particular GL driver at runtime. If you build SDL not to
load GL dynamically, you must link with GL, and it must be the .so
version of the library, not the .a version of the library. In both
cases, you can explicitly query SDL for GL function pointers, including
GL extensions.
This code will be in the CVS snapshot tonight.

So in English, this means that one could use SGI’s, MS’, or Mesa’s drivers
to implement OpenGL?

I’ve run into many problems trying to implement OpenGL on Windows inside of
a Gtk+ Window (gtkglarea doesn’t work that well on win32). And if I
remember correctly, SDL’s OpenGL implementation on Windows needed Mesa. I
can’t get or find a mingw32 compiled version of Mesa that works.

One last thing, SDL inside of a Gtk+ window in Win32 seems to be producing
two windows. The environment work around seems to have broke in the latest
releases. I could be doing something wrong, as well.

Thanks.

So in English, this means that one could use SGI’s, MS’, or Mesa’s drivers
to implement OpenGL?

Yep. SDL uses GLX internally on UNIX platforms for context creation.

On windows (not yet implemented), SDL will use wgl.

I’ve run into many problems trying to implement OpenGL on Windows inside of
a Gtk+ Window (gtkglarea doesn’t work that well on win32). And if I
remember correctly, SDL’s OpenGL implementation on Windows needed Mesa. I
can’t get or find a mingw32 compiled version of Mesa that works.

Patience my son. :slight_smile:

One last thing, SDL inside of a Gtk+ window in Win32 seems to be producing
two windows. The environment work around seems to have broke in the latest
releases. I could be doing something wrong, as well.

That’s very possible. I’ll take a look if I get a chance.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Yep, it’s only 9 am and I have an update. :slight_smile:

I fixed a silly bug in the SDL audio open code, so now it properly falls
back on ESD when /dev/dsp isn’t available. In the process I became
really frustrated with ESD hanging when /dev/dsp isn’t available, so I
have a patch for ESD. I will be submitting this to the maintainers, but
some of you might have a use for it (attached).

Also, the Heretic2 demo is now in Q/A, and works well as far as I can
tell.–
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
-------------- next part --------------
diff -ru esound-0.2.14/audio_oss.c esound-0.2.14.new/audio_oss.c
— esound-0.2.14/audio_oss.c Wed Mar 15 07:27:56 2000
+++ esound-0.2.14.new/audio_oss.c Wed Mar 15 07:27:43 2000
@@ -33,6 +33,9 @@
if ( (esd_audio_format & ESD_MASK_FUNC) == ESD_RECORD )
mode = O_RDWR;

  • /* Don’t block the open, or esd will hang in autosuspend mode */

  • mode |= O_NONBLOCK;

  • /* open the sound device */
    device = esd_audio_device ? esd_audio_device : “/dev/dsp”;
    if ((afd = open(device, mode, 0)) == -1)
    @@ -40,6 +43,11 @@
    perror(device);
    return( -2 );
    }

  • /* presumably esd wants the file descriptor in blocking mode */

  • mode = fcntl(afd, F_GETFL);

  • mode &= ~O_NONBLOCK;

  • fcntl(afd, F_SETFL, mode);

    /* TODO: check that this is allowable /
    /
    set for full duplex operation, if recording */