If I understand things correctly, cinE used to dump the entire animDataTable

element to the savefile, including data pointers. After reading the savefile,
it would then test if ptr1 was NULL, to see if it should load the object.

I've extended the savefile format with a byte to indicate whether or not ptr1
was non-NULL. This seems to fix the problems I had with with loading savegames,
but of course any old savegame is now even more broken than before.

I still can't seem to get out of the room with the machine, though. Another
regression when migrating the code from cinE, or just my ability to get past
this annoying, timed puzzle?

svn-id: r21772

1 files changed, 11 insertions, 0 deletions

diff --git a/engines/cine/various.cpp b/engines/cine/various.cpp
index 78dc6e2ae6..5e54e17aec 100644
--- a/engines/cine/various.cpp
+++ b/engines/cine/various.cpp
@@ -52,6 +52,8 @@ uint16 var3;
 uint16 var4;
 uint16 var5;
 
+bool refreshAnimData[NUM_MAX_ANIMDATA];
+
 void drawString(const char *string, byte param) {
 }
 
@@ -651,6 +653,7 @@ int16 makeLoad(char *saveName) {
 		animDataTable[i].fileIdx = fHandle->readSint16BE();
 		animDataTable[i].frameIdx = fHandle->readSint16BE();
 		fHandle->read(animDataTable[i].name, 10);
+		refreshAnimData[i] = (fHandle->readByte() != 0);
 	}
 
 	// TODO: handle screen params (realy required ?)
@@ -811,6 +814,14 @@ void makeSave(char *saveFileName) {
 		fHandle->writeSint16BE(animDataTable[i].fileIdx);
 		fHandle->writeSint16BE(animDataTable[i].frameIdx);
 		fHandle->write(animDataTable[i].name, 10);
+
+		// Horrifyingly, cinE used to dump the entire struct to the
+		// save file, including the data pointers. While these pointers
+		// would be invalid after loading, the loadResourcesFromSave()
+		// function would still test if ptr1 was non-NULL, presumably
+		// to see if the object was present in the room.
+
+		fHandle->writeByte(animDataTable[i].ptr1 ? 1 : 0);
 	}
 
 	fHandle->writeUint16BE(0);  // Screen params, unhandled