forums.ps2dev.org

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

Does anyone have code for quickly converting RGB to BGR on the fly. The best I've been able to make is this (and the color is still somewhat off):

jsgf · Joined: 12 Jul 2005 Posts: 254

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

Saotome · Joined: 03 Apr 2004 Posts: 182

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

I guess I should have just posted all the code straight out, so here it is with Saotome's mod in it:

holger · Joined: 18 Aug 2005 Posts: 204

be sure that your color buffers are word-aligned, or you decrease performance by unaligned load/store instructions. Using uncached accesses should also improve performance and avoid cache-pollution, but requires flushing the cache before starting the conversion.

Using the VFPU you can further increase memory throughput, by loading 4 32-bit-words at once, maybe the overall performance is still better (especially for unaligned buffers, since you need to do only a single unaligned load/store for 8 pixels), even when moving values to GPRs for shift/and/or. The VFPU instruction set contains instructions named vt5650.q, vt5551.q and vt4444.q, but we still have no idea how they work, maybe they're related.

Another problem is right now that some lv.q cause exceptions when the loaded bit pattern is not a valid floating point number, we need to find out how to switch this off using the VFPU control registers. For fast unaligned loads on use lvl.q/lvr.q.

memon · Joined: 03 Oct 2005 Posts: 63

Couldn't you use the source 565 as a paletted texture and get the conversion 'for free'? Sure that hogs 256Kb of video memory, but since you don't need it anyway for the emulator you loose nothing :)

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

holger · Joined: 18 Aug 2005 Posts: 204

ah, yes... nice idea, too. just st up a color lookup table (LUT) with 65535 entries where the color components of entries at each index are swapped by the formula you implemented above.

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

That's really brilliant. However, I need to get the formula right. So back OT, does anyone have a working RGB->BGR 565 formula.
_________________
w00t

holger · Joined: 18 Aug 2005 Posts: 204

clut[i] = (i & 0x07e0) | ((i & 0xf800) >> 11) | ((i & 0x001f) << 11);

looks right to me. haven't tested it, though. Copy the table to VRAM, if possible, to keep memory bandwidth free for other code. i and clut[i] should be unsigned.

jsgf · Joined: 12 Jul 2005 Posts: 254

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

jsgf · Joined: 12 Jul 2005 Posts: 254

holger · Joined: 18 Aug 2005 Posts: 204

sdk/samples/gu/blit/blit.c is maybe easier to understand.

Arwin · Joined: 12 Jul 2005 Posts: 426

While we're on this topic, I think we also need either a virtual screen of 640x480 or scaling of 640x480 to 480x272. Maybe efficient to combine the two routines, but it's no doubt something ChaosKnight wouldn't mind having some help with (I don't know anything about graphics myself, anyway).

holger · Joined: 18 Aug 2005 Posts: 204

when you blit using the texture unit you can scale on-the-fly. When enabling linear interpolation, a copy to VRAM (using sceGuCopyImage) before rendering the texture could minimize the required bandwidth (direct access to system RAM for linear interpolated textures means 4 accesses per texel instead of one).

sHARD>> · Joined: 05 Oct 2005 Posts: 10

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

sHARD>> · Joined: 05 Oct 2005 Posts: 10

I surfed around, the SE uses a display with 512 x 342 pixels, so any application designed for System 7 should work great on that low resolution, I know almost everything works on my SE at least.

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

Ok, now it's a texture (as in blit.c) and everything is working, just as fast as before but still it does not seem to be using the CLUT. I will post my code here:

jsgf · Joined: 12 Jul 2005 Posts: 254

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

holger · Joined: 18 Aug 2005 Posts: 204

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

I think I have this 99% done. Looks like the screen was black both because I did not have a CLUT properly loaded, but also because the PSP needs to be in 8888 color mode to do this. Which makes perfect sense. Tricky thing is now my clut is turning the screen black and aqua. Of course my #1 culprit is this code:

ector · Joined: 12 May 2005 Posts: 195

Your problem is that the CLUT memory on-chip is only 512 (or possibly 1024?) bytes as far as I can tell.
You can't use a 65536-color palette.
_________________
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.

jsgf · Joined: 12 Jul 2005 Posts: 254

ector · Joined: 12 May 2005 Posts: 195

ChaosKnight · Joined: 14 Apr 2005 Posts: 142 Location: Florida, USA

So then i'm back to doing a while on my buffer to convert blocks of 2px?

-- EDIT --
Went back to Saotome's formula and I discovered something interesting. It was working this whole time but didn't seem like it. I will explain. The video is rendered on two differant threads simultaniously. Basilisk II has access to the "framebuffer" and that was the same one i was working with. So foolishly two threads were touching it at the same time, making the picture purple (red + blue). I created another buffer and used Saotome's method to write to it, which now results in perfect color but a severe slowdown... so here's the question... 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.
_________________
w00t