The current SVN trunk is missing the SDLCALL specifier at numerous locations.
It has to be added for all (possibly user provided) callbacks.
I stumbled over this while creating a makefile for the OpenWatcom compiler for
Win32.
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).
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...
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.
From: jimrandomh
Subject: [SDL] Re: Modifier keys pressed during initialization stick
I wrote a simple test program which initializes SDL, prints the SDL
version number, then prints any keydown and keyup events with their
modifiers. (Source code below). Compilation was done using Visual
Studio 6, release mode.
My test sequence was:
Start a command prompt. Type the name of the test program.
shift down
enter down (program starts)
Wait for window to appear
enter up
shift up
spacebar down
spacebar up
Under Windows 98, the output was correct:
SDL 1.2.8
left shift down
shift-return down
shift-return up
left shift up
space down
space up
Under Windows 2000 and under Windows XP, the output was:
SDL 1.2.8
shift-space down
shift-space up
Since shift was not held at the time space was pressed, this is
incorrect. Similar results were observed with launching in different
ways (including double-clicking in Windows Explorer), so it does not
depend on the launching terminal.
--ryan.
Date: Sun, 19 Jun 2005 15:53:22 -0700
From: Joshua Oreman <oremanj@gmail.com>
To: sdl@libsdl.org
Subject: [SDL] [PATCH] iPod framebuffer video driver
Hi SDL-list,
I've been working on a port of SDL to iPodLinux
(http://www.ipodlinux.org). I've created a patch for both the
standard 2-bit iPod screen (using an unchangeable palette) and the
16-bit iPod photo. The patch is attached, against version 1.2.8.
I've created two pages on the iPodLinux wiki about this patch:
http://www.ipodlinux.org/Building_SDL and
http://www.ipodlinux.org/SDL_Programming. See those pages if you're
curious.
Comments? Questions? Is this something that might be able to get into SDL 1.2.9?
Thanks for your feedback!
-- Josh
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.
* SDL_timer_running wasn't always updated correctly.
* Fixed occasional crash in SDL_SetTimer() when clearing threaded timers
* It was possible to get both the timer thread and event thread running
* Other misc. cleanup
From: Jon Daniel
Subject: [SDL] KeyRepeat fix
If you switch keys very fast and hold the last one it
doesn't get repeated because the key release of the first key
occured after the key press of the second key.
Unfortunatly the key release of the first key sets
SDL_KeyRepeat.timestamp = 0; causing the the second key not to repeat.
This should be always reproducable. I've only checked this on x86-64
X11.
To fix this I just added another condition to make sure the sym of the
released key matches SDL_KeyRepeat.key.keysym.sym.
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.
