Fast 565 RGB->BGR Conversion Needed

[holger]

How do I get a block of memory on VRAM? do I just have to point to a certain address? If so what is that address and how much space am I allowed to use within it. It seems i'm only using ~265K for a buffer, so it's pretty small yet, but I wish to experiment with larger resolutions and scaling.

Unless you want to do dynamic memory allocation just pass a pointer to a (yet unused) VRAM area behind your frame buffers. sceGeEdramGetSize() returns the size of VRAM, sceGeEdramGetAddr() the start address. The size of your frame buffer you need to calculate manually.

[ChaosKnight]

Okay, doing the VRAM thing led to textures that were really fun but not quite right. Flushing the cache and forcing a writeback was also fun and made the texture even crazier. So I went back to sane RAM until I get get VRAM figured out.

I did my own CLUT which is basically the same as before except instead of telling the hardware to do it I do this:

Code: Select all

	// Color correction LUT method
	for &#40;int i = 0; i < SCREEN_WIDTH * SCREEN_HEIGHT; i++&#41;
		PspFrameBuffer2&#91;i&#93; = CLUT&#91;PspFrameBuffer&#91;i&#93;&#93;;

Which is incredibly slow. Any thoughts?

[Arwin]

Any thoughts?

What did you do with this suggestion from Holger?:

The size of your frame buffer you need to calculate manually.

Maybe something went wrong there?

[ChaosKnight]

I don't think so, that was pretty simple stuff:

Code: Select all

PspFrameBuffer = (FB_TYPE *)sceGeEdramGetAddr();
PspFrameBuffer2 = PspFrameBuffer + BII_FRAMEBUFFER_SIZE;

[Arwin]

I don't think so, that was pretty simple stuff:

Code: Select all

PspFrameBuffer = (FB_TYPE *)sceGeEdramGetAddr();
PspFrameBuffer2 = PspFrameBuffer + BII_FRAMEBUFFER_SIZE;

And how does that calculate the framebuffer size? I feel like an idiot, but I don't get it. I see that a syscall gets an address, and I see that address being added to a constant/variable which seemingly comes out of nowhere.

Anyway, I don't know anything about this at all so I'm just being stupid. I think I'll go brush up on this stuff a bit later on. I need to learn a lot ... maybe find a good book on basic low-level graphics.

[ChaosKnight]

This may help:

Code: Select all

#define BII_FRAMEBUFFER_SIZE        (PSP_LINE_SIZE * SCREEN_HEIGHT * PIXEL_SIZE) 

[holger]

sceGuDepthBuffer((void*) 0x110000, PSP_LINE_SIZE); is probably at the same address as your LUT. So writes to the depth buffer overwrite the CLUT.

[holger]

another check: do you set up the CLUT pixel format correctly to BGR565 ?

[ChaosKnight]

The depth buffer is setup like this now:

Code: Select all

#define SCREEN_HEIGHT           272
#define PSP_LINE_SIZE           512
#define BII_PIXEL_SIZE          2
#define PSP_FRAMEBUFFER_SIZE    (PSP_LINE_SIZE * SCREEN_HEIGHT * PSP_PIXEL_SIZE)
sceGuDepthBuffer((void*)(PSP_FRAMEBUFFER_SIZE * 2), PSP_LINE_SIZE);

I really wish I had a memory map... I feel like some ancient explorer who didn't feel like making a map and so sailed in circles until his death.

[holger]

Should work ok for your usecase, but the macros will fail as soon you change to framebuffer color format - depth size is always 2, color pixel size can be 2 or 4, depending on the format.

Maybe you want to consider to port your graphics backend to OpenGL (the API is not far from libgu anyways). Jeremy's pspgl tree supports indexed textures as you need and you don't need to worry about cache and VRAM management, this complexity is transparently handled.

For free you get portability to desktop and other console systems. And all the work you do on the input system (in glut.c? I'd like to see some mouse/keyboard emulation there, the effort to incorporate this is the same as you need to do anyways - ), is reusable by other projects. Maybe you want to take a closer look...