A rather belated reply to the thread as I'm busy finishing up my current
project.

Muddying the waters even further here's my 2 penn'orth worth. I actually use a
couple of different methods depending on the view. I have one placed in the game
where I have a large 256 colour sprite on-screen, which obviously uses fixed
colours so I use a "fixed" palette, the sprite uses the first 64 entries in the
palette, I then over-write certain other portions of the palette for a number of
16-colour sprites that share the same screen. For another view I use a fixed
palette but switch out the first four banks of 16 colours for various team
colours, each team has two sets of colours, some of the colours are the same
(the sleeves on their shirts change colour, their caps change colour), but skin
colour and hair colour changes depending on racial origin. So I can mix and
match the players. All of these slots are "fixed" in the sense that the sprites
"know" which palette to use but the colours there may change. For the menu
systems all of the sprites are 16 colours and the palettes are dynamically
assigned. One footnote, when you mix 256 colour sprites and 16 colour sprites,
if you are "clever" with your colour allocations you can have a 256 colour
sprite and a 16 colour sprite sharing the same region of the palette, also for
the 256 colour sprite, those "transparent" colours that are modulo 16 (0, 16,
32, 48, 64, etc) are usable as normal.

Fixed palette
Info: The entire palette is determined at pre-compile time by the artist or
programmer, or determined at compile time by the compiler.
Pros: a) Allows the use of 256 & 16 colour sprites on the same screen
Cons: a) Inflexible approach. b) Can quickly run out of colours c) Artists hate
it.

Static palette
Info: Portions of the palette are loaded under programmer control as and when
needed, the colours are dynamic but the entries they are loaded to are static,
i.e. load the palette for the player at slot #5.
Pros: a) Flexible approach. Useful for both 256 colour & 16 colour sprites,
especially when mixing on the same screen.
Cons: b) Difficult to explain to the artist. b) Programmer has to worry about
which slots are open. c) Can make re-arranging palettes difficult.

Static palette & Dynamic palette
Pros: a) Flexible approach. b) Allows automatic changing of palettes on the fly.
Cons: a) Bloody difficult to explain to the artist. b) Tedious to implement. c)
Can be slow to execute if your in-game resource management system is not
implemented properly.

Fully Dynamic palette
Pros: a) Totally flexible b) You don't worry about where the palettes are
allocated.
Cons: a) Not suitable for 256 colour sprites. b) Can be difficult to debug. c)
Same as point c) above. d) Extra lookups during run-time to see which palette to
use for a particular sprite/animation frame. d) Artists love it. e) Extra
overhead when de-allocating palettes no longer in use. f) You can run out of
palettes if you have an over-zealous level designer or artist who will usually
say something along the lines of "just make it work", "don't bother me with
details", and "is there any way we can get another 128 hardware palettes?".


----- Original Message -----
From: Andrew Crowe
To: gbadev@yahoogroups.com
Sent: Tuesday, March 26, 2002 3:42 AM
Subject: Re: [gbadev] Various sprites and one palette


> I have many sprites to show simultaneously in the game I`m working on,
and I`d like to know from you guys the best way to work with the palette. Do
all sprites have to share the same palette, as in the GBC? Which would be
the best way to set up a complete palette of all my sprites? I was thinking
about making a big PCX with all of them and then saving the palette, and
then applying it back to each sprite separately, but I don't know if this
works, and it feels like brute force. Is there any other way?

Sprites use one 256 colour palette, either all 256 colours at once (all
sprites have the same palette) or each sprite can use 16 colours from the
palette, taken in groups of 16.

The way that I'm planning to do is give each sprite it's own 16 colour
palette, then build the main palette dynamically

eg.

say you have 2 copies of sprite 1 which has palette A, and another sprite
with palette B:

Sprite 1: colours 0-15
Sprite 2: colours 0-15
Sprite 3: colours 16-31

Palette:

colours 0-15 : A
colours 16-31 : B


If I moved sprite 3 off screen, and broght on a different sprite, I'd
replace colours 16-31 with the new palette

That way you could have any number of colours for sprites, tho you'd have to
write palette management routines, and of course you could only have 16
different "types" of sprite onscreen at once



Andrew



Yahoo! Groups Sponsor
ADVERTISEMENT




Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.