From: Max Horn
Subject: Modifier key fix
The internal modifier state can get out of sync with reality. To
trigger this, do for example this:
1) Launch an SDL app
2) Alt-click on the desktop (this will hide the SDL app).
3) Bring the SDL app back to the front
4) SDL will still think alt is pressed (and as such will treat left
clicks like middle clicks). If you press and release alt, it'll be fine
again.
The attached patch cures this by rechecking the modifier state whenever
we process an event.
From: Dmitry Yakimov
Subject: [SDL] [PATCH] SDL bug patch
Let me introduce 2 fixes to SDL.
1. Preventing great slowdown on fast machines while hardware
flipping (it's obviously bug).
2. Setting up 85 Hz of monitor if supported. The reason is that
Win98 by default sets lowest frequency 60 Hz.
And we can't set up maximum frequency because some users can have
wrong monitor drivers.
This is important for shareware and commercial programs.
From: Jens Leuschner
Subject: Small patch for libSDL
In newer XFree86 releases in the German keyboard the "AltGr"-Key no
longer produces the keysym "Mode_switch", instead it produces
"ISO_Level3_Shift".
I have created a small patch against SDL-1.2.6 (which cleanly applies to
the current CVS-SDL too) that makes SDL recognize ISO_Level3_Shift as
AltGR key.
From: Thomas Jarosch
Subject: Re: [SDL] DSPF_RBG15 in src/video/directfb/SDL_DirectFB_video.c
In my local DirectFB 0.1.19 copy, DSPF_RGB15 is an alias for DSPF_ARGB1555.
They seem to have it removed in DirectFB CVS.
As DSPF_RGB15 was only an alias, the attached patch
can safely be applied to SDL and won't brake older DirectFB versions.
From: Max Horn
Subject: Small libtool patch (framework related)
here is a small patch for ltmain.sh. It corrects a problems with the
libSDL.la file, which prevented applications using a version of libtool
w/o framework support (read: all currently released libtool version) to
not being able to link with SDL anymore. I also notified the libtool
maintainers, as the same problem exists in libtool CVS.
From: Stephane Marchesin
Subject: Re: [SDL] 3DNow! detection on a P4 system
Well... I found another bug : 3dnow was detected on P2/P3 cpus. So I
took one more look at the code and found a mistake in
CPU_getCPUIDFeaturesExt :
The condition for having extended cpuinfo is that when we query extended
cpuinfo we get a result >= 0x80000001. So we must exit if eax < 0x80000001.
The attached patch does that.
From: Max Horn
Subject: Auto hide mouse & other changes
the attached bug adds the auto-hide-mouse feature I talked about
earlier. Turned out it was a lot simpler than I thought, simply by
using our existing code :-). I actually spent much more time on fixing
various bugs in the code and correcting (IMO) some behavior (although,
due to the lack of real specs for SDL, it's probably arguable what
'correct' means...).
* adds auto (un)hiding of mouse depending on whether it is in- or
outside the game window
* computation of course coordinates is correct now (it often and
reproducible got out of sync with the old code, since the NSEvent
window was in some cases *not* our window anymore, so locationInWindow
returned wrong results)
* added a method which at any time returns the mouse coords, relative
to our window
* fixed handling of lost/gain input/mouse/app focus "events"
From: Max Horn
Subject: SDL_HasAltiVec; BUGS file
the attached patch adds SDL_HasAltiVec to SDL CVS. Note that at this
point, this only works on MacOSX (and maybe darwin). I don't know how
to properly add a test for e.g. Linux/PPC at this point. I found an
email which might help in doing so:
http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2003-01msg00783.html
However, since I have no way to test on a non-OSX PowerPC system, I am
not comfortable blindly adding such code... I just hope that if
somebody from the Linux/PPC (or FreeBSD/PPC, or whatever) community
notices this, they'll jump up and provide a patch for us ;-)
From: Anders_F_Bj?rklund
Subject: [SDL] Dynamic OpenGL lib support for Mac
Here's a patch that adds LoadLibrary and GetProcAddress
to the Carbon macintosh driver (for Mac OS 9 and Mac OS X):
http://www.algonet.se/~afb/SDL-1.2.6-macdynamicgl.patch
It just calls the corresponding function from SDL_loadso.
It also fixes one Mac bug in SDL_loadso.c, that made it fail
always when loading a library, and fixes the screen update
after receiving an update event - which caused the OpenGL
context to be overwritten by a blank window by UpdateRect...
From: Max Horn
Subject: Re: Again Audio CD patch
Am 04.01.2004 um 22:38 schrieb Sam Lantinga:
>
> Okay, I fixed the buffering problems by simply using a 4 second buffer
> instead of a 1 second buffer. However, using your code I can't play an
> entire CD - the playback stops after the first song.
>
Found the problem: FSReadFork returns eofErr when the file is finished.
However, we check its return value for errors, and if anything but
noErr occurs, the reader thread aborts its current iteration. That is
bad, because it aborts before it can ever set the flag which tells that
the file is over (also, any remaining data which FSRead did return is
lost - so you'd not hear about to 4 seconds from the end of the file.
Furthermore, the computed data size was 8 bytes to high (I forgot to
account for the fact that the size of an (A)IFF chunk always contains
the chunk header & size fields, too). This is enough to make it work.
However, the end condition is rather fragile, so I tuned some other
things to be pessimistic (check for <= 0 instead of == 0, when eofErr
is encountered enforce mReadFilePosition == mFileLength). You never
know...
The attached patch fixes the issue for me.
