Fast mode saving crash in vanilla?

Okay, the other similarly titled thread reminded me to post this.

Has any of you noticed how by playing vanilla Doom (unverified with ports like Boom) on -fast, if you save the game, then reload it later, it sets up a "bomb" that will lock up / crash the game moments later? It pretty much happened to me unerringly, both in vanilla Doom, DOSBoxed Doom and Doom95. It stands out because Doom otherwise is very stable.

There isn't a problem with saving/loading in Nightmare, and I don't think it happens in -respawn either...

Doesn't happen here. Tested with the v1.9 execs in Ultimate DOOM on E1M1 and in DOOM2 on MAP01, with -nosound under the XP and with sound in Dosbox. Played for a bit, saved, played some more, loaded the save game, played for another minute - no crash.

What kind of crash do you get?

Might need a projectile in flight. Maybe with some game changing position like a fireball about to kill a zombie.

Never_Again said:

What kind of crash do you get?

It's not exactly a quit to a garbled command prompt, as you'd get with badly made Dehacked files. It's a lock-up, and if a sound is playing, it starts looping like a vinyl.

Could use some further testing on my other computers if it only happened to me. But I remember it happened often enough to make me avoid it.

Sounds like a variant of the venetian blind crash, I used to get a lot of those on Final Doom MAP30 of TNT for some reason. I'd hear an object respawning sound nearby (in single player, no less) and soon after it would crash in a locked-up venetian blinds crash. Was looooong ago on a real 486 DX/50 running real DOS though, dunno if you can replicate this behavior with any emulator.

I can remember one particular instance of that very well, because it manifested itself in the final battle of TNT MAP30: I dropped down into one of the alcoves down the lava/blood under the Icon of Sin, saved, and soon after I got this weird sound I had never heard before (and which years later I understood to be the MP item respawn sound), and soon after the game crashed. Resetting the PC and reloading only resulted in more of the same scant seconds later.

Did you quit the game before reloading? If so, that's not possible with -fast in vanilla, you have to play it through in one sitting. (you can save/reload as many times as you like as long as you don't quit)

Zero-duration frames of pinkies are cause of this. Here is ddetail explanation (in russian) by entryway:
http://arc.iddqd.ru/04082009/viewtopic.php?p=29791&sid=882eee79041b12b0c1b33ae780335f5f#29791

Huh? I admit that the last time it happened, I was playing 2002ADO, probably with Doom+, and it locked up after I reloaded at E1M1's exit, went to E1M2, and shot one of the pinkies near the start.

Still, I didn't experience it at all on Nightmare. I was saving a lot through nightmare when I was going through Episode 1 of Doom, there were numerous occasions...

Hitherto said:

Zero-duration frames of pinkies are cause of this. Here is ddetail explanation (in russian) by entryway:
http://arc.iddqd.ru/04082009/viewtopic.php?p=29791&sid=882eee79041b12b0c1b33ae780335f5f#29791

For the lulz, Google translation:

I looked sortsy. In the boom is a fix for this business. Infinite loop is obtained in the vanilla in the animation at a bull fast in some frames, under certain conditions.

Here's the thing, if I understood everything

Vanilla, when you start with mapy nyugeym, setting a fast reset before loading the level, but if you specify from komstroki fast, it works the other code and fast is not reset.

With fast startup mapy to steer the initial number of ticks in all its steyt shifted by 1 bit to the right, in other words, is divided into two, that he was moving faster.

What happens here? You have to fast komstroki hence the duration of all steyt a bull is shared by two. For some, it (the length) was equal to 1 as was previously 2. After loada as doom is sure that the current state duration steyt original, makes a shift, which actually is another, but not the first one turns to 0.

Until Bychek does not go into zeroed steyt - doom does not fall, although Bychek runs faster than conventional naytmarovskogo run. Just get into the State with zero duration - just an endless cycle, and as a consequence of the frieze.

Nullable eventually steyt (2 initialization) - this steyt walk and Staten pain. If you boot from your saves and without fire gobies Will you come to the front, that he saw you and immediately began to bite, the fall will not, so how to get it after this walk, and do not bite - it must still try. If the shoot, that he before pounce even as it went thinking that he was taking (state A_Chase) - once a frieze.

In your second example, the Frisians are not seen as a square room and make a bull chase hard. If you really want, you can dial idclip, go beyond the level and shoot.

So it's all the fault of the people from Groningen. :p

Or in other words, when setting Nightmare, tics are >>= 1, which divides the frame duration in half.

However, in C, 1 >> 1 == 0, so if this is done twice in a row, the frame durations become 0 tics, and this causes a state cycle through the Demon's frames whereby it can walk infinitely many times in a single gametic.

This problem is also fixed in all BOOM-descendent ports, twice over: first, they don't apply skill setting changes twice in a row inappropriately. Second, they won't set the tics to 0 anyway, even if it could be done somehow (ie through DeHackEd editing).

So Doom's mistake is that it cumulates the -fast speed changes between game reloads? And Nightmare is prevented from this?

Printz: That's about it.

I've done some testing with this on Chocolate-Doom, and here's what I've found.

Let's say you have a game saved in Nightmare. You load said game, and then you start a new game that isn't in Nightmare. The demons will actually be slower than usual. This is because when the game loads a save that was under the Nightmare skill, it forgets to speed the demons up. But when you start a new game, it knows that it's going from fast -> not fast, so it remembers to slow them down, even though they were never fast in the first place. You can do this as many times as you want to make the demons hilariously slow.


The freeze described here is the same thing, but in reverse. You start a game in Nightmare, the demons speed up. You load a game that isn't saved in Nightmare, the demons are still sped up. You start a new game under Nightmare, the demons speed up again. This, due to integer underflow, actually makes the duration of the Demon's chase state 0, causing a freeze as soon as you alert it. What I don't understand is why the demon, going everywhere around the level in literally 0 seconds, can't bite you to death and end the freeze when all monsters go back into their "walking in place" state.

Wagi said:

What I don't understand is why the demon, going everywhere around the level in literally 0 seconds, can't bite you to death and end the freeze when all monsters go back into their "walking in place" state.

A_Chase only imparts momentum to a monster to "step" it along. Since P_SetMobjState's infinite recursion never returns to P_MobjThinker, the thing never runs another tic and therefore has any chance to be moved by the code in P_MobjThinker which moves objects (P_XYMovement), which is actually called *before* an object undertakes state transitions. So the demon sits there spinning accumulating infinite momentum. Because it has no missile attack, it never breaks out of the walking loop - unless of course you spawned within melee range of it, in which case it might get off one bite and THEN enter a potentially infinite loop, or possibly be able to bite you to death in a single gametic.