Dungeon Master Forum

Posted: **Thu Apr 01, 2004 7:00 pm**

I have received a complaint that the Champion Portraits in
a custom dungeon contained purple where yellow was expected.
This has to do with Purple Worms versus Yellow Worms.

I put a few words about palettes in the CSBwin documentation.
http://www.dianneandpaul.net/CSBwin/documentation/

Posted: **Thu Apr 01, 2004 8:20 pm**

the info found here i used sometimes to make different colored monsters :
http://www.dungeon-master.com/forum/vie ... hp?t=21142
quite a funny thing, but i don't know how to do that in csbuild.
i won't suggest to use colored monsters on a level where portraits are.

Posted: **Thu Apr 01, 2004 8:57 pm**

That information is quite out of date now. Charlatan has decoded the bulk of the structure known as '0558' -- it's part of the graphics.dat file. Within it is all the information about palettes, as well as how to get monsters using different colours from the secondary palette. It's actually possible to have more varieties than were displayed in DM and CSB by hex editing monster info (if you read Paul's documentation about the colours #9 and #10 and also read Charlatan's notes, you'll see how it all works).

Now that this information is known, the 'hit and miss' affair of assigning palettes using DMute is long gone. You do need to know how to use a hex editor to edit the graphics.dat though.

At some point I will write up Charlatan's information in English, as best as I understand it.

I'm working on a new graphics set that exploits this palette information...

Posted: **Sat Apr 03, 2004 5:47 am**

any chance to avoid hex-editing there?
i also love to have worms in 3 different colors in one dungeon, but since theres no "check level integrity" in csbuild, i can't set the level-color and if i edit the graphic.dat, all worms share one color - which musn't be purple at least but that also makes me add a graphics.dat.
i guess csbwin has still the same color limits - how about a pulldown-menu to change the color-settings of a level?
the feature still works, in imprisoned again there are red worms and the fact that portraits in mirrors may have odd colors, verifies that.
of course, the pulldown menu should have a warning: "Attention! Don't set any color on a level with champion portraits unless you risk them looking rather ugly. Not all monsters look good in any color - try pink Beholders and you see what i mean!"
is that doable?

Posted: **Sat Apr 03, 2004 1:01 pm**

A menu may well be doable, but I don't think it's practical or sensible. part of the challenge of getting new monsters into CSB4WIN is to understand how the palettes work, and how to design your creatures accordingly.

For example, if you want a creature that uses the flesh colour for skin tones, you can also use other creatures that don't switch palettes on the same level as your fleshy creature (such as screamers, skeletons, mummies, etc.). However, if you put your fleshy coloured creature on the same level as an oitu, dpending on how you set the priority, you flesh creature might turn orange. But in fact that might not look too bad, if it's the effect you want. But putting them on a level with blue cratures will make the skin turn blue which is gonna look very silly.

So you have to think carefully about what colours to use in your creatures, which creatures take priority (hex editing), and which creatures can share levels....

As for changing this info without hex editing -- no it can't be done at the moment. But the information is all available in charlatan's notes, so I guess it wouldn't be too hard for someone to write a tool for editing the 0558 data file....

Posted: **Sat Apr 03, 2004 3:27 pm**

i'm used to make thoughts which monsters may share a level and which can't, so that's no limitation.
so why not make a setting editable in csbuild, which is already there? you can still edit the graphics.dat for your advanced stuff, but i don't need that

Posted: **Sat Apr 03, 2004 4:35 pm**

Actually, it would not be too difficult to provide a
way to specify all 16 colors for each level. Some
combinations of colors would cause rather silly effects
but that is your business. In this way you would have
completely independent palettes for each level. The
walls, the floors, the monsters, everything.

There is a function in the code that sets the color palette
when the party enters a level. At the end of that function
I would override the palette if you specified a custom palette
for that level.

What is the consensus? Would this be useful?

Posted: **Sat Apr 03, 2004 4:41 pm**

I would vote yes if vote be needed : )

Posted: **Sat Apr 03, 2004 4:47 pm**

for the different colors of monsters, there are only 1 or 2 colors which need to be changed (see link), the other 14 are permament for floor, walls, items on floor and decoration. but if you can edit the 14/15 permament colors, too, that would allow some fun. or it would simply look crappy, because blue walls would also mean blue rockpiles and maybe even partial blue swordblades (when you drop them). in skillful hands, it can surely create a new ambiance, in my hands...erm...

i can't really decide if changing of the permament colors makes sense (but allowing it with some warning next to it wouldn't hurt) - changing the monster color(s) would be very useful in every case.

Posted: **Sat Apr 03, 2004 6:40 pm**

I was under the impression we only had 2 colours we can safely alter without messing the entire screen up. Those would be the two that turn purple on the worms level of DM.

now as far as I know.. in the code for the atari it takes the images.. puts them into the screen buffer and masks them if they are using the mask colour and then put's them to screen. This is where you take hold of it and put that image into your buffer and then send that to our screen.

There is no way of pulling back a step? interrupting the call for the graphic and then grabbing it yourself from the graphics.dat? then you put it to screen? Because if you could do that.. I imagine you could set a 256 colour mode and just grab the pallete from the image since it is stored in each isn't it? Then they could fiddle with the colours to their hearts content still using colour 0 as their mask colour. (at least that's how it worked in the Amiga. the first colour in your pallete was always the mask colour)

As with all my sugggestions.. this is suggestion is based on my limited knowledge of old game engines.

I have no idea how hard it would be to catch that bit before it hit the screen since in essence what you've got is an emulator of sorts right? With special hacks thrown in for all of us to fiddle with whatever..

but it would be "tres cool":)

Posted: **Sat Apr 03, 2004 6:48 pm**

wait.. better idea.. maybe..

Can you tell at any given time what is on screen at any given time? By this I mean which graphics are supposed to be shown. Wall sconce, a monster.. which frame of the monster (side, forward attack etc), stairs.. etc etc

Because If you skipped the copy of the screen and just put it to screen yourself you could do anything you want.. however you have to know what to put up and when..

Posted: **Sat Apr 03, 2004 7:06 pm**

Sounds incredibly complicated in terms of CXSB4WIN. Each image does NOT contain it's own palette -- it just contains a palette 'index' -- the palette itself is stored somewhere else, probably hard coded into the engine. I don't quite know how Rain's tool rebuilds the graphics.dat, but it definitely ignores the colours of any image you might insert, and simply retains the index information. As long as you've mapped the right colours to the right index, the graphic will show up correctly in the engine.

As for only two modifiable colours -- yes, that's true, but it's actually more flexible than FTL ever demonstrated. For example, you could have your two modifiable colours as ONE purple and ONE green. It's all to do with byte 12 for each creature, as defined in graphics.dat, structure 0558. Here's a loosely translated explanation from Charlatan's notes:

Byte 12: change colors 09 (orange) and 10 (pink) in the dungeon view, by using colors coming from another pallete (we will call it "N°2 pallete for clarity).

This makes it possible to give to certain creatures particular colors (example: color violet of the giant worm, the blue of the trolls, red of the dragon...).

The left 4 bits of byte 12 give the index of the color, from the N°2 pallet, which will replace color 10 (pink) in the dungeon view.

The right 4 bits give the index of the color, from the N°2 pallet, which will replace color 09 (orange) in the dungeon view.

** creatures & colors 09 and 10 in the dungeon view **

In the dungeon view, by default color 09 is orange, and color 10 pink. When one introduces a creature into a level with CSBuild (by small Edit/Level information), it will modify these 2 colors by the means of the byte 12 which describes it (see notes on bytes 0833 to 1156).

This takes place in the following way: - If the 4 bits of left of byte 12 have a zero value, then color 10 is not changed. Another creature introduced thereafter will thus be able to modify this color for this level!

If the 4 bits of left of byte 12 have a nonnull value, then the creature imposes a new color, coming from the N°2 pallet, which will replace color 10 used in this level of the dungeon. Any other creature introduced thereafter into the level will use this new color (this is particularly important if the image of the creature uses color 10!).

In the same way: - If the 4 bits of right-hand side of byte 12 have a zero value, color 9 remains unchanged. Another creature introduced into this level will thus be able to modify this color.

If the 4 bits of right-hand side of byte 12 have a nonnull value, then the creature imposes a new color, coming from the N°2 pallet, which will replace color 09 used in this level of the dungeon.

Any other creature introduced thereafter into the level will use this new color (important if the image of the creature uses color 9!). In practice, with CSBuild, the creature which imposes its colors for a given level is the creature lowest in the list of the "Monsters" in the window "Edict Level information".

If this creature does not modify colors 9 and 10, then one checks with the creature just above and so on.

Example: For a given level, I see in the window "Edit Level information" the following list of creatures:

Dragon
Worm
Screamer
Scorpion
Mummy

I thus start with the mummy, then I go up in the list:

byte 0964 has as a value (x00) = > the mummy does not modify colors 09 and 10.
byte 0844 has as a value (x01) = > the scorpion does not use the default color, but imposes a yellow color, which will replace color 09.
byte 0916 has as a value (x00) = > the screamer does not modify the colors.
byte 1024 has as a value (x78) = > the worm would like to change the 2 colors! But the scorpion already imposed a new color 09. The worm will thus try to modify these colours, but will only impose a colour violet for color 10.
- the byte 1132 has as a value (xCB) = > the dragon would like to also change the 2 colors! But the 2 are already modified... Therefore, the dragon will be yellow and purple in this level!

To fully understand this, you also need to read Charlatan's other notes on the bytes specified for each creature and where they are offset in graphics.dat. The colour choices can therefore be modified using a hex editor if you know what you are doing. Additonally, things like the mask colour for each creature are also defined in one of these bytes -- it's not just a case of using the same colur for every image. That's why if you extract the images from graphics.dat, you'll see that some have a cyan background while others have grey or yellow.

Here's the information Charlatan wrote about the creature bytes:

This part describes the images of the various creatures (graphics 0446 to 0532). Each creature is described by 12 bytes, detailed here:

Byte 01: ? to 0 for all the creatures...
Byte 02: index of the image of the forward facing view of the creature (starting from the graph 0446).
Byte 03: ? to 0 for all the creatures...
Byte 04: ? to 0 for all the creatures...
Byte 05: width of the image of the creature front facing view divided by 2 (NB: the width of all the images of the creatures is a multiple of 16). If it exists, the image of the rear view of the creature must have the same width exactly as the image of the front view, because it is the same value which is used.
Byte 06: height of the image of the creature front view, in pixels. If it exists, the image of the rear view of the creature must have the same height exactly as the image of the front view, because it is the same value which is used.
Byte 07: width of the image of the creature seen of profile divided by 2 (must be a multiple of 16).
Byte 08: height of the image of the creature seen of profile, in pixels.
Byte 09: width of the image of the attack view of the creature in, divided by 2 (must be a multiple of 16).
Byte 10: height of the image of the attack view of the creature in pixels.
Byte 11: - the 4 bits of left indicate the group of co-ordinates of reference which should be used to post the creature (see bytes 0265 to 0594):
group 0 = > average position (groups of 1 to 4 creatures)
group 1 = > low position (groups of 1 or 2 creatures only)
group 2 = > high position (flying creatures, groups of 1 to 4 creatures)
the 4 bits on the right-hand side give the index of the color of transparency of the image of the creature (value ranging between 0 and 15). This color must be the same one for all the views (face, profile, back, attack). Example: I open the images of the scorpion (graphs 0446 to 0449) and I check the index of the gray color used for the bottom: it is color 13, therefore the 4 bits of right-hand side of byte 0843 will have as a value 1101. Byte 12: change colors 09 (orange) and 10 (pink) in the dungeon view, by using colors coming from another pallet

** Remark **:If a creature is defined as having NO profile view (bytes 7 and 8 to 0), it is automatically considered that it does not have back view either. If a creature is defined as HA VING a profile image, then it is automatically considered that it also has a back view image.

Posted: **Sat Apr 03, 2004 8:08 pm**

Most unfortunate that someone decided to call the
first byte 'Byte 1' instead of 'Byte 0'. I am quite adroit
at making this translation automatically but it is probably
confusing to some people.

The Atari put 16 colors on the screen. Makes no difference
whether it is drawing a Screamer or a Wall. There are 16
colors on the screen. Total. Altogether. Not 16 colors for
monsters and 16 for walls. The screen can only have 16 colors.

The palette determines what those 16 colors are at the time
the pixels are being draw onto the face of the CRT.

CSBwin looks at the Atari screen and sees 16 numbers. It uses
the palette to turn those 16 different numbers into colors.
I suggested that you could define a different palette for each
level.

Now, there is a little bit of good news. Very little. One of the
16 numbers is used for the controls. That only leaves 15 numbers
that are free to be redefined. That is why one color never
gets darker as the light in the dungeon dims. That color must
stay bright for the controls. But the good news is this: CSBwin
copies the Atari screen in pieces. And each piece could have
a different palette. So the viewport could use all 16 colors instead
of the 15 it now has available. This would require some fiddling
because we would want all 16 colors to dim. I suppose that if
I provide a way to specify the palette then I should provide a
way to say which colors should dim. That is the very small
bit of good news.

Posted: **Sat Apr 03, 2004 8:36 pm**

This is an interesting prospect, but one that I think only has two benefits:

1) The controls / interface elements could be redesigned to look a bit funkier with their own palette
2) Monsters could be cleverly designed to exploit a custom palette

However, there are many other issues to consider. For example, there is an internal table within the game that defines which colurs are remapped to darker colours to simulate the darkening with distance. The table can do some weird things with the two currently modifiable colours. How could this be modified to account for a new colour that overides the cyan super-bright colour in your proposed custom palettes?

Also, you wouldn't want to change colours that are common to items and objects because they would change colour if you changed the palette on different levels. Given also that the greys are used in nearly every object and decoration, you wouldn't really want to modify them either. So that only leaves 3 practical colours that could be changed (the two exisiting and the one extra cyan that could be changed). Personally I don't see the benefit of that -- I'm already getting good results with new monsters by craefully defining which palettes they use and one extra colour wouldn't really make a lot of difference.

What I'd really like to be able to do though is to change the exisiting "palette No2" colours -- that would be worthwhile. As would a separate palette for the interface elements.

Finally:

Most unfortunate that someone decided to call the
first byte 'Byte 1' instead of 'Byte 0'.

I don't understand this -- isn't that just Charlatan's arbitrary notation? Why is it an issue?

Posted: **Sat Apr 03, 2004 9:05 pm**

Why is it an issue

Just a consistency problem. I will continue to document
the first byte as 'Byte 0'. So we have different names
for the same thing and the same name for different things.
If you like, you can call the first byte 'Byte 23', if you enjoy
arbitrary names. And someone else can call it 'Purple'.

If I am going to make provision for redefining palettes then
I am certainly not going to try to guess which colors someone
will eventually find it convenient to change. I'll make it possible
to change them all and put the burden on you to decide
whether or not it is reasonable to change color number 509
(an "arbitrary notation" for the third color

).

Posted: **Sat Apr 03, 2004 9:07 pm**

the first quote says all i need to still use purple, blue, red and yellow worms in a dungeon

setting the color manually would be handy, but i could get used to simply add a monster in the desired color, too. still easier than dmute

Posted: **Sat Apr 03, 2004 9:17 pm**

Paul Stevens wrote:I'll make it possible to change them all and put the burden on you to decide whether or not it is reasonable to change color number 509

That seems like a sensible compromise. So I therefore vote "Yes" for custom palettes.

Posted: **Mon Apr 05, 2004 12:14 am**

using that info then.. is there any chance we can assign a 16 col pallete per object then? rather than per screen section. (I'm going to assume no for now but hold a little hope for a yes)

Just since the question of wether or not you could grab the images from Graphics.dat your self and put them to screen was not addressed directly. or be it a zip file or a folder. if they have 16 colours assigned to them in a 16bit screen mode or 8bit 256 colour mode.. I would imagine you could get a lot on screen at once. maintaining that colour #0 is the mask colour. (meaning the first colour in the pallete. not the value 0 which would be black)

moo

Posted: **Mon Apr 05, 2004 1:09 am**

from Graphics.dat your self and put them to screen

No. Of course it is possible. But it ain't gonna get done.
The Atari graphics routines are so tied up in knots and
so integral to the operation of the engine that nobody is
going to re-engineer them. The best you can hope for is
that someone starts from scratch and writes a program
named RTC.

In CSBwin we must work with what appears on
the (internal) Atari screen. We can transmogrify that
to our heart's content and live with the results.

But......people have done things more amazing than is
believable. If someone wants to try I will give them every
bit of knowledge that I have on the subject.

Posted: **Mon Apr 05, 2004 1:55 am**

The best you can hope for is
that someone starts from scratch and writes a program
named RTC.

heh.. how did I know that was comming.

Now.. here comes some questions then.. though I'll post in a new thread since it's not directly related I guess

Dungeon Master Forum

Palette Information

Palette Information