(Source: https://www.youtube.com/watch?v=qfEXShKCVnU)
The first week is already over and brought up some quite interesting problems. Here is a short list of what has been done.
Implementation
The game’s assets are LZSS encoded in two libraries, imm1.lib and imm2.lib. The header starts with a 5 byte long signature “EALIB” and an uint16LE of the number of files encoded. The following table consists of 18 byte entries per file and a list terminator (flag x00) as its last entry.
Fullscreen image files like the title screen and the screen frame are stored linearly so that each nibble that represents one of the 16 possible colors just need to be written in its own byte.
Music files are stored as .BIN and consist of a custom header as colorfully shown above, followed by MIDI data. The header appears to be similar to Ski or Die but there are still questions open. This shows my best guess at what it could be + lots of googling
struct AudioHeader {
uint16 midiOffset
byte mt32ChannelActive[16]
byte mt32ChannelVolume[16]
byte adlibChannelMapping[9]
byte cmsChannelMapping[12]
// here starts the guessing for real
byte cmdChannelTuning[12]
byte TandyChannelSetup[8]
byte speakerSetup[2]
uint16 midiOffset
byte anotherMt32ChannelActive[16]
byte another_ChannelMapping[16]
char signature[6] = "rsxx}u"
byte data[10] // probably for editor but all zeroes from what I have seen
}
It is worth mentioning that the first MIDI event is missing its delta time, that I append as I convert the header to a type-0 MIDI header (code).
Audio effects have not been implemented yet. Unfortunately they are generated directly by calling into the sound driver that stills need to be reverse engineered.
Next Week
Although the audio is not yet done, I will leave it for now and implement handling of .ANM files and sprite rendering next.