Gu Functions Help

[InflamedSpirit]

After browsing/searing these forums, looking through the documentation/samples, and reading parts of pspgu.h I have some ideas on how the Gu functions work but I think I still have quite a bit of basic questions.


If I understand it correctly, the sceGuStart(GU_DIRECT,list) function starts "recording" all the graphic functions into the list and they are only executed when sceGuFinish() is called? And the sceGuSync(0,0) that appears afterword, is that required after every call of sceGuFinish()?

Also, I'm a little confused about the following code that is often in the declaration of certain variables: __attribute__((aligned(16)))
What does the __attribute__((aligned(16))) mean exactly?

And finally, about the sceGuSwapBuffers() command, are the buffers completely handled somewhere else? If I see it right, we put in the code the type of screen we want (# of bits, width/height etc) and it will make 2 different buffers for us?


Hope you can help me out :)
Thanks in advance!

[InflamedSpirit]

Ok, Scratch this question, I figured it out. (I didn't see that DrawBuffer and DispBuffer both made one)

And finally, about the sceGuSwapBuffers() command, are the buffers completely handled somewhere else? If I see it right, we put in the code the type of screen we want (# of bits, width/height etc) and it will make 2 different buffers for us?

[ReKleSS]

Ok... sceGuStart is to give the GU code some memory to use for its command list. As I understand it the GU may begin executing code before you run sceGuFinish, but you probably don't need to worry about that too much. sceGuSync just stalls until the GU is done, so you know that the scene is finished drawing - probably a good thing to do before you flip the buffers. The __attribute__(aligned) thing aligns the memory to whatever you indicate, 16 bytes in this case. This has to do with the way the GU accesses system memory. I know that texture data must also be 16 byte aligned, and I think vertex data may also require alignment.
-ReK

[InflamedSpirit]

Ok, thanks! I've gotten most of it now.

Unfortunatly, I'm having a problem now when compiling. I'm getting loads of "Undefined refrences" to all of the Gu functions:
sceGuInit
sceGuStart
sceGuDrawBuffer
sceGuDispBuffer
etc....

I have included the pspgu.h but I have a feeling I'm missing some compiler flags but I have no idea what. Note that I put the Gu functions im using inside of functions in a header.

[chp]

You also need to link with the library in question. Adding '-lpspgu' to the LIBS-line in the makefile should take care of that.

[Paolo]

sceGuSync just stalls until the GU is done, so you know that the scene is finished drawing - probably a good thing to do before you flip the buffers.

Can I trust the Gu to execute given commands in logical order, ie if I clear
back buffer using sceGuClear(), can I start drawing immediately, or should I
call sceGuSync in order to be sure that clearing is finished?

[ReKleSS]

I'm fairly sure the GU will execute commands in the order that you give them. I've been assuming it does and it hasn't gone wrong so far...
-ReK

[chp]

The GE executes all commands in the order it receives them, so a clear will always execute in the location that it was fed. The only time you could have synchronization issues is if you have something that the CPU generates and the GE depends on, and if it's not done proper you'd have a race condition.

Being able to depend on that stuff on the GE happens in the set order is very handy since you can reuse buffers later on (rendertargets for example). This is quite common on the PS2 where the next texture could be uploaded to VRAM while you're rendering using the current (mskpath3 & intermittent mode).

[Paolo]

By the way; are the state setting commands (sceGuSetStatus & sceGuSetAllStatus)
included to the command list, or are they executed immediately...?

[InflamedSpirit]

Thanks chp, I got it to start compiling without errors. However, when it runs, nothing draws. I've set up a few functions (just to test things) but nothing works (as in I just see a blank screen).

Here are the basic graphic functions I set up:

Code: Select all

struct Vertex
{
	int x, y, z;
	int padding;
};

void InitializeGu()
{
	sceGuInit();

	sceGuStart(GU_DIRECT,list);
	sceGuDrawBuffer(GU_PSM_4444,(void*)0,512);
	sceGuDispBuffer(480,272,(void*)0x88000,512);
	sceGuDepthBuffer((void*)0x110000,512);
	sceGuOffset(2048 - (480/2),2048 - (272/2));
	sceGuViewport(2048,2048,480,272);
	sceGuDepthRange(0xc350,0x2710);
	sceGuScissor(0,0,480,272);
	sceGuEnable(GU_SCISSOR_TEST);
	sceGuFrontFace(GU_CW);
	sceGuEnable(GU_TEXTURE_2D);
	sceGuClear(GU_COLOR_BUFFER_BIT|GU_DEPTH_BUFFER_BIT);
	sceGuFinish();
	sceGuSync(0,0);

	sceDisplayWaitVblankStart();
	sceGuDisplay(1);
}

void DrawStart()
{
	sceGuStart(GU_DIRECT,list);
}

void DrawEnd()
{
	sceGuFinish();
	sceGuSync(0,0);
}

void DrawLine(int x0, int y0, int x1, int y1, char r, char g, char b, char a)
{
	vertices = (struct Vertex*)sceGuGetMemory(2 * sizeof(struct Vertex));

	sceGuColor&#40;&#40;&#40;&#40;r>>4&#41;<<12&#41;|&#40;&#40;g>>4&#41;<<8&#41;|&#40;&#40;b>>4&#41;<<4&#41;|&#40;a>>4&#41;&#41;&#41;;

	vertices&#91;0&#93;.x = x0;
	vertices&#91;0&#93;.y = y0;
	vertices&#91;0&#93;.z = 0;

	vertices&#91;1&#93;.x = x1;
	vertices&#91;1&#93;.y = y1;
	vertices&#91;1&#93;.z = 0;

	sceGuDrawArray&#40;GU_LINES,GU_COLOR_4444|GU_VERTEX_16BIT|GU_TRANSFORM_2D,2,0,vertices&#41;;

&#125;

And heres the main part of my program:

Code: Select all

	InitializeGu();

	while(1)
	{
		DrawStart();
			DrawLine(0,0,240,136,255,0,255,0);
			DrawLine(10,10,340,136,255,0,0,0);
			DrawLine(50,50,140,136,0,255,0,0);
			DrawLine(200,200,240,236,0,0,255,0);
			DrawLine(400,250,240,36,255,255,255,0);
		DrawEnd();

		sceDisplayWaitVblankStart();
		sceGuSwapBuffers();
	}

I don't claim to know what most of the stuff is in the InitializeGu funtion or the sceGuDrawArray function so I assume my errors are in there.

[rinco]

You are specifying GU_COLOR_4444 which would indicate your Vertex structure is providing color information. Which it doesn't. You could either add a short color to the start of your struct (and set a value for each vertex), or not specify GU_COLOR_4444.

[InflamedSpirit]

Hmm, it still didn't work, still all blank :(
Thanks anyway though, It's a good thing to know :)

I actually used to have a color variable in my vertex structure but I removed it after looking at the lines sample seeing none.

Any other ideas?

[InflamedSpirit]

Ok, I'm about to give up with the Gu functions,

When I changed my vertex structure to floats for xyz and add the "GU_VERTEX_32BITF" to the sceGuDrawArray function, guess what, I see the lines! Now why would it not work with ints in the code posted above? (code posted minus the GU_COLOR_4444 in sceGuDrawArray)

Also while I was testing with the floats I noticed that the colors were completely messed up. The "R" variable made it green. the B did nothing, the G made it red and the A did nothing. Is my color code messed up as well?

As far as I can see, my code sets it up fine for a 4444 setup... As it says in pspgu.h "GU_COLOR_4444 - 16-bit color (R4G4B4A4)"

This IS how the bit shifting works right?

Code: Select all

&#40;&#40;r>>4&#41;<<12&#41;|&#40;&#40;g>>4&#41;<<8&#41;|&#40;&#40;b>>4&#41;<<4&#41;|&#40;a>>4&#41;&#41;

red|blu|grn|alp|
0000000000000000  u16 color variable
0000****                red
    0000****            blue
        0000****        green
            0000****    alpha


*=deleted with the >>4 shift

I would be grateful if someone could clear this up for me.

[ReKleSS]

Heh, I didn't spot that in your code before... ints are 32 bits, not 16. That's why the hardware didn't like your vertices...
Also, regarding your issue with the colours - why are you shifting right then left? If you want to clear unneeded bits then just AND them with whatever mask you need, otherwise the compiler may optimise your left shift out of it. I think your B and R channels may be switched around, you might want to check that.
-ReK

[InflamedSpirit]

THANK YOU! It finally works! :D Whew, I feel foolish about that whole int thing.

I took your advice and did an AND of each color with 240 (11110000) and it works great!
Also, apparantly it goes A G B R not R B G A so either its listed reversed in the docs or I'm supposed to read it differently.

Thanks again!