High Score Files

Alturis

Not sure if this is the right forum but I was a bit surprised by the way that there is a lack of consistency in the <game>.hi hi score file format for Final Burn Alpha.

This started because I was playing Truxton 2 and found the high scores to be crazy high for me to beat and wanted to just reset them all to zero so that the high scores could be reasonable for our household.

Simple enough, it stores each score as a 32 bit int, followed by the set of initials that go with each of those scores (but each letter is a 2 byte code), followed by which stage the score was achieved on. Easy enough to zero out all the 32 bit values.

Then out of curiosity, I was looking at something like Galaga. Here I was at first baffled because nothing in there matched any kind of integer value, nor did I see any of the ascii characters for any of the initials. In a very bizarre formatting decision this .hi file stores the scores as a series of bytes, one for each digit, appended with a '$' character. Then the initials follow the scores, followed by the highest score repeated again. What was really surprising to me was how the initials are stored. Rather that just store the ascii values, it writes them out relative to 0x0A. Meaning that the letter A would be 0x00, B would be 0x01, D would be 0x0D, L would be 0x15, etc.
I suppose I can see storing the score as a '$' terminated series of numbers because this leaves no upper limit on how large the score can be. But the indexing of both the digits and the initials just struck me as odd.

Wondering if anyone knew of why this was done this way. If nothing else I would have expected that the format would be consistent for each emulator at least.

mitu

@alturis Here's how I understand hiscores working in Mame. Someone correct me if I'm wrong.
The .hi files are just binary memory "patches" loaded by the emulator, overwriting the game's memory at start. Since most arcade did not have a persistent saving place, Hiscores work by Mame patching the memory of the game with the .hi info, after starting the game. The information needed to load this info is the hiscore.dat configuration file (i.e. where and how to load the binary .hi file).
The format of the .hi file is dependant of the arcade CPU (core) emulated, so it's no wonder the format for the file is not standard for each game emulated.

Alturis

I see. So it is a result of the original game rom storing its data that way and the emulator is just saving out the memory as is.

Strange that something like Galaga would be essentially a variable length chunk of memory though. But it looks like the hiscore.dat is setup so that it keeps writing until it hits a terminator for a given stream of bytes. So that makes sense I guess.

cyperghost

@Alturis All is explained here ;)
http://highscore.mameworld.info/tutorial.htm

But @mitu explained already

Alturis

@cyperghost Yeah I had actually skimmed those tutorials over briefly a long while ago when I was looking into what could be causing the high score garbage issues that were fixed in December with lr-fba. Sort of surprising to me that there is always a start and end marker byte.