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

Chocolate Doom

Recommended Posts

4 hours ago, kb1 said:

I'm kinda skeptical, because if Chocolate is missing movement commands that vanilla doesn't miss, this should affect Chocolate's playback of vanilla demos, shouldn't it? What I mean is that this should have been noticed a long time ago, while testing the playback of demos. I guess maybe the tic counter is corrected right before demo playback begins.

The "problem" is basically just that you can queue up input events while the game loads (eg, the text loading screen), that get sent immediately when the game starts. Modern OSes and Chocolate Doom don't really have a way to replicate this, though there are suggestions of adding an artificial delay to starting up Chocolate to emulate it a bit.

 

Demo compatibility is unaffected. Any input events recorded in the first tics of a demo get properly replicated on playback in Chocolate Doom.

Share this post


Link to post

Since Doom has the melting screen effect, it seems like you ought to be able to queue up a command while the melt is happening and instantly apply it on tic 0. I know that in vanilla Doom the melt effect is basically its own loop that nothing else in the engine (including player input) interacts with, but couldn't Chocolate Doom change that and watch for input during the melt?

 

edit: I suppose I am discounting that tic 0 has to be completed before the melt even begins because otherwise the game will have no idea what it is supposed to be drawing. Perhaps when you use the -record feature the engine should start with a special tic -1 that draws the initial setup of the map for the melt effect, but doesn't actually run any thinkers or player input or begin the gamesim until the melt finishes. This would ever so slightly change the vanilla behavior but would allow for a consistent experience across all operating systems Chocolate Doom can run on.

Share this post


Link to post
19 hours ago, chungy said:

The "problem" is basically just that you can queue up input events while the game loads (eg, the text loading screen), that get sent immediately when the game starts. Modern OSes and Chocolate Doom don't really have a way to replicate this, though there are suggestions of adding an artificial delay to starting up Chocolate to emulate it a bit.

 

Demo compatibility is unaffected. Any input events recorded in the first tics of a demo get properly replicated on playback in Chocolate Doom.

The theory is that if an engine can queue up inputs, and apply them in tics, surely it can store them in the demo. Reading demo bytes is roughly equivalent to reading inputs - these actions should occur at roughly the same point in time, during execution.

 

Stated differently, there are X chances for input, before the 3D screen is visible. Let's call this InputCmdCount. So, if a given engine can queue up InputCmdCount number of cmds before showing the 3D view, a demo recording should also be able to store X cmds, before the 3D screen is visible. Let's call that SaveDemoCmdCount. Likewise, in demo playback, X number of cmds should be able to be applied, before the 3D screen is visible. Let's call that LoadDemoCmdCount.

 

My theory is that, if working properly, InputCmdCount = SaveDemoCmdCount = LoadDemoCmdCount.

 

So, I think the first step is to be able to determine if this statement is true:

  InputCmdCount = SaveDemoCmdCount = LoadDemoCmdCount.

 

Next, we should determine if

  Vanilla.InputCmdCount = Chocolate.InputCmdCount,

  Vanilla.SaveDemoCmdCount = Chocolate.SaveDemoCmdCount, and

  Vanilla.LoadDemoCmdCount = Chocolate.LoadDemoCmdCount.

 

Finally, all 6 should match.

 

At this stage, from the reported bug above, I cannot claim to know which of the statements I list are not true. Isn't this what we're talking about? And, because it's difficult to debug vanilla, it seems to me that using and verifying demos is a decent way to get tic-level, input command debug information out of the vanilla engine, in a format that can be directly compared to Chocolate. Have I missed something?

 

 

11 hours ago, Linguica said:

Since Doom has the melting screen effect, it seems like you ought to be able to queue up a command while the melt is happening and instantly apply it on tic 0. I know that in vanilla Doom the melt effect is basically its own loop that nothing else in the engine (including player input) interacts with, but couldn't Chocolate Doom change that and watch for input during the melt?

 

edit: I suppose I am discounting that tic 0 has to be completed before the melt even begins because otherwise the game will have no idea what it is supposed to be drawing. Perhaps when you use the -record feature the engine should start with a special tic -1 that draws the initial setup of the map for the melt effect, but doesn't actually run any thinkers or player input or begin the gamesim until the melt finishes. This would ever so slightly change the vanilla behavior but would allow for a consistent experience across all operating systems Chocolate Doom can run on.

Yes, the -1 trick might be a way to go. But I'm left with wondering: How does vanilla get away with not needing it, as it's calling the same high-level functions to poll for input, write tic cmds, etc. Sure, the low-level mechanisms for actually gathering the input are different, but the rest of the engine is not supposed to care about that.

 

After studying the initial release, and then all the various ports, the D_DoomLoop function is slightly different in all of them. A lot of silly little bugs get squashed by rewriting some of the goofy global state management flags in and around this function (dont_fuck_with_me, not_to_be_fucked_with, etc.). For example, in my port, I run an extra render loop at the *end* of a level, so you can see the exit switch change state before the level completed screen appears. I also added the second counter that allows the use of the Pause button during demos, without desync.

 

In other words, it seems that there are good reasons to monkey around with the order of steps in that function, and the state management features within and around that function. This seems to be a necessary thing to do in most source ports, so it follows that this function could be a likely culprit for what looks like an "off-by-one" situation, which seems to be what we are dealing with here. (Whew! I hope that made sense.)

 

My only point is that we want Chocolate to do exactly what vanilla does, for normal play, for demos, and for net games. To do that, we need to know:

  • How many tics does vanilla apply, before showing the 3D view?
  • How many tics does Chocolate apply, before showing the 3D view?
  • Why doesn't this issue appear when playing a demo recorded in one engine, and played back in another?

or, more simply:

  • How, exactly, do we know that Chocolate's current behavior is wrong? (I need to re-read those posts, to understand exactly how this evidence was derived. I cannot claim to yet have much experience disassembling demo files).

If someone has some luck creating a fix, please post your results here. I'm very interested to know more. Thanks.

 

 

Share this post


Link to post

Of course it does not affect the playback. The only issue is INSERTING the key presses, not reading them. Chocolate Doom does not miss any frames.

 

Frame tic counter does NOT run during a wipe screen. The game runs for 1-8 frames BEFORE the wipe screen effect, those 8 frames are the quick start frames. Anything after the wipe screen effect is normal game play, and not part of the quick start.

 

In the early days of speedrunning, people did not know about quick start (or it wasnt common knowledge), hence they consistently lost 8 frames before their attempts even really began.

Edited by Looper

Share this post


Link to post
On 12/5/2018 at 8:47 AM, chungy said:

The "problem" is basically just that you can queue up input events while the game loads (eg, the text loading screen), that get sent immediately when the game starts. Modern OSes and Chocolate Doom don't really have a way to replicate this, though there are suggestions of adding an artificial delay to starting up Chocolate to emulate it a bit.

 

Demo compatibility is unaffected. Any input events recorded in the first tics of a demo get properly replicated on playback in Chocolate Doom.

This shouldn't be a problem. Just start up whatever registers keypresses and mouse movement as soon as the game starts, and let the player have all of the rest of the loading to "quickstart" some movement. A minimum load sequence of say 2 seconds would be nice as the load process would probably become pretty instant on a modern system, making it hard to get the key presses done in time for the gameplay start.

Extremely fast starts is probably a problem with vanilla Doom as well, but you could always mitigate this with stupid solutions like putting the game on a slow network drive or a slow usb stick and have cache turned off etc.

Share this post


Link to post
23 hours ago, Looper said:

Of course it does not affect the playback. The only issue is INSERTING the key presses, not reading them. Chocolate Doom does not miss any frames.

 

Frame tic counter does NOT run during a wipe screen. The game runs for 1-8 frames BEFORE the wipe screen effect, those 8 frames are the quick start frames. Anything after the wipe screen effect is normal game play, and not part of the quick start.

 

In the early days of speedrunning, people did not know about quick start (or it wasnt common knowledge), hence they consistently lost 8 frames before their attempts even really began.

You know, DOS (and Windows) would queue up and repeat keypresses that were held down for a small length of time. Maybe it's that simple: Maybe in the DOs days, with slower computers, DOS could queue up more keypresses before the game gets to the screen wipe, but on faster computers, there's just not enough keypresses in the buffer for the game to fetch, before the screen wipe.

 

If that's true, maybe Chocolate could detect a key being held down, and fill the 8 tics with it, as if the buffer was full of that keypress. Man, I really need to research this - what an interesting issue!

 

What do you all think? Could it be that simple?

Share this post


Link to post
31 minutes ago, kb1 said:

If that's true, maybe Chocolate could detect a key being held down, and fill the 8 tics with it, as if the buffer was full of that keypress. Man, I really need to research this - what an interesting issue!

 

You have to remember that during the loading, it stacks all the mouse movement into the very first frame (meaning the turn commands, not sure about vertical mouse movement), so that part shouldnt be repeated.

 

Also, the quick start duration varies between ports. In Vanilla, it seems to be 8 frames. In DOSBox + Vanilla, it was 6 frames (and it actually stacked the mouse movements to the 1st and 7th frame). In Chocolate Doom it is 7-8 frames. In PrBoom+ 9 frames (dunno which version).

Share this post


Link to post

If DOSBox + Vanilla behavior is different than pure vanilla behavior, that almost has to be due to a timing difference, and it means that there is no reliable way to get the two to match. I would bet that you'd get different results with vanilla on a 486 vs. vanilla on a much faster CPU as well. There's a tiny chance that the difference is due to a difference in a native mouse driver, vs. the speed at which DOSBox polls Window's mouse and forwards the info into a pseudo DOS interrupt.

 

What I mean is, the whole purpose of DOSBox is to emulate DOS as best as possible. If you can't even get Doom in DOSBox to match Doom in DOS, what chance is there for a source port? You might get the source port to match vanilla running on a certain CPU, but not in every case.

 

So if you cannot get a source port to match vanilla, you'd probably be better off getting the source port to, at least, work the most favorable way. So, what do the speed runners want, exactly?

Share this post


Link to post
6 hours ago, kb1 said:

So if you cannot get a source port to match vanilla, you'd probably be better off getting the source port to, at least, work the most favorable way. So, what do the speed runners want, exactly?

I dont know what other speedrunners think, but I only want the quick start to be identical with Vanilla. Identical meaning that the keypresses inserted at the start of the level shouldn't be missed from the first two frames, and the mouse movements should be buffered into the first frame. Chocolate Doom is already emulating the quick start the way I just described it, almost Vanilla, except for the first two frames for the keyboard. In rare cases, it actually works 100% identical. It is not an issue if the quick start lasts for 9 frames instead of Vanilla's 8, assuming those numbers are even constants. Only missing keypresses is the issue.

Share this post


Link to post

And to add what I actually do to perform the quick start:

1. I run the shortcut with the parameters, for example -warp 13 -skill 4 -nomonsters -nomusic- record attempt.lmp

2. I wait for the screen to go black.

3. I hold down the forward key. This will insert "MF50" commands for the first 8-9 frames. Also the mouse turning is buffered during this black screen into the first frame.

4. Once I see the wipescreen effect, I release the key because once the wipe screen effect is over, the game thinks no key is being held down.

5. I press the forward key down again before the wipescreen effect is over. If one does this, the game thinks the key is being held down, and will immediately move after the effect.

 

The problem is at step 3. You can not give two keyboard commands reliably for the game for the first two frames. And before you think this also happens during gameplay, it is not the case. I am able to press forward and strafe key down in the same frame 99 out of 100 times. However, if I press strafe left slightly before the move forward key during the step 3, it will miss the move forward command instead of strafe.

 

In case where I press a key that is NOT bound during step 3, it will insert two WAIT frames for the first two frames. So, the issue is that there is not enough time to buffer two key pressings for the first two frames. Timing of this is not difficult at all, but the fact that once you press ANY key, the game will almost instantly think that it is the only key pressed for the first two frames.

Share this post


Link to post
26 minutes ago, Looper said:

I dont know what other speedrunners think, but I only want the quick start to be identical with Vanilla. Identical meaning that the keypresses inserted at the start of the level shouldn't be missed from the first two frames, and the mouse movements should be buffered into the first frame. Chocolate Doom is already emulating the quick start the way I just described it, almost Vanilla, except for the first two frames for the keyboard. In rare cases, it actually works 100% identical. It is not an issue if the quick start lasts for 9 frames instead of Vanilla's 8, assuming those numbers are even constants. Only missing keypresses is the issue.

Ok, well this sounds like it might be possible to, at least, make the behavior predictable, and done in a clean, consistent, sensible manner. As is often the case, identifying *what* the desired behavior is is at least half the battle :)

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
×