Kreuvf commented

What is 'a saved game'? A save-game created with the same version?

EvilGuru commented

It could be an endian issue. Needs further investigation (Ideally done by someone with a PPC Mac).

bearda commented

Yes, saving with the same version results in bad bumpDir values. Almost all my saved games that weren't generated between levels (when the stat page pops up) have the same problem, it isn't one or two specific saves. I tried saving my game, going to the main menu, then immediately loading the save I had just created and had my debug print spewing bad bumpDir values before resetting them to 0.

When I have a minute I'll try converting some of the bad values I get back to little-endian and see if they fall into the 0-360 range. I have two PPC Macs (one mini and one iBook, both G4s) available if anyone wants me to test something. The mini is the only one set up to actually build the code at the moment, though, so it's where I've done all my testing so far.

Giel changed blocking which not transferred by tractive

anonymous changed blockedby which not transferred by tractive

anonymous commented

I've come to realize my problem in #177 is definitely exactly the same as described here. My bad for double-posting a bug. Not sure if there is a way to merge these or something...

Giel commented

Replying to Warzone2100/old-trac-import#96 (comment:5):

I've come to realize my problem in #177 is definitely exactly the same as described here. My bad for double-posting a bug. Not sure if there is a way to merge these or something...

I closed #177 marking it as a duplicate. As for merging there's no need really, as we can always follow the links...

mathew.eis@... commented

It appears that, at least on the PPC platform, bumpDir is being swapped twice. What takes place is roughly as follows:

// Saved droid is loaded...

move.c:6424      memcpy(psSaveDroid, pFileData, sizeOfSaveDroid);

// bumpDir is swapped...

move.c:6490      endian_sword(&psSaveDroid->sMove.bumpDir);

// Call function to create actual droid from saved droid

move.c:6525      psDroid = buildDroidFromSaveDroid(psSaveDroid, version);

// Call function to copy move data into actual droid from saved droid

move.c:5977      LoadDroidMoveControl(psDroid, psSaveDroid);

// bumpDir is swapped again!?

move.c:5699      psDroid->sMove.bumpDir      = PHYSFS_swapSLE16(psSaveDroid->sMove.bumpDir);

Possibly this is a bug in the way that LoadDroidMoveControl is set up... A rough examination makes it appear that all the byte swapping code should be removed from LoadDroidMoveControl, since it already was done in move.c:6481-6497 - not sure how this would affect x86 platforms though.

mathew.eis@... commented

The above referenced file should be game.c, not move.c

Giel changed resolution from `` to fixed

Giel changed status from new to closed

Giel commented

(In [6512]) * Do not perform endian swapping twice when loading, as it'll undo the first swap

• Make saving and loading of move controls symmetric

This should fix #96, #127 and #177

Giel commented

(In [6513]) Merged revision [6512] into the 2.1 branch via svnmerge from trunk

........
[6512] | muggenhor | 2008-12-28 15:31:54 +0100 (zo, 28 dec 2008) | 5 lines

• Do not perform endian swapping twice when loading, as it'll undo the first swap
• Make saving and loading of move controls symmetric

This should fix #96, #127 and #177
........