Thanks to everybody who contributed feedback and patches for this release!
Here are the major changes since the last release:
General:
Fixed flicker when resizing the SDL window
Fixed crash in SDL_SetGammaRamp()
Fixed freeze in SDL_memset() with 0 length when assembly code is disabled.
Added SDL_NO_LOCK_KEYS environment variable to enable normal up/down
events for Caps-Lock and Num-Lock keys.
Fixed audio quality problem when converting between 22050 Hz and 44100 Hz.
Fixed a threading crash when a few threads are rapidly created and complete.
Fixed crash loading BMP files saved with the scanlines inverted.
Fixed mouse coordinate clamping if SDL_SetVideoMode() isn’t called
in response to SDL_VIDEORESIZE event.
Added doxygen documentation for the SDL API headers.
Unix:
Fixed potential memory corruption due to assembly bug with SDL_revcpy()
Fixed crashes trying to detect SSE features on x86_64 architecture.
Fixed assembly for GCC optimized 50% alpha blending blits.
Added configure option --enable-screensaver, to allow enabling the
screensaver by default.
Use XResetScreenSaver() instead of disabling screensaver entirely.
Removed the maximum window size limitation on X11.
Fixed setting the X11 window input hint.
Fixed distorted X11 window icon for some visuals.
Fixed detecting X11 libraries for dynamic loading on 64-bit Linux.
SDL_GL_GetAttribute(SDL_GL_SWAP_CONTROL) returns the correct value
with GLX_SGI_swap_control.
The SDL_VIDEO_FULLSCREEN_HEAD environment variable can be set to 0
to place fullscreen SDL windows on the first Xinerama screen.
Added the SDL_VIDEO_FBCON_ROTATION environment variable to control
output orientation on the framebuffer console.
Valid values are:
* not set - Not rotating, no shadow.
* “NONE” - Not rotating, but still using shadow.
* “CW” - Rotating screen clockwise.
* “UD” - Rotating screen upside down.
* “CCW” - Rotating screen counter clockwise.
Fixed DirectFB detection on some Linux distributions.
Added code to use the PS3 SPE processors for YUV conversion on Linux.
Improved support for PulseAudio
The Network Audio System support is now dynamically loaded at runtime.
Fixed crash with the MP-8866 Dual USB Joypad on newer Linux kernels.
Fixed crash in SDL_Quit() when a joystick has been unplugged.
Windows:
Verified 100% compatibility with Windows 7.
Prevent loss of OpenGL context when setting the video mode in
response to a window resize event.
Improved mouse input responsiveness for first-person-shooter games.
The SDL_STDIO_REDIRECT environment variable can be used to override
whether SDL redirects stdio to stdout.txt and stderr.txt.
Fixed video initialization with SDL_WINDOWID on Windows XP
Here are the major changes since the last snapshot…
General:
?* Increased accuracy of alpha blending routines.
Unix:
?* Fixed SDL_GL_SWAP_CONTROL on X11.
?* Updated ALSA support to the latest stable API
?* ALSA is now preferred over OSS audio. ?(SDL_AUDIODRIVER=dsp will
restore the previous behavior.)
?* Added a bunch of Debian patches
Windows:
?* IME messages are now generated for localized input.
?* SDL_RWFromFile() takes a UTF-8 filename when opening a file.
Enjoy!
On Wed, Oct 7, 2009 at 1:19 AM, Sam Lantinga <@slouken> wrote:
Barring any showstoppers, this is going live on Sunday!
Noooooooooooooo. There is still a big graphical problem when running
in windows mode on a mac.
The colours are all distrorted on a mac when a game is in windows mode
(see other threads this month).
Mac OS X:
?* Verified that SDL correctly reports swapped red and blue channels
in fullscreen mode
Good. Fullscreen works fine with the game I’m building (Globulation 2
http://globulation2.org). But in windowed mode, the colours are
really warped. Things that should be black are bright blue, thinks
that should be yellow/white/green are bright blue as well.
Barring any showstoppers, this is going live on Sunday!
Noooo - just detected a no_go for the average Windows user:
The mouse cursor totally disappears when other applications get active
and happen to move the mouse over the area of an SDL application!
Details:
When the SDL app releases the mouse grab and shows and redraws the
cursors to allow the user to use other applications the standard Windows
cursor appears when the mouse leaves the SDL app window. The SDL app
cursor appears and moves again when the mouse enters the SDL window area
this is correct and unmodified to earlier releases.
But when the user once activates another application by clicking in
another window and move then the cursor back to SDL app window the
standard cursor disappears and no SDL cursor appears. The user has no
idea where the mouse is! Just when activating the SDL app by clicking
blindly anywhere within the SDL window the SDL cursor reappears. This
behaviour has changed to earlier SDL releases and is certainly a serious
bug.
I just tested this feature on Windows XP with the todays prerelease of
1.2.14. The application is a MinGW compilation. I will check other
operating systems like Linux later on.
Barring any showstoppers, this is going live on Sunday!
If this is really the last official version of SDL 1.2,
would it be possible to release it one week later ?
Maybe put a BIG RED BLINKING BOX on the SDL website, saying
that to all users out there.
Personally my computer was down the whole week, so i had
no time to test all the changes and also i got a new Mac,
which i would like to test SDL with.
Barring any showstoppers, this is going live on Sunday!
If this is really the last official version of SDL 1.2,
would it be possible to release it one week later ?
Actually, I’d say a month would be even better. There have been so
many changes recently… But even that is crap, because there still
wouldn’t be enough testing. The only way to really get loads of
testing will be through a release…
Instead, how about not making this the last release? If Sam, Ryan etc.
want to focus on 1.3.x (2.0?) from now on, so be it, but if enough
dedicated people from the community provide fixes for 1.2.x, what is
the blocker for ultimately making a 1.2.15 is some serious bugs crops
up? I know that release management can be a PITA, but even with that I
am sure we could find people who’d help. Heck, I’d be willing to do
it, if necessary :).
Bye,
MaxAm 16.10.2009 um 12:06 schrieb Torsten Giebl:
Barring any showstoppers, this is going live on Sunday!
If this is really the last official version of SDL 1.2,
would it be possible to release it one week later ?
Actually, I’d say a month would be even better. There have been so many
changes recently… But even that is crap, because there still ?wouldn’t be
enough testing. The only way to really get loads of testing will be through
a release…
Instead, how about not making this the last release? If Sam, Ryan etc. want
to focus on 1.3.x (2.0?) from now on, so be it, but if enough dedicated
people from the community provide fixes for 1.2.x, what is the blocker for
ultimately making a 1.2.15 is some serious bugs crops up? I know that
release management can be a PITA, but even with that I am sure we could find
people who’d help. Heck, I’d be willing to do it, if necessary :).
+1. I’ll help, if needed.
StevenOn Fri, Oct 16, 2009 at 5:28 AM, Max Horn wrote:
Thanks!On Fri, Oct 16, 2009 at 3:01 AM, Ronald Lamprecht <R.Lamprecht at t-online.de> wrote:
Hi,
Sam Lantinga wrote:
Barring any showstoppers, this is going live on Sunday!
Noooo - just detected a no_go for the average Windows user:
The mouse cursor totally disappears when other applications get active and
happen to move the mouse over the area of an SDL application!
Details:
When the SDL app releases the mouse grab and shows and redraws the cursors
to allow the user to use other applications the standard Windows cursor
appears when the mouse leaves the SDL app window. The SDL app cursor appears
and moves again when the mouse enters the SDL window area - this is correct
and unmodified to earlier releases.
But when the user once activates another application by clicking in another
window and move then the cursor back to SDL app window the standard cursor
disappears and no SDL cursor appears. The user has no idea where the mouse
is! Just when activating the SDL app by clicking blindly anywhere within the
SDL window the SDL cursor reappears. This behaviour has changed to earlier
SDL releases and is certainly a serious bug.
I just tested this feature on Windows XP with the todays prerelease of
1.2.14. The application is a MinGW compilation. I will check other operating
systems like Linux later on.
Thanks!On Fri, Oct 16, 2009 at 2:16 AM, Kieran P wrote:
Barring any showstoppers, this is going live on Sunday!
Noooooooooooooo. There is still a big graphical problem when running
in windows mode on a mac.
The colours are all distrorted on a mac when a game is in windows mode
(see other threads this month).
Mac OS X:
?* Verified that SDL correctly reports swapped red and blue channels
in fullscreen mode
Good. Fullscreen works fine with the game I’m building (Globulation 2
http://globulation2.org). But in windowed mode, the colours are
really warped. Things that should be black are bright blue, thinks
that should be yellow/white/green are bright blue as well.
This is the last planned release. Of course if serious issues come
up, there will definitely be additional patches, but the idea is to
put the last few major bugs to rest and focus on SDL 1.3.
Honestly, if the community is looking to help, I’ve got a TODO list as
long as my arm for SDL 1.3, and I’d love to have lots of help!
See ya!On Fri, Oct 16, 2009 at 5:28 AM, Max Horn wrote:
Am 16.10.2009 um 12:06 schrieb Torsten Giebl:
Hello !
Barring any showstoppers, this is going live on Sunday!
If this is really the last official version of SDL 1.2,
would it be possible to release it one week later ?
Actually, I’d say a month would be even better. There have been so many
changes recently… But even that is crap, because there still ?wouldn’t be
enough testing. The only way to really get loads of testing will be through
a release…
Instead, how about not making this the last release? If Sam, Ryan etc. want
to focus on 1.3.x (2.0?) from now on, so be it, but if enough dedicated
people from the community provide fixes for 1.2.x, what is the blocker for
ultimately making a 1.2.15 is some serious bugs crops up? I know that
release management can be a PITA, but even with that I am sure we could find
people who’d help. Heck, I’d be willing to do it, if necessary :).
Oh behalf of Roman Tetelman (kevlarman at gmail.com), who can also be
found in #ioquake3 on freenode:
<@kevlarman> oh god
<@kevlarman> wow
<@kevlarman> sound sucks with this sdl
<@kevlarman> zakk: ^
<@kevlarman> on an hdaudio card
with SDL svn?
<@kevlarman> yeah
<@kevlarman> well, the snapshot
<@kevlarman> not svn
so no then?
give it a shot with SDL svn
i’m not sure if the snapshot is late enough
<@kevlarman> /branches/SDL-1.2/ right?
yup
<@kevlarman> slightly better
<@kevlarman> but still bad
<@kevlarman> now instead of crackling sounds are just getting cut offOn Fri, 16 Oct 2009 00:39:52 -0700 Sam wrote:
Fixed audio crackling and distortion issues with ALSA
Thanks! If anyone is having this issue, please try the loopwave test
program included with the SDL source archive, and report what audio
driver it’s using, and then try it with some other drivers to see what
the output is:
See ya!On Fri, Oct 16, 2009 at 12:21 PM, Tim Angus wrote:
On Fri, 16 Oct 2009 00:39:52 -0700 Sam wrote:
?* Fixed audio crackling and distortion issues with ALSA
Oh behalf of Roman Tetelman (kevlarman at gmail.com), who can also be
found in #ioquake3 on freenode:
?<@kevlarman> oh god
?<@kevlarman> wow
?<@kevlarman> sound sucks with this sdl
?<@kevlarman> zakk: ^
?<@kevlarman> on an hdaudio card
? with SDL svn?
?<@kevlarman> yeah
?<@kevlarman> well, the snapshot
?<@kevlarman> not svn
? so no then?
? give it a shot with SDL svn
? i’m not sure if the snapshot is late enough
?<@kevlarman> ?/branches/SDL-1.2/ right?
? yup
?<@kevlarman> slightly better
?<@kevlarman> but still bad
?<@kevlarman> now instead of crackling sounds are just getting cut off
Yep this was a bug in Globulation where it assumed that the alpha channel was
in the high bits. I suspect all of the other windowed color issues on Snow
Leopard will be the same thing.
Barring any showstoppers, this is going live on Sunday!
Noooooooooooooo. There is still a big graphical problem when running
in windows mode on a mac.
The colours are all distrorted on a mac when a game is in windows mode
(see other threads this month).
Mac OS X:
?* Verified that SDL correctly reports swapped red and blue channels
in fullscreen mode
Good. Fullscreen works fine with the game I’m building (Globulation 2
http://globulation2.org). But in windowed mode, the colours are
really warped. Things that should be black are bright blue, thinks
that should be yellow/white/green are bright blue as well.
…
gcc -D_GNU_SOURCE=1 -I/opt/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE -DCMD_MUSIC -DWAV_MUSIC -DMOD_MUSIC -I./mikmod -DMID_MUSIC -DUSE_TIMIDITY_MIDI -I./timidity -DUSE_NATIVE_MIDI -I./native_midi -c ./native_midi/native_midi_mac.c -fno-common -DPIC -o build/.libs/native_midi_mac.o
./native_midi/native_midi_mac.c:51: error: ‘NoteRequest’ undeclared here (not in a function)
./native_midi/native_midi_mac.c:79: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘gTunePlayer’
./native_midi/native_midi_mac.c: In function ‘native_midi_loadsong’:
./native_midi/native_midi_mac.c:134: error: ‘gTunePlayer’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:134: error: (Each undeclared identifier is reported only once
./native_midi/native_midi_mac.c:134: error: for each function it appears in.)
./native_midi/native_midi_mac.c:135: error: ‘kTunePlayerComponentType’ undeclared (first use in this function)
./native_midi/native_midi_mac.c: In function ‘native_midi_loadsong_RW’:
./native_midi/native_midi_mac.c:197: error: ‘gTunePlayer’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:198: error: ‘kTunePlayerComponentType’ undeclared (first use in this function)
./native_midi/native_midi_mac.c: In function ‘native_midi_freesong’:
./native_midi/native_midi_mac.c:239: error: ‘gTunePlayer’ undeclared (first use in this function)
./native_midi/native_midi_mac.c: In function ‘native_midi_start’:
./native_midi/native_midi_mac.c:251: error: ‘gTunePlayer’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:260: error: ‘kTuneStartNow’ undeclared (first use in this function)
./native_midi/native_midi_mac.c: In function ‘native_midi_stop’:
./native_midi/native_midi_mac.c:310: error: ‘gTunePlayer’ undeclared (first use in this function)
./native_midi/native_midi_mac.c: In function ‘native_midi_active’:
./native_midi/native_midi_mac.c:322: error: ‘gTunePlayer’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:324: error: ‘TuneStatus’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:324: error: expected ‘;’ before ‘ts’
./native_midi/native_midi_mac.c:326: error: ‘ts’ undeclared (first use in this function)
./native_midi/native_midi_mac.c: In function ‘native_midi_setvolume’:
./native_midi/native_midi_mac.c:335: error: ‘gTunePlayer’ undeclared (first use in this function)
./native_midi/native_midi_mac.c: In function ‘BuildTuneSequence’:
./native_midi/native_midi_mac.c:432: error: ‘kFirstDrumkit’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:434: error: ‘kFirstGMInstrument’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:504: error: ‘kControllerVolume’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:516: error: ‘kControllerPan’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:567: error: ‘kControllerPitchBend’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:618: error: ‘kEndMarkerValue’ undeclared (first use in this function)
./native_midi/native_midi_mac.c: In function ‘BuildTuneHeader’:
./native_midi/native_midi_mac.c:627: error: ‘myNoteRequest’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:628: error: ‘NoteAllocator’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:628: error: expected ‘;’ before ‘myNoteAllocator’
./native_midi/native_midi_mac.c:633: error: ‘myNoteAllocator’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:638: error: ‘kNoteAllocatorComponentType’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:661: error: ‘kGeneralEventNoteRequest’ undeclared (first use in this function)
./native_midi/native_midi_mac.c:662: error: expected expression before ‘)’ token
./native_midi/native_midi_mac.c:688: error: ‘kEndMarkerValue’ undeclared (first use in this function)
make: *** [build/native_midi_mac.lo] Error 1
