That darn start image

Request patches for Keen Dreams.
User avatar
levellord
Crazy pAtChEr
Posts: 1401
Joined: Thu Nov 20, 2003 11:35 pm
Location: NewZealand
Contact:

That darn start image

Post by levellord »

Is it possible to edit that title image that can't be extracted with modkeen?
Kdash
Posts: 405
Joined: Sat Feb 26, 2005 5:45 pm

Post by Kdash »

Not yet... :-P

Well, i might make a Keen Dreams mod one day, so it'd be nice if this was possible.
User avatar
MultiMania
Patch Master
Posts: 153
Joined: Mon Nov 24, 2003 3:09 am
Location: Deep in the heart of keen.
Contact:

Post by MultiMania »

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!
szevvy
Posts: 4
Joined: Sat Jan 15, 2005 10:49 pm

Hmm

Post by szevvy »

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?
User avatar
MultiMania
Patch Master
Posts: 153
Joined: Mon Nov 24, 2003 3:09 am
Location: Deep in the heart of keen.
Contact:

Post by MultiMania »

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?
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.

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.
User avatar
levellord
Crazy pAtChEr
Posts: 1401
Joined: Thu Nov 20, 2003 11:35 pm
Location: NewZealand
Contact:

Post by levellord »

Well, as near as I can make out, it is Huffman compressed, but I know too little about any of the formats to be sure.

As an aside, it appears that the Keen Dreams code makes provision for an ending screen file, ENDSCRN.SCN that was never added.
Kdash
Posts: 405
Joined: Sat Feb 26, 2005 5:45 pm

Post by Kdash »

That's cause Keen Dreams was stupid.
User avatar
ckguy
Posts: 465
Joined: Tue Oct 14, 2003 11:20 am
Location: Wakefield, RI, US
Contact:

Re: That darn start image

Post by ckguy »

levellord wrote:Is it possible to edit that title image that can't be extracted with modkeen?
You can edit the *other* graphics with ModKeen?! [edit:] oh, whoops - that's pretty cool, MultiMania!
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Hello, does anyone have the LBM format? I am curious about it.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

A topic solves everything.

Post by lemm »

This is from the previous thread.
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
-------------------------------------------------------------------------------
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.

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.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

How to make a Keen Dreams Title Image

Post by lemm »

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)>
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

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.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

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:

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. 
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Can you please link to an imported and fully uncompressed image without all those useless chunks your other file has? I've been poking around, but I can't seem to make a working file without them, or the compression, and I'd like a professional example to work from.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

Example KDREAMS.CMP. It's a few coloured lines. For each plane, one full row of 320 pixels is 40 bytes.
Post Reply