Chocolate Doom

GhostlyDeath said:

Vanilla Never said I could rebind special keys such as talk, talk to player, and ending a demo.

I'm sure you can by hacking the exe. If DeHackEd support is a legit addition to ChocoDoom, key rebinding is legit as well.

exp(x) said:

I do understand the hesitation towards adding new buttons, though. For example, I had to hack in a button for switching weapons in the video above. This would open to door to things like using the mouse wheel to switch weapons. It's something I like, but it's not vanilla.

Weapon switching in Doom is so slow that the mousewheel will be massively inefficient compared to more recent games that are instantaneous or close to it. It makes sense to add support for handhelds and whatnot, and personally I don't really see that it would benefit anyone wanting to actually use that function for, eg, a mouse wheel.

Well, the way I see it, such a function can simply be ignored by purists anyway. :-)

chungy said:

Weapon switching in Doom is so slow that the mousewheel will be massively inefficient compared to more recent games that are instantaneous or close to it.

You don't have to wait until the weapon has finished raising before you can select another. E.g. hitting 3 twice in quick succession to get the single shotgun without seeing even one frame of the SSG.

chungy said:

Well, the way I see it, such a function can simply be ignored by purists anyway. :-)

Whole point of Chocolate Doom is for purists. Srsly. Playing zdoom or the geezy is what you do when you want to ignore bits that dont work exactly like vanilla. That said the whole lets be able to rebind any key thing is necessary to port to various platforms, and fraggle is right, there is no real change in gameplay.

chungy said:

Weapon switching in Doom is so slow that the mousewheel will be massively inefficient compared to more recent games that are instantaneous or close to it.

Try it, you may like it, other people do.

chungy said:

Weapon switching in Doom is so slow that the mousewheel will be massively inefficient compared to more recent games that are instantaneous or close to it. It makes sense to add support for handhelds and whatnot, and personally I don't really see that it would benefit anyone wanting to actually use that function for, eg, a mouse wheel.

What? Learn to count clicks, dude. You don't have to wait for the weapon to come all the way up to switch to the next weapon. That said, I still use numbers to switch weapons but mouse wheel switching in Doom is no different than in any other game.

fraggle said:
The argument for rebinding keys is that it's needed on platforms where a keyboard is not present. I don't think it's a big change, it doesn't change the game's behavior, and the defaults will always be the Vanilla defaults.

Why not add it as a case for whatever platforms require it? Or do you mean hardware devices? You're altering the game because of things that aren't necessarily related to the PC.

Multi-platforming does have its complications. If you don't put thought to it, you might be compromising the purpose of the engine.

Gez said:
I'm sure you can by hacking the exe. If DeHackEd support is a legit addition to ChocoDoom, key rebinding is legit as well.

You can't put those things on the same level. Few people can hack to any decent extent while nearly anyone can apply DeHackEd patches. If there were a widely used available patch for hacking the EXE binds then it would start to make more sense. That was my point above. If we start imagining all the things that could be possible in the DOS engine through hacking, you could implement tons of things commonly unseen by anyone when using Doom.

Maybe the best way to go is to provide a DOS hack for every new option necessary in Chocolate Doom, and post it on the Chocolate Doom site :p

Looks like Chocolate-doom's website is down for now. All that's on the site is a file "f5.txt" with the text "ok".

Csonicgo said:

Looks like Chocolate-doom's website is down for now.

It isn't limited to Choco-doom, every SourceForge hosted app (with URLs containing "/apps/") seems broken, including their own site support page.

I doubt it'll be long before they've fixed the problem.

Works for me. I guess they fixed it.

Hello. Here's a link to another post of mine in which I comment on a few issues regarding Chocolate Doom: http://www.doomworld.com/vb/post/878744 Guess developers don't frequent that one as much.

Anyways. I'd also like to request an enhancement: make Chocolate Doom's default refresh rate 70hz rather than 72hz. This is to avoid stuttery horizontal movement.

Basically you want to stay as close to Mode 13h as technically possible, that is, 320x200@70hz, exactly what vanilla Doom would switch to.

Right now you can achieve virtually identical results without creating a custom modeline by simply choosing DirectX as video driver and working under General Timing Formula at 320x200, but you'll still need to manually force 70hz with a third party application/registry tweak.

Vanilla Doom's refresh rate:
Hsync: 31.3
Vsync: 69.8

Chocolate Doom's ideal refresh rate:
Hsync: 29.1
Vsync: 69.8 (video drivers report 70hz)

Chocolate Doom's current refresh rate:
Hsync: 30.2
Vsync: 72.3 (video drivers report 72hz)

Thanks in advance :)

Something else I noticed is Plutonia 2 crashing Chocolate Doom after a few seconds of demo playback. It closes without an error message and I've been unable to reproduce said behavior with vanilla Doom.

Regards.

WOG said:

Hello. Here's a link to another post of mine in which I comment on a few issues regarding Chocolate Doom: http://www.doomworld.com/vb/post/878744 Guess developers don't frequent that one as much.

Sorry, yes, I have seen the post, I just never got round to replying to it. I'll see what I can do.

Generally speaking the best thing to do if you find bugs is to file them in the bug tracker on the website, otherwise there's a good chance I'll forget about it.

Anyways. I'd also like to request an enhancement: make Chocolate Doom's default refresh rate 70hz rather than 72hz. This is to avoid stuttery horizontal movement.

Unfortunately SDL doesn't provide that kind of control over the display mode.

Alrighty, thanks for the reply.

I have the tendency to assume that something not working correctly for me is the result of either my system or a bad config, thus referring to these issues as "bugs" is generally the last resource in my book. That's the reason I tried to clear things up here before submitting a proper report. If by any chance you still want me to re-post these at sourceforge, let me know.

Ok, I did some more testing on the Plutonia2 crash and figured out a way to watch the whole demo. All you need to do is start a game, play a little, like a minute or so, just kill some baddies, move around, now press F7 to end the game and let the demo roll: no crash!

Still no idea what's going on.

I've just installed Chocolate Doom 1.3.0 on window 7.

If I run in fullscreen mode, al colors are messed up, except for the status bar. If I play in window mode, colors are ok, except for status bar, which is a uniform purple.

Any idea?

Lorenzo said:

If I run in fullscreen mode, al colors are messed up, except for the status bar. If I play in window mode, colors are ok, except for status bar, which is a uniform purple.

Any idea?

video_driver "windib"

Now it's working.

thank you!

Lorenzo said:

Now it's working.

thank you!

Also you can use such brutal method:

chocolate.bat:

taskkill /f /IM explorer.exe
chocolate-doom.exe

entryway said:

Also you can use such brutal method:

chocolate.bat:

taskkill /f /IM explorer.exe
chocolate-doom.exe

or something like that
http://prboom-plus.sf.net/chocolate-doom.vbs

The "soft" way works properly, but thank you for this one too.

Choco Doom is cool and thanks for all the key binds. But, I bound "Q" to rocket launcher and the game quits when I press "Q" while recording a demo (it doesn't quit when not recording).

Already in the tracker as bug 3020514.

While playing some ol' school mods (marked as vanilla compatible), I occasionally get errors like these:

Bad V_DrawPatch
R_InitSprites: Sprite %s : %c : %c has two lumps mapped to it
R_InitSprites: Sprite %s frame %c has rotations and a rot=0 lump

Is there any way for me to debug these pwad errors?

I may have been lucky once in finding an offending patch, and repositioning it to the corresponding iWAD <X><Y> position default...

Have you tried merging the PWAD? Basically you type -merge "C:\wherever the PWAD is located" into the command line before you launch Chocolate Doom. It helps if you're using a frontend like ZDL that has a command line option. You can find further detail on merging PWADs here.

Not a lot going on it seems. Wish more developers would help with this noble project.

Does Chocolate Doom support soundfont files? Back in the day, I would play Doom on my grandmother's Windows 95 machine, and she had an AWE32 soundcard. I thought the quality of the music was great.

I used the 1mgm.sf2 file to emulate AWE32 with ZDoom, but ZDoom is too "new" for me to run through the classic IWADs (I generally use ZDoom for PWADs). When I want to play, say, Ultimate Doom, I use Chocolate Doom.

Is there a way I could do this with Chocolate Doom and load soundfonts? Just trying to get as close as I can to the "good ol' days".

Not directly, but you can use those by installing a TiMidity++ driver on your system, following Never_Again's instructions here. Otherwise, Chocolate Doom does have TiMidity support through SDL directly, but the implementation only works with PAT files (separate sound fonts per instrument) and not one-file SF2s.

Alright, thanks. Would it be possible to implement .sf2 support in Chocolate Doom (so we can emulate the old soundcards we all know and love), or is it planned for a future release?

Thanks.

Direct implementation would depend on the SDL devs, not Chocolate Doom's.

You are free to sit there and wait for the SDL team to do that one day in the hazy future, if you desire, but the setup tutorial I linked to above lets you do what you are requesting.