Chocolate Doom

Hey fraggle! I want to know how to use the GUS emulation in Chocolate doom. (P.S. I'm a NOOB)

There's some documentation in README.Music. Hope this helps.

Just tried it out, got it working following the steps. Thanks Fraggle.

I never had a GUS sound card so this is really interesting.

Just found a glitch!
When you pause the game in the intermission, you can still progress to the next level but with no music\sound untill you unpause again and it'll stay muted even if you'll restart it!

joe-ilya said:

Just found a glitch!
When you pause the game in the intermission, you can still progress to the next level but with no music\sound untill you unpause again and it'll stay muted even if you'll restart it!

That's because Chocolate-Doom uses a workaround that sets the music volume to 0 when you pause it. The intermission screen unpauses the game incorrectly, so it doesn't set the music back to the original volume. If you press pause two times, it should go back to normal. If you're using MIDI as your music device under Windows, then it explains why the sound also goes away.

Thanks Fraggle for this port. Would like to see it retouched for Android, can test it on my tablet (I have Nexus 7 2013 edition so if it would be working on pure Android, it should be working on others too).
I think that I've found a glitch / bug / something related.
Checked the stable 2.0.0 version of Chocolate Doom and the chocolate-doom-2.0.0-113-ga1b066a-win32 build. WAD used: Doom II and Ultimate Doom (for the stable 2.0.0 build as I discovered it when I was close to finishing the UD). What's happening? No sound at all. Nothing. I was running Your source port for some time and everything was OK. Later, I started to have this problem: 0 sound. My system wasn't (and isn't) muted. Everything works. Except for Chocolate Doom. I've found a solution for it - have to set sound in options (just volume 1 lvl up and then down, to the value that I was using). This helps. It was on stable 2.0.0. I have checked the newer, WIP build and that problem started to occur every time after the 1st or 2nd launch. Now ir's correct O_O. When I was launching Doom to check it again (just a few secs ago) - I had this problem. Now it's correct, on both WIP build and stable 2.0.0. Demons are invading my PC ? ;) I've specially registered here to write about it. Not sure if it's a bug or so. Seems that's kind of a random thing. Yesterday I had a "deaf" Doom.

I am not all to familiar with hacx so i am actualy wondering if this is a hacx or chocolate doom problem, so excuse me if i am posting this somewehere it does not belong.
The flying robots from hacx leave blocking dead corpses and they can literally halt any progress in the level if needed. I got stuck in a level for multiple times because of those things falling next to each other.
Is this a problem with hacx itself or the engine running it ?



http://i.imgur.com/uUo5fiD.png

FireFish said:
Is this a problem with hacx itself or the engine running it ?

Try launching Hacx with DosDoom, in virtual machine or via Dosbox. Chocolate Doom is really accurate and good but it's not perfect. If You won't find that behavior on original Dos Doom executables, then it's quite possible that's a thing related with Chocolate Doom. If You will find it, then it's maybe a Doom-related bug and won't be repaired as bugfixing the original source is beyond the scope of that port. But I'm not Fraggle and he should help You. Either here or via PM.

Quik update ;


Doom2.exe 1.9 ;
Using Dosbox and the Doom2 1.9 executable the robot bodies do not block the player from passing them.

Chocolate doom 2.0.0 ;
The falen robot corpses of the flying robots block the player. this is capable of halting level progression if they block hallways.

Which version of HacX are you using, and how are you running it in Chocolate Doom?

Hacx 1.2 IWAD (7.4 MB) [ IdGames ]
This contains no dehacked patch so the information on the chocolate wiki is kind of odd.

On dos Doom2.exe 1.9 i did -file hacx.wad
everything works as seemingly intended.

after testing with chocolatedoom 2.0.0 :

- iwad doom2.wad -file hacxwad :
Breakable lamp objects keep looping their animations when
falling apart. many things going wrong (Things).

- iwad hacx.wad
The flying enemy robots block you when dead on the floor.

I'm assuming you extracted the Dehacked file from the wad, and are loading it with -deh whatever_you_saved_it_as.deh

There were some changes to Dehacked handling recently, nothing that should affect loading external patches, but it's always helpful to have someone confirm bugs.

I don't know HacX either, where's a good spot to find flying robots?

Ok, it seems the dehacked patch stuff went bad on my side.

i have re-tested it with a newly extracted dehacked patch from the wad an now it all works. i might have had a braincell meltdown or something, or maybe it went wrong somewhere else but now everything is fixed... Awkward moments in gaming and engine usage... (0_o)'

OK, well, good to know it works.

I have a request. In the multiplayer setup hub thingy, can you add chat like Doomatic? While I know that such a feature wasn't in vanilla, neither is the built in support for dehacked and merging.

Danfun64 said:

I have a request. In the multiplayer setup hub thingy, can you add chat like Doomatic? While I know that such a feature wasn't in vanilla, neither is the built in support for dehacked and merging.

Very weak argument, although I often find myself refering to it when requesting features, too -- mostly unsuccessful, though. ;)

"Can you add jumping? and swimming? and dancing? While I know that such a feature wasn't in vanilla, neither is the built in support for dehacked and merging." ;)

fabian said:

Very weak argument, although I often find myself refering to it when requesting features, too -- mostly unsuccessful, though. ;)

"Can you add jumping? and swimming? and dancing? While I know that such a feature wasn't in vanilla, neither is the built in support for dehacked and merging." ;)

Actually, the addition of built-in support for these two are just a simple things which make our life easier AND NOT destroying the vanilla Doom's feeling. It's not interfering with gameplay or so. You got a good program which enables you playing your favourite (? :)) game on modern OSes without any problems, playing it the way ID should be and still complaining? Then try other source port. Jumping wasn't intended in Doom so Chocolate Doom won't have it, even as a parameter / option in menu or in setup (support for higher resolution is rather also out of original Doom code reach but it's helpful for modern users and their PCs - I play on 640xsomething on fullscreen and in window when I need it. I definitely should consider using higher one in window. It's still small on 1920x1080). Hope it explained a bit to someone.

RadTang said:

Hope it explained a bit to someone.

You got me wrong, my post was meant as satire. I actually know about Chocolate Doom and the design philosophy behind it.

fabian said:

You got me wrong, my post was meant as satire. I actually know about Chocolate Doom and the design philosophy behind it.

Oh.. <hits the barrel with his own fist>
Not expected this.

RadTang said:

Oh.. <hits the barrel with his own fist>
Not expected this.

What I wanted to say is that you can turn even the most absurd feature request into an apparently valid one by appending "While I know that such a feature wasn't in vanilla, neither is the built in support for dehacked and merging." to it.

Danfun64 said:

I have a request. In the multiplayer setup hub thingy, can you add chat like Doomatic? While I know that such a feature wasn't in vanilla, neither is the built in support for dehacked and merging.

It's actually not such an absurd request. One of the "crazy pie in the sky ideas" from the Chocolate Doom TODO file is to create a retro-style replacement for DWANGO (and see my recent comments about how DWANGO worked over in Doom General).

It seems a bit excessive to put something like this into the setup tool though, and chances are that I'm probably never going to get around to implementing something like this anyway. My general opinion is that we already have an ample selection of tools for communicating with other people in real time - IRC is one popular example. If I ever did implement my crazy Chocolate DWANGO idea it would probably be as a client on top of IRC anyway.

fabian said:

Very weak argument, although I often find myself refering to it when requesting features, too -- mostly unsuccessful, though. ;)

"Can you add jumping? and swimming? and dancing? While I know that such a feature wasn't in vanilla, neither is the built in support for dehacked and merging." ;)

It's not actually the same as asking for jumping or swimming - those are things that Vanilla Doom definitively does not do. What Danfun64 is asking for is something equivalent to what Doomatic did under DOS. Under Chocolate Doom's philosophy something like this would be permitted, as it would be replacing something previously used under DOS - just liked the -deh parameter replaces dehacked.exe.

That said, there are a lot of tools that worked under DOS with Vanilla Doom and I think it's possible to get carried away trying to support them all. I'd rather not do that if possible and limit ourselves to those features that were really popular (like novert, and dehacked). Doomatic was a cool program, but it wasn't that popular or widely used.

you want a ridiculous request? Chocolate Boom. A fork of Chocolate Doom with full boom compatibiliy and boom demo support, but retaining the netcode and convinience of Chocolate Doom.

...still more likely than adding "jumping swimming and dancing" into Chocolate Doom.

Also, do you have an estimated release date for 2.1? I'm running git builds until the multiplayer sound bug is fixed in a stable release.

There are a ton of boom-compatible ports, why create a new one. And with a software renderer, dehacked support etc.

What would this Choco Boom offer over Eternity?

Nobody has asked for jumping, swimming or dancing in Chocolate Doom. Please stop.

VGA said:

There are a ton of boom-compatible ports, why create a new one. And with a software renderer, dehacked support etc.

What would this Choco Boom offer over Eternity?

The benefits of chocolate doom's netcode and setup utility, as well as the ability to record boom demos natively. The overhead of dosbox wouldn't be neccesary, allowing systems which support chocolate doom and prboom but not dosbox to use the multiplayer abilities. Until odamex's demo and coop support is completed, it would also make a good stopgap measure for open source, software rendered multiplayer demos.

It would make far more sense to add those features to PrBoom or Eternity rather than creating yet another new source port.

PrBoom-Plus can already record Boom 2.02 compatible demos, as well as built-in video recording for both software and opengl modes. Not sure what other benefits you really want that it doesn't already provide. (Its netcode is probably lacking, but that should be fixable.)

Danfun64 said:

The benefits of chocolate doom's netcode and setup utility,

But Boom itself didn't have a separate setup tool.

Ever checked out WinMBF? It is probably as close to the original MBF.EXE as you can get. Not sure about the netcode, though.

XCOPY said:

Did anyone make a patch that renders the 'real' resolution, and not simply scaling?

http://www.doomworld.com/vb/source-ports/67168-crispy-doom-1-5-supernova-update-18-aug-2014/

Still capped at 640x480, though.