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
From: "Michael Leonhard"
Subject: [SDL] resize bug on Win32 and patch
This is my first post to this mailing list. In this email I will detail a
bug in the behavior of resizable SDL windows on Win32. Then I will
explain the solution and provide a patch.
Symptoms:
Under Windows, an SDL display created with the SDL_RESIZABLE flag exhibits
quirky behavior when being maximized. The window is resized to the proper
size, but it is shifted upwards about half the height of the title bar.
Similarly, a window whose origin is above the top of the screen will
spontaneously move its upper-left origin upon being resized. After two
such resize-induced moves, the title bar will be entirely off the top edge
of the screen. Subsequently, when the mouse is clicked and released on
the window border, the window will shrink its height spontaneously. This
height shrinkage occurs even if the user did not resize the border.
To observe this curious situation, please invoke:
SDL-1.2.8/test/testwm.exe -resize
Cause:
A pair of integers, SDL_windowX and SDL_windowY, are defined in
video/wincommon/SDL_sysevents.c. They are used by the DirectX video
driver and the DIB video driver:
video/windx5/SDL_dx5video.c
video/windib/SDL_dibvideo.c
As I understand the source code, the primary use of these variables is to
create a rectangle that represents the surface area in CLIENT SPACE.
Client space refers to a coordinate system that originates at the upper
left corner of a Win32 Window's drawable area. This is just inside the
window border and title bar. This client space rectangle, called bounds,
is subsequently converted to screen space with a call to
AdjustWindowRectEx. The problem is found in SDL's handling of the
WM_WINDOWPOSCHANGED message. According to MSDN,
"The WM_WINDOWPOSCHANGED message is sent to a window whose
size, position, or place in the Z order has changed as a
result of a call to the SetWindowPos function or another
window-management function."
I have confirmed that this message is indeed being sent to the SDL window
when the mouse is clicked on the window border, even if the window border
is not dragged.
In video/wincommon/SDL_sysevents.c, on line 464, in response to the
WM_WINDOWPOSCHANGED message, the (potentially) new client rectangle is
obtained. This rectangle is translated into screen coordinates and THEN
assigned to the SDL_windowX and Y variables. Thus screen coordinates are
being assigned to client coordinate variables. Once this is understood,
the solution is apparent: assign SDL_windowX and Y before translating the
rectangle to screen coordinates. This is accomplished by the following
patch.
-Mike_L
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401290
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: 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.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401285
From: "Brian Kropf"
Subject: [SDL] Windx5
I was wondering if I could suggest a change for (at least) the mingw/msys
build. Every time I do the ./configure, make on a fresh download it crashes
when it tries to find directx.h for the audio portion of the build
In file included from SDL_dx5audio.c:37:
SDL_dx5audio.h:31:21: directx.h: No such file or directory
In file included from SDL_dx5audio.c:37:
I usually copy the directx.h from the video/windx5 into the audio/windx5 and
things go smoothly after that; just thought I'd suggest it for making future
builds go smoothly. ;)
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401277
From: Tyler Montbriand <tsm@accesscomm.ca>
Subject: Re: [SDL] Hardware buttons on pocket pc
I found it! :)
It has to do with the UNICODE translation code, in SDL_dibevents.c, in the
'#ifdef NO_GETKEYBOARDSTATE' block in DIB_HandleMessage(). The error
handling is a little... aggressive. If it can't translate from unicode, it
wipes out the virtual keycode.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401267
From: Ignacio Casta�o <castanyo@yahoo.es>
Subject: [SDL] SDL_GL_GetAttribute( SDL_GL_MULTISAMPLESAMPLES ...
It would be nice to add the following lines:
case SDL_GL_MULTISAMPLEBUFFERS:
*value = 0;
break;
case SDL_GL_MULTISAMPLESAMPLES:
*value = 1;
break;
in wincommon\SDL_wingl.c int the function WIN_GL_GetAttribute at line
484, so that it returns the correct values when arb_pixel_format is not
supported.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401264
From: Mike Shal
Subject: [SDL] Bug in SDL_wave.c?
Hey everyone, I'm not sure if this is a bug in SDL, or if I just have
incorrect WAV files. The problem I'm having is loading multiple
concatenated WAVs from SDL_LoadWAV_RW. Some WAV files put comments at
the end of the file (which may be bad form), and SDL doesn't skip past
them when reading from the RWops. So the next WAV I try to load will
start at the comment section of the previous WAV, which obviously
doesn't work. If anyone else is having this problem, one quick fix you
can do is run sox on the bad WAVs, which strips out all of the comment
sections.
Eg:
$ sox sound.wav tmp.wav
$ mv -f tmp.wav sound.wav
The other fix is to patch SDL_wave.c, which is included with this email.
(Assuming I made the patch correctly :). All it does is calculate how
much remaining space there is in the WAV file after the data chunk, and
does SDL_RWseek to skip it. I don't think it should interfere with
anything else, but if someone could check it that would be nice :). If
the bug is really with SDL and not with my WAVs, can someone work this
into the next version of SDL? Thanks,
-Mike Shal
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401263
From: "Jim"
Subject: [SDL] Frame buffer patches...
Would seem that GCC 3.2.2 promotes all signed values to unsigned if any single vlaue is unsigned in an expression...
for instance when calculating an elo touch position....evertyhign is an (int) except for cach_vinfo.xres which is unsigned. THerefore if y
ou reverse the SDL_ELO_MIN_X and SDL_ELO_MAX_X values the resulging negative value pegs the expression to it's max. Attached it the accumu
lated patch to typecast the unsigned values to (int)
- *dx = (cache_vinfo.xres - (cache_vinfo.xres * (input_x - ELO_MIN_X)) / width);
+ *dx = ((int)cache_vinfo.xres - ((int)cache_vinfo.xres * (input_x - ELO_MIN_X)) / width);
and also to provide quite failure to operations which have the screen currently locked...
The touch screen I'm using the original values were exactly opposite of any position I touched on the screen - evaluating the math the expr
ession SHOULD have handled reversing the min and max values - and after casting the unsigned .xres and .yres to a signed int - worked well.
..
Jim
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401262
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.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401260
This is a collaborative effort between Alex Volkov and John Popplewell.
Thanks guys! (Fixes bug #39)
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401256
