GP2X Nes Tile Optimization

[bitbank]

This may have been done already, but I came up with a good ARM optimized way of taking NES tile data and converting it into 1 byte per pixel. The NES tile data is stored as bitplanes with each byte containing all 8 pixels for a single bit plane. Here's my code for converting the 2 bit planes into 2 longs with the 8 pixels.

At the start of the loop, set r10 = 0x01010101 to mask off unwanted bits
R9 contains the color pallete in every byte (bit 6 & 7)

ldrb r6,[r3,r1] ; get bit 0 pixels
add r3,r3,#8
ldrb r7,[r3,r1] ; get bit 1 pixels
orr r6,r6,r6,LSL #9 ; shift them over 1 byte + 1 bit
orr r6,r6,r6,LSL #18 ; now 4 pixels take up 4 bytes
and r8,r10,r6,LSR #7 ; mask off the upper nibble pixels we want
and r6,r10,r6,LSR #3 ; mask off the lower nibble pixels we want
orr r4,r9,r8 ; add the color to the "left" dword
orr r5,r9,r6 ; ditto for the "right" dword

orr r7,r7,r7,LSL #9 ; process the bit 1 pixels
orr r7,r7,r7,LSL #18
and r6,r10,r7,LSR #7 ; mask off the upper nibble pixels we want
and r8,r10,r7,LSR #3 ; mask off the lower nibble
orr r4,r4,r6,LSL #1
orr r5,r5,r8,LSL #1

stmia r2!,{r4,r5} ; store 8 pixels

Anyone see a better way?

 

[slaanesh]

Not sure how many response you are going to get. Lots of specialized knowledge required here.

Planar to Chunky conversion has been the bane of many a programmer since the old Amiga/ST days. I've always wondering why hardware used planar formats in the first place - there must be some advantage. For the Amiga it was conserving RAM and bandwidth through sacrificing color palette size.

Planar graphics layouts are often used in arcade machines too. MAME converts graphics from these weird and varied formats to a one byte per pixel CLUT. Well early versions of MAME relevant to the GP2X anyway.

As for your code, I'd have to get my ARM9 assembly documentation out again...

 

[rememberthe8bit]

Cool. Hopefully this will be implemented into GPFCE.

 

[Mudi]

These are probably things worth posting in the NESemDev forum at NESdev

 

[Exophase]

I imagine that efficient NES emulators would cache the tiles in this form and update it as PPU memory is modified. I would also imagine that these modifications happen much, much less frequently than the tile data itself is used (with occasionally en entire screen being reloaded). In fact, isn't much of this data often in bank switched ROM anyway?