| ||
|
|
Batman
The Caped Crusader By Brian Provinciano July 4th, 2002
These Tech Docs for Batman The Caped Crusader apply to the PC version only. The ports of the game contain completely different file formats. Before reverse engineering the game, it needed to be unpacked. The program UNEXE was the only one able to successfully unpack it. It needs to be unpacked twice with this program. You first unpack the original EXE, then unpack the produced EXE.
The
EGA Sprite/Picture Graphics (EGA*.DAT)
The EGA Sprite/Picture Graphics The EGA graphics are quite a simple format. Being four bit, 16 colour images, they are stored in the standard EGA bitplane form, along with a mask on the end. The image is stored in a series of four 1 bit images. Combining them, you will get the final image. They were stored like this for speed since it writes directly to the EGA video. Picture graphics (EGALOGO.DAT) have no transparency information. The sprites do. The transparency is generated by a fifth 1 bit image, each bit for a pixel. If the bit is set, is will be transparent, otherwise, it will be normal. There is no size information stored in the files. It is hard coded in the EXE. Here is the size table: FILE NAME WIDTH HEIGHT FRAME HEIGHT
Each of the four or five (if it has transparency) images are the dimensions of the WIDTH*HEIGHT rather than for each frame. The icons are each 24x24 images. Each icon file contains 31 icons. Graphics are stored in the same method as the others, except that each icon is separated. It contains 31*4 1 bit images, rather than one large one. The level tile files are generally just an array of words defining the tile indexes to be used in the level. However, they are stored is a strict ASCII format rather than binary. The file contains ASCII arrays of tile information for each level. Each time is represented by a three byte ASCII number. If the high bits are zero, they can be represented by a space. Each level it terminated by a 'Z'. Since the character codes are three bytes, a '\r' and '\n' follow it. Finally, the file is padded with '.' characters. Here is the code I wrote based off the original EXE (should be identical to the original algorithm).
And here is a more readable version I wrote later:
When the game loads the files, it not only converts them to binary, but also builds a look up table with their offsets. The level information files contain each level's width, height, position, surrounding rooms, and door positions. They are stored in an encrypted format. Once decrypted, they are stored in two seperate tables--one for the size and coordinates, the other for the room/door information. They encryption method is difficult to explain. Here is the code I wrote based off the original algorithm in the EXE...
pDatBut1 contains the level size and coordinates broken up into two word sized arrays, each 0x100 bytes long. The first array contains two bytes for each level. The first is the level's height shifted left four bits. The next contains the level position. The high nibble is the X, the low is the Y (more on this later). The second array contains two byte entries for each level as well. The first entry is the Width of the level, the second is a copy of the position. I believe it was a limitation of the PC which made it so the levels could only be positioned on spots divisible by eight. The files store more precise locations, but they are lost. So, 3 is the same as 5, for example. Here are
algorithms for obtaining the actual X and Y values:
pDatBuf2 contains the level room information. It is broken up into eight 0x80 byte arrays. Each byte represents a level, with mazimum 127. The arrays are as follows:
|
BriPro.com ©1999-2008
Brian Provinciano. All rights reserved. |