Sat, 18 Mar 2006 22:42:09 +0000Implemented RISC OS and OS/2 desktop resolution code (thanks to Alan and Doodle)
Sam Lantinga <slouken@libsdl.org> [Sat, 18 Mar 2006 22:42:09 +0000] rev 1549
Implemented RISC OS and OS/2 desktop resolution code (thanks to Alan and Doodle)

Sat, 18 Mar 2006 18:41:59 +0000EXTRA_LDFLAGS are the linker flags and libraries needed to build SDL.
Sam Lantinga <slouken@libsdl.org> [Sat, 18 Mar 2006 18:41:59 +0000] rev 1548
EXTRA_LDFLAGS are the linker flags and libraries needed to build SDL.
SDL_LIBS are the linker flags and libraries needed to build SDL applications.
SDL_STATIC_LIBS is set to SDL_LIBS by default.

Fri, 17 Mar 2006 19:54:39 +0000I 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
Patrice Mandin <patmandin@gmail.com> [Fri, 17 Mar 2006 19:54:39 +0000] rev 1547
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

Thu, 16 Mar 2006 00:35:21 +0000*** empty log message ***
Sam Lantinga <slouken@libsdl.org> [Thu, 16 Mar 2006 00:35:21 +0000] rev 1546
*** empty log message ***

Wed, 15 Mar 2006 17:46:41 +0000Added 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.
Sam Lantinga <slouken@libsdl.org> [Wed, 15 Mar 2006 17:46:41 +0000] rev 1545
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.)

Wed, 15 Mar 2006 15:47:49 +0000Fixed bug #33
Sam Lantinga <slouken@libsdl.org> [Wed, 15 Mar 2006 15:47:49 +0000] rev 1544
Fixed bug #33

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;

Wed, 15 Mar 2006 15:43:15 +0000From: "Alex Volkov"
Sam Lantinga <slouken@libsdl.org> [Wed, 15 Mar 2006 15:43:15 +0000] rev 1543
From: "Alex Volkov"
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.

Wed, 15 Mar 2006 15:39:29 +0000Fixed bug #15
Sam Lantinga <slouken@libsdl.org> [Wed, 15 Mar 2006 15:39:29 +0000] rev 1542
Fixed bug #15
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.

Wed, 15 Mar 2006 05:52:31 +0000Quartz implementation for SDL_DisplayYUVOverlay() was returning non-zero on
Ryan C. Gordon <icculus@icculus.org> [Wed, 15 Mar 2006 05:52:31 +0000] rev 1541
Quartz implementation for SDL_DisplayYUVOverlay() was returning non-zero on
error, instead of zero, contrary to documentation.

Fixes Bugzilla #165.

Wed, 15 Mar 2006 04:32:49 +0000Added disk/dummy audio and dummy video to the Visual CE projects
Sam Lantinga <slouken@libsdl.org> [Wed, 15 Mar 2006 04:32:49 +0000] rev 1540
Added disk/dummy audio and dummy video to the Visual CE projects