Sentimental Shooting Graphics Files: Code Update

So, the disassembly thing is basically not going to happen.  Or at least, not by me.  As it turns out, people want tons of money for this kind of software and the free alternatives that I'm willing to run on my computer are lacking in documentation and the features I need to get my foot in the door.  Some are written in Python, which is annoying to deal with because everyone has their own pet version of Python that they never upgrade from and require you to install for all their stuff to work.

However, I can make my existing code better, and figure out more of the files.

I've already made the code better, by translating it to C#.  It runs faster and is far simpler now.  The reason for the simplicity is because my original PowerShell scripts were designed to work with paths containing wildcards and the PowerShell pipeline, so there had to be a bit of overhead in there to transition from one file to the next cleanly.  Stuff that an end-user probably wouldn't think of, but would absolutely annoy them if I didn't do it.  Namely, closing file handles properly so files don't stay marked as "in use" and become unable to be moved, renamed, or deleted.

But also in my typical fashion there was code in the PowerShell script for the UME files, for a use case I didn't need: some of the UME files are sort of grafted at the hip to System.ume, and being that the script was designed to be able to process an arbitrary number of input files, I put in code that would try to use System.ume from different directories, but if it's still in the same directory it'll keep the current System.ume open, and just seek back to the beginning of it.  It's kinda dumb, but I wrote it off as being forward-thinking.  After all, this code I'm working on could very well be the basis for modding the game, so maybe you have files for a few different mods you want to convert and they all have their own custom System.ume...  While ostensibly there to avoid closing and reopening the same file repeatedly, it does have this other use case.

Yeah, like I said, it's a use case that I didn't actually need.  It's technically preserved in the C# code, but the C# code also only handles one file at a time.  If you want to process a whole directory, you get to call the method once per file, specifying the path to your desired System.ume with each call.  Yeah, there's some overhead to that, constantly closing and re-opening the same System.ume, but the code's cleaner and easier to follow.  I also got to re-examine what I was doing and remove some of the stupider bits, so the new code is just... more better.

Both the PCG code and the UME code now exist as C# static methods, along with a couple static methods I created to see what was going on with my transformation of the input path to the output path, that I decided to leave in there because why not.  They could be useful.  Yeah, the methods don't take an output path as a parameter, they just transform the input path and then bitch if that file already exists.  That's kinda how I roll I guess.  I did put in a lot of work transforming the file names to be useful, it's not just extension swapping.  For example, Akr1b.ume will get transformed to Akira Stage 1 Background.bmp.

As for figuring out more of the files, honestly, without the ability to understand what's going on in the game's code, I can't do very much more.  The interesting stuff, the PRT, ROT, SPR, and DMO files, will all take more work than I can realistically do right now.  Running some quick commands to get file extension stats shows there's a couple other oddballs in there as well, Enemy.inf and Enemy.pnt.  I've looked at those and have no clue where to start.  This leaves two pieces of extremely low-hanging fruit: Option.dat and Destroy.sco.  Option.dat holds the options, of which the game only has a handful, and aside from the difficulty setting they're all toggles.  Destroy.sco holds your high scores.  They're such low-hanging that I already have classes for both to allow creating, loading, and saving them.

Destroy.sco was interesting because it contains the same structure repeated 12 times.  I chose to represent this in two ways: named properties on my class to allow accessing a specific stage's data by character name, and a custom indexer that puts the stages in the order they appear on the stage select screen from right to left.  That's actually significant because the score data in Destroy.sco is not in the same order as the stage select screen.  Figuring out the order was easy enough since it was simple to identify which values in the file were the scores.  I just set each stage's score to a number from 1 to 12, so when I looked at it in-game I could see which score showed up where.  Because I implemented an indexer, it didn't feel right without a Count property and an IEnumerable<T> implementation, so those are present as well.  I didn't implement ICollection<T> because it's not actually a collection and doesn't need management methods.

Also, the scores are signed values, which is interesting because if you give it a negative score, it reads an incorrect graphics tile from System.ume when it tries to display the minus sign, despite the fact that there is a minus sign available.  Also, if it has to display more than 7 characters for the score (7 digits, or 6 and a minus sign), it won't fit properly in the box on the stage select screen.  My code range checks and sanitizes both the scores and the percentages to avoid causing display bugs.

The structure of Option.dat suggests to me that the difficulty setting was probably added later on in development.  It appears at the very end of the file even though it shows up at the top of the options screen (everything else is in the order in which it appears on the options screen), Normal difficulty has a value of 0, Easy has a value of 1, and Hard has a value of 2.

Anyway, I've basically done all I can do in terms of figuring out file formats.  I suppose that my next endeavor will be trying to tweak the game's graphics files to avoid the palette corruption.  This will be annoying given that I can't get GIMP to load the palette from the files in its palette editor.  Worst case scenario, I have to roll my own code to change a palette entry and update palette indices to point to the new color, because I'm not writing an image editor.