GU_ONE blend factor? and other blending musings

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
jsgf
Posts: 254
Joined: Tue Jul 12, 2005 11:02 am
Contact:

GU_ONE blend factor? and other blending musings

Post by jsgf »

It is just me, or does it look like the GU has no equivalent of the GL_ONE blending factor (or GL_ZERO, but that's less useful).

This means that it's hard to use pre-multiplied alpha source fragments (since GU_SRC_ALPHA will re-multiply it with alpha again, giving alpha^2). Also, it make simple additive blending hard (simply summing the fragments rather than alpha blending them).

The only workaround I can see is to use GU_FIX and set the fixed color to 0xffffff, but there doesn't seem to be a way to set a fixed alpha channel.

Am I missing something here?

BTW, there seems to be a mistake in pspgu.h. GU_DST_COLOR is defined as 0, but that GU_SRC_COLOR. The DST factors are different from SRC factors; I suspect they should be something like:

Code: Select all

/* Blending Factor */
#define GU_SRC_COLOR             (0)
#define GU_ONE_MINUS_SRC_COLOR	(1)
#define GU_SRC_ALPHA		       (2)
#define GU_ONE_MINUS_SRC_ALPHA	(3)
#define GU_DST_COLOR		       (4)
#define GU_ONE_MINUS_DST_COLOR	(5)
#define GU_DST_ALPHA		       (6)
#define GU_ONE_MINUS_DST_ALPHA	(7)
/* 8? */
/* 9? */
#define GU_FIX			          (10)
but I haven't tested it. There's still two more gaps in there for other types of blend factors (maybe one of the non-standard GL extension blend factors, like alpha^2). Perhaps GU_ONE is > 10?

Hm, and I wonder if the source and destination factors have the same encoding? OpenGL specifies things this way, but there's no reason the hardware has to do it (especially since it doesn't seem to fully implement all possible OpenGL blending modes anyway).

It looks like the stencil buffer is stored in the framebuffer alpha channel, which suggests that you either get destination alpha blending or a stencil buffer. (Other hardware typically handles this tradeoff by using some of the depth buffer as a stencil buffer, so you get 24 bits of depth and 8 of stencil; I guess the PSP has a fixed 16 bit depth, and you really can't make do with anything smaller, so no sharing with stencil).

I guess some experiments are in order.
Coderboy
Posts: 6
Joined: Sun Aug 07, 2005 12:10 pm

Post by Coderboy »

If I remember correctly the blending (in both DX and GL) works like this:

FINAL = FACTOR1 * SRCFRAG + FACTOR2 * DESTFRAG

Using GU_FIX and fixed color for source or destination will be exactly the same as using GL_ONE / GL_ZERO...? (which in opengl represents a value of 0xffffffff / 0x00000000). So GU_FIX is actually more versatile than the constants in opengl/directx.

Or am I not understanding what is troubling you?

And yes, source and destination use the same so you can specify GU_FIX for one or both of these with independant factors.
jsgf
Posts: 254
Joined: Tue Jul 12, 2005 11:02 am
Contact:

Post by jsgf »

Coderboy wrote:Using GU_FIX and fixed color for source or destination will be exactly the same as using GL_ONE / GL_ZERO...? (which in opengl represents a value of 0xffffffff / 0x00000000). So GU_FIX is actually more versatile than the constants in opengl/directx.

Or am I not understanding what is troubling you?
Right, but the fixed colour is only 24 bits, so you can't specify an alpha, so the resulting alpha will be wrong. Does the hardware support destination alpha? Or is there a second fixed colour register for the alpha channel?
chp
Posts: 313
Joined: Wed Jun 23, 2004 7:16 am

Post by chp »

jsgf wrote: Right, but the fixed colour is only 24 bits, so you can't specify an alpha, so the resulting alpha will be wrong. Does the hardware support destination alpha? Or is there a second fixed colour register for the alpha channel?
This was just as annoying as on the PS2, which also lacked separate alpha-blending. The hardware DOES support destination alpha, at the time when I derived the blending flags however, I didn't figure it out and then I forgot about it.. :) I have added the remaining blending-flags from pspgl. Grab latest from gu in pspsdk and you will have those flags.
GE Dominator
Coderboy
Posts: 6
Joined: Sun Aug 07, 2005 12:10 pm

Post by Coderboy »

Ah ok, I didn't know that. That might explain a bug or two I am seeing actually.

Very weird that the fixed color isn't 32 bit... Oh well, thanks for the heads up.
jsgf
Posts: 254
Joined: Tue Jul 12, 2005 11:02 am
Contact:

Post by jsgf »

chp wrote:I have added the remaining blending-flags from pspgl. Grab latest from gu in pspsdk and you will have those flags.
OK. What about the DST_COLOR values? Are they right?
chp
Posts: 313
Joined: Wed Jun 23, 2004 7:16 am

Post by chp »

jsgf wrote:
chp wrote:I have added the remaining blending-flags from pspgl. Grab latest from gu in pspsdk and you will have those flags.
OK. What about the DST_COLOR values? Are they right?
yes.
GE Dominator
Coderboy
Posts: 6
Joined: Sun Aug 07, 2005 12:10 pm

Post by Coderboy »

Another thing I've noticed is that alpha masking doesn't seem to affect zbuffer. That is, if a pixel is rejected based on alpha masking, it still writes to the zbuffer?!!!

Anybody else notice this behavior or might it be a bug on my end?

(This is very bad since one-bit alpha textures will have to be alpha sorted = slow as hell)
Coderboy
Posts: 6
Joined: Sun Aug 07, 2005 12:10 pm

Post by Coderboy »

Nevermind, mixed up ref and mask in my calls. Hehe.
starman2049
Posts: 75
Joined: Mon Sep 19, 2005 5:41 am

Post by starman2049 »

Question: on PS2 an Alpha value of 128 == full value, completely opaque. Is t the same on PSP, or is it 0xff is full value.

This question is both for vertex alpha, and for texture alpha.
ector
Posts: 195
Joined: Thu May 12, 2005 10:22 pm

Post by ector »

0xff is full value, as far as I can tell.
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.
Post Reply