Mon, 02 Jan 2006 08:07:41 +0000 Toggle flip debugging in testsprite.c on the command line, not as a hardcoded
Ryan C. Gordon <icculus@icculus.org> [Mon, 02 Jan 2006 08:07:41 +0000] rev 1214
Toggle flip debugging in testsprite.c on the command line, not as a hardcoded #define. --ryan.
Mon, 02 Jan 2006 07:09:52 +0000 Quartz target shouldn't crash if an event thread is used.
Ryan C. Gordon <icculus@icculus.org> [Mon, 02 Jan 2006 07:09:52 +0000] rev 1213
Quartz target shouldn't crash if an event thread is used. (SDL_INIT_EVENTTHREAD still doesn't work, but the crash is gone...)
Mon, 02 Jan 2006 00:31:00 +0000 To: sdl@libsdl.org
Ryan C. Gordon <icculus@icculus.org> [Mon, 02 Jan 2006 00:31:00 +0000] rev 1212
To: sdl@libsdl.org From: Christian Walther <cwalther@gmx.ch> Date: Thu, 15 Dec 2005 21:19:53 +0100 Subject: [SDL] More mouse enhancements for Mac OS X The attached patch brings two more enhancements to mouse handling on Mac OS X (Quartz): 1. Currently, after launching an SDL application, SDL's notion of the mouse position is stuck in the top left corner (0,0) until the first time the mouse is moved. That's because the UpdateMouse() function isn't implemented in the Quartz driver. This patch adds it. 2. When grabbing input while the mouse cursor is hidden, the function CGAssociateMouseAndMouseCursorPosition(0) is called, which prevents the system's notion of the mouse location from moving (and therefore leaving the SDL window) even when the mouse is moved. However, apparently the Wacom tablet driver (and maybe other special pointing device drivers) doesn't care about that setting and still allows the mouse location to go outside of the window. Interestingly, the system cursor, which is made visible by the existing code in SDL in that case, does not follow the mouse location, but appears in the middle of the SDL window. The mouse location being outside of the window however means that mouse button events go to background applications (or the dock or whatever is there), which is very confusing to the user who sees no cursor outside of the SDL window. I have not found any way of intercepting these events (and that's probably by design, as "normal" applications shouldn't prevent the user from bringing other applications' windows to the front by clicking on them). An idea would be placing a fully transparent, screen-filling window in front of everything, but I fear that this might affect rendering performance (by doing unnecessary compositing, using up memory, or whatever). The deluxe solution to the problem would be talking to the tablet driver using AppleEvents to tell it to constrain its mapped area to the window (see Wacom's "TabletEventDemo" sample app, http://www.wacomeng.com/devsupport/mac/downloads.html), but I think that the bloat that solution would add to SDL would outweigh its usefulness. What I did instead in my patch is reassociating mouse and cursor when the mouse leaves the window while an invisible grab is in effect, and restoring the grab when the window is entered. That way, the grab can still be effectively broken by a tablet, but at least it's obvious to the user that it is broken. That change is minimal - it doesn't affect operation with a mouse (or a trackpad), and the code that it adds is not executed on every PumpEvents() call, only when entering and leaving the window. Unless there are any concerns about the patch, please apply. Feel free to shorten the lengthy comment in SDL_QuartzEvents.m if you think it's too verbose. Thanks -Christian
Sun, 01 Jan 2006 23:45:52 +0000 To: sdl@libsdl.org
Ryan C. Gordon <icculus@icculus.org> [Sun, 01 Jan 2006 23:45:52 +0000] rev 1211
To: sdl@libsdl.org From: Christian Walther <cwalther@gmx.ch> Date: Wed, 28 Dec 2005 12:13:20 +0100 Subject: [SDL] Fix for opening documents on Mac OS X < 10.4 The current code in SDLMain.m that transforms documents opened from the Finder into command-line arguments (introduced in revision 1.14, 2005-08-11) uses the methods -[NSString lengthOfBytesUsingEncoding:] and -[NSString getCString:maxLength:encoding:], which are only available in Mac OS X 10.4. Compiling this code on 10.3 produces warnings, and running it (i.e. starting an SDL application by opening a document) leads to weird behavior which I didn't investigate in detail ("*** -[NSCFString lengthOfBytesUsingEncoding:]: selector not recognized" is printed to the console log, and the SDL window never opens). The attached patch removes the offending calls and uses -[NSString UTF8String] instead, which is available everywhere. Tested on 10.3.9, and I see no reason why it shouldn't also work on 10.2 and 10.4. Two further comments: * The comment above the -[SDLMain application: openFile:] implementation says "You need to have a CFBundleDocumentsType section in your Info.plist to get this message, apparently." This is not the case in my experience - it worked just fine with a hand-built bare-bones application consisting only of Test.app/Contents/MacOS/test, without any Info.plist (although you have to press the option and command keys for such an application to accept a dragged file). * I took the liberty of cleaning up another area of SDLMain.m: I changed "CustomApplicationMain (argc, argv)" to "CustomApplicationMain (int argc, char **argv)". This avoids the "type of `argv' defaults to `int'" warnings, and I'm not sure if leaving out the types could cause problems on platforms where an int and a char** aren't of the same size. -Christian
Sun, 01 Jan 2006 23:34:06 +0000 Bumped windib's priority above DirectX, since both DirectDraw and DirectInput
Ryan C. Gordon <icculus@icculus.org> [Sun, 01 Jan 2006 23:34:06 +0000] rev 1210
Bumped windib's priority above DirectX, since both DirectDraw and DirectInput seem to be giving people issues on newer Windows and DX revisions. We'll see if this is just a temporary fix or not... :/ --ryan.
Sun, 01 Jan 2006 19:14:11 +0000 Added preliminary missingtranslation from Atari to Unicode charset
Patrice Mandin <patmandin@gmail.com> [Sun, 01 Jan 2006 19:14:11 +0000] rev 1209
Added preliminary missingtranslation from Atari to Unicode charset
Fri, 23 Dec 2005 09:40:15 +0000 From: "alan buckley" <alan_baa@hotmail.com>
Sam Lantinga <slouken@libsdl.org> [Fri, 23 Dec 2005 09:40:15 +0000] rev 1208
From: "alan buckley" <alan_baa@hotmail.com> Subject: Patch for RISC OS cursor palette handling in SDL Date: Mon, 07 Nov 2005 09:14:15 -0800 The mouse cursor palette was not correctly restored on RISC OS if the system was using anything but the default mouse colours. Additionally I've modifed the order the wait for vsync is called as it should be after the screen bank switching.
Wed, 21 Dec 2005 18:02:36 +0000 To: sdl@libsdl.org
Ryan C. Gordon <icculus@icculus.org> [Wed, 21 Dec 2005 18:02:36 +0000] rev 1207
To: sdl@libsdl.org From: Christian Walther <cwalther@gmx.ch> Date: Wed, 21 Dec 2005 13:39:39 +0100 Subject: [SDL] Another mouse bug patch for Mac OS X Oh my, yet another change in the quartz mouse handling code! :) The attached patch fixes the following bug: Calling SDL_WarpMouse() while the cursor is invisible and grabbed should only update SDL's internal mouse location, not try to warp the system cursor (which is not at that location, but fixed in the middle of the window). Otherwise, the next mouse motion event is wrong. Please apply. Thanks Christian
Mon, 19 Dec 2005 06:58:51 +0000 Patched to compile on gcc 2.95.3.
Ryan C. Gordon <icculus@icculus.org> [Mon, 19 Dec 2005 06:58:51 +0000] rev 1206
Patched to compile on gcc 2.95.3.
Wed, 14 Dec 2005 05:55:17 +0000 Updated to the latest glext.h
Sam Lantinga <slouken@libsdl.org> [Wed, 14 Dec 2005 05:55:17 +0000] rev 1205
Updated to the latest glext.h
(0) -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip