Date: Sun, 23 Oct 2005 16:39:03 +0200
From: "A. Schmid" <sahib@phreaker.net>
Subject: [SDL] no software surfaces with svgalib driver?
Hi,
I noticed that the SDL (1.2.9) svgalib driver only makes use of linear
addressable (framebuffer) video modes. On older systems (like one of
mine), linear addressable modes are often not available.
Especially for cards with VESA VBE < 2.0 the svgalib vesa driver is
unusable, since VESA only supports framebuffering for VBE 2.0 and later.
The changes necessary to add support for software surfaces seem to be
relatively small. I only had to hack src/video/svga/SDL_svgavideo.c (see
attached patch). The code worked fine for me, but it is no more than a
proof of concept and should be reviewed (probably has a memory leak when
switching modes). It also uses the vgagl library (included in the
svgalib package) and needs to be linked against it.
-Alex
Implemented snd_pcm_sw_params_set_start_threshold() and snd_pcm_sw_params_set_avail_min() in the ALSA 0.9 driver.
This doesn't actually change any latency for me, but it's the right thing to do...
[Note: I'm applying this patch since it's a cleaner version of what's already implemented, and supports this controller on older kernels. I'll ask to make sure this doesn't break on the new kernels where it's no longer necessary]
Date: Mon, 21 Mar 2005 09:41:11 -0500
From: Chris Nelson
Subject: SDL Patch
Hey, Ryan.
I submitted the following patch about a year ago. It's just a simple
patch for the linux port, to make multiple joysticks each appear to SDL
as their own device, if they are on the same USB port (specifically,
these guys
<http://www.consoleplus.co.uk/product_info.php?pName=super-joybox-5-quad-joypad-converter>,
which allow 4 Playstation2 controllers to be accessed via a single USB
port). Without this patch, SDL pretty much drops the ball, and reports
that there are 4 joysticks available when less than that number are
plugged in.
My work built upon the work of another person with the same device. When
I submitted the patch to the list, he tested it, but it didn't work for
him, so the patch was never accepted. Maybe about 3 times in the past
year, I've tried to email the guy, to see if he couldn't run my new
version, complete with debug code to diagnose the problem he was having.
He never got back to me.
So, I'm attaching the patch. I wish I knew why it didn't work for him,
but I've been using it for the last year with no problems. Let me know
if you need any more information, or have any ideas as to how I could
test it. I'd like to see it in the tree, but I want to make sure it works.
-Chris
From the autoconf obsolete macros documentation:
Macro: AC_CANONICAL_SYSTEM
Determine the system type and set output variables to the names of the canonical system types. See section Getting the Canonical System Type, for details about the variables this macro sets.
The user is encouraged to use either AC_CANONICAL_BUILD, or AC_CANONICAL_HOST, or AC_CANONICAL_TARGET, depending on the needs. Using AC_CANONICAL_TARGET is enough to run the two other macros.
From the documentation for the canonical environments:
case $target in
i386-*-mach* | i386-*-gnu*)
obj_format=aout emulation=mach bfd_gas=yes ;;
i960-*-bout) obj_format=bout ;;
esac
Note that the above example uses $target because it's taken from a tool which can be built on some architecture ($build), run on another ($host), but yet handle data for a third architecture ($target). Such tools are usually part of a compiler suite, they generate code for a specific $target.
However $target should be meaningless for most packages. If you want to base a decision on the system where your program will be run, make sure you use the $host variable.
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;
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.
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.
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).
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
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
