The Frame buffer proxy hehe

[binaryONE]

Can someone explain or maybe show how to use sceDisplaySetFrameBuf() function please?

Also, does the vram on psp have 2 buffers for screen? I mean like literall 2 buffer..?

If so,

Is there a way (without using the gu/ge/gum libraries) to write to one of vram's frame buffers, for example, the one that is not active yet, and then set it to active maybe with sceDisplaySetFrameBuf(), and keep swapping em?

Is that how that function is supposed to be used?

I'm just curious, I have nothing against using libraries, but so far i can get a 7MB throughput without using any of em (no swizzling ofcourse) but i am hoping to use it if it's possible to flip the switch without major hacking so that any data going to the vram frame buffer is processed as swizzled.

Sorry if it got a little confusing hehe.

Thank you :)

[jonny]

sceDisplaySetFrameBuf sets where the display buffer start, for example:

sceDisplaySetFrameBuf(p, 512, PSP_DISPLAY_PIXEL_FORMAT_8888, PSP_DISPLAY_SETBUF_IMMEDIATE);

show the content of the memory pointed by p to the psp screen (in this example p is supposed to point to a 512x272x4 buffer)
p doesn't need to be in vram (so you can "malloc" many buffers)

if you fill buffers with the cpu it's probably the best way (iirc reading/writing the vram with the cpu is slower compared to normal ram access)



you could also use the vram:

sceGuDrawBuffer(GU_PSM_8888, 0, 512);
sceGuDispBuffer(480, 272, 4 * 512 * 272, 512);

in this example the draw buffer can be accessed at 0x04000000
the display buffer at 0x04000000 + 4 * 512 * 272

so you can write the draw buffer and swap the buffers with:

sceGuSwapBuffers();

afaik sceGuDrawBuffer/sceGuDispBuffer can set the buffers everywhere (as long as you stay in the 2MB vram limit and you probably respect some alignment)

this way require a minimum gu setup (as the sdk samples show) and, as i have told you, it's probably slower if you fill the draw buffer with the cpu

[binaryONE]

So then it would be faster to 'set' the frame pointer to an already allocated and color loaded 512 * 272 * 4 memory region then to memmove it to vram frame buffer?

Also then, once that's done, the frame is .5~MB so there is room in vram for 3 such regions. Then would it be faster setting the frame pointer to the data already within the vram 2MB space then in memory?

[jonny]

not tested, but the cost of sceDisplaySetFrameBuf should be near to 0.
i also think that sceGuSwapBuffers is internally implemented via sceDisplaySetFrameBuf (i don't find reasons why it shoudn't).

but in the real case, to avoid flickering, you should do something like this:

sceDisplayWaitVblankStart();
sceDisplaySetFrameBuf

handling vsync with no overhead is more difficult (at least if you don't decide to ignore it :)

[binaryONE]

Hmm, I'm definately going to try that today.

About the swizzling mode; from the sdk source all I can tell is that it's a switch, does it tell the psp to to flush the contents of a memory region vram or ram, to the screen, in that specific way to output it in chunks?

That would make sense, and if it's true then is it possible to just flip that switch and 'set' the frame buffer to the swizzled pixel array?

THis is what i've found in the psp docs:

12.5.155 TMODE

0xc2 4 w TMODE - Texture Mode
31 24 23 16 15 8 7 0

bit(s) description
16-20 Maximum mipmap level
8-15 ???
0 Swizzle Enable

that explains why the command is 'OR'ed' with a 0 or 1 in the sdk code.

But im still not sure if that makes the flushing the pointed to contents of ram or vram in 16 byte chunks, or is there more to be done...

[chp]

Swizzling is done in hardware, the GE uses that flag to tell it to read textures in a more optimized way in preprocessed data. You cannot render into a swizzled surface, the GE is only doing linear writes.

[binaryONE]

I see.

Makes, sense, swizzling is a texture mode option which is an option for the GU and it understands what to do with it...

thanks for the help guys :)