Chocolate Doom

[TimeOfDeath666]

Ok, thanks. I'm just curious why I haven't heard about a DOS utility for vanilla doom that changes keys (since you can't change the weapon keys in vanilla doom). So, if that IS possible, I don't see why that would be any different than using a novert utility, or a turn180 utility (legal for compet-n?).

[Blastfrog]

fraggle said:

Vanilla Doom actually doesn't have any proper auto-run option - at all. However, there is a hack that uses the joyb_speed configuration variable - by setting it to a special value, it tricks the game into thinking that the joystick run button is always being held down (this works even if the joystick is disabled).

In the upper half of my post, I was talking about Strife's buggy vertical looking, not that.

[fraggle]

eternal slumber said:

Ok, thanks. I'm just curious why I haven't heard about a DOS utility for vanilla doom that changes keys (since you can't change the weapon keys in vanilla doom). So, if that IS possible, I don't see why that would be any different than using a novert utility, or a turn180 utility (legal for compet-n?).

It might be possible, but from what I know about how direct access to the keyboard hardware works under DOS, I think it might be fairly difficult.

[RestlessRodent]

eternal slumber said:

Ok, thanks. I'm just curious why I haven't heard about a DOS utility for vanilla doom that changes keys (since you can't change the weapon keys in vanilla doom). So, if that IS possible, I don't see why that would be any different than using a novert utility, or a turn180 utility (legal for compet-n?).

You could probably handle your own keyboard interrupt, possibly.

[fraggle]

That's my point, actually, because that's what Doom does. Installing your own interrupt handler might work for some programs, but not for Doom, which would overwrite your interrupt handler with its own.

[mammajamma]

I noticed a bug with the audio: when I turn the music volume down, the SFX volume goes down with it.

I'm running r2380 on 7 Professional 64-bit.

[Mithran Denizen]

mammajamma said:

I'm running r2380 on 7 Professional 64-bit.

There's your problem, I think; blame MS's half-assed MIDI interface implementation since Vista. You can pick OPL synth through the setup utility to get around this, but that might not be good enough for you.

[exp(x)]

mammajamma said:

I'm running r2380 on 7 Professional 64-bit.

Just an FYI: if you really want to be bleeding-edge, the v2 branch is more current than trunk.

[Janizdreg]

mammajamma said:

I noticed a bug with the audio: when I turn the music volume down, the SFX volume goes down with it.

I'm running r2380 on 7 Professional 64-bit.

As noted in earlier messages, the main issue indeed lies in the crappy MIDI support of the new Windows versions. In addition to using OPL emulation, the other currently possible workaround is using TiMidity and a sound font for MIDI playback. Here's a guide for setting it up if you wish to give it a shot.

I think I'll try writing up a Choco wiki FAQ section on the Windows MIDI issues at some point, as these questions definitely are "frequently asked" with Windows 7 becoming commonplace.

[Gez]

Backporting PrBoom+'s new MIDI code (which include a FluidSynth option) might be a good idea for a future feature.

[entryway]

Gez said:

Backporting PrBoom+'s new MIDI code (which include a FluidSynth option) might be a good idea for a future feature.

portmidi works also fine and does not require sound fonts

[Janizdreg]

I fully agree with Gez and entryway. Oh yeah, and another freshly implemented PrBoom+ feature I'd love to see borrowed into Choco is the ability to switch from windowed mode to fullscreen and vice versa during runtime.

[axdoomer]

Looks like the multiplayer is not working for Doom in v2. When I try to start a game, it starts a single player game. So nobody can join the game.

EDIT: Oh, yeah. It's because the multiplayer code is not written for every game yet. I should have figured this out before.

EDIT2: It's working very fine now (r2411). It was a good idea to add a game browser, it's much more easier to join a game on the internet with it.

[Moustachio]

Whenever I try to set my use key as the right-mouse button in Hexen, it never functions properly. Is this intentional?

[MP2E]

axdoom1 said:

EDIT2: It's working very fine now (r2411). It was a good idea to add a game browser, it's much more easier to join a game on the internet with it.

Use doomseeker to search for Chocolate Doom games easily.
http://skulltag.net/doomseeker

Also, Chocolate Doom v1.6.0 has been submitted into the ports tree for FreeBSD. It should be part of the official ports tree within the week(crossing my fingers for the port to be included in 9.0-STABLE when it's released)

[Convex]

Just tried out the new (v2) version of this with Heretic, great work guys! Thanks for all the hard work putting this together.

[Csonicgo]

I'm trying to compile the blasted thing on cygwin and got this error:

$ ./build-chocolate-doom -svn
mkdir: cannot create directory `/home/caf/chocolate-doom': File exists
mkdir: cannot create directory `/home/caf/chocolate-doom/packages': File exists
mkdir: cannot create directory `/home/caf/chocolate-doom/build': File exists
Have SDL_net.h
Have SDL_mixer.h
./build-chocolate-doom: line 401: syntax error near unexpected token `fi'
./build-chocolate-doom: line 401: `fi'

plz2help as I am not good with computer.

[axdoomer]

I have problems compiling v2-branch with Microsoft Visual C++ 2010 Express and Code::Blocks.

[chungy]

CSG: that sounds like a bug with fraggle's script

[fraggle]

Fixed, sorry about that!

[Csonicgo]

fraggle said:

Fixed, sorry about that!

awwww yeah

[Quasar]

Csonicgo said:

awwww yeah

And no random BSODs from SDL?

[Csonicgo]

Quasar said:

And no random BSODs from SDL?

Nope! not yet, anyway.

[fraggle]

Nice. I've had quite a few bug reports about Windows 9x, though. Don't expect any support for it :)

[Csonicgo]

fraggle said:

Nice. I've had quite a few bug reports about Windows 9x, though. Don't expect any support for it :)

the only problem I had is that I was OUT of video memory. 320x200 can't be forced for some reason (winquake has no problem with this, however) but windows GDI fixes a lot of problems. DirectX IS faster, but most of the CPU time is spent writing to the screen, and not the actual rendering of the screen. There's that much overhead.

Here, have an aspect-ratio corrected version.

[_bruce_]

Csonicgo said:

awwww yeah

Cool!

[Csonicgo]

I've come to the conclusion that SDL sucks.

I know that's a shocker, but seriously - it sucks.

To demonstrate how much it sucks, I did a comparison of it to something that already sucks - Doom 95 - and tested the framerates.

This was tested on a 100MHz Pentium Processor (minus any famous errata).

Doom95 at 640x480 max screen size (with increased resolution!) = 20-28 fps, mostly 17 fps average. the biggest dip (MAP29) was 10 fps.

Chocolate Doom in Direct X mode : I'm barely pulling 10 fps on MAP01. MAP29 is unplayable.

I'm sure there are technical reasons for this: mainly, the overhead of SDL.

[fraggle]

Csonicgo said:

I'm sure there are technical reasons for this: mainly, the overhead of SDL.

No offence but it sounds like you may be jumping to conclusions there. Doom 95 was optimised for the computers of its day; Chocolate Doom isn't optimised for those machines. I'm not surprised at all that performance isn't great.

Your analysis just compares frame rates and doesn't actually analyse what's really causing the lower performance. You're leaping to the assumption that "the overhead of SDL" is the only possible thing that could be causing it; it isn't.

As an example, the biggest performance bottleneck with Chocolate Doom is the aspect ratio correction / screen scaling code (rendering Doom's 320x200 screen takes next to nothing on modern computers). The 600MHz Pentium 3 I originally used to write that code could just about handle 640x480 scale-up at full frame-rate, so I'd expect it to swamp a 100Mhz machine. But from your comments about being unable to "force 320x200 mode" it doesn't sound like you've even turned that off.

Another thing is that with a machine that old, you're back to the column and span rendering functions (used to draw the walls/floors) being the performance bottlenecks. Vanilla Doom (and presumably Doom 95 too) had hand-optimised assembler implementations of those functions; Chocolate Doom doesn't.

[Csonicgo]

fraggle said:

As an example, the biggest performance bottleneck with Chocolate Doom is the aspect ratio correction / screen scaling code (rendering Doom's 320x200 screen takes next to nothing on modern computers). The 600MHz Pentium 3 I originally used to write that code could just about handle 640x480 scale-up at full frame-rate, so I'd expect it to swamp a 100Mhz machine. But from your comments about being unable to "force 320x200 mode" it doesn't sound like you've even turned that off.

I have turned it off. However, Chocolate-doom doesn't understand that it can use 320x200. I assume it's a driver issue.

I can use 320x200 windowed, but I will get video memory errors with DirectX (literally out of memory). When I install my ATI Mach64 I'll see if that solves any problems. Right now I'm on a Trio64V+ which is bottom of the barrel.

[Wagi]

Just a curiosity: How well is the OPL emulator supposed to handle real MIDIs and a large number of voices playing at once? I tried using a custom-made MIDI in there the other day and OPL slowed it down to about half the tempo and some of the tracks didn't line up properly.