Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Danfun64

Assorted Demo Questions (once "doom-plus demo recording limits and crispy doom")

Recommended Posts

I have a question. I know that doom-plus raises limits, but what about demo limits? Crispy-Doom disables those limits, and I would like to record a multiplayer demo of a limit-removing map. The most compatible ways to do it are doom-plus and crispy doom. However, if Doom-plus has demo limits where crispy doom has none, and one records a demo in crispy doom, would such a demo be unplayable in doom-plus if it's too long?

TL:DR Does Doom-Plus have demo limits? Is it possible to record a demo in Crispy Doom that can't play in Doom-Plus

Share this post


Link to post

http://prboom-plus.sourceforge.net/doom-plus.features.html

I think you still need to use the -maxdemo parameter for recording.

There's no need for it on playback of large demos. It's not that the engine can't handle larger demos; it was put there so that people wouldn't accidentally run out of hard disk space. I don't what what happens with insanely long demos (e.g. days, months or years), but assuming you're not looking to test it to out-of-memory dstruction, there shouldn't be a problem.

Also: http://www.doomworld.com/vb/showthread.php?s=&postid=190684#post190684

Share this post


Link to post

A couple more questions.

If a demo uses a vanilla compatible map using vanilla compatible settings, can a crispy doom demo be played in chocolate doom?

Also, does Boom have the "desync when accessing menu" bug?

Share this post


Link to post
Grazza said:

I don't what what happens with insanely long demos (e.g. days, months or years), but assuming you're not looking to test it to out-of-memory dstruction, there shouldn't be a problem.

I seem to recall BaronOfStuff saying that in vanilla Doom, demos that ran on for as little as hours would eventually cause the game to crash with an obscure error message. We used Boom during a our little DosBox netplay get together, and that solved the problem.

Danfun64 said:

Also, does Boom have the "desync when accessing menu" bug?

I'm fairly certain it does. I think PrBoom-Plus is the only port that fixed that behavior when dealing with vanilla / Boom style recordings.

Speaking of which, has Fabian ever released a detailed set of specs on how CrispyDoom demos work? I've wanted to use it several times myself for demo recordings, but wasn't sure if it used a specific CrispyDoom format or something PrBoom-Plus could read.

Share this post


Link to post

Crispy Doom records demos in exact the same way as Chocolate Doom. It is just that the arbitrary demo size limit is disabled by default, but you can achieve the same in Choco by disabling it in the setup tool.

If you enter the menu while recording a demo in Crispy, the game will pause -- and it will unpause again as soon as you leave the menu. Thus, demos will not desync anymore. Of course this is less elegant than the separate ticrate counter that Boom and derived ports use, but it is also a much less intrusive code change.

TL/DR: I don't think it is possible to record a demo in Crispy that fails to play (or desyncs) in PrBoom+ or even Chocolate Doom. If it ever does, that would be against Crispy's design goal and would be considered a severe bug that I'd ask you to report.

Share this post


Link to post

I believe vanilla Doom stored the demo in memory during recording, and wrote the file at the end, hence the limit. In a typical DOS Doom setup, there was no hard drive cache (SMARTDRV.EXE) unless you had tons of memory (16Mb :) Vanilla Doom in DOS would stutter if it were to write to a file during the game. You may remember the short delay while saving a game.

Newer ports (on newer computers) can write directly to a file, and take advantage of the write caching in the OS, and in the HDD circuitry.

Share this post


Link to post

One more question. I noted mbf-fixes on the smmu homepage. Can demos in mbf be played in mbf-fixes, or vice versa? What about both demo types on prboom-plus?

Share this post


Link to post

I don't think that any of the fixes in mbf-fixes affect demo compatibility. That is, unless you push the "use" button in front of a three-keyed door. ;)

But I doubt that you will get it to compile on anything else than a DOS box with a Borland compiler and Allegro headers installed, anyway.

There is an MBF compatibility level (-complevel 11) in PrBoom+ but I don't know how faithful that is.

Share this post


Link to post

Borland? I was under the impression that I had to compile with DJGPP. Yes, I knew about -complevel 11, but I didn't know how it handled demos from the latest official version of mbf compared to mbf-fixes.

Share this post


Link to post

Maybe DJGPP works as well. What I wanted to say was that I found it absurd enough to compile source code for DOS at all, but you really seem to be going to do that.

That said, apart from the three-keyed door fix, I don't see anything in the changes introduced by mbf-fixes that should affect demo compatibility.

Share this post


Link to post
fabian said:

There is an MBF compatibility level (-complevel 11) in PrBoom+ but I don't know how faithful that is.

Like all Prboom+ complevels, intended to be completely faithful to the exe it is emulating. All demos at DSDA and Compet-n (and others) were tested, and any desyncs investigated and fixed where possible.

I recall that several years ago, the last known demo incompatibility with MBF (there had been several, dating back to Prboom-not-plus) was fixed.

That said, the number of MBF demos, especially on wads that make extensive use of MBF features) is somewhat limited, so it is possible that there are some unknown incompatibilities. If you find any, report them as bugs.

Share this post


Link to post

I think it's worth noting that the latest "stable" release (2.5.1.3) has some serious dehacked incompatibilities. The beta emulation codepointers are not supported, and the state table is wrong. These problems were fixed in development versions.

Share this post


Link to post

@Grazza: That's good to know, thank you!

@Danfun64: You may want to have a look at WinMBF which -- despite its name -- also compiles on Linux (and on Windows with MingW) with a little patching.

Share this post


Link to post

Honestly, if someone provided boom with the demo menu sync bug fixed (probably the same way as crispy doom, by possing the gamme while in menu), I would rather use that instead.

I heard of winmbf. Can you provide those patches? How is the netcode? Can it be compiled into other architextures? Most importantly, is the 3 key door bug fixed there or not?

Nobody has answered my question on how prboom-plus handles the 3 key door bug for mbf demos. I am using prboom-plus trunk btw.

Share this post


Link to post
Danfun64 said:

Honestly, if someone provided boom with the demo menu sync bug fixed (probably the same way as crispy doom, by possing the gamme while in menu), I would rather use that instead.


You should really use PrBoom+ for recording demos, it is really the most advanced (and tested) port for this purpose.

I heard of winmbf. Can you provide those patches? How is the netcode? Can it be compiled into other architextures? Most importantly, is the 3 key door bug fixed there or not?


Please find my patch set here:
http://anonscm.debian.org/cgit/pkg-games/winmbf.git/tree/debian/patches

The patch file names are pretty self-explanatory. You will not want to apply all of them, especially the 64-bit patch is still really hackish.

I have no idea about the net code, never inspected that part of the port.

Yes, it can be compiled on other architextures, but is currently limited to 32-bit environments. I have tested it myself on Linux and Windows with MinGW.

No, it does not have the 3-key-doors bug fixed (but there is a patch for it in the repo I just posted). WinMBF is simply a port of MBF to SDL, so it can run in a window on supported OS. Everything else is left untouched. You can think about it as Chocolate MBF.

Nobody has answered my question on how prboom-plus handles the 3 key door bug for mbf demos. I am using prboom-plus trunk btw.


It is considered, please see p_spec.c:P_CanUnlockGenDoor()

[...]
      if
      (
        skulliscard &&
        (
          (!player->cards[it_redcard] &&
            !player->cards[it_redskull]) ||
          (!player->cards[it_bluecard] &&
            !player->cards[it_blueskull]) ||
          // e6y
          // Compatibility with buggy MBF behavior when 3-key door works with only 2 keys
          // There is no more desync on 10sector.wad\ts27-137.lmp
          // http://www.doomworld.com/tas/ts27-137.zip
          (!player->cards[it_yellowcard] &&
            (compatibility_level == mbf_compatibility && 
             !prboom_comp[PC_FORCE_CORRECT_CODE_FOR_3_KEYS_DOORS_IN_MBF].state ? 
             player->cards[it_yellowskull] :
             !player->cards[it_yellowskull]))
        )
      )
[...]

Share this post


Link to post
Danfun64 said:

Nobody has answered my question on how prboom-plus handles the 3 key door bug for mbf demos. I am using prboom-plus trunk btw.

My post did kind of answer. It handles it in the same way as MBF (just the two keys needed); otherwise it would be a compatibility bug.

You should always use the latest "test" version, for any purpose. The cautious manner in which Prboom+ is developed means that terms like "stable" and "experimental" are quite inappropriate; the current version is almost always going to be the better option. During the period when I was actively involved in this port's development (c. 5 years), I recall just one 24-hour period where there was a serious problem with the "test" version before it was fixed. Most problems actually came when code from regular Prboom was incorporated; there was more likely to be a bug in a "release" than in a "test" version.

Share this post


Link to post

Multiplayer demos. I want to record multiplayer demos with boom maps but without the menu desync bug. Prboom-plus is horrible for multiplayer, and regular prboom seems just as difficult.

So prboom-plus follows official mbf behavior. Does that mean demos recorded from versions of mbf-fixes that have the door bug patched desync on prboom-plus?

Share this post


Link to post

Grazza: Actually, the latest pr+ seems to be crashing quite a bit. :/ I updated my year (or so) old test version because of the improved precision in rendering nearly vertical lines and I started encountering very unceremonious crashes to desktop. Next time it happens I need to check stderr, if the crash even generates one. It most certainly doesn't end a demo properly.

Share this post


Link to post
Danfun64 said:

Does that mean demos recorded from versions of mbf-fixes that have the door bug patched desync on prboom-plus?

Not ad hoc, only if the bug is exposed, i.e. if a three-keyed door is attempted to open with the critical keys picked up.

Share this post


Link to post

so when prboom-plus is in mbf mode, it always assumes that this bug is in affect? Is there a way for prboom-plus to differentiate between mbf demos and fixed mbf demos?

Share this post


Link to post
dew said:

Grazza: Actually, the latest pr+ seems to be crashing quite a bit. :/ I updated my year (or so) old test version because of the improved precision in rendering nearly vertical lines and I started encountering very unceremonious crashes to desktop. Next time it happens I need to check stderr, if the crash even generates one. It most certainly doesn't end a demo properly.


I've had the same issue just to confirm it isn't just you. The crash as I approached the exit on one demo was the final straw that led me to revert to 2.5.1.3 :V

Share this post


Link to post
Danfun64 said:

so when prboom-plus is in mbf mode, it always assumes that this bug is in affect?

Yes, it emulates MBF's behaviour.

Danfun64 said:

Is there a way for prboom-plus to differentiate between mbf demos and fixed mbf demos?

There's the "-force_correct_code_for_3_keys_doors_in_mbf" command line switch.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×