Discussion:
SDL 1.2.7 RC1
(too old to reply)
Sam Lantinga
2004-02-17 18:25:41 UTC
Permalink
Okay, the official release candidate for SDL 1.2.7 is available here:
http://www.libsdl.org/cvs/SDL-1.2.7-RC1.tar.gz

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
Stephane Marchesin
2004-02-17 19:27:40 UTC
Permalink
Post by Sam Lantinga
http://www.libsdl.org/cvs/SDL-1.2.7-RC1.tar.gz
Latest cvs produces libSDL-1.2.so.0.7.0, while it used to be
libSDL-1.2.so.0.0.7.
Is this on purpose ?

Stephane
Sam Lantinga
2004-02-17 20:20:09 UTC
Permalink
Post by Stephane Marchesin
Latest cvs produces libSDL-1.2.so.0.7.0, while it used to be
libSDL-1.2.so.0.0.7.
Is this on purpose ?
Yes. Functions were added, so the ABI has been revved.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Glenn Maynard
2004-02-18 03:02:01 UTC
Permalink
Post by Sam Lantinga
* 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 ...
--
Glenn Maynard
Sam Lantinga
2004-02-18 03:55:20 UTC
Permalink
Post by Glenn Maynard
Post by Sam Lantinga
* 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 ...
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
Glenn Maynard
2004-02-18 05:02:48 UTC
Permalink
Post by Sam Lantinga
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.)
--
Glenn Maynard
Florian Hufsky
2004-02-20 18:03:59 UTC
Permalink
but how many users nowadays have such systems?
and how many of them use software that use sdl?
Post by Glenn Maynard
Post by Sam Lantinga
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.)
Sam Lantinga
2004-02-18 16:14:38 UTC
Permalink
Post by Glenn Maynard
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
Glenn Maynard
2004-02-18 21:15:14 UTC
Permalink
Post by Sam Lantinga
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?
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. :)
--
Glenn Maynard
Sam Lantinga
2004-02-18 23:56:27 UTC
Permalink
Post by Glenn Maynard
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.
It doesn't appear to.
Post by Glenn Maynard
I'd have to rearrange monitors to reproduce this, which I can't do right now.
I'd appreciate it if you get the chance.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Continue reading on narkive:
Loading...