That darn start image
That darn start image
Is it possible to edit that title image that can't be extracted with modkeen?
- MultiMania
- Patch Master
- Posts: 153
- Joined: Mon Nov 24, 2003 3:09 am
- Location: Deep in the heart of keen.
- Contact:
Well. It is possible.
The Title screen is stored as a compressed (I think!) Deluxepaint "LBM" Image in the file "KDREAMS.CMP"
The file is in some "SLIB" (I think) format and seems to be an archive of some type. The titlescreen is the file "TITLESCR.LBM" in the archive. (I currently believe that this is the only file in the archive).
NOTE: I just (while typing) extracted a LBM that HAS NO COLOURMAP. If anyone can add a colourmap to an LBM then they can have the title screen!
The Title screen is stored as a compressed (I think!) Deluxepaint "LBM" Image in the file "KDREAMS.CMP"
The file is in some "SLIB" (I think) format and seems to be an archive of some type. The titlescreen is the file "TITLESCR.LBM" in the archive. (I currently believe that this is the only file in the archive).
NOTE: I just (while typing) extracted a LBM that HAS NO COLOURMAP. If anyone can add a colourmap to an LBM then they can have the title screen!
Hmm
How do you mean? It's showing up but with incorrect colours, or...? Keen Dreams uses the standard EGA palette, so the title screen uses those same colours - as for adding a palette to an LMB - why not simply convert it to an bitmap or somesuch?
- MultiMania
- Patch Master
- Posts: 153
- Joined: Mon Nov 24, 2003 3:09 am
- Location: Deep in the heart of keen.
- Contact:
The LBM file refuses to open at all without a colourmap. I believe that this is a pallete but I do not know the LBM file format.How do you mean? It's showing up but with incorrect colours, or...? Keen Dreams uses the standard EGA palette, so the title screen uses those same colours - as for adding a palette to an LMB - why not simply convert it to an bitmap or somesuch?
All I know for certain [as I believe that the LBM [DeluxePaint II] is not valid; I hought I added a colourmap to it and the actual image is probably just junk] is that the file is in "Softdisk SLIB format". The file SHOULD open with "LOADSCR KDREAMS.CMP TITLESCR.LBM" but returns "Unknown Chunk.Compression Type"
KDREAMS.EXE includes the code to decompress and decode the file; but I am unable to provide the full format specification as I have not yet decompiled the suspect code.
All in all, if anyone can find the correct compression foormat, pleas4e do. All I know is that it is an SLIB Archive with the file "TITLESCR.LBM" in it, compressed using an algorithm that is not commonly used by the format. Probably huffman compression, as that is used by almost all of the Keen Dreams Code.
Re: That darn start image
You can edit the *other* graphics with ModKeen?! [edit:] oh, whoops - that's pretty cool, MultiMania!levellord wrote:Is it possible to edit that title image that can't be extracted with modkeen?
A topic solves everything.
This is from the previous thread.
http://wiki.gamedev.net/index.php/ILBM
http://www.fine-view.com/jp/labs/doc/ilbm.txt
Example: Stack Up (TITLESCR.LBM in ZIP)
As for the compression, there is an option to disable it. Simply change the Compression Flag in the image data and replace the compressed data starting at byte 10 with your uncompressed LBM format. Check out TITLESCR.LBM which I copied out of game memory.The decompressed length of the file is $5D1C. Addding the header gives $5D26, which must be put in the appropriate KDREAMS.CMP fields.
This looks like the LBM format used. Note that some values may be big endian; I see many calls to a function that converts endian-ness.Commander Keen Dreams uses the SLIB format for its title screen in earlier versions. It is
divided into three main parts, the file header, a varying number of image headers and the
image data. When decompressed images are planar EGA data, like those of Keen 1 ending screens.
Compression method is probably huffman, using EGADCT.
-------------------------------------------------------------------------------
FILE HEADER:
0 4 Sig Signature, 'SLIB'
4 2 Version Version number, always $0002
6 2 Imgs Number of images in file
8 30x Img hed Image headers
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
IMAGE HEADERS:
? 16 Name Name of compressed image (Max len 12 chars) padded with nuls
+16 4 Dat st Start of image data in file (From start of first image chunk)
+20 4 Dat end End of image data in file (From start of first image chunk)
+24 4 Decompressed Length
+28 2 ? $0002
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
IMAGE DATA:
? 4 Sig 'CUNK' (Chunk)
+4 4 Decompressed Length
+8 2 Compression Flag: 0 = uncompressed, 2 = compressed
+10 ? Data Image data
-------------------------------------------------------------------------------
http://wiki.gamedev.net/index.php/ILBM
http://www.fine-view.com/jp/labs/doc/ilbm.txt
Example: Stack Up (TITLESCR.LBM in ZIP)
As for the compression, there is an option to disable it. Simply change the Compression Flag in the image data and replace the compressed data starting at byte 10 with your uncompressed LBM format. Check out TITLESCR.LBM which I copied out of game memory.The decompressed length of the file is $5D1C. Addding the header gives $5D26, which must be put in the appropriate KDREAMS.CMP fields.
How to make a Keen Dreams Title Image
Code: Select all
The original KDREAMS.CMP is a compressed SLIB archive, containing an ILBM file, which is further compressed. I do not know the SLIB compression scheme, but the ILBM file uses a form of run-length encoding. Fortunately, this is irrelevant for us, since there are options to disable both SLIB and ILBM compression.
This document describes how to construct a keen dreams title image. Default values are given in parentheses and should not be altered (i.e., nothing but the actual pixel data should be modified). There is further information on the ILBM format floating around the internet, and there is a tiny bit of info on the SLIB format on Keen:Modding. All values are in hex.
FILE ("KDREAMS.CMP")
SLIB FILE HEADER
0 4 Sig: signature bytes ('SLIB')
4 2 Version: Version number (2)
6 2 Imgs: Number of images in archive (1)
END SLIB FILE HEADER
SLIB IMAGE HEADER[n] (n = 1)
0 10 Name: Name of compressed image (Max len 12 chars) padded with nuls ("TITLESCR.LBM")
10 4 DatSt: Start of image data in file (From start of first image chunk) (0)
14 4 DatEnd: End of image data in file (From start of first image chunk) (7D38)
18 4 Len: Decompressed Length (7D38)
1A 2 Unk: Unknown, looks like keen doesn't use it (0)
END SLIB IMAGE HEADER[n]
SLIB IMAGE DATA[n] (n = 1)
0 4 Sig: Chunk signature ('CUNK')
4 4 Len: Decompressed Length (7D38)
8 2 Comp: Compression Flag: 0 = uncompressed, 2 = compressed (0)
A x Data: Image Data (LBM format, below, should start at byte 30 in KDREAMS.CMP)
ILBM FORM CHUNK
0 4 'FORM' signature ('FORM')
4 4 FORM Chunk Length. (7D30) BIG ENDIAN
4 8 'ILBM' Signature ('ILBM')
8 1C Bitmap Header (BMHD) Chunk (below)
24 7D00 Body Chunk (below)
ILBM BMHD CHUNK
0 4 'BMHD' Signature ('BMHD')
4 4 BMHD Chunk Length (14) BIG ENDIAN
8 2 Pixel Width (320)
A 2 Pixel Height (200)
C 2 X-Origin (0)
E 2 Y-Origin (0)
10 1 nPlanes (4): Number of bitplanes
11 1 Mask (0): Mask style
12 1 Compression (0): ByteRun1 Run Encoding Flag
13 1 Padding (0): Nul
14 2 Transparency Colour (3): transparent "color number" if Mask == 2
16 1 xAspect (5) : pixel aspect, a ratio width:height
17 1 yAspect (6)
18 2 pageWidth (320): source "page" size in pixels
1A 2 pageHeight (200)
END BMHD CHUNK
ILBM BODY CHUNK**
e.g., One row of pixels
0 28 Plane 0
28 28 Plane 1
50 28 Plane 2
78 28 Plane 3
ILBM BODY CHUNK
END ILBM FORM CHUNK
END SLIB IMAGE DATA[n]
END FILE
**BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
This one chunk holds all bitplanes and the optional mask, interleaved by row.
When you are done, your file should look like this, and should be 7D60h bytes.
53 4C 49 42 02 00 01 00 54 49 54 4C 45 53 43 52
2E 4C 42 4D 00 00 00 00 00 00 00 00 38 7D 00 00
38 7D 00 00 00 00 43 55 4E 4B 38 7D 00 00 00 00
46 4F 52 4D 00 00 7D 30 49 4C 42 4D 42 4D 48 44
00 00 00 14 01 40 00 C8 00 00 00 00 04 00 00 00
00 03 05 06 01 40 00 C8 42 4F 44 59 00 00 7D 00
<pixel data (7D00h bytes)>
My file's image data starts with 'CMAP" and also contains 'DPPS' later on and many 'CRNG's
I assume this is something to do with the image chink header?
Also, there is no need to disable the RLE compression in the image, that's handy to have and doesn't seem to be disabled in the 'decompressed' CMP file you have linked.
I assume this is something to do with the image chink header?
Also, there is no need to disable the RLE compression in the image, that's handy to have and doesn't seem to be disabled in the 'decompressed' CMP file you have linked.
CMAP signifies a colour map chunk, CRNG is colour range which is used for "colour cycling" or something, and I don't know what DPPS is... anyways, I deleted CMAP, DPPS, and CRNG and the startup screen still loads.
Yeah the LBM RLE-compression is still enabled in that file, but by decompressed I meant it was not SLIB compressed.
As for the RLE-compression that is used:
Yeah the LBM RLE-compression is still enabled in that file, but by decompressed I meant it was not SLIB compressed.
As for the RLE-compression that is used:
Code: Select all
Appendix C. ByteRun1 Run Encoding
The run encoding scheme byteRun1 is best described by psuedo code
for the decoder Unpacker (called UnPackBits in the Macintosh* toolbox):
UnPacker:
LOOP until produced the desired number of bytes
Read the next source byte into n
SELECT n FROM
[0..127] => copy the next n+1 bytes literally
[-1..-127] => replicate the next byte -n+1 times
-128 => noop
ENDCASE;
ENDLOOP;
In the inverse routine Packer, it's best to encode a 2 byte repeat
run as a replicate run except when preceded and followed by a literal
run, in which case it's best to merge the three into one literal run.
Always encode 3 byte repeats as replicate runs.
Remember that each row of each scan line of a raster is separately
packed.
...
Remember to pad any BODY chunk that contains
an odd number of bytes.
Code: Select all
Body Compression
The BODY contains pixel data for the image. Width, Height, and depth (Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Example KDREAMS.CMP. It's a few coloured lines. For each plane, one full row of 320 pixels is 40 bytes.