gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > The 17th palette

#15580 - poslundc - Sun Jan 25, 2004 6:11 pm

Just something that has occurred to me occassionally in my musings while I'm coding. I imagine it's occurred to others as well, but since no one's documented it to my knowledge I figured I may as well post it here.

If you're using 16-colour sprites you can squeeze an extra palette in by using the zeroth entry of each of the sixteen palettes as the colours of your 17th palette. Then you just need to store sprites using the 17th palette as 256-colour sprites.

The colours of the 17p-sprite will render as transparent on all of your other sprites (because they are the zeroth entry of those palettes) but solid on the 17p-sprite, except for the very first entry which will be transparent.

So to map a normal 16-colour sprite to the 17th palette, you would just have to walk through each of the pixels and multiply its value by 16. Something along the lines:

*(p++) = *(q++) << 4;

... but with some or-ing and shifting modifications to handle multiple pixels.

Can't say I've ever run into a situation where having an extra 16-colour palette would make all that much difference, but there you have it anyway.

Dan.

#15581 - DekuTree64 - Sun Jan 25, 2004 8:46 pm

Yeah, beeing the resource-conserving hacker that I am, I've thought about that too, and also for tiles. Like for my RPG's battle system, which has static backgrounds, I could use the first entries of the first 8 palettes, and all the entries of the next 8 to get a 136 color BG instead of 128, while still leaving those lower 8 palettes open for spells to use.
Not worth the trouble for just a couple of extra colors, but still a thought.

One that is worth doing though is since the battle screen only takes the upper 20 rows of the screen data, use the lower 12 for tiles. 12rows*32wide*2bytes each is 24 extra 16-color tiles, which are quite usable for the start of the font data.

And then there's using the 'dead' VRAM space like that for tables and stuff, which I did a lot in my Eternity demo. I think it's a little faster than EWRAM, so it's fun to use for other things.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#15593 - Miked0801 - Sun Jan 25, 2004 11:09 pm

Cool Idea. A 17th palette is always useful :)

And I believe VRAM is 0 wait state - though only 16-bit bus so it would be faster than EWRAM.

#15600 - Tim - Mon Jan 26, 2004 12:10 am

That's a great idea, I always thought that 16 different transparent colours was a bit of a waste :)

#15614 - poslundc - Mon Jan 26, 2004 4:48 am

Miked0801 wrote:
And I believe VRAM is 0 wait state - though only 16-bit bus so it would be faster than EWRAM.


I've often thought about using VRAM for stuff like that, the only problem is I almost never know how much VRAM I'm using until it's too late anyway. :)

Here's a thought: you could put Thumb code in VRAM to make multiboot games run faster.

Dan.

#15615 - tepples - Mon Jan 26, 2004 5:42 am

What changes would one need to make to the DevKit Advance R5 crt0 and link script to allow for a 16 KiB R/W overlayed segment at 0x0600c000 called ".vram0" through ".vram9"? Yes, copying the IWRAM support would work, but can somebody state the requirements more carefully for a proper feature request?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.