OK, I’v been trying to trace the bug for the whole day,
in facts I’v been trying to make a simple source that
reproduces the bug to send it to the list, but I really
can’t do this, I can reproduce the bug from my app but
sending the sources would be OK for me, but it is a
whole C++ implementation of SDL, somekind of lightweight
wrapper and I really think that sending it all would be
too much work for anybody to understand it and locate the
bug…
I’v come to the conclusion that the simplest way is to send
a “call stack” , a description of the surfaces involved in
the blit that causes the bug, and specs about my computer
configuration (sw and hw)…
So my config. is as follows:
PIII 650MHz, 256MB RAM, GeForce2 MX200 32Mb VRAM
WinXP, latest Detonator drivers v30.82, latest SDL from
CVS compiled with VC++7.0 as all my sources
Surfaces involved in the blit
source:
32 BitsPerPixel, 4 BytesPerPixel
r,g,b,a loss = 0
rshift = 16 (decimal)
gshift = 8 (decimal)
bshift = 0 (decimal)
ashift = 24 (decimal)
rmask = 0x00ff0000 (hex)
gmask = 0x0000ff00 (hex)
bmask = 0x000000ff (hex)
amask = 0xff000000 (hex)
colorkey = 0
alpha = 255
FLAGS : SDL_SRCALPHA | SDL_SWSURFACE
it has perPixelAlpha values set, its
created from SDL_ttf, blended text
(TTF_RenderUTF8_Blended(_ttf_font, text, foreCol))
width = 57, height = 18
pitch = 228
SDL_RLEACCEL set through call to SDL_SetAlpha
destination:
32 BitsPerPixel, 4 BytesPerPixel
r,g,b loss = 0, aloss = 8
rshift = 16 (decimal)
gshift = 8 (decimal)
bshift = 0 (decimal)
ashift = 0 (decimal)
rmask = 0x00ff0000 (hex)
gmask = 0x0000ff00 (hex)
bmask = 0x000000ff (hex)
amask = 0x00000000 (hex)
colorkey = 0
alpha = 255
FLAGS : SDL_SRCCOLORKEY | SDL_SWSURFACE
width = 180, height = 50
pitch = 720
SDL_RLEACCEL set through call to SDL_SetColorKey
the blit:
SDL_BlitSurface(source, NULL, destination, &destinationRect);
it returns 0, but after the blit source->pixels = 0x00000000!!!
the buffer is lost…
There is one thing that I’m wondering, how can I know if the surface
has the RLEACCEL flag set??? if I do :
bool m_isRLE(SDL_Surface *srf)
{
if ((srf->flags & SDL_RLEACCEL) == SDL_RLEACCEL)
return true;
else
return false;
}
it returns me always false, even if I set SDL_RLEACCEL with
SDL_SetColorKey
or SDL_SetAlpha…I’m really interested in that!!!
Anyway I’v came to the conclusion that when some SDL_BlitSurface call
gets to “sdl_rleaccel.c” line 1222 saying:
/* Now that we have it encoded, release the original pixels */
if((surface->flags & SDL_PREALLOC) != SDL_PREALLOC
&& (surface->flags & SDL_HWSURFACE) != SDL_HWSURFACE) {
–> free( surface->pixels );
–> surface->pixels = NULL;
}
it gets lost!!! And when you do consequent blits with the surface
you get an exception (“Access violation reading location 0x???”)
at “sdl_rleaccel.c” line 870 saying:
switch(df->BytesPerPixel) {
case 2:
if(df->Gmask == 0x07e0 || df->Rmask == 0x07e0
|| df->Bmask == 0x07e0)
RLEALPHABLIT(Uint16, Uint8, BLIT_TRANSL_565);
else
RLEALPHABLIT(Uint16, Uint8, BLIT_TRANSL_555);
break;
case 4:
–> RLEALPHABLIT(Uint32, Uint16, BLIT_TRANSL_888);
break;
}
because of reading the buffer that was lost earlier…
Here is the “call stack” of the blit function before the
buffer gets lost:
SDL_D.dll!RLEAlphaSurface
(SDL_Surface * surface=0x00eb1108) Line 1222
SDL_D.dll!SDL_RLESurface
(SDL_Surface * surface=0x00eb1108) Line 1426 + 0x9
SDL_D.dll!SDL_CalculateBlit
(SDL_Surface * surface=0x00eb1108) Line 284 + 0x9
SDL_D.dll!SDL_MapSurface
(SDL_Surface * src=0x00eb1108, SDL_Surface * dst=0x00ee3328)
Line 608 + 0x9
SDL_D.dll!SDL_LowerBlit
(SDL_Surface * src=0x00eb1108, SDL_Rect * srcrect=0x0012f5f8,
SDL_Surface * dst=0x00ee3328, SDL_Rect * dstrect=0x0012f7b0)
Line 408 + 0xd
SDL_D.dll!SDL_UpperBlit
(SDL_Surface * src=0x00eb1108, SDL_Rect * srcrect=0x00000000,
SDL_Surface * dst=0x00ee3328, SDL_Rect * dstrect=0x0012f7b0)
Line 521 + 0x15
!!!IMPORTANT!!!
All of this only occurs if I set the flag SDL_RLEACCEL through calls
to
SDL_SetColorKey or SDL_SetAlpha, if I don’t do this it all works
FINE!!!
By the way, I know that SDL is not officialy supported for compiling
on VC++7.0, but I’v compiled lot’s of code wich was for VC++6 on VC++7
(FreeType2, libjpeg, libzip, libpng, sdl, sdl_mixer, sdl_image,
sdl_ttf,
sdl_gfx, sdl_draw…)and it never turned to be some incompatibilies…
so I really think that VC++7.0 should not be the problem…
I don’t have VC++6.0 installed now to try it all with it, but if
someone
have some good reason to believe that VC++7.0 is the problem,
I’ll try with VC++6, LET ME KNOW about this!!!
I think that should be enought to find the bug…
Anyway, I know that this two surfaces are maybe in a bad format for
optimal
bliting, one has alpha, the other has colorKey, maybe it’s better to
convert them before the blit, but anyway SDL should not loose the
pixel buffer in any “wierd” situation and return 0, like a success
, and I think that indeed is a bug wich must be corrected…
If I can help in some other way let me know!!!
On the end I want to ask another question, has anyone noticed that
SDL apps on WinXP block the TaskBar and make it unusable
(I can’t click on any app. or TaskBar icon or shortcut,
neither the “Start” buton!!!)???
It happens allways on my machine when I’m in WinXP,
eventually after a long period it resumes to work for
some second, Win98 on the same machine does’t do that…> ----- Original Message -----
From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org] On Behalf Of
Sam Lantinga
Sent: Friday, October 04, 2002 4:46 AM
To: sdl at libsdl.org
Subject: Re: [SDL] SDL_RLEACCEL Bug
If this explanation is not enought I can try to reconstruct the bug
again and write down the exact location of the bug in SDL, I’v found
it once with a debug build of SDL.lib after loosing about 4 hours
tring to find the bug in my sources, I’v made a debug lib of SDL and
found the bug was in it.
Yes, if you could point out where the bug is, that would be great.
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
