New version here. I think everything is sorted now, in particular saving and high scores now work. It turns out that the problem was in the loading of definitions - the stuff I'd written to replace the Windows-specific code didn't work. The save file format seems fine.

I just tried the new Kobold Quest binary, and, alas, it's still not working for me. It still crashes when I try to start a new game, this time freezing for a while before it does(this time I get the message that the application has unexpectedly quit, incidentally). It's definitely getting closer, though- the text is fixed, but the cursor is invisible. And, interestingly, the kobold picture at the title screen still doesn't show up, but the bug he's holding does. I wonder if there's some display issues with the brown colors or something.

It sounds like you got it working on more than one machine, so this might be just some weird conflict with something on my computer. I might try it on a couple of other Macs later and see how it does on those...

What would be super-helpful to me would be if you could open the console application, run the game until it crashes, and then copy the output of the console to me in an email. You can send it to peterb - a t - gmail d o t com.

Thanks! And yes, I've gotten confirmation that it runs on at least two machines now. That certainly doesn't mean there aren't still bugs.

(and just to make sure: you threw out the old folder and completely replaced it with the new one, right? The issue in the old folder is that it had a save file generated on my machine, and I suspect endianness issues).

Wow almost one month gap between these last 2 posts. I don't use a mac but a cafe I like to go to only has two imacs, and I would love to play some DF there. I could probably get at least 5 people hooked (its a comics cafe, tons of nerds there).

I don't know anything about how Macs store files, so I can't do that part without burning a lot of time. I'm not even sure what all the issues are. The way the data is stored in the game and the way they are written to a file by another OS aren't necessarily the same, so files wouldn't work between computer without some kind of header information in the file and routines that can convert from the save format to the storage format for a given system. Perhaps there are other issues as well.

There are plenty of floating points and 32 bit integers and other variables that are saved to the disk. If a "long" isn't 32 bits on another platform or the order of the 4 bytes is reversed, that would need to be accounted for, and I have no idea what other platforms do. I'm not even sure how my own platform stores the 4 bytes.

This would increase the file size by quite a lot. Right now, I copy things into a character array which is then compressed by zlib and saved. It could copy the longs and other variables into the array as a number string instead (so a long would take 11 bytes, and a short would take 6 bytes), but it would be best to handle the issues prior to saving the file. As far as I know, I'd only need to handle the one place where the longs are copied into the compression array, since after compression it's just a list of chars that can be saved easily. So it's just a matter of knowing sizeof(long) and the endian issues for long (and other types) on the target system, and making the small number of "copy into the array" functions behave differently based on the OS. Unless there are various things I'm missing, which is quite possible.