From: Eric Wing
Subject: SDL/Universal Binary updates

Hi Sam,
Attached is a big set of changes to the Xcode projects to support
Universal Binaries. I have also included .dmgs that include the
prebuilt frameworks.

Ryan, I also updated SMPEG which is also in the package.

The SDL and smpeg binaries were built against the CVS version (pulled
maybe a month ago?).

I do not have an Intel Mac to test on so I have no idea if this stuff
actually works. However, Christian Walther has been a big help in
testing 10.2.8 and 10.3.9 so I'm fairly confident we got the build
settings correct for at least PPC.

I have attempted to document the important things for producing these
Universal Binaries. Documentation is somewhat scattered through out
everything, but there is a big centralized piece of documentation in
the UniversalBinaryNotes.rtf in the SDL.dmg.

As far as Universal Binaries are concerned, the big things were:
- Build with gcc 3.3 on PPC, 4.0 on Intel.
- We couldn't get any of the MMX/SSE code to compile/link (SDL and
smpeg).
- All 3rd party dependencies had to be rebuilt as Universal

There were also a bunch of non-Universal things that have been updated:
- I converted the SDL-satellites to create .dmg's instead of .pkg
installers
- Updated all 3rd party static libraries with current versions. (I
think libpng was the most dramatic going from 1.0.? to 1.2.8 with API
breakage. I haven't found any problems so far in doing this.)
- Changed some compiler optimization settings
- Finally updated the exports list for SDL_mixer
- Tried to include a static smpeg in SDL_mixer (multiple build
variants in Xcode project now)
- Enabled Altivec in SDL (we forgot to add the flags to Xcode last time)
- More documentation

Since so many things have changed, there might be new problems
introduced. The big issue I've found so far is with SDL_mixer. As I
mentioned on the mailing list, MP3's produce an assertion failure.
And the MikMod problem reported on Bugzilla continues to persist.

There's probably a bunch of other stuff I'm forgetting. There really
were hundreds of little things I mucked with so it's hard to remember
them all.

If you have any questions, feel free to ask.

Thanks,
Eric

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401324

  Fixes Bugzilla #131.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401323

 when it should be != NULL.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401322

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401321

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401320

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401319

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401318

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401317

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401316

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

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401314

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401313

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401312

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401311

(Resolves bug #114)

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401310

  Reference Bugzilla #116.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401309

https://bugzilla.libsdl.org/attachment.cgi?id=3

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401308

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401307

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

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401304

Fixes Bugzilla #64.

--ryan.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401303

Fixes Bugzilla #87.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401302

is allowing linking with a shared object to be considered sufficient for
complying with section 6 of the LGPL.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401301

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401300

#include <SDL.h>

int main(int argc, char** argv)
{
        SDL_Init(SDL_INIT_EVERYTHING);
        SDL_SetVideoMode(640, 480, 0, SDL_FULLSCREEN);
        SDL_ShowCursor(SDL_DISABLE);
        SDL_Delay(1000);
        SDL_SetVideoMode(640, 480, 0, SDL_FULLSCREEN | SDL_OPENGL);
        SDL_Quit();
        printf("Everything okay\n");
}

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401299

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

From: ville
Subject: [SDL] Changing, at least some, anonymous enums to named enums.

Howdy,

Could, some if not all, enums be named rather than being anonymous enums?
I ran into troubles with the enum describing event types in SDL_events.h.
The problem is that an anonymous enum cannot be used in C++ templates like
so:

enum { C };

template< typename T >
void
f( T ) {
}


f( C );

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401297

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401296

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401295

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401294

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

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401291

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

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401289

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401288

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401287

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