Main > Software Forum
HiToText (Version 2010.11.4).
Fyrecrypts:
Post #1 and #11...
headkaze:
--- Quote from: retrometro on August 24, 2008, 09:43:07 am ---I'm definitely interested in an app that can run reports of high scores. It'll be a lot of work to decipher scores from each game but once that happens, I can see how it can be extended to lots of things. For example, it would be great to see the top score(s) through a FE like MALA as you browse your games... or a report ran after your FE shutsdown so that upon boot the top scores of your favorite games are displayed.
--- End quote ---
This was basically the idea I had and PMed MKChamp about recently. As you guys have already figured out the hiscore.dat only stores/restores a chunk of memory used to hold the hiscores, nothing else.
We would have to write another dat file which took this chunk of memory and broke it up into Player Name / Scores which would be locations in the chunk of memory for each hiscore entry.
The rest is trivial I guess writing software to support the displaying and sharing of hiscores, so yeah the hard part is getting another hiscore dat with all the locations for each hiscore entry.
Here is the hiscore.dat entry
--- Code: ---; <gamename>:
; <cpu>:<address>:<length>:<value to wait for
; in the first byte/word>:<value to wait for in the last byte/word>
--- End code ---
There is also a couple of interesting tutorials on how the hiscore's are obtained.
But for simplicity sake I think NOP's idea is worth a look at. The only problem I see with that is the whole system couldn't be automated. Each .hi file would have to be examined, and what if there are two top hiscores in two different .hi files, there would have to be a way to merge them into one file. So I think even with this idea, you need a new dat file with all the hiscore entries defined. Then there is hope of automating a system like this, as well as being able to display actual hiscores on the website. Also people would have to register 3 character names on the website that will be accepted. Alot of work but I think it's a good idea. Alot of the hard work would be creating this new dat file.
Fyrecrypts:
I'm hoping to have the automate stuff done by the end of the week, and you don't want to have one person have just a 3 character name be accepted, at least I don't. If my brother comes over to play, and beats everyone's Dig Dug, I want everyone to see his initials too.
I'm solving this problem, by having the webserver information stored in a settings.xml file and anyone I want to access the hi scores can use the address I give them with the application. As for the new .dat file, I would propose this as a standard:
<gamename>:
<numOfScoresSaved>:
<nameOfStatToBeSaved>:<statToBeSaved>:<#ofbytes>:<someTypeOfByteFormat>
(Repeat the above as necessary for names/initials, rank, scores, floor, character, world, etc...).
<Any important trailing bytes>
Here's the problem though, certain games are not as easy to breakdown as the above. If you look at msword.hi you'll see that there's an extra byte around the third score that I can't account for. It's an extra 0D, I believe, right before where I would guess is the floor reached bytes, and it offsets all the other scores by that one byte. How do you account for that in the above new .dat file? In addition we'd need something to explain the format of the bytes, hi scores themselves are usually just the literal digit representation (despite the bytes being in hex). So the 4 bytes: 00-50-00-00 is 500,000 and not the hex to decimal equivalent: 5,242,880. Certain games allow lower case characters (Super Mario Bros), certain games allow the © symbol (1942), and so on...
I'm thinking it's going to need to be semi-hardcoded for each game, or at least each game that can't be described by the above schema. Like I said, I'm more than willing to share the source when it's completed. In the meantime, if you want a game included in this application, please try and break down the game's method for storing the scores in memory here. The more information you can provide the better, in particular a character mapping to bytes for each allowable character that the game uses for storing names.
I know this is going to take a lot of work, but it has the potential to be a very cool application, and one that everyone can actually help with.
headkaze:
Fyrecrypts: Not sure what you mean by the hex issue. If your trying to figure out what bytes do what in the .hi files I suggest you take a look at tutorials on the hiscore dat website and use the Mame debugger to view the data in memory. Although I think in most cases viewing the .hi file in a hex editor (my personal favourite is HxD) should be good enough. There might be some cases where numbers are stored in big endian which will mean the bytes will need reversing. There may be some cases like this where it's difficult to describe in a dat file but it may be possible. Some ways the data is stored could be dependent on the game, the CPU and driver. Some games may use the same format as their parent ROMs.
If you write a program and hard code it, that would be fine, just make it a command line application that can accept a .hi file as a parameter and output the hiscore table to stdout in a standard format. Then with that any FE or software can use this util to grab the hiscore list from a .hi. So I'm not against hard coding it into a program, and lets face it it will be alot easier hard coding each game rather than writing some complex dat file as long as it's maintained I wouldn't even care if the source was released. Come to think of it a dll may be even better, but anyway you get the idea.
Let's not rule out the idea of a dat file though, see how hard it is hard coding it first and after a few games you might realise it would be possible or too hard to make a dat. For now I support the idea of a program and even if we do go for a dat file in the end, the program may even be modified to output the games it supports to a dat. Either way you should learn a few things about how hiscores are stored, and I have a feeling a dat file may be too hard create anyway. Also if we do go the dat file way and it becomes complex to parse it, there seems like no point going that way anyway.
Fyrecrypts:
Edit: Post left so the rest of the thread makes sense, but just know this issue was only because .hi files converted to .txt files and then uploaded caused some extra stuff to be included in the file resulting in strange .hi files.
This is the hex issue:
Score: 00-50-00-00- (500,000)
Name: 08-0C-2C- (EGW)
Floor: 00-0C- (might just be 0C) (12)
Rank: 04- (big hulking guy)
Unknown: 00-00-00-00-00-00-
Score: 00-45-00-00- (450,000)
Name: 30-00-1A- (YAN)
Floor: 00-0B- (11)
Rank: 04- (big hulking guy)
Unknown: 00-00-00-00-00-00-
Score: 00-40-00-00- (400,000)
Name: 0E-00-04- (HAC)
Floor: 00-0D-0A- (10) (Why the extra 0D?)
Rest: 04-00-00-00-00-00-00-00-35-00-00-0C-30-1C-00-09-04-00-00-00-00-00-00-00-30-00-00-0E-1C-24-00-08-00-00-00-00-00-00-00-00-25-00-00-04-00-1E-00-07-00-00-00-00-00-00-00-00-20-00-00-04-1C-18-00-06-00-00-00-00-00-00-00-00-20-00-00-04-00-1E-00-05-00-00-00-00-00-00-00-00-20-00-00-04-1C-18-00-04-00-00-00-00-00-00-00-00-20-00-00-04-00-1E-00-04-00-00-50-00-00
As you can see there's an extra byte to describe the floor for the third score, all the other scores line up fine if you break it down in the format I have for the first two scores (4 score bytes, 3 name bytes, 2 floor bytes, 1 rank byte, 6 zero padded bytes). How do you explain in the .dat for that extra 0D?
In addition, the character representation for 'A' is 0A in 1942, but 00 in msword, and it's not just an offset, the character representation in msword for 'G' is 0C, and for 'H' is 0E, what is 0D? in 1942 0D is 'D'. So we would need to have some sort of translation table in the new .dat as well that could convert these values per game.
The app I plan on working on would have the side effect of having an xml file containing all the current codes in the .hi file, but I'm not sure if I'd do the job of breaking it out and making a standalone app/dll file that would convert a .hi file to stdout. That may end up being the best solution however.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version