From: "mystml@adinet.com.uy"
Subject: [SDL] ALT-F4 using DirectX
My game isn't getting SDL_QUIT when I press ALT-F4 using the DirectX
driver; it does get SDL_QUIT when I press the red X in the window.
I tracked this down to DX5_HandleMessage() in SDL_dx5events.c;
WM_SYSKEYDOWN is being trapped and ignored which causes Windows not to post
a WM_CLOSE, hence no SDL_QUIT is being generated.
The relevant code is this :
/* The keyboard is handled via DirectInput */
case WM_SYSKEYUP:
case WM_SYSKEYDOWN:
case WM_KEYUP:
case WM_KEYDOWN: {
/* Ignore windows keyboard messages */;
}
return(0);
If I comment the WM_SYSKEYDOWN case, it falls through DefWindowProc() and
ALT-F4 starts working again.
I'm not sure about the best way to fix this. One option is handling ALT-F4
as a particular case somehow, but doesn't sound good. Another option would
be to handle WM_SYSKEYDOWN separately and breaking instead of returning 0,
so processing falls through and goes to DefWindowProc which does The Right
Thing (TM). This seems to be the minimal change that makes ALT-F4 work and
normal keyboard input continues to work.
Does this sound reasonable? Am I overlooking anything? Do I submit a patch?
--Gabriel
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401352
I'm still wrestling with autoheader, but this should work for now...
Fixed lots of build problems with C library support disabled
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401345
it doesn't show the desktop between modes anymore.
Fixes Bugzilla #100.
--ryan.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401344
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
From: Hayashi Naoyuki
Subject: Re: [SDL] Character Composition problem on X
The compilation fails.
cc: Error: SDL_x11events.c, line 717: In this statement, "XK_dead_hook"
is not declared. (undeclared)
ODD_keymap[XK_dead_hook&0xFF] = SDLK_COMPOSE;
-------------------^
cc: Error: SDL_x11events.c, line 718: In this statement, "XK_dead_horn"
is not declared. (undeclared)
ODD_keymap[XK_dead_horn&0xFF] = SDLK_COMPOSE;
Neither XK_dead_hook nor XK_dead_horn are defined on Tru64.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401332
Use XFilterEvent() to handle dead-key composition under X11
Cleaned up the code in preparation for 1.3 API changes
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401331
I tried to compile with gcc on Tru64, and got the following error.
SDL_systimer.c:45:45: error: operator '&&' has no right operand
It succeeds if changing
#if (defined _POSIX_TIMERS && _POSIX_TIMERS > 0)
to
#if (defined _POSIX_TIMERS && _POSIX_TIMERS + 0 > 0)
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401329
Use the real executable's name for the window class, if it's available.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401328
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: Sean Childs
Subject: [SDL] Compiling SDL 1.2.8 with the free Borland compiler
When compiling SDL 1.2.8 with the free Borland compiler, I received this
error (there is a similar error that occurs in
src\video\windx5\sdl_dx5events.c):
Error E2342 ..\..\src\video\windib\sdl_dibevents.c 189: Type mismatch in
parameter 'lpPrevWndFunc' (wanted 'int (__stdcall *)()', got 'long
(__stdcall *)(void *,unsigned int,unsigned int,long)') in function
DIB_HandleMessage
I checked the MSDN library at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/
windowsuserinterface/windowing/windowprocedures/windowprocedurereference/wind
owprocedurefunctions/callwindowproc.asp
and it had this to say:
If STRICT is not defined, the lpPrevWndFunc parameter has the data type
FARPROC. The FARPROC type is declared as follows:
int (FAR WINAPI * FARPROC) ()
In C, the FARPROC declaration indicates a callback function that has an
unspecified parameter list. In C++, however, the empty parameter list in
the declaration indicates that a function has no parameters. This subtle
distinction can break careless code. Following is one way to handle this
situation:
#ifdef STRICT
WNDPROC MyWindowProcedure
#else
FARPROC MyWindowProcedure
#endif
...
lResult = CallWindowProc(MyWindowProcedure, ...)
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401306
From: Andrew Fuller
Subject: [SDL] [PATCH] ML-8866 PS2->USB converter
This converter seems to go by several names -- Super Dual Box, Dual
USB Joypad, and who knows what else. Also branded differently with
different colour cases, etc. But it seems to all be the same
internals. It is a common converter used for StepMania, with several
posts Googleable trying to make it work in Linux. I got mine
yesterday and wanted to play stepmania, so I went ahead and made a
crude patch for libsdl to split this baby into two logical joysticks.
A couple notes about the patch:
This patch works well for two dance mats hooked up and playing
stepmania, however the mapping of the other buttons may be off. I
have no joystick which uses all the buttons the converter reports, so
I have no way of testing them.
The name I used 0925:8866 which is the USB ID, and what SDLjoytest-GL
reported is the name, even though lsusb shows Wisegroup, Ltd MP-8866
Dual USB Joypad, and the existing virtual joystick mapping uses the
Wisegroup... name. Not sure why the discrepency.
I'm not subscribed to this mailing list, so please CC me on any
comments to this.
-Andrew
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401305
From: Per Inge Mathisen
Subject: [SDL] Fullscreen refresh on win32
Windows has a terrible default for fullscreen 3D apps of 60mhz refresh
rate. This can be fixed by the user by going into his driver's
control panel and forcing the refresh rate higher. However, this not a
very user friendly way about it, and in any case SDL contains no code
that could figure out this that condition has afflicted the user.
So the question is, could SDL fix this for the user? It is possible
under Windows to request a higher refresh rate. The danger is of
course that if the user has an old monitor, and you request a too high
refresh rate, the monitor could be damaged. However, I believe there
might be a way around that: Check before switching what refresh rate
the user's desktop runs in, and if our fullscreen dimensions are equal
or less than those of the desktop, use the higher refresh rate of 60
and the desktop rate.
Since most users run their desktops in the same or higher resolution
something sane, this should fix this problem for most users.
Thoughts?
An alternative is to add an SDL_GL_GetAttribute(SDL_GL_REFRESH_RATE)
option so that programs can bitch at their users at their own
convenience.
- Per
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401298
What we really needed to do was avoid doing client rect adjustment on
zoomed windows. :)
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401293
From: "Mike Gorchak"
Subject: [SDL] [PATCH] QNX6 and not only QNX6 fixes
1) Update SDL.qpg.in for the QNX 6.3.
4) video/photon/SDL_phyuv.c - fixed bug with swapped U and V planes, using
YV12 mode with radeon cards.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401292
