forums.ps2dev.org

InflamedSpirit · Joined: 03 Oct 2005 Posts: 14

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 · Joined: 03 Oct 2005 Posts: 14

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

ReKleSS · Posted: Thu Nov 10, 2005 1:23 pm Post subject:

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 · Joined: 03 Oct 2005 Posts: 14

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 · Joined: 23 Jun 2004 Posts: 313

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

Paolo · Joined: 08 Nov 2005 Posts: 12

ReKleSS · Posted: Thu Nov 10, 2005 8:23 pm Post subject:

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 · Joined: 23 Jun 2004 Posts: 313

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).
_________________
GE Dominator

Paolo · Joined: 08 Nov 2005 Posts: 12

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

InflamedSpirit · Joined: 03 Oct 2005 Posts: 14

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:

rinco · Posted: Sat Nov 12, 2005 10:59 am Post subject:

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 · Joined: 03 Oct 2005 Posts: 14

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 · Joined: 03 Oct 2005 Posts: 14

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?

ReKleSS · Posted: Sun Nov 13, 2005 7:59 am Post subject:

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 · Joined: 03 Oct 2005 Posts: 14

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!