Search In
• More options...
Find results that contain...
Find results in...

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.

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.

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

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.

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

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.

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?

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).

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?

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.

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.

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 :)

Are ".vgm" files supported?

And what music formats are supported on this port?

3 hours ago, Poohlyash said:

Are ".vgm" files supported?

No. Vgm is a very specialised format which chocolate-doom would have absolutely zero interest supporting, seeing as it doesn't have any relation to vanilla doom compatibility.

3 hours ago, Poohlyash said:

And﻿ what﻿ music formats are supported on this﻿ port﻿?﻿

OGG via music packs. It will only load midi and mus in WADs.

On 1/19/2019 at 5:41 PM, Poohlyash said:

Are ".vgm" files supported?

And what music formats are supported on this port?

Try the fork of Chocolate Doom named Crispy Doom which supports MP3, OGG, FLAC in the WADs. The new version 5.5 is coming out just in 1 or 2 days.

Is Chocolate Strife supposed to suport strife0.wad? I can't seem to get it working with -file or -iwad.

On 12/7/2018 at 6:42 PM, kb1 said:

What I mean is, the whole purpose of DOSBox is to emulate DOS as best as possible.

While it may be argued in some sense that compatibility with more games is a goal, DOSBox is a "performance over accuracy" emulator, and the devs have always admitted this and stated they don't intend to ever change that.  It's always been willing to take shortcuts and as a result certain more esoteric things don't always work correctly or need workarounds (though you're still often more likely to get a favorable result with DOSBox than with an actual machine for a lot of known finicky programs, just based on the sort of hardware and software compatibility nonsense from the myriad clones and peripherals existing in the DOS ecosystem, a far cry from standardized console machines).  It's not always the case but it's still reasonable to question in cases where an actual DOS machine gets different results than DOSBox whether DOSBox might be causing something unintended or at the very least be misconfigured for the program at hand.

PCEm is probably closer in pedantic accuracy when it comes to emulating DOS stuff, but it's much more of a performance hog and requires you to futz around with BIOS ROMs to get it running (ugh).

Posted (edited)
4 hours ago, SiFi270 said:

Is Chocolate Strife supposed to suport strife0.wad? I can't seem to get it working with -file or -iwad.

Sadly, the shareware Strife is not supported. Only the retail version 1.2+ is. @Quasar or @Kaiser may be able to give all the gritty details, but it would involve basically a new reverse engineering effort and probably a lot of conditionals to support the older versions (I kind of hope that some day it will, but the chances of it are low).

For what it's worth though, Veteran Edition is pretty cheap on either Steam or GOG, and this will work with Chocolate Strife perfectly.

11 hours ago, ETTiNGRiNDER said:

While it may be argued in some sense that compatibility with more games is a goal, DOSBox is a "performance over accuracy" emulator, and the devs have always admitted this and stated they don't intend to ever change that.

To expect it to work at all, CPU instruction execution almost has to be spot on. That leaves DOS interrupt emulation, driver emulation, and hardware translation as places where steps could be taken to gain performance over accuracy.

In the context of that post above, the question is if DOSBox issues cause Doom to fail to register mouse movements before the screen melt feature has completed. It's reasonable to assume that DOSBox could turn on mouse support too late, or could produce vastly different timer values.

Back in the day, certain timings varied much less than today. You wouldn't attempt to play a serious DOS Doom game on anything less than a 486, and there just wasn't much faster than that, before everything switched to Windows. What I'm getting at is, could this simply be a problem with Doom.exe running in a faster environment, DOSBox or not?

And, really, that's not the best question. The best question is: Can we make a source port that produces a consistent result that mimics Doom.exe on a fast 486, regardless of actual CPU speed? In other words, can we take the average of the number of action tics that Doom.exe allowed pre-game, on a few real 486 PCs, and call that number *The* proper number of pre-game tics, and, finally, build our source ports to read exactly that number of tics pre-game?

For ports that strive to provide the most original vanilla game experience possible, I think it's most important to lock down that number, and for source ports to use it moving forward. It may not be possible for Doom.exe to be consistent, in DOSBox, in DOS, on a 486, on a modern PC, etc. But we should be able to get our ports to match both the "expected" DOS behavior, and each other.

Hi, I have been using this sourceport to play both Hexen and Heretic and I really enjoy the vanilla feel of it and the ease of use but I am trying to play the Hexen expansion and it requires me to manually locate the file using the command prompt which I have no clue how to use. Is there a more simple and user-friendly way for me to launch the expansion rather than the normal Hexen WAD?

Sorry if this comes off as redundant or minor but I do not know how to use the command prompt at all.

Posted (edited)
14 hours ago, Uni said:

Hi, I have been using this sourceport to play both Hexen and Heretic and I really enjoy the vanilla feel of it and the ease of use but I am trying to play the Hexen expansion and it requires me to manually locate the file using the command prompt which I have no clue how to use. Is there a more simple and user-friendly way for me to launch the expansion rather than the normal Hexen WAD?

Sorry if this comes off as redundant or minor but I do not know how to use the command prompt at all.

1) Create a windows shortcut to Chocolate Hexen.  Right-click and drag the Chocolate Hexen icon, then move it anywhere in the folder.  You'll get a menu where one of the options is "Create Shortcut Here".  Select "Create Shortcut Here".

2) Once you have done that, right click on the shortcut and select "Properties".

3) In the new menu that appears, select the "Shortcut" tab.

4) In the "Target" field, type the following text after chocolate-hexen.exe, starting with a single space after the closing quotation mark:

-file hexdd.wad

Your target field should look similar to this (of course, wherever it was you installed Chocolate Hexen, since I don't know where it is located on your PC. "\path\to\chocolate-hexen" is just a placeholder for chocolate hexen's location on your system.):

"\path\to\chocolate-hexen" -file hexdd.wad

Make sure that hexdd.wad (Deathkings file) is in the same folder as hexen.wad (the main Hexen campaign) and chocolate-hexen.exe itself.

In future, all you will have to do is click on that Icon and you'll run Deathkings by merely double clicking. I would also recommend renaming the shortcut to Deathkings of the Dark Citadel for obvious reasons.

Edited by Master O

@Master O Worked like a charm, thank you.

15 minutes ago, Uni said:

@Master O Worked like a charm, thank you.

With respect to autoloading (link), am I right in saying that it is currently doing it simply by looking at each subfolder named after the IWAD in use?

Is there a way to give a wad for autoloading for all Doom IWADS (doom1, doom, doom2)?

I'd like to donate to the creator of chocolate doom, it  helped me finish ultimate doom.  Fraggle, what is ur paypal handle?

A very kind offer but I really don't need the money. If you'd like to express your appreciation then can I suggest you make a donation to Girls who Code? They're doing great work to fix the gender gap in the tech industry.

Posted (edited)
3 hours ago, fraggle said:

A very kind offer but I really don't need the money. If you'd like to express your appreciation then can I suggest you make a donation to Girls who Code? They're doing great work to fix the gender gap in the tech industry.

Did it.

I feel like i owe some to chocolate doom... i mustve tried somany chocolate versions over the years (before even finding this doom site)

I like chocolate doom 2.10.0    the sb and opl sound the best to me on that version.

How about a way to donate to doomworld??

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