In the way of using dynamic palettes,
You can implement a control system in the level compilation.
While compiling, the program detect if more than 16 palettes are used by
animations in 1 GBA screen.
It is true that when you have a dynamic management for animations, it take
more ressources, but the processor is fast.
In my engine, I have full dynamic allocations for animations (characters and
palettes) and the same for background. At the same time, we uncrunch all
data in real time for animations and background (2 levels of compression : 1
is a kind of RLE compression) for levels & animations.
And we haven't any problems of time.

So in my opinion, Dynamic alloactions are the best way to make a good game,
because graphists don't take care of anything. There are less problems.

Christian.




-----Message d'origine-----
De : Otaku [mailto:otaku@...]
Envoyé : mardi 2 avril 2002 04:01
À : GBADEV Mailing List
Objet : Re: [gbadev] Various sprites and one palette

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