From: Vassilis Virvilis <vasvir@iit.demokritos.gr>
Subject: [SDL] Request: Please reconsider adding tag in SDL_Event
Hi,
Patch in question:
--- include/SDL_events.h 20 Aug 2004 18:57:01 -0000 1.11
+++ include/SDL_events.h 19 Jan 2006 17:35:09 -0000
@@ -214,7 +214,7 @@
} SDL_SysWMEvent;
/* General event structure */
-typedef union {
+typedef union SDL_Event {
Uint8 type;
SDL_ActiveEvent active;
SDL_KeyboardEvent key;
Reasoning:
----------
1) Allows forward declaration of the SDL_Event union in C++. Please
note that in plain C it is possible to forward declare it.
2) Forward declaration is good because it allows encapsulation. It hides
the specific implementation and does not necessarily exposes SDL staff
to my appication's namespace
3) It can't harm plain C because tags are living in a different namespace
than typenames
4) It is already done like this in other places in SDL. Check for example
SDL_KeySym, and SDL_.*Event structures.
5) Right now I have to include SDL/event.h from a C++ header file. See 2)
Following commit 1.51, I come accross a problem when SDL must choose between
several video modes that could suit the one asked.
If I ask 320x240 with this list:
768x480 768x240 640x400 640x200 384x480 384x240 320x400 320x200
The smallest selectables modes are 384x240 and 320x400. And SDL choose the later
in this list, but 384x240 is more suitable. So I added a check to compare
the pixel count (surface) of modes, and select the one which has the smallest
pixel count.
In my example, 384x240 has 92160 pixels, and 320x400 has 128000 pixels. So now
SDL will choose 384x240 for the asked 320x240 mode.
queried for a missing extension (such as the XiG vidmode one that most
people don't have), and default Xlib behaviour is to write notification to
stderr, this tends to generate incorrect bug reports.
Since we'll actually deal with the missing extension when querying for it,
we ignore these errors in our hook. The rest continue to pass through to
the default handler.
Fixes Bugzilla #42.
--ryan.
changed in five years, and it's a small .c file that just calls into the X11
dependencies we already use elsewhere. Including it directly allows us to
make use of the dynamic X11 code.
Fixes Bugzilla #41.
--ryan.
There are a couple of issues with the selection of Altivec alpha-blitting
routines in CalculateAlphaBlit() in src/video/SDL_Blit_A.c.
1) There's no check for the presence of Altivec when checking if the
Blit32to565PixelAlphaAltivec() routine can be selected.
2) Altivec cannot be used in video memory, and there's no check if the
destination surface is a hardware surface. (Alpha-blitting to a hardware
surface with GPU support is a bad idea, but somebody's bound to do it anyway.)
Patch to fix these attached.
- libsdl-PIC-load-mmx-masks-from-stack.patch
this one may be a little controversial ... the fix here is again that you cant
reference the memory addresses like this to load into a mmx register, so the
way to do it is to push two 32bit words onto the stack, load the 64bit value
off of the stack into the mmx register, and then adjust the stack so that
it's back to normal.
- libsdl-SDL_stretch-PIC.patch
ignoring the general fact of how SDL_stretch relies on executing dynamic code,
the inline asm should let gcc handle the a details for getting the actual
address for _copy_row as it will do the right thing
test case: http://dev.gentoo.org/~vapier/libsdl/sdl-stretch.tar.bz2
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
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
