[Berrex]

Hey guys. I purchased Duke Nukem 3D off GOG.com recently, and I have a desktop and a laptop, both of which dual boot (Windows 7 + Arch Linux on my desktop, OS X 10.6 + Arch Linux on my laptop). Ideally, I would like to be able to synchronize my game save files via Dropbox so that I can play Duke Nukem on either of these computers, regardless of OS, and pick up where I left off. Unfortunately, I'm having troubles getting this to work. As of right now, I'm trying to get the game save data from Arch on my Desktop to work on Windows 7, but when I copy over dukesav0.esv to my eduke directory on Windows and attempt to load it, the save is titled "?AVE1" in gray text, and I cannot load it. In the preview window to the left it says:

"OLD VERSION
Saved: 1.1.235
Our: 1.1.235"

For Windows, I downloaded the same release that is available through Arch's AUR channel (20120114-2257), so I'm not sure why there seems to be version incompatibility here. I even tried making it work between Arch on my desktop and Arch on my laptop, which are also running the same version of eduke32, and it's still a no-go. Same issue. Is there any way I can get this to work? I switch between operating systems and computers frequently, so I don't want to have to be tied down to one specific computer/OS to be able to play the game.

Thanks.

UPDATE: I just copied my entire Duke Nukem 3D folder (~/.wine/drive_c/Program Files/GOG.com/Duke Nukem 3D) and ~/.eduke32 folder from my Arch installation on my desktop over to my Arch installation on my laptop, and I'm still having the same problem. I'm not sure why this is happening, since in this case, all game files are exactly the same, the versions are exactly the same, and even the OS and installation methods are exactly the same. Why doesn't this want to work?

[Helixhorned]

Savegames made with 32-bit and 64-bit executables of EDuke32 aren't compatible with each other. For greatest protability, try compiling 32-bit version on Linux (BUILD32_ON_64=1 make ...) and use the 32-bit one from the fat binary on OS X (arch -i386 ./EDuke32.app/Contents/MacOS/eduke32).

[Berrex]

Sorry for the late reply. Had some life happen in the last week. Anyway, you're probably right regarding the cause of the problem. I was able to create a new save in Windows and load it just fine in Arch on my 32-bit laptop, and my Arch installation on my desktop is 64 bit. So I tried building from source with BUILD32_ON_64=1, but I can't seem to satisfy the 32-bit dependencies since it's a 64 bit system, so I'm repeatedly running into a total dependency hell trying to get it to build, making this way more trouble that it's worth to me. Guess I'll just have to skip playing Duke on my desktop while running Arch. Or play in a VM or something. Sad. :-\

Thanks for your help anyway.

[LeoD]

More savegame issues or same issue in different environment:

Since the introduction of the *.esv savegame format the 'official' synthesis snapshots can no longer load saved games from my local MinGW32 builds of the same source revision. I assume the synthesis snapshots are compiled with MSVC?

If I have read the subversion logs correctly this would also mean that recorded demos can't be exchanged between different builds (same revision and bit width), too.

Of course I don't know how much work that would mean, but I think it should be worth the effort to make the saved games (demos) portable again between all builds of the same revision.

Btw., when using a self-compiled eduke32.debug.exe, can I stick to the 'official' ebacktrace1.dll or should I build my own one?


Bonus: more compiler warnings (Wheezy 64bit):

source/sdlmusic.c: In function ‘MUSIC_Init’:
source/sdlmusic.c:157:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

src/driver_sdl.c: In function ‘fillData’:
src/driver_sdl.c:101:8: warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith]

src/sdlayer.c: In function ‘getvalidmodes’:
src/sdlayer.c:969:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

[Hendricks266]

Synthesis builds are built through MinGW32 using WINE. (Check synthesis.sh in the SVN repository.) If the savegames are not portable, that sounds like a problem.

[Helixhorned]

LeoD, on 30 September 2012 - 11:09 AM, said:

Since the introduction of the *.esv savegame format the 'official' synthesis snapshots can no longer load saved games from my local MinGW32 builds of the same source revision. I assume the synthesis snapshots are compiled with MSVC?

Savegames should definitely exchangeable in that case. What does the latest revision say in the "Load Game" menu?

[LeoD]

Helixhorned, on 01 October 2012 - 11:31 AM, said:

Savegames should definitely exchangeable in that case. What does the latest revision say in the "Load Game" menu?

I have made four different savegames. 64/32bit incompatibility is shown in the menu. When loading my MinGW savegames with the synthesis build or the other way round, eduke32 bails out with an error window.

Attached thumbnail(s)

• 
• 

Attached File(s)

•  eduke32.log (1.55K)
  Number of downloads: 302

[Helixhorned]

It's likely a different size of some struct due to padding or the like. My guess is sizeof(_prlight); can you check that with something like

initprintf("size=%d\n", (int)sizeof(_prlight));

added at the beginning?

[LeoD]

Helixhorned, on 02 October 2012 - 08:54 AM, said:

It's likely a different size of some struct due to padding or the like. My guess is sizeof(_prlight); can you check that with something like

initprintf("size=%d\n", (int)sizeof(_prlight));

added at the beginning?

?of what?
In the meantime I have built an MS VisualC++ Express 2010 executable. The savegames are interchangeable with my MinGW builds, but not with the synthesis builds. Could it be that this issue depends on the processor used to compile the stuff? I'm on AMD FX/Bulldozer. Maybe I should try to get synthesis.sh running.

[Helixhorned]

LeoD, on 02 October 2012 - 10:22 AM, said:

?of what?

I thought you know C or knew it at one point, so I assumed I could spam you with C-ese . It's unlikely that "this issue depends on the processor used to compile the stuff" in this case, since in both cases, the same architecture is targeted (x86). However, different compilers may carry out the alignment of structs (aggregate data) differently, and as a consequence the savegames would become incompatible between their builds. So, if you inserted the mentioned line somewhere in the initialization code (app_main), and compared its output in the log for both builds, that might explain the problem. I'll probably just go ahead and remove Polymer lights from the savegame, I think they're not supposed to be there anyway.

edit: On second though, it's better to be sure first. Besides, I wouldn't like to bump the savegame version unnecessarily.

[LeoD]

Helixhorned, on 02 October 2012 - 11:35 AM, said:

I thought you know C or knew it at one point, so I assumed I could spam you with C-ese .

Over the last dozen years I didn't do much besides hacking some trivial patches into mt-daapd and Rockbox. (And I didn't search for app_main( but main{ ... well... )

Helixhorned, on 02 October 2012 - 11:35 AM, said:

So, if you inserted the mentioned line somewhere in the initialization code (app_main), and compared its output in the log for both builds, that might explain the problem.

MinGW (third attempt to find a suitable position...): size=264
Somehow I've messed up my MSVC env ... this will take awhile.

Helixhorned, on 02 October 2012 - 11:35 AM, said:

I'll probably just go ahead and remove Polymer lights from the savegame, I think they're not supposed to be there anyway.
edit: On second though, it's better to be sure first. Besides, I wouldn't like to bump the savegame version unnecessarily.

Saving Polymer lights is a major improvement imho. I hope it can stay somehow.

[LeoD]

LeoD, on 02 October 2012 - 12:31 PM, said:

MinGW (third attempt to find a suitable position...): size=264

Btw: "gcc is /mingw/bin/gcc gcc.exe (GCC) 4.7.0"

LeoD, on 02 October 2012 - 12:31 PM, said:

Somehow I've messed up my MSVC env ... this will take awhile.

...size=264
I can't figure out how to set include and library paths for VS2010 permanently outside of the project. I've lost my own howto and the EDukeWiki is about VS2008.

[LeoD]

LeoD, on 02 October 2012 - 10:22 AM, said:

Maybe I should try to get synthesis.sh running.

Done. size=264 (no surprise, ofc.)
The savegames are compatible with all my other 32bit builds, but not the official one. The error message in the log is a little different now. (My synthesis build tries to load a savegame from yours.):

Attached File(s)

•  eduke32-synthesisLeoD.log (1.68K)
  Number of downloads: 236
•  game.c.zip (75.24K)
  Number of downloads: 175

[Helixhorned]

Sure enough, sizeof(_prlight) is 261 for me, in every compiler setup I tested: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, clang version 3.2 (trunk 157762), some MinGW GCC 4.6.

r3052 said:

In savegames, store dummy constant-length block instead of a _prlight array.

sizeof(_prlight) differs across compilers, and besides, Polymer lights were
not loaded anyway (they're restored live in-game later). The savegame version
was not bumped, but only savegames made with builds where sizeof(_prlight)==261
(like synthesis) will stay compatible!
Report and helpful debugging information by LeoD.

[Plagman]

I thought the pack pragma was supposed to avoid these sort of problems around the prlight definition.

[Helixhorned]

Looks like it's not very standardized... the disagreement here seems to be about whether the pack pragma only affects the alignment of the members inside the struct, or additionally the alignment of the struct itself too. I think it's best practice to lay out the members so that no holes occur other than maybe at the end, and pad the struct manually to 4- (or 8-?) byte alignment if they do.

[LeoD]

Helixhorned, on 03 October 2012 - 07:32 AM, said:

r3052

Works. Thanks.
It's funny to see gcc-4.7 "teaming up" with MSVC vs. gcc-4.6/clang.
Is it likely we'll see 64<->32bit compatible savegames, too?

[Helixhorned]

LeoD, on 04 October 2012 - 10:13 AM, said:

Is it likely we'll see 64<->32bit compatible savegames, too?

One day, maybe...