MOO2 Graphics Viewer: And the struggle continues…

I’ve managed to get rid of format reading bugs. Now the image is read and interpreted properly. Only what’s left is the palette problem. Here are few shots:

moo2gfxview2.png moo2gfxview3.png moo2gfxview4.png moo3gfxview5.png moo4gfxview5.png

Hope you like it. 🙂 The first one shows the viewer that had corrupted palette (it turned out to be Gimp problem, not my program) and the second has almost correct palette (slight problems are still occuring though). I’m currently not using original palette maps from MOO2. They’re only quickly hacked with Gimp (manually). So the problems exist. I will try to decipher MOO2 palette format and then try to use it within my program. As you can see the progress made so far is neat. The last three images have some palette problems, however I’m now absolutely sure that the format used for graphics in MOO2 is the same for every graphic regardless where it’s used. That’s really nice as you can say.

I have depacked few LBX files and tested my viewer against their contents. It’s working with 90% graphic files. The files that are not opening with it have some quirks in their formats. Especially there’s junk at the end of some files, I haven’t figured out yet, but I hope I will. I can say something about the format at this point. All values are little-endian. Header at the beginning has a word (2 bytes) containing width, and a word containing height of the image. Then there is a word of junk (always 00 00). Next is probably the frame counter (also 2 byte word) followed by four byte junk. Next two bytes represents a word indicating starting offset for graphics. Two bytes junk that’s always 00 00, followed by four bytes of junk with differing values. Then there is two byte 01 00 that is probably start indicator or perhaps the frame number (I’m not sure really). Then follows two byte relative y position of line. Each line can consist of infite “line items”. That means the line can consist of infinite smaller sequences of pixels. Each pixel sequence (line item) starts with two byte length followed by relative x position of the sequence. Then follows the color sequence itself. Each pixel is represented as 8bit value (one pixel = one byte). There can be many pixel sequences within a line. If the sequence length is odd the sequence is rounded to even length by adding 00 byte. Each line terminates with what I call end-line terminator. It’s a double byte (00 00). After this the new line starts with two byte word representing relative y position and the whole thing starts again.

However when testing my viewer on some data sets from MOO2 I have spotted that some graphic files end with few bytes of junk. I’m assuming that this could be a pivot point of some kind or my LBX decompressor is not doing very good job really. Also I’m quite suspicious about line terminators, because it seems that in some files my program is getting out of sync with data stream. I’m wondering if it has something to do with rounding of line. Also it’s very likely that the junk at the end of some graphic files is associated with some kind of frame termination/additional data. It still needs further investigation.

Also. If you’ll use the information I have gathered about this graphic format please drop me a line. If you want to write an application using this information I’d be very thankful if you give me some credit for it. Thanks!

About Wolverine

If you are looking for IT consultant, let me know! karol at karoltomala dot REMOVE com Just remove the REMOVE word from the e-mail above!
This entry was posted in Hacking, Master Of Orion 2. Bookmark the permalink.

3 Responses to MOO2 Graphics Viewer: And the struggle continues…

  1. deowll says:

    Did you try just ripping them off the cd using the microsoft meadia progam?

  2. Wolverine says:

    No. I’ve depacked LBX files using LBXplode and then manually analysed the file format. After knowing which bytes do what I’ve written simple program using Python and TkInter to show them. Development is currently on hold, because I’ve semestral exams soon at the university and I simply don’t have time for it.

  3. Thof says:

    just some additions from my side

    concerning the start-offsets of the single image frames:
    1) all starting offsets are defined by a 4 byte value (your 2 junk bytes “always 00 00” belong to the first starting offset!)
    2) there are always [frame count] + 1 offsets in the file where the final offset identifies the end of the last frame (maybe EOF; have not yet verified this).
    If there are multiple frames in the pic, each frame reaches from its own starting-offset to the next starting ofset – 1 (except the last frame where the next “starting offset” is already equal to the EOF).

    concerning the start bytes of a frame:
    as you figured out each frame starts with a 2 byte word. these bytes don’t seem to be a real identifier as the word is always/mostly(?) named 01 00. I think this is just another relative value (like the x and y values of lines and sequences).

    final comment:
    your LBX decompressor did a good job. the single bytes at the end of each frame/file (??) are always available. these are always E8 03 plus a varying number of additional bytes. possibly this E8 03 is an additional frame/file terminator?! No idea what the remaining bytes could mean as there is a various number of bytes and these are having completely different values (sometimes only 00 bytes, sometimes varying bytes, …).

    Good job!!
    Your information were pretty useful to me.
    I’m going to extract and convert these pictures from the LBX files as I’m going to use them in the savegame analyzer / editor I’m currently building in my free time.

    I know it’s not the first moo2 savegame editor. but as i’m using a mac all these windows applications won’t work for me 🙁 … and finally it’s a lot of fun 😉

Leave a Reply

Your email address will not be published. Required fields are marked *