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

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

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

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

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

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

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

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

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

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

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

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

http://cvs.savannah.gnu.org/viewcvs/config/?root=config

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

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

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

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

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

From: Rob Neff
Subject: [SDL] testgl.c minor bug fix for fullscreen mode

from:

  if ( strcmp(argv[1], "-fullscreen") == 0 ) {

to:

  if ( strcmp(argv[i], "-fullscreen") == 0 ) {


Minor bug, but might help someone else out who is trying to pass
the command-line params -logo -fullscreen like I was! :)

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

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

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

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

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