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
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
fixed bugs 159 and 160:
+ added threaded timers support
! fixed restoring sdl window focus (AV in windows message handler)
! disabled forgotten cdrom and joystick in config file.
* disabled minimizing sdl window while loosing focus.
PocketPC does not have a task bar, so it is an inconvenient and unusual
behaviour for PPC users.
+ added WIN_Paint handler for GAPI
! fixed loosing focus while using GAPI videi driver
+ added TestTimer project
* removed unnecessary macros (ENABLE_WINDIB ...) from projects
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401501
