Chocolate Doom

fraggle said:

Music is really tricky to get right. I've thought about modifying DOSBox to dump what is going to the music device and then trying to emulate that somehow. If I can, I'd like to fix it, but I'm not quite sure how easy doing so will be.

Is it possible to get access to NWTPro's code? I remember that it played mus's perfectly.

ravage said:
Is it possible to get access to NWTPro's code? I remember that it played mus's perfectly.

The NWT code is available at the TiC site, though it states in NWT's readme that its MUS player was coded by Vladimir Arnost, which is incidentially the author of MusPlay.

It's basically impossible for me to fix a bug like that. I'll add a mention to the BUGS list, though

woah there boy... does that mean that it's a bug in chocolate doom that a bug from doom2 isnt emulated? so that's a non bug bug? or a bug not bugging bug? or a bug bug bug bug bug?

(infinite loop)

forgive my ignorance, but how do you set up the conrtols without the orignal setup files?

For now you can't; either let it create a default.cfg and then edit it, or use a copy of setup.exe. There's a little app called keycode.exe that comes with Boom for checking the codes for the keyboard keys, which is pretty useful when manually editing the CFG.

Really neat new cocodoom thing, hopefully fraggle won't mind me pasting this:

<@fraggle> i got one of the dehacked settings working which doesnt work in boom
<@fraggle> the "Monsters Infight" setting in the Misc section
<@fraggle> its misleading as to what it does though
<@fraggle> it doesnt enable/disable all monster infighting
<@fraggle> what it does is enable/disable monster infighting within species
<@fraggle> like you know imp fireballs dont hurt imps
<@fraggle> if you turn on "Monster infight" in dehacked it makes it so they do hurt them
<@fraggle> but its a really weird variable because you have to set it to 202 or 221
<@fraggle> anyway looks like the boom guys just got totally confused and never implemented it

Heh, chocodoom is awesome. i made the icon after all! :p

The scancodes here :
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html#ss1.4

Should work with chocodoom. Note that the numbers are in hexadecimal, for example:

W = 11 = (16 * 1 + 1)
W =17

Or you can use the windows calculator or whatever.

Captain Red said:

forgive my ignorance, but how do you set up the conrtols without the orignal setup files?

Well, if you install Shareware Doom, you can use the setup.exe out of that.

I just released a new version, v0.1.1. It fixes a load of the bugs that were reported earlier in this thread. You can get it from www.chocolate-doom.org.

More feedback is always welcome!

fraggle said:

More feedback is always welcome!

OK...

I spotted a couple of glitches when testing a demo to see if it would play back in ChocDoom 0.1.1.:

• -merge doesn't work correctly with Scientist 2. The error message is "Error: R_InitSprites: Sprite SGN2 frame A has multip rot=0 lump". It runs OK using a deusf-ed version of the wad though (as does Doom2.exe).
  
• When running the demo, it crashes towards the end with the message "Error: unsupported sample rate 17990". This error doesn't occur in Doom2.exe.

I'm not sure who is right but according to ZDoom, the values of DeHackED [Sound] patches map as follows:

           else CHECKKEY ("Zero/One",           info->singularity)
           else CHECKKEY ("Value",              info->priority)
           else CHECKKEY ("Zero 1",         info->link)
           else CHECKKEY ("Neg. One 1",     info->pitch)
           else CHECKKEY ("Neg. One 2",     info->volume)
           else CHECKKEY ("Zero 2",         info->data)
           else CHECKKEY ("Zero 3",         info->usefulness)
           else CHECKKEY ("Zero 4",         info->lumpnum)

Chocolate Doom appears to map values differently (according to the CVS).

I've not tested it yet to find out which is correct. Speaking of which - what TCs make extensive use of [Sound] patches?

PrBoom says this (and Eternity, too):

static const char *deh_sfxinfo[] = // CPhipps - static const*
{
  "Offset",     // pointer to a name string, changed in text
  "Zero/One",   // .singularity (int, one at a time flag)
  "Value",      // .priority
  "Zero 1",     // .link (sfxinfo_t*) referenced sound if linked
  "Zero 2",     // .pitch
  "Zero 3",     // .volume
  "Zero 4",     // .data (SAMPLE*) sound data
  "Neg. One 1", // .usefulness
  "Neg. One 2"  // .lumpnum
};

I haven't seen a single patch that manipulates this though (it it even makes sense.)

Grazza said:

OK...

I spotted a couple of glitches when testing a demo to see if it would play back in ChocDoom 0.1.1.

Thanks for the bug report!

:

• -merge doesn't work correctly with Scientist 2. The error message is "Error: R_InitSprites: Sprite SGN2 frame A has multip rot=0 lump". It runs OK using a deusf-ed version of the wad though (as does Doom2.exe).
  

This actually seems to be occuring due to a bug in the WAD itself. The sprite SGN2A0 is in SCI2.wad twice. Deutex apparently fixes this, though, so I should as well. The '-merge' option is supposed to behave like deutex does, but this is harder than it sounds (the deutex source is almost impossible to understand).

When running the demo, it crashes towards the end with the message "Error: unsupported sample rate 17990". This error doesn't occur in Doom2.exe.

This occurs because Chocolate Doom only supports sound effects with sample rates of 11025 and 22050. I guess Doom supports the whole range. Chocolate Doom itself runs at 22050hz: 11025hz sounds are "scaled up" to match. I'll see if I can make it more general and support the full range of sample rates.

Regarding the dehacked mappings for the sound structures: I just used the Boom mapping, but it's a moot point because most, if not all of the fields are internal things that shouldn't really be touched. It isn't whats causing this bug.

fraggle said:
This occurs because Chocolate Doom only supports sound effects with sample rates of 11025 and 22050. I guess Doom supports the whole range. Chocolate Doom itself runs at 22050hz: 11025hz sounds are "scaled up" to match. I'll see if I can make it more general and support the full range of sample rates.

It seems like Doom supports both 11025 and 22050 but plays anything at about 11025. Could that be? DOSDoom's SSG sounds different than Doom's (too sonorous when reloading, which is at 22050), and similar to the way XWE plays the sound back (at real rates I presume.) Setting other engines to output 11025 makes them sound right. Also, Doom seems to have the ability to play anything, albeit high sound frequencies might sound wrong or even terrible. I recall AV's first version had a sound in the 30th level that played back wrong in Doom and otherwise caused issues in some engines (I think it was some older version of ZDoom.)

myk said:

Qmus2mid (though I haven't seen its source anywhere.)

This might be it not exatly, but better than nothing:
http://cvs.sourceforge.net/viewcvs.py/doomlegacy/doomlegacy/Attic/qmus2mid_sdl.c?rev=1.2

Greetings
Funduke

Edit:
... And here the linux version, includiung source code:
http://www.hitsquad.com/smm/programs/qmus2mid/

2nd edit:
And here another package, the readme says, it's still compilable under DOS:
http://russell.slipgate.org/files/qmus2mid.zip

myk said:

It seems like Doom supports both 11025 and 22050 but plays anything at about 11025. Could that be? DOSDoom's SSG sounds different than Doom's (too sonorous when reloading, which is at 22050),

The SSG sounds are different from all the other sound effects in Doom, as they are recorded at 22050Hz, while all the others are 11025Hz. A common bug in the early source ports (such as the first version of DOSDoom) was to ignore what the sound effect's sample rate was and assume that all sound effects are 11025Hz. If that's the case, the sound effect plays back at half speed, which is what happens to the SSG.

Doom certainly plays 11025 and 22050Hz sound effects back properly, and apparently it plays back other sample rates as well. I need to look into whether it actually scales them properly or whether it just takes the nearest value.

funduke said:

This might be it not exatly, but better than nothing:
http://cvs.sourceforge.net/viewcvs.py/doomlegacy/doomlegacy/Attic/qmus2mid_sdl.c?rev=1.2

Greetings
Funduke

Edit:
... And here the linux version, includiung source code:
http://www.hitsquad.com/smm/programs/qmus2mid/

2nd edit:
And here another package, the readme says, it's still compilable under DOS:
http://russell.slipgate.org/files/qmus2mid.zip

This is really useful! Thanks!

fraggle said:
More feedback is always welcome!

Not sure if this has been talked about much: How possible would it be to have Chocolate Doom take mouse turning input at the last instants of startup? Currently it doesn't take any till the screen is ready, while in Doom you can turn the mouse earlier.

Would a fullscreen command prompt be possible? I don't mean actual DOS, but a full screen prompt that behaves likewise (or not full-screen if you choose fullscreen 0.) With a DOSKey-like functionality that'd pretty much be emulating one of Doom's DOS-based features on Windows 9x. I mean, not instead of the current "back to Windows" exit, which is similar to clicking on the Doom icon, but as a "dos 0/1" option in chocolate-doom.cfg, or something.

myk said:

Not sure if this has been talked about much: How possible would it be to have Chocolate Doom take mouse turning input at the last instants of startup? Currently it doesn't take any till the screen is ready, while in Doom you can turn the mouse earlier.

This is a distinct possibility. In the startup code it currently eats any waiting events after setting the video mode: this is because I found that every time I started a new game I'd end up facing the wrong way (some leftover mouse events sitting in the queue caused the player to flip round).

Would a fullscreen command prompt be possible? I don't mean actual DOS, but a full screen prompt that behaves likewise (or not full-screen if you choose fullscreen 0.) With a DOSKey-like functionality that'd pretty much be emulating one of Doom's DOS-based features on Windows 9x. I mean, not instead of the current "back to Windows" exit, which is similar to clicking on the Doom icon, but as a "dos 0/1" option in chocolate-doom.cfg, or something.

I'm not sure what you're suggesting here. What exactly would this do and why would it be useful?

fraggle said:

I'm not sure what you're suggesting here. What exactly would this do and why would it be useful?

I guess myk would like a launcher that look and feels like good ol'DOS.

fraggle said:

There are actually three versions of Doom 1.9:

• Doom 1.9 - Used for Shareware, Registered and Doom2
  
• Ultimate Doom 1.9 - Adds episode 4 support.
  
• Final Doom 1.9
  

All three are slightly different. For example, Final Doom's teleporters behave differently.

How did the teleports behave differently in the final doom exe?

DarkknightXC said:

How did the teleports behave differently in the final doom exe?

If you teleport from a sector higher than the destination sector, you teleport in mid-air and fall down.

Julian Hope said:
I guess myk would like a launcher that look and feels like good ol'DOS.

Yes, something like an external but Chocolate Doom dependent command prompt or console...

But in retrospect, perhaps it's not important and would probably be redundant; one difference with the Start Menu's "Run" is that in DOS you don't have to type the full path, but then you can edit more easily so it's about the same. Plus I'm aware this stuff varies somewhat with the operating system and there's usually some sort of command prompt that can often be configured somewhat.

I suppose I said it because with the DOS command prompt you don't have to click on two things (Start and Run), then select the line to edit in Run (or just hit enter); you're out of the game and all you have is the prompt where you start another game, and that seems easier for cases where you might need a small command line edit and then will quickly go back to the game (such as when recording a demo or testing a map), but I'm so used to the DOS screen for that that perhaps I'm biased.

myk said:

Yes, something like an external but Chocolate Doom dependent command prompt or console...

But in retrospect, perhaps it's not important and would probably be redundant; one difference with the Start Menu's "Run" is that in DOS you don't have to type the full path, but then you can edit more easily so it's about the same. Plus I'm aware this stuff varies somewhat with the operating system and there's usually some sort of command prompt that can often be configured somewhat.

I suppose I said it because with the DOS command prompt you don't have to click on two things (Start and Run), then select the line to edit in Run (or just hit enter); you're out of the game and all you have is the prompt where you start another game, and that seems easier for cases where you might need a small command line edit and then will quickly go back to the game (such as when recording a demo or testing a map), but I'm so used to the DOS screen for that that perhaps I'm biased.

You can already run it from the "DOS" command line in Windows...

/me blushes from shame

I'll be damned; I've always been using shortcuts for PrBoom and friends when that works, and I prefer the command line. I was fooled by Windows 98 telling me stuff (like PrBoom or Chocolate Doom) doesn't work in DOS while running the command prompt full screen.

myk said:

/me blushes from shame

I'll be damned; I've always been using shortcuts for PrBoom and friends when that works, and I prefer the command line. I was fooled by Windows 98 telling me stuff (like PrBoom or Chocolate Doom) doesn't work in DOS while running the command prompt full screen.

It can be confusing, especially since we have a "DOS" command line now which isn't really DOS, but you can run DOS programs in :-)

Chocolate Doom is actually a "Windows Console" program: it is a native Windows program, but it displays output in/takes input from the command prompt ("DOS") window.

By the way, I've revamped the Chocolate Doom website. It's now a wiki. I plan to put all kinds of useful information on there for people using Chocolate Doom, and encourage others to contribute any information they feel is useful or interesting.

myk said:

The NWT code is available at the TiC site, though it states in NWT's readme that its MUS player was coded by Vladimir Arnost, which is incidentially the author of MusPlay.

Interestingly, CDoom plays MUS files much better than any other port I've seen. The code is written by Vladimir Arnost (probably the musplay code). The only problem here is that it runs under DOS. It may be next to impossible to write equivalent code under Windows.

Hmmm...that's the only other port I've used that had OPL emulation or whatever it uses...Zdoom and Cdoom...

fraggle said:
Interestingly, CDoom plays MUS files much better than any other port I've seen. The code is written by Vladimir Arnost (probably the musplay code). The only problem here is that it runs under DOS. It may be next to impossible to write equivalent code under Windows.

Yeah, it's from MusLib (the one I linked above), which is pretty much the code for MusPlay. I presumed it would be hard to port that to Windows and Linux, considering what I've been told of the way DOS generally accesses sound devices, but might it not be useful for finding differences in order to emulate DOS-like MUS playback more closely?

I don't think the music playback is really bad as it stands, but if can be improved, cool.

Grazza said:

OK...

I spotted a couple of glitches when testing a demo to see if it would play back in ChocDoom 0.1.1.:

• -merge doesn't work correctly with Scientist 2. The error message is "Error: R_InitSprites: Sprite SGN2 frame A has multip rot=0 lump". It runs OK using a deusf-ed version of the wad though (as does Doom2.exe).
  
• When running the demo, it crashes towards the end with the message "Error: unsupported sample rate 17990". This error doesn't occur in Doom2.exe.

Ok, I've fixed these two bugs. Scientist 2 plays now. The second bug is actually a bug in the WAD - the sample rate is some weird value, but should be 11025. I tried running Scientist 2 in Vanilla (by patching the exe and iwad) and found that those sound effects don't play (it doesn't complain - you just get silence). So I've modified Chocolate Doom to do the same. You don't hear those sound effects.

I have a question concerning the -merge parameter:
Can ANY wad file be "merged into the iwad" and multiple ones as well?
Basically, what's the difference between -file and -merge, other than -file not loading sprites?