I did not find in configure.in where SYSTEM_LIBS where set for other platforms, and why I did not have required extra libraries added in sdl-config, so I set it there

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

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

Added current_w and current_h to the SDL_VideoInfo structure, which is set to the desktop resolution during video intialization, and then set to the current resolution when a video mode is set.

SDL_SetVideoMode() now accepts 0 for width or height and will use the current video mode (or the desktop mode if no mode has been set.)

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

Mike Frysinger wrote:
> with libsdl-1.2.9, some games (like bomberclone) started
> segfaulting in Gentoo
[...snip...]
> the last change in the last hunk:
[...snip...]
> if i change the statement to read:
> (table[which].blit_features & GetBlitFeatures()) == GetBlitFeatures()
> bomberclone no longer segfaults on my box

Alex Volkov wrote:
> The test "(table[which].blit_features & GetBlitFeatures()) ==
> table[which].blit_features)" is correct, and the previous
> "(table[which].cpu_mmx == SDL_HasMMX())" was actually broken.

I think there is potentially a slightly different cause of the above problem.
During the introduction of the Altivec code, the blit_table struct field
'alpha' got changed from a straightforward enum to a bitmask, which makes
perfect sense by itself. However, now the table driven blitter selection code
in SDL_CalculateBlitN() can choose the wrong blitters when searching for a
NO_ALPHA blitter because of the following code:
    int a_need = 0;
    ...
    (a_need & table[which].alpha) == a_need &&
When searching through the normal_blit_2[] table, a SET_ALPHA blitter (like
Blit_RGB565_ARGB8888) can now be selected instead of a NO_ALPHA one, causing
alpha channel bits to appear in a non-alpha destination surface. I suppose this
could theoretically be an indirect cause of the segfault mentioned above.

I *think* this can be fixed by changing to
    int a_need = NO_ALPHA;

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

Date: Thu, 10 Nov 2005 21:53:40 -0500
Subject: [SDL] BUG[?]: 32bpp RGBA->RGB colorkey blit, no SDL_SRCALPHA

It seems there is either a documentation vs. reality mismatch or a real bug
in SDL_blit_N.c:BlitNtoNKey().
The exact blit in question is a 32bpp RGBA->RGB, where RGBA has SDL_COLORKEY
and *no* SDL_SRCALPHA flags. The doc in SDL_video.h states:
* RGBA->RGB:
*     SDL_SRCALPHA not set:
*       copy RGB.
*       if SDL_SRCCOLORKEY set, only copy the pixels matching the
*       RGB values of the source colour key, ignoring alpha in the
*       comparison.

BlitNtoNKey(), however, forgets to "ignore alpha in the comparison". The
documentation makes perfect sense, so I think it is the code that is faulty.

The attached patch corrects the code.

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

SDL_blit_A.mmx-speed.patch.txt --
        Speed improvements and a bugfix for the current GCC inline mmx
        asm code:
        - Changed some ops and removed some resulting useless ones.
        - Added some instruction parallelism (some gain)
        The resulting speed on my Xeon improved upto 35% depending on
        the function (measured in fps).
        - Fixed a bug where BlitRGBtoRGBSurfaceAlphaMMX() was
        setting the alpha component on the destination surfaces (to
        opaque-alpha) even when the surface had none.

SDL_blit_A.mmx-msvc.patch.txt --
        MSVC mmx intrinsics version of the same GCC asm code.
        MSVC compiler tries to parallelize the code and to avoid
        register stalls, but does not always do a very good job.
        Per-surface blending MSVC functions run quite a bit faster
        than their pure-asm counterparts (upto 55% faster for 16bit
        ones), but the per-pixel blending runs somewhat slower than asm.

- BlitRGBtoRGBSurfaceAlphaMMX and BlitRGBtoRGBPixelAlphaMMX (and all
variants) can now also handle formats other than (A)RGB8888. Formats
like RGBA8888 and some quite exotic ones are allowed -- like
RAGB8888, or actually anything having channels aligned on 8bit
boundary and full 8bit alpha (for per-pixel alpha blending).
The performance cost of this change is virtually 0 for per-surface
alpha blending (no extra ops inside the loop) and a single non-MMX
op inside the loop for per-pixel blending. In testing, the per-pixel
alpha blending takes a ~2% performance hit, but it still runs much
faster than the current code in CVS. If necessary, a separate function
with this functionality can be made.

This code requires Processor Pack for VC6.

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

 error, instead of zero, contrary to documentation.

    Fixes Bugzilla #165.

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

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

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

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

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

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

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

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

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

   Fixes Bugzilla #161.

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

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

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

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

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

Re-enable OpenGL window resetting code for the windib driver

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

Print Screen key events weren't reported on Windows

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

I'm using SDL 1.2.9 with Visual C++ 7.0 on Windows 2000.

Here's the setup: my game starts in a window, with
SDL_WM_GrabInput(SDL_GRAB_ON) to constrain the cursor to the game window. The
mouse cursor is outside of the window when the game launches, and when the
window appears the cursor is grabbed and placed at the top left corner of the
inside of the game window. At this point, if I click the mouse without moving
it, the SDL_MOUSEBUTTONDOWN event's mouse coordinates are (65535,65535).

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

Date: Fri, 13 Jan 2006 18:09:45 -0500
From: mhall4400 vipmail kvcc edu
Subject: Possible SDL bug

Greetings

I believe Ive come across a bug in your SDL product (1.2.9), in the CD-ROM
control portion of the library.

When calling the SDL_CDPlay() function to play the last track of a CD using the
offset and length from an SDL_CD structure generated by SDL_CDOpen(), I get the
following error from a call to SDL_Error():

mciSendCommand() error: The specified parameter is out of range for the
specified command.

The code returning the error is:
SDL_CDPlay(g_playingDriveSDLCD,
g_playingDriveSDLCD->track[trackNumberInt].offset,
g_playingDriveSDLCD->track[trackNumberInt].length)

Subtracting one from the length of the provided length seems to repair the
problem:
SDL_CDPlay(g_playingDriveSDLCD,
g_playingDriveSDLCD->track[trackNumberInt].offset,
(g_playingDriveSDLCD->track[trackNumberInt].length) - 1)

Ive replicated this problem on Windows 98 SE (several months since last
patch), fully-patched Window ME, seldom-patched Windows XP SP1, and
fully-patched Windows XP SP2.

While investigating the issue, I came across a line in your librarys win32
source code in file \src\cdrom\win32\SDL_syscdrom.c (source code zip archive
from your download page), function: SDL_SYS_CDGetTOC(), line 226 where you add
1 to the value for length to fix MCI last track length bug.  This may be the
source of the issue (because subtracting 1 from the length seems to resolve the
issue).  Microsoft may have patched the referenced bug since you wrote that
line.

Mike Hall

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

Date: Tue, 14 Mar 2006 03:30:11 +0000
From: Peter Mulholland
Subject: [SDL] Windows MessageBox() strangeness fixes

Hello all,

I *think* this should fix the issues that people were seeing with
MessageBox() not working and therefore assert() on mingw/msvc. Forgive
me if i've screwed up making the diff file - I'm a total newb when it
comes to things like CVS and diff.

It modifies a few files as I saw that FlushMessageQueue() was in both
the windx5 and windib driver, so I moved this into wincommon. It was
also in the gapi driver, so I changed that too. The function is now
WIN_FlushMessageQueue() in src/video/wincommon/SDL_syswm.c

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

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

Fixed iconv.h detection on Cygwin32

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

FIXME: See if we can dynamically load NAS

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

RFC 3629 restricted the range of characters encoded with UTF-8 to 0000-10FFFF (the UTF-16 accessible range)

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

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

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

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

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

Added missing target configurations

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

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

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

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

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

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

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