Sat, 27 Jul 2013 13:09:15 -0400 Added a FIXME discussion to last commit.
Ryan C. Gordon <icculus@icculus.org> [Sat, 27 Jul 2013 13:09:15 -0400] rev 7535
Added a FIXME discussion to last commit.
Mon, 22 Jul 2013 20:55:07 -0400 Cocoa: Make the next-highest window gain focus when a window is closing.
Ryan C. Gordon <icculus@icculus.org> [Mon, 22 Jul 2013 20:55:07 -0400] rev 7534
Cocoa: Make the next-highest window gain focus when a window is closing. (if the closed window wasn't the foreground, this is effectively a no-op.)
Sat, 27 Jul 2013 14:22:52 +0200 Fixed SDL_HapticOpened() returning -1 instead of 0.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Sat, 27 Jul 2013 14:22:52 +0200] rev 7533
Fixed SDL_HapticOpened() returning -1 instead of 0. According to header file it should only return 0 or 1.
Sat, 27 Jul 2013 14:06:06 +0200 Removed C++ macro setup in internal header for Android port which is only C now.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Sat, 27 Jul 2013 14:06:06 +0200] rev 7532
Removed C++ macro setup in internal header for Android port which is only C now.
Sat, 27 Jul 2013 13:52:16 +0200 Fixed SDL_HapticRumblePlay() maybe working because of SDL_HapticUpdateEffect().
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Sat, 27 Jul 2013 13:52:16 +0200] rev 7531
Fixed SDL_HapticRumblePlay() maybe working because of SDL_HapticUpdateEffect().
Sat, 27 Jul 2013 13:39:43 +0200 Corrected SDL_HapticUpdateEffect() returning 0 instead of index of effect.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Sat, 27 Jul 2013 13:39:43 +0200] rev 7530
Corrected SDL_HapticUpdateEffect() returning 0 instead of index of effect. According to documentation in header and wiki the index should be returned. This change may break existing programs which assume only 0 means a success.
Sat, 27 Jul 2013 03:48:23 -0700 Added example of using the software renderer and window surface API, contributed by Nitin Jain.
Sam Lantinga <slouken@libsdl.org> [Sat, 27 Jul 2013 03:48:23 -0700] rev 7529
Added example of using the software renderer and window surface API, contributed by Nitin Jain.
Sat, 27 Jul 2013 03:44:03 -0700 Fixed bug 1983 - SDL_thread.h broken under MinGW crosscompiling environment
Sam Lantinga <slouken@libsdl.org> [Sat, 27 Jul 2013 03:44:03 -0700] rev 7528
Fixed bug 1983 - SDL_thread.h broken under MinGW crosscompiling environment q66 after updating SDL2 to the latest RC I'm unable to build my game engine under mingw crosscompiling environment for Windows (32bit, hosted on freebsd 64bit). The error is in SDL_thread.h with messages like this: http://codepad.org/jEQXd3Yq The problem is, while _beginthreadex return type is correctly mapped to uintptr_t (as specified by Microsoft), the return type under mingw is unsigned long int (same size, different signature), resulting in the error above. The reason it didn't error before is this: http://codepad.org/8FAbKAxz You can see the _beginthreadex case is only used without HAVE_LIBC defined; at one point though, SDL_config_windows.h was changed like this: -/* Enabled for SDL 1.2 (binary compatibility) */ -#define HAVE_LIBC 1 +/* This is disabled by default to avoid C runtime dependencies and manifest requirements */ resulting in these errors.
Sat, 27 Jul 2013 03:22:37 -0700 Fixed variable scoping for Windows build
Sam Lantinga <slouken@libsdl.org> [Sat, 27 Jul 2013 03:22:37 -0700] rev 7527
Fixed variable scoping for Windows build
Sat, 27 Jul 2013 03:20:09 -0700 Fixed bug 1272 - Bogus numlock key up/down events being reported on MacOS X
Sam Lantinga <slouken@libsdl.org> [Sat, 27 Jul 2013 03:20:09 -0700] rev 7526
Fixed bug 1272 - Bogus numlock key up/down events being reported on MacOS X Vern Jensen The problem is that in certain situations I'm getting THREE keyUp/keyDown events when I push certain keys. In my event code I added: case SDL_KEYUP: printf("SDL KeyScanCode for KEYUP event: %d\n", event->key.keysym.scancode ); … and case SDL_KEYDOWN: printf("SDL KeyScanCode for KEYDOWN event: %d\n", event->key.keysym.scancode ); … The result of one test run where I push 2 keys and then release them is this: SDL KeyScanCode for KEYDOWN event: 92 // Pushed keypad 4 SDL KeyScanCode for KEYDOWN event: 83 // Pushed left shift SDL KeyScanCode for KEYUP event: 83 SDL KeyScanCode for KEYDOWN event: 225 SDL KeyScanCode for KEYUP event: 92 // Released keypad 4 SDL KeyScanCode for KEYDOWN event: 83 SDL KeyScanCode for KEYUP event: 83 SDL KeyScanCode for KEYUP event: 225 // Released left shift There *should* be only a total of 4 events above… 2 for each key being pushed, and 2 for each being released. But instead some bogus events for numlock being pushed/released are sent from SDL. These events did not occur. I did not push numlock. The value above for numlock is 83. Comments above show when I pushed each key. As you can see, when I push left shift, THREE events are instantly sent to my application, keyDown and then keyUp for numlock, and then the valid event for left shift (the key that was actually pushed). You could replace keypad 4 with pretty much any keyPad key and it'll still happen. You can also replace it with any arrow key and it'll happen. However, when trying it with normal letter keys on the main keyboard it didn't. It happens with other modifier keys too, not just left shift. The order in which the keys are pressed matter. For instance, if I do: 1) keypad 4 2) left shift 3) release left shift 4) release keypad 4 Then at step 2, I get the 3 events above (when there should be only one), but steps 3 and 4 work properly… I don't get extra keyUp/keyDown events for steps 3 or 4. Thereas if the order of steps 3 and 4 are reversed, I get the bogus extra events for numlock. Also, the problem can occur even when pushing just a single key by itself. If I push left shift, then keypad 4, then release left shift, then release keypad 4, then the following push of left shift will cause the bug. If I continue pushing and releasing left shift though, it won't happen again until I again involve keypad keys. --- Sam Lantinga According to the Apple documentation, NSNumericPadKeyMask is set for any arrow or numeric keypad event. Indeed this is what's happening. I verified that we get the correct events for the numlock key and the mod state gets set correcly, so it should be safe to remove this bogus code.
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip