Chocolate Doom

abysmal said:

A bug or mishandling of conflicting linedef actions?
Icarus.wad MAP16, sector 216 there is a yellow key door with first encountered side with action 34, open/stay. The other side has action 27 open/close.

In Chocolate the door closes after I originally opened it from first encountered side after I went through. When I opened it again to retrace steps it closed behind me, trapping me out. I tried for awhile to figure out how to open it back up and ended up clipping(I never cheat).
In Doomsday and Legacy this door stays open preventing anyone from getting trapped. I had yellow key but some reason it wouldnt open a second time from original encountered side in Chocolate.

I've tried this, but I seem to be able to open and close the door (216 is the door to the library) as many times as I want. I'm not sure I can reproduce the problem. Instead of other ports, can you compare the behavior against the behavior of doom2.exe and confirm that it is different?

I reinstalled my cd and Doom2.exe also does this.
After door is open it took about 20 seconds of random pushing, anywhere in doorway to get door to close. If I am on the first side I cant reopen door. This happens in Chocolate, Doom2.exe and Doomsday.
I guess its an original bug with game or Iwad was using an odd linedef action combination that the game was not meant to understand.
I must have been desperately looking for a secret when I locked myself out.

My yellow key bug is better than your yellow key bug. Playback of ep1-0500.lmp desynchs because the yellow door doesn't open on e1m4. The weird thing is this only happens in the 64-bit version of choco doom.

Any word on possible OPL emulation or something similar?

A thought just crossed my mind; Chocolate Doom supports resolutions of 640x400 and 640x480. Won't that make it susceptible to VPOs on levels that Doom should normally be able to handle? Microsoft raised Doom95's VPO threshold for this very reason. I presume Chocolate Doom could perhaps raise it somewhat if the game were loaded at these resolutions. No idea how much, though.

It's just doubling up on pixels to get those resolutions, though.

myk said:

A thought just crossed my mind; Chocolate Doom supports resolutions of 640x400 and 640x480. Won't that make it susceptible to VPOs on levels that Doom should normally be able to handle? Microsoft raised Doom95's VPO threshold for this very reason. I presume Chocolate Doom could perhaps raise it somewhat if the game were loaded at these resolutions. No idea how much, though.

It is actually running at 320x200 always, just like Vanilla Doom. When it runs at 640x400 it is just doubled up. This is one of the reasons I'm hesitant to support high res video modes properly.

Ah, I see.

Now I was messing with Chocolate Doom and PrBoom side by side, and recalled that PrBoom (and many other engines) have an option to modify the frequency of sounds in general. I know Chocolate Doom's sound code is perhaps a bit different, but it seems to me that Chocolate Doom plays back sounds more or less like PrBoom when it is set to 11025 Hz. This setting, in turn, sounds less solid than Doom's sound, which seems to be more like PrBoom with the sound set to 22050 Hz. At least on my system. What's all that about? Should something be changed there?

I also hear more static in SDL based engines, but I don't know if that depends on my particular sound drivers. Sound is cleaner in Doom or ZDoom. But this is especially evident in Chocolate Doom, or PrBoom at 11025 Hz.

EDIT: Maybe you've seen this, but I've found a DeHackEd related bug in v0.2.0.A5. Try loading Chocolate Doom with AV's old DEH file, as an example. The line "M_Init: Init miscellaneous info." should start one line below, and not right where the PWAD message ends.

Hey,

Just so everyone knows, Chocolate Doom is definitely not dead and work is continuing on it. Here's an animated screenshot of the new setup tool:

http://www.chocolate-doom.org/wiki/index.php/Image:Setup.gif

Haha! That rules

myk said:

Ah, I see.

Now I was messing with Chocolate Doom and PrBoom side by side, and recalled that PrBoom (and many other engines) have an option to modify the frequency of sounds in general. I know Chocolate Doom's sound code is perhaps a bit different, but it seems to me that Chocolate Doom plays back sounds more or less like PrBoom when it is set to 11025 Hz. This setting, in turn, sounds less solid than Doom's sound, which seems to be more like PrBoom with the sound set to 22050 Hz. At least on my system. What's all that about? Should something be changed there?

I also hear more static in SDL based engines, but I don't know if that depends on my particular sound drivers. Sound is cleaner in Doom or ZDoom. But this is especially evident in Chocolate Doom, or PrBoom at 11025 Hz.

Chocolate Doom plays back sound at 22050Hz (16 bit). I'm surprised that it sounds very different to PrBoom, although the sound code is different.

EDIT: Maybe you've seen this, but I've found a DeHackEd related bug in v0.2.0.A5. Try loading Chocolate Doom with AV's old DEH file, as an example. The line "M_Init: Init miscellaneous info." should start one line below, and not right where the PWAD message ends.

Yeah, I noticed this already. I'll see if I can fix it.

myk said:

EDIT: Maybe you've seen this, but I've found a DeHackEd related bug in v0.2.0.A5. Try loading Chocolate Doom with AV's old DEH file, as an example. The line "M_Init: Init miscellaneous info." should start one line below, and not right where the PWAD message ends.

The "You are playing ALIEN VENDETTA" message is missing an ending newline character, so the next message that gets printed is shown on the same line (which turns out to be the M_Init message).

Interestingly, Vanilla Doom actually behaves in a similar way. It displays "commercial version" indented to the middle of the screen. The same thing happens as with the M_Init message, but because of the indenting it's not very noticeable. I'll add in something to check that these messages have a newline at the end, and to print one if they don't.

EDIT: Here's your fix :-)

fraggle said:
Here's your fix :-)

Thanks!

Talking about sound, I saw the # of channels option in the Setup app. Is Doom actually limited to 8, or is more possible? I changed my CFG entry to 32 and it seems to work, but I'm not entirely certain whether there really is a difference with 8.

Another thing; while Chocolate Doom supports the DOOMWADDIR environment variable, it is ignored when using the -iwad switch.

Curiously, I noted that in alpha 5 if the IWAD is not found it prints nothing, while in alpha 3 it starts the engine, but then stops, saying "Error: Unknown or invalid IWAD file."

I've been creating builds for windows and uploading them to the Doomwire website if you guys want to try those

Be sure to drop by #chocolate-doom on irc.oftc.net and check the sourceforge page

RTC_Marine said:
I've been creating builds for windows and uploading them to the Doomwire website if you guys want to try those

I tried the alpha 6 version; the screen is 100% black. I can hear the game (DEMO1) in progress, but see nothing. I tried with both the included DLLs, and with the ones for alpha 5, and the results were the same.

upgrade your SDL dll's, that problem was noted on the website (1.2.11 = SDL, 1.2.7 = SDL_mixer, 1.2.6 = SDL_net)

Also, make sure the dlls in your windows system32 folder are replaced by the newer ones

RTC_Marine said:
upgrade your SDL dll's, that problem was noted on the website (1.2.11 = SDL, 1.2.7 = SDL_mixer, 1.2.6 = SDL_net)

That didn't help, I'm afraid.

EDIT: I was running it from a console with "SDL_VIDEODRIVER=directx". I ran it on one without that and it worked... but like in alpha 4 or 5, where it forces fullscreen 2 and screenmultiply 2, and looks wrong (streched out horizontally).

Did you try the build (newest post one) from the doomwire site? it has multiplayer and wad merging features compiled in

The other thing to do is run it in Window mode, but that isn't very doomish :P

Here's the reply to my previous report on the issue a few pages back:

fraggle said:
Apparently in your case, it is possible to set modes which are not listed as present (320x200 mode). However, no matter what you do, Chocolate Doom will keep autoadjusting back to the other settings because it thinks it isnt a valid mode :-) I can add another configuration file setting for you to disable the autoadjust.

I'm guessing it hasn't been added to this alpha you have on the Doomwire site.

myk said:

Here's the reply to my previous report on the issue a few pages back:
I'm guessing it hasn't been added to this alpha you have on the Doomwire site.

Yes, it is. Edit chocolate-doom.cfg and change "autoadjust_video_settings" to 0.

fraggle said:
Yes, it is. Edit chocolate-doom.cfg and change "autoadjust_video_settings" to 0.

I had to insert the line as it didn't show up. After that, instead of rendering it as described above, it drew only a small chunk of the DOOM screen near the center. When I set it to 1, it went back to the doubled 320x200 over 640x480 behavior.

Hi. Just a quick update. I've finished the setup program and the latest version has this included. Hopefully configuring Chocolate Doom should become a lot easier now. Any comments or feedback on this are welcome!

Cool, now it does let me bypass the video autoadjust, so my resolution issue is gone.

There's a video setup option for "startup delay"; is it a feature made to go with slower monitors, so that the game won't start while you can't see it?

myk said:

There's a video setup option for "startup delay"; is it a feature made to go with slower monitors, so that the game won't start while you can't see it?

Yes, it's there so you can let the screen settle before the game starts :-)

Fraggle, Thanks for this port, it's so easy to set up a LAN game now and set up video modes. Mouse sensitivity is brilliant! Now All I want is the "fake autorun" in setup. :)

Csonicgo said:

Now All I want is the "fake autorun" in setup. :)

Ummm....

Oh, I didn't see that! Heh, awesome.

Now I can start on the integrated EE frontend, which will use fraggle's textlib ;) It'll be part of eternity.exe, and will thus have direct access to the game's configuration variables, as well as its entire existing code. This'll allow it to do things of the like which have not been seen since the D! frontend ^_^

Quasar said:

This'll allow it to do things of the like which have not been seen since the D! frontend ^_^

Such as...? :P

Does the water look wrong to anyone else with this latest version? I can't provide a screenshot (because the print key and every image-capturing program just give me a black box with Chocolate Doom), but it is easily noticeable if it is different.

Also, the startup_delay doesn't seem to work.