Ultima 1 Revenge: Ultima 1 Savegame File Format Reference Updated
Dino the Dark Dragon shot me an email to let me know that the savegame file format information hosted on his newly-launched Complete Guide to Ultima 1 is actually a newer and updated version of the one that graces the Ultima 1 Revenge project entry.
Can’t have that, can we? I’ve gone and updated the download at the project entry as a result.
I admire that kind of attention to detail. If everyone followed that policy there would be a lot fewer divorces, and probably even wars. Nice work there.
It might be a good idea to put file format specifications in the Codex of Editable Wisdom as a reference for devs. Jc/FEARYOURSELF and others could benefit from up-to-date specs.
Nice excel file. I noticed though that Dino is missing the random number for the dungeons, which should be 2 bytes at 32H and 33H.
You can try this by creating 2 identical savegames and compare. If you maintain those numbers the dungeons layout stays the same (just doors, barriers and secret doors, as far as I know, chests and coffins do not stay the same).
I hope he sees this 🙂
Hey Natreg! Thanks a lot for this information – I have just verified it and have added it to my Excel sheet (though I haven’t uploaded it yet).
I remember you had also told me about NIF.BIN being used in the endgame, and I hadn’t managed to confirm what it is exactly, even though I had confirmed that it is needed by the endgame (because removing it causes issues). I think I’ll try and check that out too.
Thanks again 🙂
You’re welcome
NIF.BIN is the ending text. I think it’s an image that loads (seeing as it loads on screen as a scroll down). Being unique unlike the tilesets, which have CGA, EGA and T1K, it’s probably monochrome so that all graphic cards can load it.
You can test it by opening the file in hexadecimal. You’ll see several blocks of hex values, each one is a line of the ending. If for instance you swap 2 blocks, you will see the changes in the ending.
Yep, from what I’ve seen so far it’s a 1 bit per pixel black & white image, 320 pixels wide and 168 pixels high (leaves some space for the “Press Ctrl+Alt+Del” message at the bottom.
I originally thought it was text in the large DOS font (40×25) but in the game it loads progressively, one scanline at a time – probably that’s why they stored the text in an image.
I am currently writing a little program to verify this. 🙂
Btw, do you also happen to know the formats of the CASTLE.4 and CASTLE.16 files (which show the castle graphic in the intro)? I’m guessing they’re CGA/EGA versions, but the last time I tried to figure these out, I didn’t have much luck.
I checked things a bit further.
It seems a letter in the ending is 1 byte. The text starts at 50H
so it’s something like this:
A rain of silver
50H CC 00 DC 78 70 F8 00 78 60 00 7C 70 30 CC 78 DC
A r a i n o f s i l v e r
What’s weird is that the “a”, “o” and “e” share the same hexadecimal number. But as you can see the words match the with the number of hexadecimal bytes separated by ’00’ which are bank spaces.
Re NIF.BIN, I don’t think so 🙂 If you open a screenshot of the endgame (e.g. from my walkthrough) in MS Paint, you can see the pixels. The first byte is 30 (hex), which in binary is 00110000, which matches the pattern of the pixels. The next two pixels of white, in the dot of the ‘i’ in “rain” also matches. The program I’m writing should show that this holds for the rest of the file. 🙂
I’m quite certain that those are images. probably the .4 has a pixel represented by 2 bits and the .16 has a pixel represented by 4 bits, being 4 and 15 colors respectively. The sizes also confirm this, being the .16 one double size compared to the .4 one.
One way to test it could be changing one of the hexadecimal that repeat a lot to something else (all of them).
For instance, .16 has the value 66 repeated a lot (or 6 if you prefer just the 4 bits per pixel theory).