I haven't seen any threads about Chocolate Doom yet, so here we go:
What do you think of it? What features would you like to see implemented into it? What features would you not like to see?

IMO this port is very promising - getting to play vanilla (-like) Doom in Windows XP with sound is something truly awesome.

What I'd like to see is full implementation of all the Doom 1.9 limitations and bugs (even and especially the ones that cause the game to crash). What I'd also like to see is support for high resolutions and uncapped FPS (of course only as options and not as the default setting). Apart from these I consider all the newschool port features (mouselook, jumping, slopes, etc.) a definite no-no for this source port.

Share this post


Link to post

I think it should remove (at least increase) the most annoying limits but have an option to output a warning if that happens. Something like that would be of great benefit for a mapper who wants to be Doom2.exe compatible.

There's really no point in keeping crash bugs in there if something simple can be done about it.

Of course, since it wants to be vanilla-compatible it should not alter any gameplay settings.

Share this post


Link to post

The Compet-N players ought to be jumping for joy over this port, unless for some reason they still deem it unworthy.

Share this post


Link to post

Janizdreg said:
What I'd like to see is full implementation of all the Doom 1.9 limitations and bugs (even and especially the ones that cause the game to crash).

Yes, some are likely to be hard to reproduce since "vanilla" sources aren't available, but the concept of actually porting it (with the experience of using it) "as is" is superb. Once it's pretty much done people could work on variants, like one that doesn't really have some bugs and limits but warns about them or one that's pretty much the same but adds some sort of mass multi-player functionality, or people could take some chocolate implementations and somehow enhance old school engines with the information. The bugs and limitations should include things like flat and sprite loading, as these affect the way maps are made for "vanilla." But the thing would be "first get it ported, then play around."

To illustrate the effect of a bug to the user, let's take the VPO itself; and let's say you are recording. The VPO becomes part of the map in such a way that you either avoid triggering the VPO, or your demo is eliminated. The complete impossibility to record while viewing too many visplanes makes up part of the experience of playing (and recording) or editing for "vanilla." If you start to mess with some bugs you start to change the way it can be used (which includes that it can't.)

What I'd also like to see is support for high resolutions and uncapped FPS (of course only as options and not as the default setting).

This is another feature a variant could well have, but 640x400 is proper as things go (a decent res already, akin to Doom95's hi res and on the same exact ratio as Doom.) I mean, PrBoom-plus already has these features, and it can even record v1.9 demos. Implementing every kinky feature someone requests would mong up the product. Why hi res and not hi frequency sounds or MP3 music? All that deviates the project from its purpose and is already possible with the plethora of engines available. Plus the source is available and anyone can add stuff. But would that be chocolate? Maybe swiss chocolate or chocolate with nuts.

Chocolate Doom seems to be going great as of now, and some of the things already implemented surprised me and are in my opinion crucial to the user-wise "as is" concept, like a novert option and mouse acceleration, as they came with DOS, easily thus getting into Doom, and the way it can work and has often been used. Also the use of exact CFGs plus an additional for special settings was also on target.

The next big step would appear to be DeHackEd support, which has never been fully implemented in any other engines, as far as I know. BEX expands it and is also unable to take some text-based input, like some resource names, for example. Even such things as the -file warning text should be supported (some add-ons use it to say something about the changes or the wad, for instance.)

Eventually there's also MultiPlayer. The standard methods should be kept: IPX; 4 Player LAN, 2 Player serial, and even modem to modem (it may seem ancient, but still useful for people without high speed Internet or people with flat phone bills and a spare dial-up modem.) Additionally TCP/IP otherwise working like LAN would be great, to function like Doom over Kahn, Kali, Git or the former MS Zone, especially since IPX is rather deprecated for today's systems.

Share this post


Link to post

Eternity is already benefitting from this port. I've used code from Chocolate DOOM to repair issues related to releasing the mouse, avoiding rendering while minimized, and restoration of ENDOOM lump support. fraggle's doing some brilliant work by laying down a solid SDL core instead of focusing on flashy features.

Share this post


Link to post
WildWeasel said:

The Compet-N players ought to be jumping for joy over this port, unless for some reason they still deem it unworthy.


Comet-N won't accept anything if it wasn't recored on doom2.exe, so us XP users still won't be able to record Compet-N demos, even with this port.

This sounds pretty good so far. I've always wanted to play the Doom games with the original .exe, but it ran too slow for my PC, even with sound off.

Share this post


Link to post

Holy schnikes! This is almost perfect. Now all we need is OPL emulation (for the ones who didn't have a good sound card :P) and this would be perfect Vanilla Doom playable on any Windows.

EDIT: This may be common knowledge, but I noticed that with Ultimate Doom, every episode has the E1 sky...odd.

Share this post


Link to post
Darkman 4 said:

Comet-N won't accept anything if it wasn't recored on doom2.exe, so us XP users still won't be able to record Compet-N demos, even with this port.

This sounds pretty good so far. I've always wanted to play the Doom games with the original .exe, but it ran too slow for my PC, even with sound off.

Even if we use the Collector's Edition EXEs? I use them on my WinXP desktop and laptop and they work fine, though the laptop has trouble rendering spectre invisibility.

Share this post


Link to post

E1 sky in Ultimate DOOM is a common and apparently now famous Linux DOOM bug that resulted from the DOOM II source being used to run Ultimate DOOM (some genius stripped out the Ultimate sky selection and replaced it with DOOM II's). It should be fixed, as it is *not* a proper v1.9 compatibility feature :P

Share this post


Link to post

Thanks everyone for your kind words.

myk said:

The next big step would appear to be DeHackEd support, which has never been fully implemented in any other engines, as far as I know.

There is dehacked support in the latest version. There are some screenshots on the site of several TCs being run in Chocolate Doom. Dehacked support isn't all finished yet, though.

Eventually there's also MultiPlayer. The standard methods should be kept: IPX; 4 Player LAN, 2 Player serial, and even modem to modem (it may seem ancient, but still useful for people without high speed Internet or people with flat phone bills and a spare dial-up modem.) Additionally TCP/IP otherwise working like LAN would be great, to function like Doom over Kahn, Kali, Git or the former MS Zone, especially since IPX is rather deprecated for today's systems.


I've started working on multiplayer support. This is one area where it will be slightly different. First you have to understand that it is almost impossible to support the old ipxsetup/sersetup system. It is theoretically possible to write code which does the same thing, but this I don't think it is worth my time. IP networks are the dominant form of networking nowadays. Chocolate Doom networking will be UDP/IP based, like all the other ports out there. It will not be "protocol compatible" with Vanilla Doom.

While I guess this does sacrifice its "purity" somewhat, I think it is worth it. There are a lot of players out there who still like playing on Vanilla Doom over any of the multiplayer ports, and I hope this will appeal to them.

Keep in mind that despite this, the multiplayer gameplay should be exactly the same as in Vanilla Doom.

Share this post


Link to post
Bashe said:

Holy schnikes! This is almost perfect. Now all we need is OPL emulation (for the ones who didn't have a good sound card :P) and this would be perfect Vanilla Doom playable on any Windows.


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.

EDIT: This may be common knowledge, but I noticed that with Ultimate Doom, every episode has the E1 sky...odd.


Thanks for the heads up.

Thu Oct 13 23:12:30 2005 fraggle

        Fix Doom 1 skies
(fixed)

Share this post


Link to post

This is great, Fraggle...there is one thing that would be useful (imo): if there is more than IWAD in the directory, make it so like a menu comes up and you can pick...for me it seems to be biased towards Ultimate Doom.

Share this post


Link to post
Bashe said:

This is great, Fraggle...there is one thing that would be useful (imo): if there is more than IWAD in the directory, make it so like a menu comes up and you can pick...for me it seems to be biased towards Ultimate Doom.

You can specify an IWAD using the '-iwad' command line parameter.

Share this post


Link to post

I use Chocolate Doom for testing my maps. You cannot configure the controls though. I have a specific Doom set-up that I use while I play. I hate the default setup Id has for Doom. It sucks.

Share this post


Link to post
DarkFoxSoldier20 said:

I use Chocolate Doom for testing my maps. You cannot configure the controls though. I have a specific Doom set-up that I use while I play. I hate the default setup Id has for Doom. It sucks.

Run Doom's setup.exe probably?

Share this post


Link to post

Darkman 4 said:
Comet-N

Heh.

fraggle said:
While I guess this does sacrifice its "purity" somewhat, I think it is worth it. There are a lot of players out there who still like playing on Vanilla Doom over any of the multiplayer ports, and I hope this will appeal to them.

Keep in mind that despite this, the multiplayer gameplay should be exactly the same as in Vanilla Doom.

Yeah, it makes sense.

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.

Have you managed to look into MusPlay's code? Could that be of any use?

BUGS.TXT says:
An example is the music on the title screen of deca.wad. The music here does not seem to be in the .mus format, yet somehow plays in Vanilla Doom nonetheless. Attempting to convert it using the mmus2mid code used in Chocolate Doom results in a crash.

Is it a true MIDI? Doom plays any real MIDI that can be converted to MUS format due to size, and bigger MIDIs are ignored (no music is heard) but don't cause issues.

Another thing about the music is that it plays on while the game is paused; on an Eternity thread muting it was discussed since pausing it seemed unlikely.

Mouse button stuff: It seems that Chocolate Doom and Doom count the mouse buttons differently; "0" is the left button in either case, but for Vanilla "1" is the right button and "2" is the central one, while for Chocolate "1" is center and "2" right.

Setup stuff: I took default.cfg from Doom and tried it with Chocolate Doom; it froze Windows (98.) The cause was the snd_* entries (except snd_channels.) I set them all to 0 and it ran fine; if Chocolate doesn't use them couldn't it ignore them or set them to 0? Ignoring them is probably better for exchanges, if it's possible.

Will it eventually have a setup.exe equivalent for the controllers? I imagine either a separate EXE, a GUI launched "Chocolate Doom -setup" (by choice closing at the end or entering the game), or an internal menu accessible only during the demo looping sequence (when you start or by using End Game) because Doom doesn't allow ingame controller setup changes. Maybe the setup could also let you set the chocolate-doom.cfg settings?

Mnimizing: Will it be possible to minimize the game when in full screen mode? I think PrBoom lets you do it pretty well, but Chocolate clobbered my system resources to death when I minimized it with Alt+Tab.

Resolutions: When windowed, don't 320x200 and 640x400 make the visuals look flat? For general purposes I'm sure keeping the standard Doom ratio (1.6) for windowed mode is a good idea, since this could be ported to diffrent systems with various resolutions, but shouldn't desktop resolutions (320x240 and 640x480) be included? Maybe with a chocolate-doom.cfg entry called desktop (0/1) where 1 means windowed mode uses the 1.333 ratio? Full screen would ignore it.

Share this post


Link to post
myk said:

Have you managed to look into MusPlay's code? Could that be of any use?

I haven't heard of it. Chocolate Doom uses mmus2mid. Does musplay convert them better?



Is it a true MIDI? Doom plays any real MIDI that can be converted to MUS format due to size, and bigger MIDIs are ignored (no music is heard) but don't cause issues.

Trying to convert it with mmus2mid crashes the conversion code. It isn't a valid MUS, although Doom still plays it. I haven't tried it in ports other than PrBoom.



Another thing about the music is that it plays on while the game is paused; on an Eternity thread muting it was discussed since pausing it seemed unlikely.

I'll look at it. I hadn't realised this was happening, though (perhaps Linux SDL_mixer pauses properly).



Mouse button stuff: It seems that Chocolate Doom and Doom count the mouse buttons differently; "0" is the left button in either case, but for Vanilla "1" is the right button and "2" is the central one, while for Chocolate "1" is center and "2" right.

I shall have to look into this. I'm developing under Linux, so I think I may have "fixed" the mapping under Linux and inadvertently broken Windows mappings.



Setup stuff: I took default.cfg from Doom and tried it with Chocolate Doom; it froze Windows (98.) The cause was the snd_* entries (except snd_channels.) I set them all to 0 and it ran fine; if Chocolate doesn't use them couldn't it ignore them or set them to 0? Ignoring them is probably better for exchanges, if it's possible.

This is odd. I think they should be ignored already.



Will it eventually have a setup.exe equivalent for the controllers? I imagine either a separate EXE, a GUI launched "Chocolate Doom -setup" (by choice closing at the end or entering the game), or an internal menu accessible only during the demo looping sequence (when you start or by using End Game) because Doom doesn't allow ingame controller setup changes. Maybe the setup could also let you set the chocolate-doom.cfg settings?

I have vague plans to write a chocolate-setup program which will behave like setup.exe (but allow extra chocolate configuration, netgame setup, etc). There won't be anything like this for a while though,



Mnimizing: Will it be possible to minimize the game when in full screen mode? I think PrBoom lets you do it pretty well, but Chocolate clobbered my system resources to death when I minimized it with Alt+Tab.

If this happens, then it is a bug. I thought I'd already fixed it, but I will have to give it some more attention.


Resolutions: When windowed, don't 320x200 and 640x400 make the visuals look flat? For general purposes I'm sure keeping the standard Doom ratio (1.6) for windowed mode is a good idea, since this could be ported to diffrent systems with various resolutions, but shouldn't desktop resolutions (320x240 and 640x480) be included? Maybe with a chocolate-doom.cfg entry called desktop (0/1) where 1 means windowed mode uses the 1.333 ratio? Full screen would ignore it.

On my system, I can get a proper 320x200 mode which looks like the originals. It seems video card specific (some cards maybe don't support old modes like 320x200). At the moment I just request 320x200 or 640x400, and SDL seems to be "letterboxing" the screen if that isn't available. I may be able to fix this by querying to see what is actually available, and stretching if the proper mode is not available. I definitely need to fix this.

Share this post


Link to post

fraggle said:
I haven't heard of it. Chocolate Doom uses mmus2mid. Does musplay convert them better?Trying to convert it with mmus2mid crashes the conversion code.

Yeah, mmmus2mid is Jim Flynn's. There's also, Qmus2mid (though I haven't seen its source anywhere.) They seem to both have similar results. MusPlay is a MUS file player, you can get the source, too. It's from the guy who detailed the MUS format (included w/ the source.)

It isn't a valid MUS, although Doom still plays it. I haven't tried it in ports other than PrBoom.

It's fucked up... maybe it got corrupted by the tool that imported it. MusPlay won't play it when XWE extracts it as a lump (it says it's an unknown file format), WinTex won't read it, and DeuTex won't extract it using either method of finding MUS lumps. Perhaps Doom doesn't care about the header or some part of the file, and other programs do, so it reads the maimed lump anyway? That might be why it reads both MUS and MIDI lumps indifferently (as long as the MIDIs aren't too big.)

This reminded me of something because Doom played the title music on deca.wad only from the left headphone. Doom supports something that allows a kind of stereo-like music playback, and also "sourround-like" sound for headphones. Not sure how these would correlate with how SDL handles sound and music in Chocolate Doom:

From a DOOM II readme:
SPECIAL SOUND OPTIONS:
These options are normally disabled for stability reasons, but
the features may work on your computert. Setting the environment
variable DMXOPTIONS to -opl3 may, if you have a modern SB
compatible card, give you stereo music. Setting the same
environment variable to -phase will enable phase-shifted sounds
which is most easily heard with headphones. This deepens the
stereo effect of sound effects.

Both have always worked on true Sound Blaster (16) cards. Not sure if Chocolate Doom is using stereo music; by default Doom's music is mono, unless -opl3 is used.

On my system, I can get a proper 320x200 mode which looks like the originals. It seems video card specific (some cards maybe don't support old modes like 320x200). At the moment I just request 320x200 or 640x400, and SDL seems to be "letterboxing" the screen if that isn't available. I may be able to fix this by querying to see what is actually available, and stretching if the proper mode is not available. I definitely need to fix this.

But isn't that full screen stuff (which works just fine for me)? If a window were displayed showing DOOM in "320x200 full screen" proportions, wouldn't the pixels within the game window be stretched in relation to the rest of the desktop screen pixels? If I take a screen shot in Doom and paste it into Paint it'll look flatter than ingame, but if I paste a 320x240 screenshot it'll be proportioned like the 320x200 Doom full screen, and that's why they used 320x240 and 640x480 for Doom95's windowed modes.

Share this post


Link to post
fraggle said:

I've started working on multiplayer support. This is one area where it will be slightly different.

Irmo!

Share this post


Link to post
Ajapted said:

Irmo!

It's not that radically different :-)

Share this post


Link to post

Another possibility for mus to mid conversion might be using the code Skyjake wrote for Doomsday.

Share this post


Link to post

I notice it doesn't play Ledmeister's Blackbug demo correctly. Maybe it's asking a bit much for it to emulate even a bug like that, but if you're trying to emulate all the original bugs, then I guess you'll want to try for that one too.

Some of Led's other odd demos would also be good for testing bug emulation.

In one of the text files, you mention a fix so that uac_dead works. Note that if the aim is to emulate the Ultimate Doom exe, then this map should not work. It worked OK in Doom.exe v1.9 (which is the same as Doom2.exe v1.9), so perhaps this could be implemented as a command line option. Maybe "-d19"?

Sorry if any of the above duplicates something I have missed in the textfiles or previous posts - I'm a bit jetlagged atm.

Share this post


Link to post
Grazza said:

I notice it doesn't play Ledmeister's Blackbug demo correctly. Maybe it's asking a bit much for it to emulate even a bug like that, but if you're trying to emulate all the original bugs, then I guess you'll want to try for that one too.



I doubt it is possible to emulate that. If it is indeed a memory overflow it heavily depends on the compiler's layout of the global data and some quite non-obvious internal handling that would even break if the exact same code was recompiled with another compiler.

Share this post


Link to post
Grazza said:

I notice it doesn't play Ledmeister's Blackbug demo correctly. Maybe it's asking a bit much for it to emulate even a bug like that, but if you're trying to emulate all the original bugs, then I guess you'll want to try for that one too.

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

In one of the text files, you mention a fix so that uac_dead works. Note that if the aim is to emulate the Ultimate Doom exe, then this map should not work. It worked OK in Doom.exe v1.9 (which is the same as Doom2.exe v1.9), so perhaps this could be implemented as a command line option. Maybe "-d19"?

Sorry if any of the above duplicates something I have missed in the textfiles or previous posts - I'm a bit jetlagged atm.

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. Ultimate Doom and Final Doom have "bouncing lost souls". At some point while developing Ultimate Doom they apparently broke tag 666, which is what stopped uac_dead.wad working.

I'm thinking of adding in a compatibility option, like "-exe" for example. So you could specify '-exe v19' and it would behave like Doom 1.9, or '-exe ultimate' and it would behave like Ultimate Doom.

Share this post


Link to post
myk said:

Mouse button stuff:[/b] It seems that Chocolate Doom and Doom count the mouse buttons differently; "0" is the left button in either case, but for Vanilla "1" is the right button and "2" is the central one, while for Chocolate "1" is center and "2" right.

Mnimizing: Will it be possible to minimize the game when in full screen mode? I think PrBoom lets you do it pretty well, but Chocolate clobbered my system resources to death when I minimized it with Alt+Tab.

I have fixed these bugs now.

Setup stuff: I took default.cfg from Doom and tried it with Chocolate Doom; it froze Windows (98.) The cause was the snd_* entries (except snd_channels.) I set them all to 0 and it ran fine; if Chocolate doesn't use them couldn't it ignore them or set them to 0? Ignoring them is probably better for exchanges, if it's possible.

Are you sure this was what was causing it? I had a look at my default.cfg file and snd_* were all set to non-zero values; chocolate doom runs ok. These variables are basically ignored. Are you sure you didn't change anything else?

Share this post


Link to post

fraggle said:
Are you sure this was what was causing it? I had a look at my default.cfg file and snd_* were all set to non-zero values; chocolate doom runs ok. These variables are basically ignored. Are you sure you didn't change anything else?

Yeah, sorry, that wasn't it; I tried it now and it ran fine. I hadn't changed anything else, though. Maybe it wasn't Chocolate Doom's fault... Windows 98 isn't exactly the most stable system out there, and it had been running for a while. I even ran it with a bunch of programs running (that I was using back when the freeze occurred) and it was quite okay.

Share this post


Link to post
This topic is now closed to further replies.