Chocolate Doom

[Porsche Monty]

Here's something weird. Remember the song "D_THEDA2"? it actually plays back correctly on several DOS midi players. Works with my CMI8738's as well as with DosBox. Here's one player that stands out of the lot and is conveniently open source: http://www.pldos.pl/windos/midier.htm

Could this be useful to anybody? whatever's in there may not necessarily apply to Chocolate given that the player handles midis rather than the original mus files, but it can't hurt to try.

[fraggle]

Porsche Monty said:

Here's something weird. Remember the song "D_THEDA2"?

No. Well, I remember it's one of the music tracks from Doom II. What about it?

[Porsche Monty]

-iwad doom2.wad -warp 12

Very dissonant.

[_bruce_]

Plays fine for me. The song itself has some "curvy" harmonies.

[Bashe]

I think it's supposed to sound dissonant with Doom 2's OPL timbres. I've always heard it that way, even on old machines that could run Doom 2 natively with OPL music playback. The fretless bass instrument just has that bizarre sound when played really lowly in Doom 2. Not so much in Doom though, but some of its timbres differ from Doom 2's.

[Porsche Monty]

Here's more on the subject: http://forum.zdoom.org/viewtopic.php?f=7&t=21120

Scroll down to Xaser's post.

[Xaser]

Fark. I wouldn't have taken the sounds down if I knew someone was going to link that post in the future. :P

But yes, Chocolate's OPL player plays that sample back wrong... or at least differently than it did for me in the DOS days.

[Bashe]

I remember someone recording a clip of the map12 music using a genuine DOS machine, and it sounded like the dissonant chord that's apparently "incorrect," but I've also heard that no two sound cards produced the exact same timbres, so this might be one of those cases.

[Xaser]

Well, shoot. I've heard enough people say they remembered it the "broken" way that maybe it's a sound card specific thing after all.

I re-posted the sounds in the linked post, for reference n' whatnot.

[exp(x)]

The "correct" one sounds more familiar to me.

[fraggle]

Can someone distil the details please? Does it sound correct with doom2.exe in DOSbox?

[Porsche Monty]

Nope, they both sound exactly as wrong, only with a third party midi player under DosBox does it seem to improve.

[fraggle]

The only way it might not sound right under DOSbox is if DOSbox's OPL emulation code was inaccurate (which in some edge cases it is). If it plays okay with a third party MIDI player then the MIDI player is just programming the OPL chip in a different way. Obviously the goal here is to emulate Vanilla.

Chocolate Doom uses the DBOPL OPL emulation code from DOSbox. So if it sounds the same as Vanilla does under DOSbox, then Chocolate Doom itself (ie. its MIDI playback code) is doing the right thing. It might be that the DBOPL code is inaccurate. You can verify this if you have a sound card with hardware OPL playback.

[Porsche Monty]

fraggle said:

It might be that the DBOPL code is inaccurate. You can verify this if you have a sound card with hardware OPL playback.

Well, I can definitely tell it's inaccurate as I still have a real Sound Blaster mounted on a 486 sitting right in front of me, yet some people seem to remember it being "broken". I wonder if there's something more to this. Maybe each SB model behaved differently enough to drastically alter the playback under certain circumstances, and let's not forget the recommended sound card for Doom was actually a Sound Blaster Pro, not the SB16 that I use for comparison.

I'm only partially familiar with OPL hardware, so be it improper emulation or an undocumented "feature", I'm sorry to say that's beyond my realm.

[hex11]

Another crash, this time with The Invaders, and it's 100% reproducible (happens every time).

Running it (DEH files not necessary):

chocolate-doom -iwad doom2.wad -merge invadgfx.wad invaders.wad

That gets you to the title screen, which display for a fraction of a second and then:

I_InitStretchTables: Generating lookup tables....
Segmentation fault (core dumped)

Adding -warp 01 makes it playable.

(gdb) bt
#0 V_DrawPatch (x=-2098787741, y=-2115564959, scrn=-2115666517,
patch=0x81e67c6c) at v_video.c:250
#1 0x1c0054b2 in D_PageDrawer () at d_main.c:471
#2 0x1c005295 in D_Display () at d_main.c:291
#3 0x1c00544b in D_DoomLoop () at d_main.c:440
#4 0x1c006421 in D_DoomMain () at d_main.c:1519
#5 0x1c00b6cf in main (argc=-2115564801, argv=0x81e70aff) at i_main.c:152
(gdb) frame 0
#0 V_DrawPatch (x=-2098787741, y=-2115564959, scrn=-2115666517,
patch=0x81e67c6c) at v_video.c:250
250 while (column->topdelta != 0xff )
(gdb) l
245 for ( ; col<w ; x++, col++, desttop++)
246 {
247 column = (column_t *)((byte *)patch + LONG(patch->columnofs[col]));
248
249 // step through the posts in a column
250 while (column->topdelta != 0xff )
251 {
252 source = (byte *)column + 3;
253 dest = desttop + column->topdelta*SCREENWIDTH;
254 count = column->length;
(gdb) info locals
count = 171
col = 171
column = (column_t *) 0x82e70a63
desttop = (byte *) 0x81e57dab ""
dest = (byte *) 0x140 <Address 0x140 out of bounds>
source = (byte *) 0x81e70a61 ""
w = 320
(gdb) print column->topdelta
Cannot access memory at address 0x82e70a63

More info: deutex doesn't like invadgfx.wad:

Extracting graphics...
Warning: Picture TITLEPIC(313): post Y-offset too high. Skipping rest of column.
Warning: Picture INTERPIC(313): post Y-offset too high. Skipping rest of column.

Apparently this PWAD is from 1995, so it must/should have run okay with doom2.exe and deutex shouldn't have any problems with it.

Btw, lots of nice gfx in there, and I don't mean just the Heretic textures.

Oh, and it looks like deutex DOES extract the entire titlepic and interpic. The PPM files look fine in xv, and ImageMagick also:

$ identify graphics/[it]*
graphics/interpic.ppm PNM 320x200 320x200+0+0 8-bit DirectClass 188kb
graphics/titlepic.ppm[1] PNM 320x200 320x200+0+0 8-bit DirectClass 188kb

[fraggle]

v1.6.0 is out.

[Janizdreg]

Awesome, the new release is looking good. And thanks again for your continued hard work on the port, it's very much appreciated by me and the other cocoathusiasts.

Just finished a test co-op session with Ultimate Doom E4's first two levels. There were a couple of short (maybe 1-2 second) lag spikes, but it was otherwise fine and dandy. Although I've experienced similar small lag issues with earlier versions as well, so I'm guessing it's not an issue directly related to this new version. Me and the other player both had a stable and fast broadband connection and we both live in Finland, so it shouldn't be a connection issue either.

Also, entryway implemented an on-the-fly fullscreen/window toggling feature into PrBoom+ in the revision r3790. Could the same code be used in Chocolate Doom as well? I for one would love to see such a feature in Choco, and IMO it would be a major improvement on its general usability.

[axdoomer]

I have the same lag problem but I'm playing using a serial cable between two computers. The connection speed is 19.2 kbps and the game runs smoothly but their's always some random lag spikes of about one second, but it doesn't happen frequently. I didn't post this on Chocolate-Doom's bug tracker because I'm not sure if it's Chocolate-Doom or my null modem connection. I'm tunneling TCP/IP through my serial cable, it took one month before I figured out how it was working and I still have problem getting it to work. Now, I'm not the only one having this lag problem. It's very frustrating during intense deathmatch.

[fraggle]

Janizdreg said:

Awesome, the new release is looking good. And thanks again for your continued hard work on the port, it's very much appreciated by me and the other cocoathusiasts.

Just finished a test co-op session with Ultimate Doom E4's first two levels. There were a couple of short (maybe 1-2 second) lag spikes, but it was otherwise fine and dandy. Although I've experienced similar small lag issues with earlier versions as well, so I'm guessing it's not an issue directly related to this new version. Me and the other player both had a stable and fast broadband connection and we both live in Finland, so it shouldn't be a connection issue either.

Do either of you use wifi? I've found that's the most common cause of lag spikes.

Also, entryway implemented an on-the-fly fullscreen/window toggling feature into PrBoom+ in the revision r3790. Could the same code be used in Chocolate Doom as well? I for one would love to see such a feature in Choco, and IMO it would be a major improvement on its general usability.

I've certainly thought about it in the past. It would be a nice complement to the dynamic window resizing feature I added recently. It needs some more thought as to how it would work. I'm particularly keen to avoid triggering it accidentally - on Windows it's already possible to accidentally hit the Windows key during a game, for example. So it would probably be a good idea to make it ctrl-alt-enter to avoid accidentally triggering.

axdoom1 said:

I have the same lag problem but I'm playing using a serial cable between two computers. The connection speed is 19.2 kbps and the game runs smoothly but their's always some random lag spikes of about one second, but it doesn't happen frequently. I didn't post this on Chocolate-Doom's bug tracker because I'm not sure if it's Chocolate-Doom or my null modem connection. I'm tunneling TCP/IP through my serial cable, it took one month before I figured out how it was working and I still have problem getting it to work. Now, I'm not the only one having this lag problem. It's very frustrating during intense deathmatch.

That is really odd. Perhaps I'll dig up a serial cable and see if I can reproduce it.

[entryway]

Janizdreg said:

Also, entryway implemented an on-the-fly fullscreen/window toggling feature into PrBoom+ in the revision r3790. Could the same code be used in Chocolate Doom as well? I for one would love to see such a feature in Choco, and IMO it would be a major improvement on its general usability.

Is there a sense to have two settings for resolution? Like:
resolution_windowed "640x480"
resolution_fullscreen "1024x768"

[_bruce_]

Choco reigns supreme.

Thx for the update!

[Gez]

fraggle said:

on Windows it's already possible to accidentally hit the Windows key during a game, for example

Unless you have one of these leet gamer's keyboard where you have a sliding button to toggle these keys on and off. ;)

[Janizdreg]

fraggle said:

Do either of you use wifi? I've found that's the most common cause of lag spikes.

I don't. I guess it's perhaps also relevant to mention that I haven't experienced similar lag spikes in other games with this setup.

[fraggle]

And the other player?

[xttl]

fraggle said:

And the other player?

Nope. Some ping statistics:

--- ns-secondary.funet.fi ping statistics ---
384 packets transmitted, 384 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 16.662/17.361/20.539/0.355 ms

(this is not the other player's address though, but the latency between me and him should be as consistent and not much higher, if at all)

I didn't pay much attention to how much the game was lagging since the lag never got to a point where it would have annoyed me too much, so I can't say anything for sure about the lag spikes. I'll try to pay more attention the next time we play (possibly as soon as later today). :-)

[Lila Feuer]

Welp, I don't wanna sound like a tard but I'll be honest, I never did know how to load WADs via -file back in the day, I was also stuck with the "convenient" Doom95 launcher (but I thought that was a mere frontend, not a port) which allows easy WAD loading albeit the lack of DeHacked support made many custom WADs a pain, unless they came with their own executable.

This was until I began using source ports the drag-n-drop method was the way to go.

Now I realize Chocolate Doom takes it's vanillaness literally, so the old method is used to load PWADs. But where exactly do you put these command lines in? I am using a Windows XP Pro SP3 and I doubt you use the Command Prompt to load things. I'd really like to use this port, if only I knew how to make it launch PWADs.

And yes I did look over documentation, nothing helped specify what you're doing exactly (it just implies you already know how to).

[_bruce_]

"chocolate-doom.exe"

right click on it

"properties"

"create shortcut"

right click on the new shortcut

then in the target box go to the end of the scribble and add

-file a_wad_file.wad

"apply"

click on the shortcut and voila your user made wad


In my case the target box contains...
D:\Edit\Doom2\chocolate-doom.exe -file mx.wad

[tm512]

You can also just use the Run dialog in Windows (Windows Key + R), and type in your command line parameters that way... it's a bit less of a hassle than using a shortcut or a batch file.

[Lila Feuer]

Oh. My. God. So easy.

Thanks both of you.

[TimeOfDeath666]

I was trying to make a demo with chocolate doom 1.3.0 but the program exited all of a sudden with an error window. I did that twice and noticed both files were 127 kb. Is there a size limit for demos? Will turning off vanilla_demo_limit solve the problem? How do people record long demos with doom2.exe?