Fixed crash: #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"); }

Date: Sun, 6 Mar 2005 17:06:20 +0100 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

Date: Fri, 18 Feb 2005 20:49:35 +0200 (EET) 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 );

Added some useful command line arguments for testing

Fixed palette bug on non-WinCE

Only save the window position if we're in windowed mode

The event code was fine, and calculated the SDL_windowX/Y correctly. What we really needed to do was avoid doing client rect adjustment on zoomed windows. :)

Date: Fri, 18 Feb 2005 07:58:00 +0200 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.

Cleaned up the app registration stuff a bit

Date: Tue, 15 Feb 2005 21:28:48 +0900 (JST) 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