64 bit support and fixes

[winterheart]

• Added 64 bit support (based on @icosahedral-dragon works)
• Various fixes and cleanups

[icosahedral-dragon]

To be perfectly frank, I'm still not entirely happy with the file format translation stuff, although it works well enough in terms of getting the game to run. By all means keep up to date with the proof-of-concept, but I wouldn't recommend merging it to upstream just yet.

[donnierussellii]

I'm currently having a try at cleaning up and rewriting saveload.c to read/write each element of the arrays. I've done something similar in my roguelike ports, but I'm a bit out of my element here.

[icosahedral-dragon]

@donnierussellii Take a look at the current 64-bit proof of concept code. I've added a table of map archive formats indexed by resource ID, so the code in saveload.c looks pretty much as it would have done in the old DOS days.

[donnierussellii]

@icosahedral-dragon So I can just make more *Layout structures and use them with the decoder FIXMEs?

[icosahedral-dragon]

There are a few structures I skipped over because I figured it would be impractical at the time to define layouts for them. Notably the player struct, partly because there are multiple versions of it in various save game formats that are difficult to distinguish, and partly because it is enormous. Which FIXUS in particular were you thinking about?

[donnierussellii]

Just the FIXMEs marked in saveload.c that need to be decoded with ResLock. I added layouts and fixed them all except level_gamedata , which contains an array of structures that I don't know how to deal with using ResLock. saveload.txt

[icosahedral-dragon]

The only ones left in saveload.c in the current PoC branch are loading the fullmap where some left-over conversion code can probably be removed and the schedule queue, which probably could do with a proper layout. As far as level_gamedata goes, I confess I fudged it; the array is only 3 entries long so I just put all 3 entries in separately. I perhaps should add support for structured arrays, but that would be a bit more sophisticated than I'm going for right now.

[donnierussellii]

I was working from an older file version, but it was nice to dive into shockolate again. I was thinking of doing the same with the array in level_gamedata.

[donnierussellii]

I loaded up archiveformat.c from your PoC branch. I've been making a layout for the Player struct. On disk it has packing alignment 1, and I'm doing an offsetof for every array element. It should be fun, and might be useful to the project ;)

[icosahedral-dragon]

To be honest, it was partly laziness that stopped me constructing a layout for that. There's quite a lot of it. Unfortunately there are a few different binary versions extant without a corresponding version number change. The mfd_access_puzzles array was changed in size at some point. I think it's 32 entries in saves created from the old DOS version but 64 in post-Night Dive saves. Also I changed the MFD_Status typedef from an enum to a byte; gcc does not like to create single-byte enums but the size should be 1 on disc. Again, creating a layout type that is a single byte on disc but an enum in memory would be a little bit tricky.

[donnierussellii]

Here's my attempt at a player layout. I made an effort to keep it free of errors. Maybe it can be used as a starting point for further work. player layout.txt

[icosahedral-dragon]

Great. You can now define a byte array within a struct using the RFFT_BIN macro, so we could get rid of most of the long lists of individual bytes. Arrays of anything more structured than a byte aren't supported, though.

[donnierussellii]

Okay, here's my updated player layout. player layout.txt

[icosahedral-dragon]

That looks pretty good. I'll give it a whirl in due course.

[Interrupt]

Are there any additional fixes from this that should get merged in? Might be worthwhile to merge from Master and see if there are additional changes.

[winterheart]

Seems all in place. Closing now.