a demo desync that i don't quite understand

[noshutdown]

the demo in question is:
http://doomedsda.us/lmps/586/1/h232x747.zip
pwad is hell revealed 2

doomedsda says that its recorded with prboom. i don't know which compatibility level its recorded with, but it played correctly with vanilla doom2.exe, so i assume that this demo is vanilla compatible.

the problem is, when i tested playing it with boom, it went desync and the player died. does this mean that boom is not fully demo-compatible with vanilla doom?

[Ancalagon]

just so you have a quick answer until those guys that know all about how doom is programmed connect, boom sounds like prboom's complevel 9, when vanilla is complevel 2, they change a lot of stuff in the game making them uncompatible.
Hope I am at least 50% right

[noshutdown]

Ancalagon said:

just so you have a quick answer until those guys that know all about how doom is programmed connect, boom sounds like prboom's complevel 9, when vanilla is complevel 2, they change a lot of stuff in the game making them uncompatible.
Hope I am at least 50% right

hello
i know about the existence of prboom's complevels, but i reckon that complevel9 is mainly for boom's added features over vanilla doom. when i tried to load a boom-demanding wad with complevel2, it doesn't play right.
when loading a vanilla wad with boom, i expected it to behavior close to vanilla doom... but i may be wrong.

[Linguica]

Boom fixes / changes various things in the Doom engine that will desync demos. Did you try playing the demo in Boom with the right complevel specified?

[noshutdown]

Linguica said:

Boom fixes / changes various things in the Doom engine that will desync demos. Did you try playing the demo in Boom with the right complevel specified?

only prboom has the complevels.
according to the boom documents, as far as i knew there is only an "original_doom_compatibility" option in the cfg file, which claimed to provide better accuracy of vanilla doom behavior. and as i remember the demo still went desync the same way, the player died at same place.

[Never_Again]

noshutdown said:

does this mean that boom is not fully demo-compatible with vanilla doom?

That's correct. Chocolate Doom and even Eternity have better vanilla demo support than Boom.

HR2 MAP32 is well-known for causing intercepts overflows, BTW, but this doesn't seem to be the culprit here. As MBF also desyncs on h232x747, it must be caused by something neither engine addressed. If I had to guess, I would say it's probably tm* global vars or comp_moveblock.

[Sp00kyFox]

cannot really reproduce the problem here. I used the latest test version of prboom+ from the changelog site:
http://prboom-plus.sourceforge.net/history.html

and this commandline:

prboom-plus.exe -iwad DOOM2.WAD -file hr2final.wad -timedemo h232x747.lmp

went just fine.

[Never_Again]

You can't reproduce it because the problem discussed here has nothing to do with Prboom-plus.

[Sp00kyFox]

yeah, my bad. as soon as I read "boom" my brain just adds 'pr' and 'plus'.

[scifista42]

noshutdown said:

when i tried to load a boom-demanding wad with complevel2, it doesn't play right.

That's right. The same will happen when you try to load a vanilla-compatible demo with -complevel 9. Automatic detection of complevel sometimes fails. Run your HR2 demo with -complevel 2 and see if it helps. The demo in question might have been recorded with -complevel 2, in that case it's vanilla compatible.

[Never_Again]

Hmmm, it never occurred to me to try to play back a vanilla-format demo with "-complevel 9", and it turns out that Prboom-plus allows it (with predictable results). It would never attempt it on its own, however, because there is no practical situation where a vanilla-format demo would require a non-vanilla complevel (except the hypothetical "-complevel 7" demos that I don't remember ever seeing outside my own tests).

Automatic detection of complevel does fail in a small number of cases, but that only happens with vanilla-format demos of unusual origin, like Doom95 demos of D2 or Final Doom. There's no such ambiguity about h232x747, its TXT file states clearly: "-complevel 2". And the OP already mentioned it plays back correctly in DOOM2.EXE.

Anyway, this is all irrelevant, there are no complevels in Boom. Whether Prb+' complevel detection fails or not on some demos is not going to help BOOM.EXE play back this one correctly.

[dew]

scifista42 said:

That's right. The same will happen when you try to load a vanilla-compatible demo with -complevel 9. Automatic detection of complevel sometimes fails. Run your HR2 demo with -complevel 2 and see if it helps. The demo in question might have been recorded with -complevel 2, in that case it's vanilla compatible.

I love how Boom and prboom get interchanged so liberally that no one even knows what the others are talking about anymore, haha.

Of course Boom-compatible wads cannot be played with complevel 2 in prboom, the Boom-specific features will be ignored, including critically important linedefs required to progress in the map.

Of course vanilla demos will possibly desync in native Boom, it doesn't emulate vanilla errors it fixed well enough.

Of course vanilla demos will desync in the same manner in prboom-plus if you force an incorrect complevel on them.

And finally, there's absolutely no way prboom-plus automatic detection could've failed on that particular demo. It has a vanilla header AND a footer specifying complevel 2.

[GoneAway]

I note just for completeness that even prboom+ will desync for some vanilla demos, even with the right complevel. I'm not sure exactly what the cause is. One demo from last year's Reverie pack comes to mind (plays back in doom2.exe, but not in prboom+ -cl2).

[noshutdown]

Never_Again said:

That's correct. Chocolate Doom and even Eternity have better vanilla demo support than Boom.

HR2 MAP32 is well-known for causing intercepts overflows, BTW, but this doesn't seem to be the culprit here. As MBF also desyncs on h232x747, it must be caused by something neither engine addressed. If I had to guess, I would say it's probably tm* global vars or comp_moveblock.

thanks man, at least i can now confirm that boom is not too compatible with vanilla demos. looks the only choice to watch demos(both vanilla and boom wads) in dos is eternity.

[noshutdown]

kraflab said:

I note just for completeness that even prboom+ will desync for some vanilla demos, even with the right complevel. I'm not sure exactly what the cause is. One demo from last year's Reverie pack comes to mind (plays back in doom2.exe, but not in prboom+ -cl2).

maybe andrey will find out why and fix it if you report the matter to him.

[Never_Again]

He did it in September. It must be a really obscure bug to have escaped detection this long.