Extremely weird demo desync.

[Archy]

Hello Doomworld, I'm going to tell you a little about my self today. When ever I make a YouTube video of one of my demos, I always make a batch file like this:

ren NR01-434.LMP demo1.lmp
doom2 -file nerve.wad nervemus.wad demo2.lmp demo1.lmp -config dpp.cfg
ren demo1.lmp NR01-434.LMP

This is so the title screen displays before the demo plays and makes the video look like this as opposed to this .

demo2.lmp is deigned to crash doom2.exe so Fraps stops recording as soon as the demo ends. demo2.lmp has codes similar to this:

gadfskjlhgadsklhad54654165465skudfsladskjl

But when I wanted to make a video of KF05-412.LMP using the same method, the demo desynced and this has never happened to me before. Here's my batch code:

ren KF05-412.LMP demo1.lmp
doom2 -file ksutra.wad demo2.lmp demo1.lmp -config dpp.cfg
ren demo1.lmp KF05-412.LMP

This code however doesn't desync the demo:

doom2 -file ksutra.wad -playdemo KF05-412 -config dpp.cfg

After playing around a bit, I found that a good portion of demos with the -FAST Parameter desync with my method of starting the title screen before demo playback. I theorized that it was because of the "strange" parameter and quickly tried other "weird parameter demos" such as Green Herring's M226R545.LMP demo which features the -RESPAWN Parameter and it indeed desynced.

I then tried this same method with source ports. First PrBoom-Plus-2.5.0.4 which was a complete fail because it didn't except *.lmp files after the -FILE parameter. Chocolate-Doom-1.60 however desynced the demos in the same way Vanilla Doom2 v1.9 did.

Any ides how this glitch happens? It doesn't affect all -FAST and all -RESPAWN demons but the ones it affects it always affects in the same way. Know any way to get around this glitch? How well has this glitch been documented because I've never heard of it.

Thanks good people of Doomworld.

[Ryback]

I have no idea, but it sounds like an interesting bug. The only issue I'm aware of with demos that desync when played back from the title screen involve revenant missiles. Something in the missile behaviour code checks against the internal timer, and this is different when played back from the command line versus played back in the demo1-demo2-demo3 loop. Doesn't sound like something that would be responsible for a -fast demo not playing back though.

[Archy]

Ryback said:

I have no idea, but it sounds like an interesting bug. The only issue I'm aware of with demos that desync when played back from the title screen involve revenant missiles. Something in the missile behaviour code checks against the internal timer, and this is different when played back from the command line versus played back in the demo1-demo2-demo3 loop. Doesn't sound like something that would be responsible for a -fast demo not playing back though.

It's interesting that you say that because all the -FAST and -RESPAWN demons desynced when a revenant got involved. I'll try to find a non -FAST/-RESPAWN demo with lot's of revenants in it to test this out. Map 27 of Doom 2 sounds like a good map to test this. I'm to tired to test it now but I'll try tomorrow or the day after. Thanks for the info and it explains allot.

[zokum]

Sorry of necrobumping, I was looking for some info about such a desync on my own project, and figured things out. Demos with revenant missiles can desync because the type of missile, homing or not, depends on how long doom has been running. A demo can play back fine if you use -file map.wad -playdemo demo1 but not if you just let it start on its own.

[scifista42]

Relevant doomwiki page (this has been a known issue for a while): https://doomwiki.org/wiki/Revenant_tracers_desync_internal_demos