Please download it, install it, and report any problems that you have
with it ASAP. Barring any showstoppers, I’ll be releasing SDL 1.2.7
in the next day or two.
Here is the list of major changes since SDL 1.2.6:
Added a test program for dynamically loading OpenGL
Increased sensitivity of the Windows joystick driver
Added support for SDL_VIDEO_WINDOW_POS and SDL_VIDEO_CENTERED on Windows
Added fullscreen toggle support in testwm for Windows, etc.
Fixed mouse focus events after resetting video mode on Windows
Added colorkey blit tests to testvidinfo (thanks Mike!)
Added video hardware acceleration support on QNX (thanks Mike!)
SDL no longer sets a fatal signal handler for SIGPIPE
Fixed modifier key state on MacOS X (thanks Max!)
Added support for remote XVideo (thanks Frederic!)
Try to use higher refresh rate by default in DirectX driver (thanks Dmitry!)
Fixed static linking on MacOS X (thanks Max!)
Various Atari video driver improvements (thanks Patrice!)
Fixed compiling with broken Linux 2.6 headers
Fixed mouse cursor visibility and focus events on MacOS X (thanks Max!)
Added support for /dev/joy* on Free/Net/OpenBSD (thanks Christian!)
Fixed problems with CD-ROM audio playback on MacOS X 10.1
Added dynamic GL library loading to MacOS Carbon support (thanks Anders!)
Added the ability to hide the cursor in the DirectFB driver (thanks Pete!)
Added minor cleanup for Embedded Visual C++ 3.0 (thanks Andy!)
Fixed high CPU usage with ALSA audio driver (thanks Michel!)
Added function to create RWops from const memory: SDL_RWFromConstMem()
Fixed compiling with ALSA 1.0 (thanks Stephane!)
Added YUV overlay support on BeOS (thanks Andrew!)
Fixed build problems with newer versions of automake
Fixed MacOS X libtool framework support (thanks Max!)
Added CPU feature detection functions to SDL_cpuinfo.h
Fixed illegal instruction crash using 3DNow on Intel processors
Fixed asm issues with mmx.h and gcc 3.3 (thanks Stephane!)
Updated libtool support so Mingw32 builds work.
Disable screen saver in Windows DIB video driver
Added Atari CD-ROM support (thanks Patrice!)
Fixed crash calling app defined window proc (thanks Scott!)
Fixed long long constant warnings in GCC 3.3.1 (thanks Stephane!)
Added configure.in support for K*BSD (thanks Robert!)
Added QNX package and audio fixes (thanks Mike!)
Fixed joystick open problems on BSD (thanks SUGIMOTO!)
Fixed X11 mode line crash with only one video mode (thanks Alan!)
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Despite the fact that this doesn’t work on some older systems, causing
desynced monitors and confused users? Sigh. Oh well, I’m already
using a forked SDL anyway …On Tue, Feb 17, 2004 at 10:25:41AM -0800, Sam Lantinga wrote:
Try to use higher refresh rate by default in DirectX driver (thanks Dmitry!)
Can you check the snapshot and see if it doesn’t work on any systems
you have available?
Thanks,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Tue, Feb 17, 2004 at 10:25:41AM -0800, Sam Lantinga wrote:
Try to use higher refresh rate by default in DirectX driver (thanks Dmitry!)
Despite the fact that this doesn’t work on some older systems, causing
desynced monitors and confused users? Sigh. Oh well, I’m already
using a forked SDL anyway …
It won’t work on systems that have misconfigured non-PnP monitors. I
have a monitor next to me that won’t do higher than 60Hz in 640x480, which
I use for testing. If it’s plugged into a system that thinks it has a
better monitor, the system has no way of knowing this, and will desync.
(“Fix the user’s system” would be nice, but I’m not going to tell a remote
user of a system this old to change his monitor configuration-- since it’s
likely to stop working entirely, and a user of a system this old isn’t
going to be able to fix it himself.)
A possibly safe thing to do is query the desktop resolution’s refresh rate,
and use that as a maximum. (If the desktop is at 70Hz, we can probably use
at least up to 70Hz, unless the resolution is higher than the desktop
resolution.)On Tue, Feb 17, 2004 at 07:55:20PM -0800, Sam Lantinga wrote:
Can you check the snapshot and see if it doesn’t work on any systems
you have available?
It won’t work on systems that have misconfigured non-PnP monitors. I
have a monitor next to me that won’t do higher than 60Hz in 640x480, which
I use for testing. If it’s plugged into a system that thinks it has a
better monitor, the system has no way of knowing this, and will desync.
The systems I’ve tested against return zero for the refresh rate if it
can’t detect available refresh rates. Is this the case for that monitor?
If using SDL 1.2.7 with that monitor really does desync, can you send a
patch to clamp the refresh rate to the current desktop refresh rate?
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Are you saying that the API being used doesn’t return refresh rates at all
for non-PnP monitors? That’d be bizarre behavior for a low-level API.
I’d have to rearrange monitors to reproduce this, which I can’t do right now.
I’m just pointing this out since I was surprised that this was applied
despite the warnings about this. I use my own refresh rate code, anyway;
I don’t have the motivation to fix up refresh rate code I’m not going to
use. :)On Wed, Feb 18, 2004 at 08:14:38AM -0800, Sam Lantinga wrote:
The systems I’ve tested against return zero for the refresh rate if it
can’t detect available refresh rates. Is this the case for that monitor?
If using SDL 1.2.7 with that monitor really does desync, can you send a
patch to clamp the refresh rate to the current desktop refresh rate?
but how many users nowadays have such systems?
and how many of them use software that use sdl?
Glenn Maynard wrote:>On Tue, Feb 17, 2004 at 07:55:20PM -0800, Sam Lantinga wrote:
Can you check the snapshot and see if it doesn’t work on any systems
you have available?
It won’t work on systems that have misconfigured non-PnP monitors. I
have a monitor next to me that won’t do higher than 60Hz in 640x480, which
I use for testing. If it’s plugged into a system that thinks it has a
better monitor, the system has no way of knowing this, and will desync.
(“Fix the user’s system” would be nice, but I’m not going to tell a remote
user of a system this old to change his monitor configuration-- since it’s
likely to stop working entirely, and a user of a system this old isn’t
going to be able to fix it himself.)
A possibly safe thing to do is query the desktop resolution’s refresh rate,
and use that as a maximum. (If the desktop is at 70Hz, we can probably use
at least up to 70Hz, unless the resolution is higher than the desktop
resolution.)