viewport palette

Adamo · Post by **Adamo** » Sat May 26, 2007 6:55 am

I`ve learned how to deal with "Viewport Overlays". I know how to add them to the CSBgraphics.dat file etc. But I don`t have idea how the "Viewport Palette" works. I guess this is the fuction that is responsible for the "radioactive" effect when eating mushrooms in Conflux (there is ~50 Viewport Palette files in Conflux`s CSBgraphics.dat). There`s also Paul`s "Viewport Overlay" demo, wchich explains a lot. But my question is: how to edit the Viewport_Palette.bin -like files??
Is there any tool? The only thing I can do is to open it with HexEditor, but I don`t understand the meaning at all...

I really don`t understand things like:

Code: Select all

lXrm``7`o m{olŕ'ŕ7ŕoŔ~ }||˙$  €4M Yl)$  5R@Zl$‰

Post by **Paul Stevens** » Sat May 26, 2007 1:57 pm

It looks like you opened it with a text editor.
The file looks like this with a hex editor:

Code: Select all

000000  0000 0410 0910 0D10 1210 1610 1B10 1F10
000010  8400 0400 0900 0D00 1200 1600 1B00 1F00
000020  2401 2901 8900 8D00 9200 9600 9B00 9F00

etc

I will try to update the documentation of the
overlay capability to explain the palette usage.

Post by **Paul Stevens** » Sat May 26, 2007 4:43 pm

Look at

http://www.dianneandpaul.net/CSBwin/doc ... lette.html

Adamo · Post by **Adamo** » Sun May 27, 2007 8:07 am

Thank you for updating the docs!

ok, so ViewportPalette.bin file has 1kb (1024 bytes), and AtariST has 512 possible colours; so I assume each of the colours is 2 bytes long.
As I read from the documentations, Atari uses RGB palette (8x8x8 colours=512).
Where can I find Atari 8x8x8 Colour Palette Table to compare all the colours? I searched the vikipedia and AtariST sites and I couldn`t find it.
*I need all of them to be displayed on one screen, that`ll help he a lot)*
Is the ADGE Palette Editor table part of the RGB possibilities?

How many of these 512 colours are actually used in original Atari DM? Isn`t it only 16 basic ones + its darker variations (except the blue one)? And, of course, all the possible replacements (13) of custom 9th and 10th colours if used? It would give 16+13=29 base colours then.

******
I found nice comparition between Atari RGB values and RGB values: http://dmweb.free.fr/?q=node/209

BTW, there were nice informations on the Encyclopedia about the DM light levels and colour changes between them (I think in "misc" or "Technical Documentation" sections). There was also something about the light duration etc. Or maybe it was in Paul`s docs? Anyway, I couldn`t find them here nor there. I`m PRETTY SURE IT WAS IN "OLD" ENCYCLOPEDIA. Where is it now?

Post by **Paul Stevens** » Sun May 27, 2007 3:28 pm

Atari 8x8x8 Colour Palette Table
to compare all the colours

It is a simple linear mapping. For each component
of the color. To switch to 24-bit RGB colors, for
example, the three-bit components map to eight-
bit components 0 maps to 0. 7 maps to 255.

I did this in csbwin by copying the atari component
to the top of the eight-bit field and then duplicating
it in the lower bits until the eight-bit field was
full. Assume the 3-bit field contains the binary
bits xyz. Then the eight-bit field that would result
from thi s mapping would be xyzxyzxy.

Another way of looking at it would be a multiplication.
result = x*32 + x*4 + x/2
result = x * ( 36.5 )

This has the desired result....0 maps to 0 and
7 maps to 255.5 (truncate to interger).

Post by **Paul Stevens** » Sun May 27, 2007 3:31 pm

How many of these 512 colours are actually used in original Atari DM

It would be hard to tell. There are many palettes.
A different one for the prison door, for example.
And many are created 'on-the-fly' when the scene
changes and one palette fades into another.

Adamo · Post by **Adamo** » Sun May 27, 2007 4:27 pm

It would be hard to tell. There are many palettes.

hmm.. that`s why your info about DM light levels and colour changes between them (I think in "misc" or "Technical Documentation" sections - now withdrawn from Encyclopedia) is so important for me. I`m not going to replace every possible Atari colour (there is 512 of them!). It would be a waste of time. Only those that were used in a game (more precisely, in the viewport), wchich means 16 base colours + 13 additional colours + all its variations in every light level...
I think total number of colours used in the viewport is not more than 100. I can deal with this. But first of all, I need to identify them all and sort them before I`ll start replacing them.

Post by **ChristopheF** » Mon May 28, 2007 1:59 am

It looks like encyclopaedia.
It tastes like encyclopaedia. But it is not really encyclopaedia.
Adamo, I think what you're looking for is here:
http://www.dianneandpaul.net/CSBwin/Tec ... aneous.htm

Note: I never remove anything from the Encyclopaedia. In fact, the only thing I remember removing was a page with some tables that showed how champion stats were increased during a level up. I removed them because they were wrong

Adamo · Post by **Adamo** » Mon May 28, 2007 2:01 am

ooh thank you Christophe! I couldn`t find it.. thanx again!

Adamo · Post by **Adamo** » Mon May 28, 2007 2:26 am

Paul Stevens wrote:

The various levels of lighting are accomplished by the use of six different color palettes, each with sixteen colors.

6 palettes * 16 colours each = 96 colours !

I though that lower light levels uses less colours than 16! For example lowest light level displays only 2 colours when looking at the ordinary wall (because every grey colour is replaced by black, only white changes to dark grey)..

**********************
if so, I guess the lowest light level has 16 (potencial/virtual/possible) colours, but in this (special) case most colours are "empty" = black?
Then can I theoreticly replace COLOUR NR.0 (black) to, say, red, COLOUR NR.1 (black) to green, COLOUR NR.2 (black) to blue, COLOUR NR.12 (black) to yellow, COLOUR NR.13 (black) to brown and COLOUR NR.15 (dark grey) to dark green on the darkest light level..??

Post by **Paul Stevens** » Mon May 28, 2007 3:44 am

Perhaps there is a bit of confusion. There are two
layers of palette.

The first layer is specified by Graphics.dat and
by the hard-wired code. It translates the 4-bit
colors to Atari 9-bit RGB values where each of the
color components occupies 3 bits for a total
of 512 possible colors.

***THEN*** the DSA &PALETTE command allows
you to redefine how each of these 512 RGB
values will be displayed on the screen. This
is a second layer of palette.

lower light levels uses less colours than 16

The objects in the game still have 16 different
color values assigend to them. The palette
may assign the same RGB value to more than one
the 16 colors, as you say. In such a case, the
&PALETTE layer cannot make them different again
because it translates the RGB values and does not
know about the original 4-bit color number.

This all makes perfect sense once you manage
to make sense of it.

Adamo · Post by **Adamo** » Mon May 28, 2007 4:37 am

ooh I see.. so I would have to change the original code to force the engine to draw full palette on the darkest LightLevel.. DSA doesn`t care about the palettes and only replaces EXISTING colours on the screen..

I asked about this, because I have an idea of an "X-ray spell" working independently of the LLs. If there were 16*6 colours I could do this by replacing every existing palette by my own colours (say, 16 different shades of red) identicals for each of those 6 palettes. So no matter wchich palette is currently in use, the screen would always look the same (monochromatic red).

Now, as this is impossible, here`s what I`m gonna do: I have to change ONLY the basic palette (plus, of course, the custom colours I use in game) in Viewport Palette file and try to force the engine somehow to change the LL to the highest possible (=LL0 ) always when Xray is in use. But that has to be independent of intensity/brightness computations; a sort of a cheat.

Here`s how it would look like: the player is in a dungeon with the lowest LL; the player cast Xray spell; the LL changes immediately to the highest one and in the same moment Xray is turned on - the whole wiewport has different shades of one colour (say, the red one). The Xray expires and the LL immediately goes back to it`s "proper" state (lower LL).

***Otherwise, (without somehow changing the LLs), if a player cast Xray on the lower LL, it wouldn`t show all 16 (changed) colours, so it would look rather creepy. Besides, as far as I know, Xrays doesn`t depend on the light, am I wrong?***

Is it possible to cheat this way (ex: to change the LL3 <or any other> directly to LL0 only for a short period of time so that the engine still thinks that LL3 <or any other> is currently in use and doing ordinary computations for the "real" LL)?

Adamo · Post by **Adamo** » Mon May 28, 2007 5:07 am

here is a nice table of colours in HTML notation:
http://en.wikipedia.org/wiki/Web_colors

for example "LightGreen" = 90 EE 90 / 144 238 144
Each colour in this notation has Red, Green and Blue range between 0 and 255.
But 90EE90 is a 3-byte hex value, while ViewportPalette.bin file needs 2-byte hex values, like 7600.. How to write 90EE90 in 2 bytes?

Post by **Paul Stevens** » Mon May 28, 2007 5:40 am

The ViewportPalette uses 16-bit RGB values,
not 24-bit. The 4th paragraph of the documentation
describes the format with an example.

To translate the 8-bit values to 5-bit values you
can simply use the 5 most significant bits.

90 ee 90 would become 12 1d 12.
Packed together in binary 100101110110010.
or 0x4bb2 as a hex integer. Then remembering
that it must be little-endian put the following
two bytes into the file: 0xb2 0x4b

Wheee! Quite a ride. It is probably best
done with a simple little program. There
are several opportunities to make mistakes.

Adamo · Post by **Adamo** » Mon May 28, 2007 6:01 am

http://en.wikipedia.org/wiki/Highcolour

@#$$%#^ GIMP describes colours only in 24bit HTML notation

******************************************

It is probably best
done with a simple little program. There
are several opportunities to make mistakes.

help! I need a table of possible Atari colours (from 0 to 511). Is it somewhere on the net?? I searched through Atari pages..
Also some tools (if exists) that I could use for Viewport Palette.. tools for computing 24bit RGB to 16bitRGB.. etc, etc, etc. anything.

Tom Hatfield · Post by **Tom Hatfield** » Mon May 28, 2007 10:14 am

If you have the VB6 run-time installed, I'll write such a tool for you when I have some free time this week.

The table of Atari colors I assume is just a list of all the possible 3-3-3 bit RGB values? And the 24- to 16-bit conversion is just chopping off bits. That will be easy. I'd write the program this moment, except I just got home and it's 4:13 a.m. Tomorrow is Memorial Day here. I have a cookout at 5 pm, but I should have time to write the app before then, unless plans change, in which case I can do it Tuesday.

Adamo · Post by **Adamo** » Mon May 28, 2007 10:55 am

thank you, thank you, thank you !!!!!!!!!!!!!!!

each Atari color has RGB values, where R has 0 to 7 factor, G has 0 to 7 factor and B has 0 to 7 factor. So 8x8x8=512. You can see it by turning on "Monster Graphic Info" in ADGE; there`s "Custom color A" and "Custom color B" fields for each monster. Click on the color tile and you`ll see Light Level Palette Editor. But I need a sort of a complete table to see all the differences between them.

Post by **Paul Stevens** » Mon May 28, 2007 4:40 pm

Go to:
http://www.dianneandpaul.net/CSBwin/doc ... lette.html

At the bottom you will find a link to a program
that will display the 512 colors.

Tom Hatfield · Post by **Tom Hatfield** » Mon May 28, 2007 9:40 pm

Paul saved me the trouble of making a palette viewer, so I just did the 24- to 16-bit converter. Its use should be fairly intuitive. The <-> checkbox on the right toggles byte order (reversed when it's enabled).

Updated (see post below)
http://three.homeip.net/files/RGBConverter.zip (8 KB zipped)

If you need VB6 run-times, you can get them from my main page. If you need some kind of batch output functionality, I can add it tomorrow.

Post by **Paul Stevens** » Tue May 29, 2007 3:12 am

It is not entirely obvious to me.

I plugged in RGB of 118,78,153

The 24-bit decimal and hex values make sense.

But it turned it into 14,19,19 in the 16-bit side.
The Blue should be about twice the green, should
it not? And the Decimal value makes sense (20078)
but the hex value (0x740c98) won't fit into 16
bits, nor do I know from whence it came!

EDIT

Ohhhh! I think you used 6 bits for the green
component. That is a 5-6-5 format. CSBwin uses
a 5-5-5 format (bit 15 unused).

Still don't understand the 16-bit hex value.

Adamo · Post by **Adamo** » Tue May 29, 2007 5:28 am

thank you for the tools !!

Code: Select all

Exact equivalents in Atari colour table: 

colour  0 (#000000) (black)      = 0 
colour  1 (#6D6D6D) (grey3)      =     ??? 
colour  2 (#919191) (grey2)      =     ??? 
colour  3 (#6D2400) (brown)      =     ??? 
colour  4 (#00DADA) (pale blue)  = 39   ? 
colour  5 (#914800) (pale brown) =     ??? 
colour  6 (#009100) (green)      = 32   ? 
colour  7 (#00DA00) (pale green) = 56   ? 
colour  8 (#FF0000) (red)        = 448  ? 
colour  9 (#FFB600) (orange)*    = 480  ? 
colour 10 (#DA916D) (skin)*      = 484  ? 
colour 11 (#FFFF00) (yellow)     = 504  ? 
colour 12 (#484848) (grey4)      =     ??? 
colour 13 (#B6B6B6) (grey1)      =     ??? 
colour 14 (#0000FF) (blue)       = 6    ? 
colour 15 (#FFFFFF) (white)      = 511

*- can be replaced by other colours

the last row on the right with 0-511 numbers or "?" signs shows the position of originally used colours on the Viewport Palette file.

Tom Hatfield · Post by **Tom Hatfield** » Tue May 29, 2007 7:39 am

Yes, I used 5-6-5. Didn't realize another format was needed. An update is forthcoming.

The 16-bit hex value shouldn't make sense because I didn't calculate it properly! It's actually the 24-bit value redux. Thanks for pointing that out.

Will post an update to support 15- and 9-bit values. Tomorrow.

By the way, depending on the conversion technique used, your results may deviate greatly from mine. I did some fairly simple bit-masking and shifting using basic math (no shift operations were harmed in the making of this app). Faster results can be achieved via C or ASM, and I will eventually take that course once the prototype is finished.

I also want to find a faster technique for drawing those gradients. The performance hit when they're enabled is noticeable even on my 2.8 GHz dual. I did have one technique in mind for speeding it up about 33 percent, but obviously I didn't bother implementing it yet.

Edit:
Bah, I couldn't wait until tomorrow, so here's a new version. It includes 15- and 9-bit conversions and also fixes the hex problem. I improved the gradient slider performance as promised, though it's still kinda slow. Oh, and this update preemptively fixes a potential bug involving small data types. The download link is the same as above, but I'll copy it here for convenience.

http://three.homeip.net/files/RGBConverter.zip (8 KB zipped, screenshot)

No idea if anyone will actually need the 9-bit converter, but it's there, and it uses the formula Paul posted above.

Post by **Paul Stevens** » Tue May 29, 2007 3:28 pm

Very nice. But......

I put in 255,255,255 on the sliders.

I expected to see 0111111111111111 binary
in the 15-bit window. That is three 5-bit
fields. or 0x7fff or 32767. That is not at
all what I see. And the hex and decimal
values don't seem to agree in the 16-, 9-,
and 15-bit cases. 511 is not equal to 0x070707.

Post by **Paul Stevens** » Tue May 29, 2007 3:41 pm

Those color gradients make life a lot easier.
I have never seen that done before. And
I see no performance issues whatsoever
on my 1.2 GHz AMD Athlon.

Picky, picky, picky....The color gradients
are not redrawn when your window is covered
by another window and then is uncovered
again. I have to move the sliders to get the
gradients redrawn. Windows 2000.

Adamo · Post by **Adamo** » Tue May 29, 2007 4:17 pm

Than you Tom!!!

Your tool is extremally usefull, because it allows easily replacing Atari colours with the new ones using the Viewport Palette! It should be added to Encyclopedia!

Thanx again!!!!!!!!

Tom Hatfield · Post by **Tom Hatfield** » Tue May 29, 2007 11:46 pm

Rrg. I should have checked that. I did all the bit math on paper and plugged it in and was satisfied when it no longer returned negative values (the type bug I mentioned, which occurred due to overflow rollover). Let me go ahead and replace all those operations with C code so I can use real bit-shifting. That should solve a great many problems.

The hex issue is stupidity on my part. I was splitting the values wrong.

The problem with fixing this stuff quickly is that I have a virtual PC for development in VB6, and I have to start it up anytime I want to edit the app. Also, changing values in the interpreter freezes VB, which means I have to compile and run it under my host OS anytime I want to test it. So, this is taking a bit longer than it should.

Working on it.

Edit

Done. I'm very pleased with this release. All numerical issues have been fixed, and I also implemented a fix for the overlapping window problem you mentioned. I did this by rewriting the gradient algorithm from scratch using a sophisticated (read: annoying to code) DMA approach. The new version is enabled automatically if your desktop is set to at least 24-bit color, and it renders way faster than the old method, so color gradients are on by default now. If you're using a lower color depth, the old method is used instead.

http://three.homeip.net/files/RGBConverter.zip (9.7 KB, zipped)

Oh, and my IDE stopped freezing on me, so I was able to test more rapidly. I tried implementing a 16-bit version of the fast gradient algorithm, but the bit manipulation was killing me, so I gave up.

By the way, I didn't use any C after all.