To: SDL Mailing List <sdl@libsdl.org>
Date: Fri, 17 Nov 2006 00:39:29 -0200
Subject: [SDL] Alpha blending bug - fixed?
It turns out mm5 never got the correct value. This failed :
[...]
"movd %1, %%mm5\n\t"
: : "m" (amask), "m" (sf->Ashift) );
mm5 got 0xFF000018 instead of 0x00000018. However I did this :
Uint32 ashift = sf->Ashift;
[...]
"movd %1, %%mm5\n\t"
: : "m" (amask), "m" (ashift) );
and everything worked fine.
The only thing I could find out was that ashift is 32-bit aligned but
sf->Ashift isn't:
printf("ashift %8X [%d]\n", &ashift, (int)(&ashift) % 4);
printf("sf->Ashift %8X [%d]\n", &sf->Ashift, (int)(&sf->Ashift) % 4);
ashift at BFF0E0C4 [0]
sf->Ashift at 08AFB9CD [1]
Could this be the problem? If it is, the fix is extremely trivial.
Should I submit a patch?
--Gabriel
--HG--
branch : SDL-1.2
input. This allows us to enable DGA mode, even when the system cursor was
outside of the window when the grab was initiated.
Fixes Bugzilla #299, which has a more detailed explanation of the issue.
--HG--
branch : SDL-1.2
I might be on crack here.
It looks like SDL_ConvertMono() in src/audio/SDL_audiocvt.c adds the left and
right channels of a stereo stream together, and clamps the new mono channel if
it would overflow.
Shouldn't it be dividing by 2 to average the two sample points instead of
clamping? Otherwise the mono sample point's volume doubles in the conversion.
This would also make the conversion faster, as it replaces two branches per
sample frame with a bitwise shift.
--ryan.
--HG--
branch : SDL-1.2
Date: Thu, 9 Feb 2006 17:06:51 +0300
From: "Oleg K [BeSman]"
Subject: BeOS SDL patches
Hello all. My name is Oleg K. [BeSman], Im a BeOS user from Russia.This mail
contain a BeOs-specific patches to SDL (implementation of InputGrabbing and
mouse_relative mode). See the source in attached file for details.
--HG--
branch : SDL-1.2
------- Comment #2 From Christian Walther 2006-07-23 07:37 [reply] -------
Wow, that was an interesting bug to chase. It was a timing issue: it seems that
for some reason, a certain time must pass between ShowMenuBar() being called in
QZ_UnsetVideoMode() and the application quitting. Before rev. 1885, this delay
was provided by the slow hand-coded fade. With the asynchronous Core Graphics
fading introduced in rev. 1885, that delay was no longer present (most of the
time) and the bug became apparent. Adding an SDL_Delay(100) somewhere between
ShowMenuBar() and the end of QZ_VideoQuit() lowered the frequency of the bug
appearing from "almost every time" to "very rarely" here.
However, there is another solution: doing the ShowMenuBar() before releasing
the captured display instead of afterwards. Apparently, no delay is necessary
in that case, and it looks nicer to me anyway because it is the reverse order
of the way things are set up in the beginning: capture display - set video mode
- hide menu bar - ... - show menu bar - reset video mode - release captured
display. So, this is what the attached patch does.
In addition, I've taken the liberty of
- removing some unused code that I forgot to remove in rev. 1885,
- fixing two warnings about undeclared functions in SDL_QuartzVideo.m by
including OpenGL.h (whose name is a bit misleading - it only declares CGL
stuff, so there's no interference with SDL_opengl.h).
--HG--
branch : SDL-1.2
Hi,
if "configure" is given an explicit --libdir, the sdl-config still contains
the default "${exec_prefix}/lib" for runtime linker path.
That should be changed to $libdir, as this is where the library goes to...
Regards,
Juergen
--HG--
branch : SDL-1.2
