Engine freeze when loading Vaporware saves

Make a save in the Cargo Transfer level and then try to load it. Unless you are very lucky, Eternity will freeze. Tested with the "Plus" version, though I don't think it'd be different with the others but I'll try anyway.

This doesn't happen with saves made in other levels, even if the vaporware demo wad is loaded anyway; so I guess it is caused by something that is used there but not in vanilla levels. The list of potential suspects is rather big anyway.

Two other people have confirmed the problem so far, so it's not just me.


Edit: tests.
First test: commenting out the acsscript property in EMAPINFO to turn off all ACS scripts. Negative result, it still freezes.
Second test: renaming EDFROOT to disable all custom EDF stuff. Negative result, it still freezes.

The entire save code was rewritten as part of the C++ transition so I'm not surprised that I would have made at least one mistake that flew under the radar til now. Doh >_<

EDIT: Do you think you could do one of your SVN builds of r1507 or later? We'd like to rule out that this isn't a result of the optimizer, since essel says he never saw a problem while testing. But, he did all his testing on your SVN builds and not mine.

Test 3: Used a freshly compiled build (r1509). Negative result, still freezes. :(

Does it use the ML_BLOCKALL flag? Oh, I guess it's not very important anyway just for testing savegames. I'll try with an older revision, such as r1490.

Edit: test 4 with r1490 freezes too.

It does use the BLOCKALL flag, yes.

r1510 now committed, fixes this problem.

Yes, works for me now. :)

gez, do your builds take advantage of the SSE2 optimizations?

Csonicgo said:

gez, do your builds take advantage of the SSE2 optimizations?

I don't believe so, but 3.40.11 Plus does, and contains the savegame fix.

esselfortium said:

I don't believe so, but 3.40.11 Plus does, and contains the savegame fix.

The project he sent me earlier was not configured for them, and neither is the official Eternity VC2005 build. Chief reason why? That build is intended to be compatible with 98 and ME and few if any machines that run those are going to have SSE2 opcodes.

I think ZDoom has some code to detect at run time if SSE2 is available or not and choose the appropriate functions accordingly. Something like this may be worth adding to the TODO list, though with a low priority.

Gez said:

I think ZDoom has some code to detect at run time if SSE2 is available or not and choose the appropriate functions accordingly. Something like this may be worth adding to the TODO list, though with a low priority.

Right except in ZDoom's case they're using SSE2 in selected routines. By enabling the SSE2 codegen implicitly in Visual Studio, it uses it throughout the program, anywhere the compiler decides it'll be the best way to execute some given code.

I would assume there's probably a flag set in the PE header to just stop the program dead in its tracks if the processor is too old, though I'm not going to volunteer trying this, as I understand programs that *don't* check for it can hard-crash older Pentiums as they misinterpret some of the SSE opcodes as having other meanings entirely.