Problem with transparency in SDL

[Eskema]

Hi all, im using SDL in 8bpp mode, and im testing with some graphics in 32bpp. The problem is the transparency isnt working as expected

Im using the usual colorkey function:

SDL_SetColorKey(image, SDL_SRCCOLORKEY, SDL_MapRGB(image->format, R, G, B));

This works perfect in 8bpp, but if i try 16 or 32bpp the function doesnt work, ¿why? ¿how can i manage colorkey in 16 or 32bpp?

Thanks

[SG57]

What graphic format?

I know for PSPGL and TGA texture loading, the TGA must have 8-bit ALPHA with 24-bit color... So 32-bit option when saving... (Check my spoiler for a picture of the TGA textures with ALPHA on 2d squares, theres more at my photobucket album if your dying to see them for some reason)...

So im pretty sure its completely graphics format dependent...

[Eskema]

PNG format, anyway im making a standard 2d game not 3d
I think its a bug or a lack of functionality in the SDL port, because in pc when i compile in 16 or 32bpp the colorkey works perfectly, but in psp not

[SG57]

Well, that may certainly be the case, since SDL isn't a full fledged port to my understandings, but im positive others have had this problem and worked around it... any thoughts on that? I for one am not a fan for SDL as its too much of a pain to install and what not So cant help you there, sorrry.

EDIT

Juts looking at hte line of code,Im seeing your mapping R,G and B values, no A/alpha? Is there anyway to map R,G,B and A/alpha? Im taking a shot in the dark for you here, sorry if im way off )

[Eskema]

The only solution i see its the 8bpp mode, so ive tested the code on pc, gp2x and xbox, so it works. Then i think its a lack of funtionality in the SDL port.

The rgb values in the function are normal, in SDL u work with rgb values to get the color u want for transparency, i never used alpha parameters.

Well at this point ill continue working with 8bpp color mode thanks for ur interest SG57

[psiko_scweek]

Eskema,
was there any change to this, or was the 8bpp limitation still a limitation?

thanks
psiko

[Eskema]

Originally Posted by psiko_scweek

Eskema,
was there any change to this, or was the 8bpp limitation still a limitation?

thanks
psiko

Well i tried 16 or 32bpp and none of them works, the console freezes or get a blue screen. I hope in a future the SDL port works better and support 16bpp or 32 without problems.

Actually my games still in 8bpp

[framerate]

Originally Posted by Eskema

Well i tried 16 or 32bpp and none of them works, the console freezes or get a blue screen. I hope in a future the SDL port works better and support 16bpp or 32 without problems.

Actually my games still in 8bpp

You are setting the alpha channel and getting a problem correct?

I use 32 bit and 16 bit images and blit them onto my surfaces (losing their background like intended) just find in 32 bit color, but I'm not messing with the alpha channel directly... (which I think is your problem?)

If in fact you're having problems just losing the background of a sprite you're blitting, take a look at SDL_DisplayFormat(). Solves a lot of problems for me on PSP.

[Eskema]

I dont wanna use the alpha channel, instead im using the colorkey to get the transparency in my graphics, usually the magenta color

So if i put something easy like this

SDL_SetColorKey(imagen->imagen, SDL_SRCCOLORKEY, SDL_MapRGB(imagen->imagen->format, R, G, B));

in 16 or 32bpp SDL dont recognize the colorkey and i dont have transparency, so in pc or gp2x for example the function works perfect and i get my colorkey transparency.


This is my loadgraphics function

void LoadImage(Objeto *image, Objeto *tmp, unsigned char *name, int size,int R, int G, int B)
{

    tmp->tmp=IMG_Load_RW(SDL_RWFromMem(name,size),0);
    image->image=SDL_DisplayFormat(tmp->tmp);
    SDL_FreeSurface(tmp->tmp);
    if(R>-1 && G>-1 && B>-1){
	SDL_SetColorKey(image->image, SDL_SRCCOLORKEY, SDL_MapRGB(image->image->format, R, G, B));
	}


}

As u can see its a normal function that works perfect in other platforms, but none in psp

[psiko_scweek]

lol damn,

my code is much like yours...but its still not working. I have to decrease th BPP to 8 or the background colors on my images stay and do not disappear. The problem with me doing that though, is my images look like crud then. I had set the BPP to 24 and got the transparancies correct, but it ran dirt slow. in fact, with the BPP set to 16 the colors look fine, but the backgrounds dont disappear and it runs a lot faster than with the BPP set to 8. eh, i dunno maybe im doing something wrong?

here is my code:

/////////// CREATE THE SPECIFICS FOR LOADING GRAPHICS ///////////
SDL_Surface *gfx_load_image(char *filename) 
{
    SDL_Surface* loadedImage = NULL;
    SDL_Surface* optimizedImage = NULL;

    loadedImage = IMG_Load(filename);
    if( loadedImage != NULL )
    {
        gfx_SetSDLTransparentColor(gfx_GetPixel(loadedImage,0,0),loadedImage);
        optimizedImage = SDL_DisplayFormat( loadedImage );
        SDL_FreeSurface( loadedImage );
    }

    return optimizedImage;
}

and:

/////////// FUNCTION FOR SETTING THE TRANSPARENT COLOR ///////////
int gfx_SetSDLTransparentColor(Uint32 Color, SDL_Surface *surf)
{
   //sets the transparent color 
   SDL_SetColorKey(surf,SDL_SRCCOLORKEY, Color);
   return 0;
}

it works fine in 8BPP mode but does not want to work in 16, 32, or anything else.

oh yeah, here is how i set up the video in SdL

/////////// INITIALIZE THE SDL VIDEO, SET THE SCREEN MODE ///////////
int InitSDLVideo()
{
gfx_screen = SDL_SetVideoMode(SCR_W,SCR_H,SCR_BBP,SDL_HWSURFACE|SDL_HWPALETTE|SDL_DOUBLEBUF);
	if(gfx_screen == NULL)
	{
	fprintf(stderr,"Error in video  %s\n", SDL_GetError());
	return 1;
	}
return 0;
}

[Eskema]

its a limit in SDL port, the only way it seems to be use 32bpp with alpha channel, but this is slow, so ill continue using 8bpp until SDL port changes

[psiko_scweek]

im suprised ive never heard of it before...save for us :-) hmm...maybe there is a work around?

i hope!

[Eskema]

If u see the readme:

Video - yes, single 32-bit ABGR framebuffer surface only; SDL will
emulate other formats as necessary. No HW accel. No 3D.


so only has 32bpp support, and none HWSURFACE, all surfaces will be converted to SWSURFACES, but maybe im wrong with this.... but if im wrong, ¿why in other platforms our code works and why psp none?

[Raphael]

ANSWER: Don't - use - SDL - on - PSP.
At least not for anything serious. It sucks. Really. It's incomplete and slow.
Start learning GU by looking into the graphics.c file from yeldarb's tuts and at the SDK samples. It's really easy, you don't depend on others code and updates and you get the full flexibility of all the nice features (plus some more if you get sophisticated with those) and all that with hardware acceleration.
It's at least 5:1 good reasons to use GU instead of SDL. The only one for SDL is portability. But I say screw that, PSP is too specific too be worrying about 100%-portability of your code (special cpu, special gpu, special vfpu, special display resolution, complete different caching system/efficiency than PC...).

[Eskema]

Of course u are right SDL port sucks, but i dont have time to make 3 versions of the same game (psp, xbox, gp2x) thats why i use SDL. And other cuestion is flexibility, i can test my code in pc, so i made some changes in a few seconds, instead of use pspsdk, copy the code in the mem stick, try, reboot, copy again....

[Insert_Witty_Name]

Originally Posted by Eskema

...instead of use pspsdk, copy the code in the mem stick, try, reboot, copy again....

PSPLink is your friend

But as Raphael already mentioned you should stay away from SDL for every reason except portability - and it seems that isn't even 100%

[Raphael]

PSPLink. change code, make, ./eboot.pbp, repeat. It takes me between 10-30s for one evaluation step (from the point of saving the last edited source file, to the point when the application gets executed). There's really no reason anymore not to develop on 1.5.
Also, testing code on PC to see if it does what was expected is ok (though with PSPlink it's the same effort, or well, even more on PC, because you have two builds to manage), but as soon as you get to optimizing, the PC won't help you.

Using SDL to have several plattforms supported is ok as long as SDL is properly supported on those platforms and it really is on the most. But it isn't on PSP and thatswhy you should take the relatively small amount of work to get your own GU Interface done (or if you are generous, why not try to write the SDL->GU interface?), at least if you have some serious graphical project going on. But that's just my opinion, if you have no problems being stuck with the limitations that SDL currently puts on you, then it's ok.

[Eskema]

well ill try the pspsdk, i downloaded the graphics functions, and well i miss my dear SDL_RWFromMem function, i want to put all the graphics in eboot, not load from memstick.
Is there any good place to find functions for pspsdk? like load converted images to file.h, manage transparency without alpha,....

[framerate]

Originally Posted by Raphael

ANSWER: Don't - use - SDL - on - PSP.
At least not for anything serious. It sucks. Really. It's incomplete and slow.

Come on man, be fair. It may not be perfect, but I have 300 frames per second. I wouldn't call that "slow"

[Eskema]

wow!! 300fps tell us how do u do that, im actually finishing biohazard2 and i dont get more than 15-20fps with very slowdowns, so im forced to try the pspsdk

[rbm115]

hey eksema,

where can i get the best sdl reference ? tutorials, libraries.

thanks,

[Ravine]

www.libsdl.org Try google next time.