alpha blend -- PLEASE HELP.

[dbeyer3069]

After working and researching for a few days now, I am posting another message in hopes of getting an answer. This is a small part of my project but it's stopping me. I've looked at every example and thread message I can find but nothing seems quite the same as mine (most use RAW files). Please help if you can.

I am trying to blend a 32 x 32 png image (game character) in with my 480 x 272 background image.

Here's my source:

void initGraphics()
{
dispBufferNumber = 0;

sceGuInit();

guStart();

sceGuDrawBuffer(GU_PSM_8888,(void*)0,BUF_WIDTH);
sceGuDispBuffer(SCR_WIDTH,SCR_HEIGHT,(void*)(512 * 272 * 4),BUF_WIDTH);
sceGuDepthBuffer((void*)0x110000,BUF_WIDTH);

sceGuClear(GU_COLOR_BUFFER_BIT | GU_DEPTH_BUFFER_BIT);
sceGuOffset(2048 - (SCREEN_WIDTH / 2), 2048 - (SCREEN_HEIGHT / 2));
sceGuViewport(2048, 2048, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuDepthRange(0xc350, 0x2710);
sceGuScissor(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuEnable(GU_SCISSOR_TEST);
sceGuAlphaFunc(GU_GREATER, 0, 0xff);
sceGuEnable(GU_ALPHA_TEST);
sceGuDepthFunc(GU_GEQUAL);
sceGuEnable(GU_DEPTH_TEST);
sceGuFrontFace(GU_CW);
sceGuShadeModel(GU_SMOOTH);
sceGuEnable(GU_CULL_FACE);
sceGuEnable(GU_TEXTURE_2D);
sceGuEnable(GU_CLIP_PLANES);

sceGuTexMode(GU_PSM_8888, 0, 0, 0);
sceGuTexFunc(GU_TFX_MODULATE, GU_TCC_RGBA);
sceGuTexFilter(GU_LINEAR, GU_LINEAR);

//sceGuTexMode(GU_PSM_8888, 0, 0, 0);
//sceGuTexFunc(GU_TFX_REPLACE, GU_TCC_RGBA);
//sceGuTexFilter(GU_NEAREST, GU_NEAREST);

sceGuAmbientColor(0xffffffff);
sceGuEnable(GU_BLEND);

//sceGuBlendFunc(GU_ADD, GU_SRC_ALPHA, GU_ONE_MINUS_SRC_ALPHA, 0, 0);

sceGuBlendFunc(GU_ADD, GU_SRC_ALPHA, GU_ONE_MINUS_SRC_ALPHA, 0xffffffff, 0xffffffff);
sceGuFinish();
sceGuSync(0, 0);

sceDisplayWaitVblankStart();
sceGuDisplay(GU_TRUE);
initialized = 1;
}

image = loadPngImage("ms0:/PSP/GAME/splash.png"); // 480 x 272 no alpha
position = loadPngImage("ms0:/PSP/GAME/character.png"); // 32 x 32 with transparent background

initGraphics();
blitImageToScreen(0, 0, 480, 272, image, 0, 0);
blitAlphaImageToScreen(0, 0, 32, 32, position, 0, 0);
flipScreen();

#####

I changed my previous 24 x 32 to be 32 x 32 to meet the power of 2 requirement.

There are WAY too many variables for me to work with here trying to figure out what the problem is. The blitted 32 x 32 image shows up 100% transparent (nothing shows). The background is fine.

I am learning (quickly) more about this stuff but I am still too new to it. I have tried MANY different combinations trying to figure this out.

*** I will be happy to send my png file to someone too if they could make sure it's saved in a format compatible with this code if the code looks ok. ***

Your help is GREATLY appreciated. This is stopping me in my project and it's the only place i'll use this type of coding.

David Beyer

[dbeyer3069]

I have made a breakthru in ALPHA BLENDING (FINALLY -- pulled plenty of hair out). Is ANYONE reading this forum that knows about this stuff?

Soap Box: It's in ALL our best interests to help each other out and expand the programs that get turned out. I read EVERY forum post and looked at EVERY example I could find but there is so little information available (wasn't me trying to be lazy). If I wasn't determined to finish my product, I would have given up 3 days ago when I started on this ALPHA BLENDING.

For those newbies... here is what I did to get ALPHA BLENDING to work:

1. I created a 32 x 32 png image as a 8 bit/256 (depth) color image (this is how my graphics program insisted on saving it) with the transparency color set to white (for now, will change this). I tried greater depth (depth = 256 colors, 16 million, etc.) and it didn't work at all (always got white backgrounds displayed). I tested my image (finally got smarter) in Internet Explorer to see if it was really working transparently before moving it back to the PSP to test.

2. I went back and recopied the core graphics.c libraries (just to make sure I didn't screw something up in the process). The core graphics.c works as is (including the initGraphics() at the end and all those settings). graphics.c, graphics.h, etc. are available at http://svn.pspdev.org/listing.php?repna ... rev=0&sc=0

3. I STILL can't get the blitting with alpha to work straight to the screen. It does work if I blit to another image (my background). If anyone knows why... PLEASE POST. It seems I've seen this problem mentioned somewhere else before. I am working in 8888 mode.

###

If you are working with alpha blending (transparency) and are having a hard time getting it to work with PNG, email me and I will TRY to help out (no promises - I know I've learned more than I ever thought I would have to). I know what it's like to start from square one.

I will provide source fragments for the applicable area if someone needs it. Hope this has been helpful.

David Beyer

[ufoz]

You seem too concerned about PNG and missing the point. Alpha blending works regardless of what your image format is, the only things that matter are:

1) When you load the image, it should be in a format that contains alpha data, and that alpha data should be correct for the image. (8888, or 4444 or whatever)
2) Alpha blending should be on in the GU - looks like you have this covered.

So all you need to do is make sure your PNG does have an alpha channel, and check what format the LoadPNG function returns it as (looks like 8888). You seem to have the rest of the stuff covered in your source (GU_TCC_RGBA and GU_BLEND and your blend func is fine as well) - so check your pixel format, dump it to the memcard or something, and compare it to your raw image data, make sure every fourth byte is a valid alpha value :)

[dbeyer3069]

You're right. It's not just PNG. That just happens to be what I'm using. I'm not familar with all the formats that work (beyond the jpg that I also have the code for).

I don't understand why a blit to the screen fails and a blit to another image works. It does work consistently and I have look at some of the data values to make sure i'm not just "getting lucky". Beyond that, I'm a bit stumped.

Thanks for the comments.

David Beyer

[jsgf]

I have made a breakthru in ALPHA BLENDING (FINALLY -- pulled plenty of hair out). Is ANYONE reading this forum that knows about this stuff?

Sure, lots of people are willing to help. But you've got to throw us a bone:

• You never actually described what problem you were having? What were you expecting?
• You listed all the boring setup code, but you didn't post your actual blit* or loadPng functions. That would be the meat of the problem. Where did you get them from? (Sure, you tell us Lua now, but were we supposed to guess before?)
• You should use

  Code: Select all

   to list your source, to make it readable; wading through badly formatted code is hard work.
  [*] Did you try removing the PNG files from the equation?  What happens if you link in the raw images?  Do they work?
  [/list]
  
  Besides, it looks like the Lua loadPngImage doesn't preserve the alpha channel, and just replaces it with 0xff.  It should only do that for color_type == PNG_COLOR_TYPE_RGB, and not PNG_COLOR_TYPE_RGB_ALPHA.

[dbeyer3069]

Sure, lots of people are willing to help. But you've got to throw us a bone:
You never actually described what problem you were having? What were you expecting?

Problem (from original post):

I am trying to blend a 32 x 32 png image (game character) in with my 480 x 272 background image.

You listed all the boring setup code, but you didn't post your actual blit* or loadPng functions. That would be the meat of the problem.
Where did you get them from? (Sure, you tell us Lua now, but were we supposed to guess before?)

The blit and load statements are right below the "boring code" and before the ##### in the original post.

You should use

Code: Select all

 to list your source, to make it readable; wading through badly formatted code is hard work.[/quote]

I probably could have reformatted the code a little -- then you would have seen the blit and load statements in the original post.

[quote]Did you try removing the PNG files from the equation?  What happens if you link in the raw images?  Do they work?[/quote]

I'm new to this PSP development and haven't experimented with RAW files yet.  I am trying to get the basics going before I get fancy.  I did examine the image data with printf statements.

[quote]Besides, it looks like the Lua loadPngImage doesn't preserve the alpha channel, and just replaces it with 0xff.  It should only do that for color_type == PNG_COLOR_TYPE_RGB, and not PNG_COLOR_TYPE_RGB_ALPHA.[/quote]

loadPngImage() is used to load the png file that is passed to blitAlphaImageToImage() which works.  I'm still hoping someone can give some definative feedback on why image to image works and image to screen doesn't in testing.

Thanks for the time to post a response.

David Beyer

[jsgf]

I am trying to blend a 32 x 32 png image (game character) in with my 480 x 272 background image.

Yeah, but what are you seeing? Nothing at all? No blending? Black square? White square?

The blit and load statements are right below the "boring code" and before the ##### in the original post.

Right, but you didn't post the source to those functions, so its hard to know what they do.

I'm new to this PSP development and haven't experimented with RAW files yet. I am trying to get the basics going before I get fancy. I did examine the image data with printf statements.

After loading? Did they have the expected alpha channel?

loadPngImage() is used to load the png file that is passed to blitAlphaImageToImage() which works. I'm still hoping someone can give some definative feedback on why image to image works and image to screen doesn't in testing.

Despite its name, blitAlphaImageToImage doesn't seem to do any blending at all; it only uses alpha as an on/off switch for non-zero/zero alpha values. blitAlphaImageToScreen() uses the hardware to do alpha blending, but perhaps the state isn't set up right. It looks OK as far as I can tell though.

Though there are some pretty dubious states being set in the init code; I don't see why these should be there for simple blitting:

Code: Select all

sceGuEnable(GU_ALPHA_TEST);
sceGuEnable(GU_DEPTH_TEST);
sceGuEnable(GU_CULL_FACE);

Also, I think you want to keep the GU_TFX_REPLACE rather than MODULATE, at least for now. It removes a variable (vertex colour) from the equation.

[dbeyer3069]

Yeah, but what are you seeing? Nothing at all? No blending? Black square? White square?

When the blitalphaimagetoscreen() is used, it is showing nothing (fully transparent). The blitalphaimagetoimage shows the png correctly, skipping the alpha channel data (transparent areas).

Right, but you didn't post the source to those functions, so its hard to know what they do.

BELOW is cut from graphics.c (original and unmodified):

Code: Select all

void blitAlphaImageToImage(int sx, int sy, int width, int height, Image* source, int dx, int dy, Image* destination)
{
        // TODO Blend!
        Color* destinationData = &destination->data[destination->textureWidth * dy + dx];
        int destinationSkipX = destination->textureWidth - width;
        Color* sourceData = &source->data[source->textureWidth * sy + sx];
        int sourceSkipX = source->textureWidth - width;
        int x, y;
        for &#40;y = 0; y < height; y++, destinationData += destinationSkipX, sourceData += sourceSkipX&#41; &#123;
                for &#40;x = 0; x < width; x++, destinationData++, sourceData++&#41; &#123;
                        Color color = *sourceData;
                        if &#40;!IS_ALPHA&#40;color&#41;&#41; *destinationData = color;
                &#125;
        &#125;
&#125;

void blitAlphaImageToScreen&#40;int sx, int sy, int width, int height, Image* source, int dx, int dy&#41;
&#123;
        if &#40;!initialized&#41; return;

        sceKernelDcacheWritebackInvalidateAll&#40;&#41;;
        guStart&#40;&#41;;
        sceGuTexImage&#40;0, source->textureWidth, source->textureHeight, source->textureWidth, &#40;void*&#41; source->data&#41;;
        float u = 1.0f / &#40;&#40;float&#41;source->textureWidth&#41;;
        float v = 1.0f / &#40;&#40;float&#41;source->textureHeight&#41;;
        sceGuTexScale&#40;u, v&#41;;
        
        int j = 0;
        while &#40;j < width&#41; &#123;
                Vertex* vertices = &#40;Vertex*&#41; sceGuGetMemory&#40;2 * sizeof&#40;Vertex&#41;&#41;;
                int sliceWidth = 64;
                if &#40;j + sliceWidth > width&#41; sliceWidth = width - j;
                vertices&#91;0&#93;.u = sx + j;
                vertices&#91;0&#93;.v = sy;
                vertices&#91;0&#93;.x = dx + j;
                vertices&#91;0&#93;.y = dy;
                vertices&#91;0&#93;.z = 0;
                vertices&#91;1&#93;.u = sx + j + sliceWidth;
                vertices&#91;1&#93;.v = sy + height;
                vertices&#91;1&#93;.x = dx + j + sliceWidth;
                vertices&#91;1&#93;.y = dy + height;
                vertices&#91;1&#93;.z = 0;
                sceGuDrawArray&#40;GU_SPRITES, GU_TEXTURE_16BIT | GU_VERTEX_16BIT | GU_TRANSFORM_2D, 2, 0, vertices&#41;;
                j += sliceWidth;
        &#125;
        
        sceGuFinish&#40;&#41;;
        sceGuSync&#40;0, 0&#41;;
&#125;

After loading? Did they have the expected alpha channel?

As far as I can tell, the data is correct (with my limited knowledge). The image is 32 x 32 8 bit/256 color with a transparent color set (this works fine with bitalphaimagetoimage) and internet explorer.

Despite its name, blitAlphaImageToImage doesn't seem to do any blending at all; it only uses alpha as an on/off switch for non-zero/zero alpha values. blitAlphaImageToScreen() uses the hardware to do alpha blending, but perhaps the state isn't set up right. It looks OK as far as I can tell though.

You do appear to be right that it only drops those alpha characters and doesn't render them.

Though there are some pretty dubious states being set in the init code; I don't see why these should be there for simple blitting:

Code: Select all

sceGuEnable(GU_ALPHA_TEST);
sceGuEnable(GU_DEPTH_TEST);
sceGuEnable(GU_CULL_FACE);[/quote]

The default graphics.c library sets all of these up.  I have tried to learn about and educate myself on these different modes but there is so little information available.  The problem is that the naming conventions used in the PSP libraries and what is out on the net are different and without a wide base knowledge, it's very difficult (and time consuming) to research them all -- so I learn a little at a time.  I did find a few web sites with info on transparency, which helped me save the file correctly.

[quote]Also, I think you want to keep the GU_TFX_REPLACE rather than MODULATE, at least for now.  It removes a variable (vertex colour) from the equation.[/quote]

I've wondered about this.  Again, little documentation leaves me coming up a bit short.  I've just done my best to experiment.  Once I get a good grasp of all this, I will probably write up a document for other newbies.

Thanks for the post.

David Beyer

[jsgf]

As far as I can tell, the data is correct (with my limited knowledge). The image is 32 x 32 8 bit/256 color with a transparent color set (this works fine with bitalphaimagetoimage) and internet explorer.

Hm, it should be a 32-bit RGBA image. 256 colour means it has a palette, and I don't think that has an alpha channel. If your image simply has a single transparent colour, I don't think libpng will turn that into a useful RGBA image when it decompresses it.

Can you post a sample of the pixel values you're seeing coming out of the loaded png?

The default graphics.c library sets all of these up. I have tried to learn about and educate myself on these different modes but there is so little information available. [...]
I've wondered about this. Again, little documentation leaves me coming up a bit short. I've just done my best to experiment. Once I get a good grasp of all this, I will probably write up a document for other newbies.

In general these names are derived from OpenGL: it has GL_ALPHA_TEST, GL_DEPTH_TEST, etc. The REPLACE and MODULATE are the same as the GL_REPLACE and GL_MODULATE arguments for glTexEnv(). Learning some basic OpenGL will help a lot in understanding libgu (or use PSPGL directly).

[dbeyer3069]

Hm, it should be a 32-bit RGBA image. 256 colour means it has a palette, and I don't think that has an alpha channel. If your image simply has a single transparent colour, I don't think libpng will turn that into a useful RGBA image when it decompresses it.

Originally, I thought it should be 32bit RGBA too but the program I am using (Paint Shop Pro) refuses to add a transparency color for any depth greater than 256 colors (16 million, etc.). It always flattens the image back to 8 bit/256 colors. Since the image showed up correctly in IE and with the blitalphaimagetoimage, I was assuming I was on the right track. It also says inside Paint Shop Pro that it is 24 bit/16 million when it's setup to 16 million colors. Maybe this is a limitation of that program.

Can you post a sample of the pixel values you're seeing coming out of the loaded png?

I will get some data to report back here. I wonder if my paint program is the main problem here. Are there any shareware paint programs you could suggest that I could use to prove this theory? (I own Paint Shop Pro and it's generally pretty good).

In general these names are derived from OpenGL: it has GL_ALPHA_TEST, GL_DEPTH_TEST, etc. The REPLACE and MODULATE are the same as the GL_REPLACE and GL_MODULATE arguments for glTexEnv(). Learning some basic OpenGL will help a lot in understanding libgu (or use PSPGL directly).

All help is appreciated. The learning curve is a bit overwelming.

David Beyer

[dbeyer3069]

I'm still working on getting some data out but I did look at the pngload and the blitalphaimagetoimage functions. As you suspected, the blit is just skipping alpha channel data.

The color data is AND'd by 0xFF000000 to see if the alpha channel is set and it is -- therefore not coping that data to the destination buffer.

So it looks like the 8 bit/256 is storing the alpha channel data correctly.

David Beyer

[jsgf]

Hm, it should be a 32-bit RGBA image. 256 colour means it has a palette, and I don't think that has an alpha channel. If your image simply has a single transparent colour, I don't think libpng will turn that into a useful RGBA image when it decompresses it.

Originally, I thought it should be 32bit RGBA too but the program I am using (Paint Shop Pro) refuses to add a transparency color for any depth greater than 256 colors (16 million, etc.). It always flattens the image back to 8 bit/256 colors. Since the image showed up correctly in IE and with the blitalphaimagetoimage, I was assuming I was on the right track. It also says inside Paint Shop Pro that it is 24 bit/16 million when it's setup to 16 million colors. Maybe this is a limitation of that program.

You need a program which can generate a full alpha channel, which means 24 bits of RGB and 8 bits of alpha -> 32-bit RGBA image. 256 colours with a single "transparent" colour means you won't get alpha blending, just on/off masking.

I use The Gimp to general RGBA png files.

[jsgf]

I'm still working on getting some data out but I did look at the pngload and the blitalphaimagetoimage functions. As you suspected, the blit is just skipping alpha channel data.

The color data is AND'd by 0xFF000000 to see if the alpha channel is set and it is -- therefore not coping that data to the destination buffer.

So it looks like the 8 bit/256 is storing the alpha channel data correctly.

Well, you should see alpha == 0 where you want the background to show through, == 255 where you want your character to be, and somewhere between on the edges if you want some antialiasing.

Also, the format in memory should be R,G,B,A as bytes, not ARGB, ABGR, etc. If you load the pixels from memory into a 32-bit variable, then the colour channels will be endian reversed ABGR.

[chp]

Hm, it should be a 32-bit RGBA image. 256 colour means it has a palette, and I don't think that has an alpha channel.

It depends on the format used for the palette. For example, the blend-sample in the PSPSDK uses a 256-color texture with alpha using 8888 format on the palette, and it works just fine. (It just looks really ugly, I should rewrite it. :)

[jsgf]

Yeah, the hardware can deal with it, but I don't think PNG supports colourmaps with alpha; and anyway, I think the png loader is using libpng to expand the image to RGBA anyway, rather than just exposing the 8bpp+cmap, which would be better for the hardware.

[chp]

Ah, no, you're right, most picture-formats suck when it comes to saving palettes with alpha. TGA supports it (set colourmapbits on the palette to 32 when using 8-bit clut tgas), but hardly any saver or loader handles it. What I recommend is saving in 32-bit truecolor, and then preprocess textures into its own format (or during loading, but that's a performance hit since you need to quantize them) when it's time to use them. Using a good dithering-filter (I really recommend diffuse (floyd-steinberg)) and quantizer and you'll get excellent results.

[dr_watson]

David: if you're using Paint Shop Pro, to create a PNG with alpha channels, use the "Export->PNG Optimizer" and then change the options in "Transparency".

I'm using PNG and having alpha blending effects in my game, check out the source code here:
http://forums.ps2dev.org/viewtopic.php?t=4286

[dbeyer3069]

Paint Shop Pro insists on changing an image to 8 bit/256 color when there is a transparency involved (not sure why). It supports 16 million true color (but not with transparency).

I checked the Export->PNG Optimizer option and it's the same thing I've been using, except I access it by Image->Palette->Set Transparency with a single color. That saved PNG works with the blit image to image -- not with image to screen.

Can you say that the results of a PNG from Paint Shop Pro using that method is producing a PNG that works with blitting direct to the screen using the graphics.c library... if this is your experience and what you use (or LUA PLAYER which uses the same thing). It appears to be valid alpha channel data (according to how the PNG load/blit to image works) but now I'm just not sure.

Thanks for all the help.

David Beyer

[dbeyer3069]

I'm using PNG and having alpha blending effects in my game, check out the source code here:
http://forums.ps2dev.org/viewtopic.php?t=4286

[/quote]

I looked at the program JGFX code which appears to be an enhanced graphics.c file (some of the code is the same).

The main difference seems to be you have most (or all) of the tests disabled (ALPHA, DEPTH, etc.) whereas I still have them enabled. I've seen comments both ways -- but could having some of these enabled keep it from working with blit to the screen with the single transparency color/PNG/8 bit/256 colors of Paint Shop Pro? I felt like I was chasing my tail and was happy when the blit image to image worked and figured I'd wait for more help and info. I tried disabling all of those at some point... can't recall the exact timing or combination though.

David Beyer

[dr_watson]

If you want to use a single "transparent color", Paint Shop Pro will change your image to 256 color mode, that's very true. BUT, if you want to do alpha blending, that is, different levels of transparency, say 50% transparent, 80% transparent, you'll use "Export".

From my understanding, to enable alpha blending for blitting, you only need to do the following:

Code: Select all

sceGuEnable(GU_BLEND);
sceGuBlendFunc(GU_ADD, GU_SRC_ALPHA, GU_ONE_MINUS_SRC_ALPHA, 0, 0);

Also have a look of the Gfx_LoadTexture function and see if there are any differences between this and your PNG loader.

Note that alpha value of 255 is full opaque and 0 if full transparent and anything in between is semi-transparent.

BTW, what pixel format are you using?

[memon]

I would disable (instead of enable): alpha test, cull face, depth test and clipplanes in the setup code. There is no need to enable them. Any of those can cause (in theory) your face not to be rendered. My head is already concetrating on that turkey in kitchen, so I don't really want to go and check the rest of the graphics.c.

If the GU stuff seems too complicated, teach yourself first opengl. It is much easier since the round trip time is fast on PC and there are two billion noob tutorials out there as well. After that it is really fast to pick up GU stuff. And it is not that complex once you get your ehad around it ;)

[dbeyer3069]

If you want to use a single "transparent color", Paint Shop Pro will change your image to 256 color mode, that's very true. BUT, if you want to do alpha blending, that is, different levels of transparency, say 50% transparent, 80% transparent, you'll use "Export".

I looked at the docs (help) for Paint Shop Pro and it only has a few topics on alpha blending or transparency... basically just telling you how to use the interface. I will try a few things: 1) I will disable all the extra tests and face modes and 2) I will try the export function and see if it acts differently than the image->palette->set transparency mode when saving (I will probably just compare the binary files) so I can put that issue to bed.

From my understanding, to enable alpha blending for blitting, you only need to do the following:

Code: Select all

sceGuEnable(GU_BLEND);
sceGuBlendFunc(GU_ADD, GU_SRC_ALPHA, GU_ONE_MINUS_SRC_ALPHA, 0, 0);

I guess what got me started originally was that the graphics.c library (and a number of source examples) enable a mess of tests, etc. I am beginning to understand what all the different modes are now and how they impact things.

Also have a look of the Gfx_LoadTexture function and see if there are any differences between this and your PNG loader.

I looked at this and it has some of the same identical code as graphics.c (which leads me to believe graphics.c was a starting point for that library).

Note that alpha value of 255 is full opaque and 0 if full transparent and anything in between is semi-transparent.

The library seems to check that the color data simply "isn't fully opaque" -- so anything else is presumed to be alpha.

BTW, what pixel format are you using?

I'm in 8888 mode.

Thanks everyone for the continuing help.

David Beyer

[dbeyer3069]

I tried the suggestion of the export->png optimizer and selected:

16 million colors (It says 24 bit)
tolerance level: 1 (it defaulted to this)
alpha channels using the background color I chose (preview looks right)
non-interlaced (interlace was default but crashed the pngload function)

I also tried removing the depth, alpha test, cull and clipping.

Paint Shop Pro did get rid of the option of the alpha channels if I selected 256 colors so it was different than the mode I was using.

###

Neither of these solved the problem. My same code works with the 16 million colors and alpha channels png file from the export (blitting alpha image to image) but the blitting image to screen does the same as always.

I've learned alot but still can't use the blitting straight to the screen. I will look at the gfx example some more. :(

David Beyer

[dr_watson]

Just spotted this in your code:

Code: Select all

sceGuDrawArray(GU_SPRITES, GU_TEXTURE_16BIT | GU_VERTEX_16BIT | GU_TRANSFORM_2D, 2, 0, vertices); 

What's in your Vertex structure? There seems to be no "COLOUR". Mine looks like this:

Code: Select all

struct Vertex
{
	float u, v;
	u32 color;
	float x, y, z;
};

And the corresponding code:

Code: Select all

sceGuDrawArray(GU_SPRITES,GU_TEXTURE_32BITF|GU_COLOR_8888|GU_VERTEX_32BITF|GU_TRANSFORM_2D, 2, 0, vertices);

My wild guess was that this could be the problem!

[jsgf]

Vertex colour shouldn't matter if you're not using a MODULATE texture environment. REPLACE means the fragment colour is completely replaced by the texture colour.

[dbeyer3069]

DR. WATSON:

You are the man. You nailed it!

There's a bug in the graphic.c library apparently (I just checked their copy and it's in there still). Doesn't look like anyone has reported/discovered that bug yet.

Oddly enough, I had tried changing that line to match yours a few days ago but I had not yet gotten the file in 32 bit mode correctly yet (thanks to you directing me to the export feature) and I hadn't added the missing color field.

This was driving me nuts.

THANK YOU and everyone so much for helping out. This has been a real learning experience (Early CHRISTMAS present 10 minutes early!).

I will give everyone here a sneak peak at the program when it gets closer (it's a LARGE project and this was a minor but important piece believe it or not).

David Beyer

[kazlivsjy]

I'm too lazy to read all these posts throughly and I don' know if the main question has been answered yet, but I've been through the very same problem myself, and after a lot of tampering and testing I did it. I'll share now my knowledge; hope it is to any use to anyone...

The important stuff to make transparent textures or sprites (I've only tried sprites so far, but I believe I'll work just the same) is:

a) Of course, to have a bitmap image with alpha channel (assumed ARGB8888, for clarity)

b) Set up a blending function:

sceGuBlendFunc(GU_ADD, GU_SRC_ALPHA, GU_ONE_MINUS_SRC_ALPHA, 0, 0);

The function we want is (pixel_colour = sprite_colour * sprite_alpha + backgr_colour * (1-sprite_alpha)

c) Enable blending

sceEnable(GU_BLEND);

d) When using the texture:

sceGuTexMode(GU_PSM_8888,0,0,0);
sceGuTexImage(0,TEXW,TEXH,TEXBLOCKW,pointer_to_tex_data);
sceGuTexFunc(GU_TFX_REPLACE,GU_TCC_RGBA);
sceGuTexFilter(GU_LINEAR,GU_LINEAR);
sceGuTexScale(1.0f,1.0f);
sceGuTexOffset(0.0f,0.0f);

TexFunc must be GU_TFX_REPLACE with GU_TCC_RGBA in order use the exact values from the texture bitmap!!!

With all this, I got it to work: a sprite against a background. You can mail me for a sample file ;)