Chocolate Doom - New Improved Formula

After weeks of hard work updating the engine, fraggle has released Chocolate Doom v1.5.0. Included in this release:

• A switch to DosBox's OPL emulator
• Add and find multiplayer servers with an internet master server
• More keybinding options (improve play on non-keyboard systems)
• Many fixes for Vanilla compatibility
• support for Hacx v1.2 Iwad
• Lots of Windows fixes

The dig at Windows seems a bit unnecessary IMO.

List of changes is here

And the comment "many fixes for Vanilla compatibility" seems to imply that it wasn't already very close indeed to 100% compatible.

To be fair, if you read the log there are a number of Vanilla compatibility fixes.

Cool -- Hacx seems to work perfectly. Kudos, sir. :)

Pretty awesome, glad to see this release.

Does DosBox's opl emulation have an issue with pure midi files or is that something that has to do with Chocolate Doom in particular? If you load udmx, most of the midis will play totally butchered (wrong tempos, tracks out of sync). Of course, you have to warp to 32 and then idmus to hear these. Just curious as to what the culprit may be

Ralphis said:

Pretty awesome, glad to see this release.

Does DosBox's opl emulation have an issue with pure midi files or is that something that has to do with Chocolate Doom in particular? If you load udmx, most of the midis will play totally butchered (wrong tempos, tracks out of sync). Of course, you have to warp to 32 and then idmus to hear these. Just curious as to what the culprit may be

You've spent a lot more time creating midis than me so you might already know this, but I'll say it anyway:

Vanilla doom didn't support midi format music, it was called mus format. I think Boom integrated a util called mid2mus into the engine so that you could put actual midi files into the wad rather than running the conversion then putting in a mus lump.

Actually, later versions of Doom did support Midi. As for Boom, as far as I know it doesn't really apply since they used a different sound engine all together since the Doom source didn't include it's sound code.

Like kristus said, I thought 1.9 supported the actual midi format?

Ralphis said:

Does DosBox's opl emulation have an issue with pure midi files or is that something that has to do with Chocolate Doom in particular? If you load udmx, most of the midis will play totally butchered (wrong tempos, tracks out of sync). Of course, you have to warp to 32 and then idmus to hear these. Just curious as to what the culprit may be

Yeah, it's a Chocolate Doom problem, and nothing to do with the underlying OPL emulation code. I wrote the MIDI processing code for doing OPL playback, but it's incomplete. Specifically, there's a MIDI command that sets the tempo that I didn't implement. It doesn't seem to be a very commonly used command, so most MIDI files play back okay, but a few (udmx and others) get screwed up because of it.

mewse said:

Vanilla doom didn't support midi format music, it was called mus format. I think Boom integrated a util called mid2mus into the engine so that you could put actual midi files into the wad rather than running the conversion then putting in a mus lump.

Dead wrong, I'm afraid. I believe early versions of Doom only supported MUS, but by 1.9 it could definitely play MIDIs natively. Interestingly from my examination of the DOS executables it's clear that internally everything is MUS. Paul Radek (author of the DMX sound library used in Doom) wrote the original MIDI2MUS tool, so it's most likely that he integrated the code into Doom as a conversion stage.

mewse said:

Vanilla doom didn't support midi format music, it was called mus format.

Update to 1.5 :p

See, if Chocolate Doom can do 32bit color then why is ZDoom still dragging it's ass? You just got outdone by a port that is aiming for a more vanilla feel.

It doesn't do true 32-bit color. It blits the 8-bit doom rendering onto a 32-bit screen

Just wondering: if you play in fullscreen mode and the game window doesn't take up the entire monitor, would it be possible to have the palette changes only affect the game window instead of the entire screen (including the letter/pillarboxes)?

ultdoomer said:

Just wondering: if you play in fullscreen mode and the game window doesn't take up the entire monitor, would it be possible to have the palette changes only affect the game window instead of the entire screen (including the letter/pillarboxes)?

32-bit mode may work that way, but 8-bit is not very likely (I doubt fraggle would want to add the extra code to e.g. use the 2nd black in the palette for the letterbox areas, since that could compromise vanilla compatibility).

ultdoomer said:

Just wondering: if you play in fullscreen mode and the game window doesn't take up the entire monitor, would it be possible to have the palette changes only affect the game window instead of the entire screen (including the letter/pillarboxes)?

you know this is probably a sign of the way the original video mode worked. Even Wolf3d had the ability to change the "border" around the screen that is now lost in LCDs (could be changed to 16 EGA colors) and Doom did this border flash on picking up items and getting items. I know because I can verify this behavior on my old DOS setup... I always found it interesting that it was actually controllable.

ultdoomer said:

Just wondering: if you play in fullscreen mode and the game window doesn't take up the entire monitor, would it be possible to have the palette changes only affect the game window instead of the entire screen (including the letter/pillarboxes)?

It's in the changelog!

Thanks! I should've checked that first.

Hooray, new chocdoom. :D
Now all i need is a modern editor for my OS, cant get Yadex to compile over here, and DEU/DETH with dosboxs help isnt fun at all.

@Csonicgo:
You can even do border rasterbars with some assembler magic. ;)

EDIT:
Newest VirtualBox likes DB2, only problem is that the mouse inside the 3D view is a tad bit fast even when turned all the way down.

Great news!

All hail the Choco.

Very sad.
Chocolate Doom was the last hope for Windows 9x users who uses Doom source ports but last releases (startet with 1.3.0) continue to break the compatibility with these OS'es without any technical reason. And seems that all this time no one give any responses about that to author. Now it's time to migrate to DOSBox for me.

@aleksej:
If you use Win9x, why arnt you just using the real deal?

BTW, you are free to grab yourself MinGW (Use Dev-Cpp from Bloodsheed) and compile a Win9x compatible binary.

Bastet Furry said:

@aleksej:
If you use Win9x, why arnt you just using the real deal?

BTW, you are free to grab yourself MinGW (Use Dev-Cpp from Bloodsheed) and compile a Win9x compatible binary.

Or heck, if the compiler is the only issue I can build you a Win9x friendly build. I have a fully working MinGW toolchain set up, myself

kkaden said:

Add and find multiplayer servers with an internet master server

I like this.

aleksej said:

Very sad.
Chocolate Doom was the last hope for Windows 9x users who uses Doom source ports but last releases (startet with 1.3.0) continue to break the compatibility with these OS'es without any technical reason. And seems that all this time no one give any responses about that to author. Now it's time to migrate to DOSBox for me.

Supporting extra operating systems isn't just something that can be "fixed and forgotten about". It requires effort - ie. regular retesting to confirm that it still works and new changes haven't broken it. To be frank, I don't have a Windows 9x install to test with. Furthermore I'm not sure why it's even worth it considering (1) it's a > 13 year old OS with very few active users now, (2) the stated purpose of Chocolate Doom is to support modern operating systems (3) you can just run the original Vanilla executables in Windows 9x anyway, so what's the point?

You're welcome to test it on Windows 9x, and report any bugs you find. The source code is open for you to examine, so if you have the technical ability I'm open to fixes. Maybe you don't have the skills to do that. But you haven't even reported any bugs that I can see, so what are you expecting to happen, exactly?

What you're saying isn't even true. Read through the list of changes for v1.3.0 and you'll see that I specifically added a fix to make the game run under Windows 9x. Furthermore when I developed the OPL MIDI code I actually went out of my way to develop a Windows backend module that would work with Windows 9x - and went to the extent of testing that it worked, too.

In summary, if you want Chocolate Doom to work on Windows 9x, ditch the shitty attitude, get off your soap box and start actually reporting bugs you encounter (beyond the uselessly vague "it continues to break compatibility") so that I might actually be able to fix them.

Whoo said:

I like this.

You might like this, too.

fraggle said:

(3) you can just run the original Vanilla executables in Windows 9x anyway, so what's the point?

Are you serious?

Chocolate-Doom has features which Vanilla does not have. Higher resolutions, 32-bit mode, master server, -merge and -deh, support for HacX, OPL emulator, etc..... If you implement those "Crazy pie in the sky ideas", then there will be even more reason for people to prefer Chocolate-Doom over Vanilla.

One thing about Win9x users that truly puzzles me is that they stubbornly refuse to use anything even remotely current but then expect that modern Windows software still runs on such a crippled system (meaning that a significant portion of the Windows API was not implemented on it.)

So, bottom line, if something works, consider yourself lucky. It doesn't come by default

@Graf Zahl:
You forget something, we Germans might be lucky enough to always have a computer capable of running the latest mumbo jumbo OS out there, but other people from around the world might not be that fortunate and might still be surfing the web with some ancient P2-400. And you dont want to run a Win XP SP3 on that, not talking about Vista or Seven.

So, dont damn people for using an old OS if they dont have the money to get something better to run a newer OS, ok? :)

Well, it's still an old OS so one may be restricted to old software.

Don't forget that modern Windows C compilers need some extra help to even be persuaded to compile a Win9x compatible EXE.

Ooh I love the OPL3 emulation.... that's something every source port should have IMO. It feels so "oldskool". Even back in the day, I preferred the OPL3 FM synth sounds of my AWE32 over the wavetable version. It gives the Doom music a distinct dark futuristic sound, reminiscent of the soundtrack of 80's sci-fi movies like Bladerunner and Terminator.

One thing though, in chocolate-doom the volume of the music way too low, even with the music volume at 100% and the sound effects at 50% I can barely hear it over the sound effects. To compare, I tested vanilla doom in a dosbox with the same settings, and the music sounds a lot louder then.

Edit: thought it may be useful to mention my OS too, I'm using Ubuntu 10.10