Author of this documentation: kentaro.k-21
It will be simple to read.
I took the 1st raw data from dm2 amiga graphics.dat.
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
————————————————————————-
0000000 80 01 27 3D 00 07 54 01 49 01 44 01 53 01 46 01 ..’=..T.I.D.S.F.
0000010 47 01 50 02 00 00 08 00 00 00 00 01 00 00 0B 00 G.P………….
0000020 00 00 00 2B 00 01 00 00 00 FE 00 02 01 00 04 00 …+…………
0000030 00 00 00 F3 01 00 05 06 10 00 00 F8 01 00 05 06 …………….
The 1st highlighted word value (27 3D) represents how many entries exist in this binary.
Read this value as a big endian word value even if the target platform is oriented in little endian.
In this case, the value is obtained with expression 0x27 * 256 + 0x3D.
It is 10045. There are 10045 entries in dm2 amiga graphics.dat.
The offset of 1st entry begins at 0x00000014.
Each entry has 8 bytes long.
Next table shows known spec information with 1st entry00000014: 00 00 08 00 00 00 00 01
This is a sample for image entry.0001313C: 1A 00 01 00 00 FF 00 11
This is a sample for text entry.0001315C: 1A 00 05 14 10 FF 00 12
This is a binary dump of DM2 PC specific image to be described.
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
------------------------------------------------------------------------
0000000 0C 00 07 7C 00 00 03 00 BD 0A 22 00 27 2A 2A 27 ...|......".'**'
0000010 44 01 27 EF 2A 2D 2D 2A 44 01 2A 3B 3F CF 3F 3B D.'.*--*D.*;?.?;
0000020 2A 27 41 01 C0 02 2D 3B 9F 3F 2D 27 00 00 01 03 *'A...-;.?-'....
0000030 A0 01 2D 10 41 06 C3 01 A5 07 81 03 27 00 09 ?? ..-.A.......'..
It is 1620th binary (0 based index) in DM2 PC GRAPHICS.DAT, and is the compressed image of Blue gem.
The DM2 PC specific compressed image has 8 bytes for prefix and sequent bytes for body of compressed image. It has no suffix.
The 4th byte in Prefix is highlighted. It may be used to know that this image is formatted in DM2 PC specific image.
Majority images has 4th byte fixed in 0x7C.
There are command control byte and sequent 8 primitives in a set.
A pixel is represented in 1 byte and is a 8-bit indexed palette in DM2.
It renders only 1 pixel per pixel command.
This command is to copy pixels from previous rendered pixels. It has 2 following scalar factors
It is always consisted with 2 bytes.
First byte is variant against each image prefix. They will be grouped in ‘Type’.
X and Y are defined for expression.
Second byte is a unsigned byte value and defined as B for expression.
negative_offset and copy_length are figured out as next table shows.
This is prefix part of the image: 0C 00 07 7C 00 00 03 00
The 7th byte, the highlighted part shows the Type of decompression factor.
If it is 02, it is Type2 factor applied compressed image.
If it is 03, it is Type3 factor applied compressed image.
Here is reading sample for the 1620th compressed image.
This is Type3 factor applied compressed image.
I’m not good at explain in English, so I prepared enough screen shots to explain.
This explanation refers to the DM2 GRAPHICS.DAT of Amiga version, which is formatted in big endian.
I’ll show how to extract the next image.
This operation uses 3 images to combine and merges into one complete image.
+
+
=
In convenience, I allocate the index number for them. The index is based on order from GRAPHICS.DAT.
#4537 + #4539 + #4540 = New #4540 Image
You can extract the first image(#4537) easily.
Please visit Data Files for further information about IMG3 and IMG4 formats. It’s great resource!
This image requires to combine with 2nd image.
Generally, it appears to be the messed up image.
I’ll explain with the next figure.
This shows the binary image of 2nd image(#4539).
This tool divides a raw data into 3 parts automatically.
They are Prefix, Compressed Binary bytes and Suffix.
I copied the each heading binary into a table.
I highlighted the 6 components of “Prefix” (9, 6, F, 1, 2, D) and the entire “Binary”.
The 6 components means “Local palette of 6 most used colors in image” (from Christophe’s Data files description).
Generally, It is believed that the compressed image starts from “Binary”.
However, this 2nd image is some bit different.
The 2nd image starts from 52th bit (8*6+4) in “Prefix”.
If decompression work start from 52th bit, You can get the next image.
In this case, the last component of “Prefix” (0xD) is part of compressed image.
So, you should not contain it to decode Local palette.
They should be consisted from 5 components (9, 6, F, 1, 2).
Next problem is “What’s the mask color? or transparent color?”
I brought 2 words in my discretion. (I may need the correct for these expression.)
Empty color: from Christophe’s Data files description. “Copy pixels from the previous line of the image”
Transparent color: Copy the pixels from previous image at same position. In this case, it’s the 1st image.
Allocation for “Empty color” is same as IMG3 or IMG4 (described at Christophe’s Data files description).
Allocation for “Transparent color”.
I tried and decided the colors with my feeling. They are 6th Color and 14th Color.
I arranged role of colors/palettes to next table. ("-" means it doesn’t change the existing role.)
If combine work proceeded successfully, You can finally get the next image.
+
=
It’s the same way as method against 2nd image.
Please remember this screen shot.
The raw data at “0001” is that.
The next heading binary from this entry.
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
------------------------------------------------------------------------
0000000 00 0B 00 38 00 11 00 03 00 38 00 11 00 45 00 6D ...8.....8...E.m
0000010 00 6D 00 77 00 77 00 03 00 7E 00 77 00 DB 00 DA .m.w.w...~.w....
0000020 00 DE 00 DD 00 E5 00 E1 00 E7 00 E6 00 EA 00 E6 ................
0000030 00 EB 00 EA 00 ED 00 F2 00 EE 00 DF 00 F0 00 EF ................
This raw data is read as next table shows.
I arranged in logical consideration for extraction.
To render image #4540, it requires #4539 has been already rendered.
To render image #4539, it requires #4537 has been already rendered.
To render image #4537, it doesn’t require any image has been rendered.
Renders #4537 as 1st image.
Renders #4539 as 2nd image and overrides the previous image.
Renders #4540 as 3rd image and overrides the previous image.
Done.
These explanations are way how to read some messed up images in DM2 GRAPHICS.DAT.
And this document doesn’t have complete information.
This means that some images can be obtained with this method but other images won’t be able to be obtained correctly with this method.
So I’m welcome to have any correction for this document.
Thanks.
This is a binary of encoded text.AB B6 BC A8 D4 A7 D9 AA A8 A2 D5 A0 AB AD D1 A3 AE 9B 99 A7 99 CA A5 9F 94 9B C4 E4
The decoded text represents:
THAT’S NOT THE MASTER DISK!
The next table shows how to decode.
The next table is for decoding alphabet characters and symbols in English language.
I don’t check about unfilled part.
There are two tables in PC9801 version.
This is the encoded text in PC9801 version.0F 6C 0D 35 16 FA F9
This is decoded binary.F0 92 F0 C7 E5 00 00
If the character starts in 0xF0, It references the 2nd table with 2nd byte, and get forward 2 bytes.
Otherwise just reference the 1st table with 1st byte, and get forward 1 byte.
Example.
This is 1st table.
This is 2nd table.
The entry is an item stored in ENT1 format (check ENT1 section at Data Files).
XX = Entry category
YY = Entry index
ZZ = Entry type
AA = Entry name 1st byte.
BB = Entry name 2nd byte.
CC = Entry name 3rd byte.
A color representation. 4 bytes per palette entry.
I = Index
R = Red intensity
G = Green intensity
B = Blue intensity
They are all known image formats. Each of DM2 versions supports some of them.
Each of DM2 versions has different palette management due to hardware limitation.
Although images have palette, it seems not to be used.
Instead, there are IRGB palettes which depends on scene.
Known palettes:
Credits: Dungeon Files for Map graphics style. GreatStone for Palettes list.
Creature palettes:
Some creatures have one or more dedicated color. It is like creature specific color found in DM1. Its support is done by altering hardware palette.
Archer-guard has 2 colors:
entry (0F 1D 09 09 04 00) has alternate color for color9.
entry (0F 1D 09 0A 04 00) has alternate color for color10.
Raw data format is: 6 set of IRGB entry. It maps from brightest to darkness.
It has a palette with 256 colors.
The palette is stored at entry (01 00 09 FE 08 00).
It has a palette with 256 colors.
The palette is stored at entry (01 00 07 FE 08 00).
It has a palette with 256 colors.
The palette is stored at entry (01 00 09 FE 08 00).
Not yet.
It has a palette with 256 colors.
The palette is stored at entry (01 00 09 FE 08 00).
Not yet.
It has a palette with 256 colors.
The palette is stored at entry (01 00 09 FE 08 00).
It has a palette with 256 colors.
The palette is stored at entry (01 00 09 FE 08 00).
Not yet.
Just guess from dungeon.dat!
Check dungeon.dat.
e.g.
Thorn demon will appear on Outside area map style. So, apply the Outside area’s palette.
It uses mapping information stored in the file DM2PerImgPalDesc.csv.
(File sample: Dungeon Master II - DM2PerImgPalDesc )
(Format)
It indicates what palette should be applied for each creature and each ornate.