Some procrastination and preparation for opcode comparison

Hello everyone. There’s been some procrastination in the air so to speak. I’ve been working on making an opcode comparison between different Operation Stealth versions in order to discover which opcodes are platform specific (Amiga/PC/ST), which are extensively used etc. The idea is that once I know that then I’ll know which opcodes to try to implement first. Sev pointed out to me a standalone resource file unpacker and script decompiler for Cinématique.

My first problem was what files to decompress i.e. knowing which files are resource files. Well, I looked at ‘vol.1’ – ‘vol.9’ files. They seemed to be simply text files containing lists of at least some of the resource files (Maybe all of them, don’t know). Then I got interested in how Cine currently figures out which resources files to unpack and it seemed it doesn’t use the ‘vol.?’ files at all but instead it uses a ‘vol.cnf’ file. Well, I tried to figure out the code that deciphers the ‘vol.cnf’ file and now I understand it. I started a page about Cinématique‘s internals, file formats etc in ScummVM’s wiki at the Cine Specifications page and wrote some documentation about the ‘vol.cnf’ file format there.

The standalone resource file unpacker and script decompiler didn’t have any support for wildcards or directory recursion so I wanted to try to use Python to do the directory tree walking and call the external unpacker or script decompiler when necessary. Hadn’t done directory tree walking or cleanly done command line options parsing before in Python so it took some time to learn to use those. Eventually after some tryings I used getopt.getopt for command line parsing and os.walk for directory tree walking.

I also was somehow torn with what to do in Python and what to do in C. The resource file unpacker and script decompiler were in C. If I were to call them from Python what about error handling? I couldn’t find a nice way to pass info back to the Python script from the external programs – I tried popen3 a bit but maybe the stdin/stdout/stderr passing only works on Unix, dunno, or maybe I just didn’t try hard enough :-).

Eventually after some procrastination and different ways of trying things I’m now quite convinced it’s probably a good compromise and use of resources to let low-level stuff be done in the C code (Bit manipulation, unpacking etc) and the higher level stuff (Calculating scripts’ opcode statistics etc) be done in Python because that way I’m using both of the languages’ strengths (i.e. use them for what they’re best for) instead of trying to do most or all of the stuff in one language only.

So now I’m at the point that I’ll just combine the Python and C programs to do the unpacking of all the resource files for the different game versions and then modify the script decompiler to output in .CSV format so that it’s easy to read the C program’s output in with Python or Open Office. Once I have the data parsed I can do the opcode statistics calculations. There’s a question though about how to detect what files are script files and what are not so I know which files to call the script decompiler on. Well, we shall see…

BTW sometimes understanding C code that deals with pointers and C library calls can be a bit of a PITA (And no, I don’t mean the eatable kind). Just compare fixVolCnfName()’s old C code version and the more C++ style version I did of it with some comments. Now I can understand what it does :-).


Tags: , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: