A little update on MOO2 Graphics Viewer

Despite the fact I have semestral exams at the university (that I’ll probably f*ckup anyway) I wanted to do something else than learning thermodynamics and such stuff. So I’ve taken another look at my MOO2 graphics viewer. Recently I’ve contacted Lord Brazen, who told me to ask Grig de Griz from MOO2 Forums. Grig sent me his MOO2 Workshop program that unfortunately I haven’t been able to test, because I’m not using Windows anymore. However his documentation describing the format was quite helpful for me. There were some things I still had to decipher on my own, but some ideas that Grig had about the format were really good. So I credit him here, because if it was not he, probably I wouldn’t have will to do anything about my little program.

I thought I can rewrite my little tester app from scratch. After few hours I have written two almost complete classes for graphics and palette management. Yes, that’s right. Now the palette is loaded from MOO2 files. However when testing it with graphics from MOO2 it seems to me that either none of the palettes are useful for my test files or the conversion process from DAC RGB to 24bit RGB isn’t the same as Grig has pointed out. Further investigation definitely is needed into this matter. If you have ANY information regarding MOO2 palettes or DAC RGB to 24bit RGB conversion please do drop me a line!

Currently I have almost complete understanding of the MOO2 graphics. ALL test files are loading properly in my viewer. I haven’t checked it visually, because I wasn’t able to write GUI and drawing routines, but the format is loaded 100% properly. I have also left facilities within the class for further investigation of the “junk” bytes that seems to occur between the frames. If they are not junk from memory dump as Grig has pointed out and I have to remind you that when the game was published diskspace did count, I’m assuming that they’re either indicators of changed lines (because some frames are really small compared to others within the same graphic file) or they’re indication of color or palette shifting (ever heard of palette animation?).

For some of you waiting for some more technical details you’ll be disappointed. Tonight I’m not going to give them away. It will happen soon however when I finish rewriting the application to give it’s first beta AND THE CODE. The code and the app will be released free of charge and under GPLv2 license. So anyone who’d like to improve or take something from my app will be able to do so for as long as you will stay in compliance with this open source license. The code is written in Python 2.4. It’s primarily intended for *nix based systems (I don’t have Windows mind you), but it should be fairly simple to port it to Windows, so when I’ll release the code you should be able to run it. Also MacOS X users should be happy, because I’m currently rewriting the GUI with portable PyGUI module that is high-level GUI built over GTK2/Cocoa. So Linux/Unix/MacOSX users should be able to run it out of the box (after installing Python and PyGUI). Windows users should be able to run it after installing ActivePython, PyGUI and Windows GTK2 facilities (library). Those components are free of charge and available for download on the net.

So stay tuned, it shouldn’t be long before I’ll release the code. I’m thinking that if there will be interest in my work I could extend the program further and possibly change MOO2 Graphics Viewer to MOO2 Graphics Editor… 😉 I know that some of you would love to see it. My guess is that knowing how that format is structured it’s relatively easy to write a program that will integrate graphic editor, palette editor and LBX Decompression/Compression out of the box. And remember. If you really would like to see it, the GPL will allow you to take this basic editor and extend it more and more. 😉

No screenshots yet, but I hope that within few days I’ll be able to put some eyecandy here. 🙂 Stay tuned.