Fixed a bug where only mouse wheel up was sent on Mac OS X
Fixed a bug where mouse window focus was getting hosed by the fullscreen mouse code on Mac OS X
* Switched event type to enum (int32)
* Switched polling by mask to polling by type range
* Added SDL_RegisterEvents() to allow dynamic user event registration
* Spread events out to allow inserting new related events without breaking binary compatibility
* Added padding to event structures so they're the same size regardless of 32-bit compiler structure packing settings
* Split SDL_HasEvent() to SDL_HasEvent() for a single event and SDL_HasEvents() for a range of events
* Added SDL_GetEventState() as a shortcut for SDL_EventState(X, SDL_QUERY)
* Added SDL_FlushEvent() and SDL_FlushEvents() to clear events from the event queue
Gerry JJ 2008-11-09 02:11:49 PST
The SDL_MouseMotionEvent struct has a field named "tilt" (currently marked "for
future use"), for tablet stylus tilt information. However, one value is not
enough for this, as tilt is two-dimensional. Reserving only one field for
future use is no good when you're going to need two, so there should be two
fields, tilt_x and tilt_y.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%404321
Since many different event structures include windowID it should be placed near
the beginning of the structure (preferably right after type) so it's position
is the same between different events.
This is to avoid code like this:
if (event.type == SDL_WINDOWEVENT)
win = event.window.windowID;
else if ((SDL_EVENTMASK(event.type) & SDL_KEYEVENTMASK) != 0)
win = event.key.windowID;
else if (event.type == SDL_TEXTINPUT)
win = event.text.windowID;
else if (event.type == SDL_MOUSEMOTION)
win = event.motion.windowID;
else if ((SDL_EVENTMASK(event.type) & (SDL_MOUBUTTONDOWNMASK |
SDL_MOUBUTTONUPMASK)) != 0)
win = event.button.windowID;
else if (event.type == SDL_MOUSEWHEEL)
win = event.wheel.windowID;
...
in favor of:
win = event.window.windowID;
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403650
Fixed building SDL without XInput support
Simplified the process of registering a mouse device
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403402
From: Couriersud
Subject: SDL: Mouse last_x, last_y into SDL_Mouse
the attached diff moves the static vars last_x and last_y into
SDL_Mouse. These, as far as I understand it, should be tied to the
individual mouse.
The patch also makes the code check for out of window conditions of
mouse->x,y when relative movements are passed to MouseSendMotion.
Also attached is the latest DirectFB code (dfb20081208) supporting
multiple mice and keyboards. This works quite well with sdlmame now. It
however needs more testing with different directfb configurations.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403322
From: Couriersud
Subject: SDL: Relative mouse movements
The patch below will reenable processing of relative mouse movements.
The DirectFB drivers generates those in "grabbed" mode. These ensure,
that even in fullscreen mode relative movements are reported. SDLMAME
depends on this for games with trackballs.
Looking at the code I ask myself whether relative movements should be
handled in the drivers (x11, directfb). Both x11 and directfb are able
to report relative movements. This would leave it to the driver to use
the most appropriate method for relative movements when at the border of
a fullscreen window or being "grabbed".
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403303
Bring SDL to iPhone and iPod Touch
by Holmes Futrell, mentored by Sam Lantinga
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403222
Many-mouse and tablet support
by Szymon Wilczek, mentored by Ryan C. Gordon
Everything concerning the project is noted on the wiki:
http://wilku.ravenlord.ws/doku.php?id=start
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403155
I'm using SDL 1.2.9 with Visual C++ 7.0 on Windows 2000.
Here's the setup: my game starts in a window, with
SDL_WM_GrabInput(SDL_GRAB_ON) to constrain the cursor to the game window. The
mouse cursor is outside of the window when the game launches, and when the
window appears the cursor is grabbed and placed at the top left corner of the
inside of the game window. At this point, if I click the mouse without moving
it, the SDL_MOUSEBUTTONDOWN event's mouse coordinates are (65535,65535).
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401529
Make sure every source file includes SDL_config.h, so the proper system
headers are chosen.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401406
FIXME:
Change #include <stdlib.h> to #include "SDL_stdlib.h"
Change #include <string.h> to #include "SDL_string.h"
Make sure nothing else broke because of this...
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401340
I batch edited these files, so please let me know if I've accidentally removed anybody's
credit here.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401315
From: "SkunkGuru"
Subject: [SDL] Repeated mousemotion event on notebook
it seems that every ~500ms something fires a mousemotion event,
but with the same x and y position.
I tryed with both directx and windib video driver.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401286
From: Jiri Svoboda
Subject: [SDL] signal handling bug
I encountered the following bug:
SDL doesn't reset signal handlers for SIGTERM and SIGINT, after calling SDL_Quit these remain hooked to the handler in SDL_quit.c, being translated into SDL_QUIT events.
Consequently an application that issues a SDL_Quit and remains running will ignore any SIGTERM or SIGINT., and specifically CTRL-C presses.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401124
From: "Philippe Anctil"
Subject: [SDL] odd mouse event generated on init
The mouse relative and absolute coordinates appear to be always equal for
the first mouse event.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40944
