Tuesday, January 30, 2018

Integers Strike Again

Missions can now load and be viewable
Slowly the filesystem functions is being replaced. I can now read the mission and fleet commander files. In fact, I'm using one of the original files used by the original developer to test the game. (His commander is named after him) The time stamp when he last played the game was 7:48pm Dec, 18th 1992.

I have now run into a nasty issue I thought I wouldn't run into, but it's back again. The game was written on an compiler that used 2 byte integers. Systems nowadays have integers that are 4 bytes, or in the case of 64 bit Linux and MacOS systems, 8 bytes. Normally this wouldn't be a problem, but the way the game loads data objects from disk is   VERY byte dependent. The system just loads up the data as a block of serialized bytes and lays them directly into a struct from top to bottom. So you can imagine what happens when the data was saved with 2 byte data members and then loaded and put into a struct that has 4 byte data members.

int was replaced with int16_t
I had to change the int types to int16_t to get them to fit, but I'm thinking this is going to cause casting issues down the line. I'm already having issues with capturing the saved outpost data into the linked list properly. I'll battle that tomorrow. If worst comes to worst, I'll have to manually load each struct member individually. I'm sure the old way was optimized for speed and size. Computers have plenty of that to spare nowadays. Allegro can load integers of various sizes and endianness individually, so I can probably leverage that too.

No comments:

Post a Comment