Chocolate Doom

[ixfd64]

This is probably a stupid question, but is the GUI launcher (the one that lets the user select the IWAD) exclusive to the Mac version? I can't seem to find it on Windows.

[Holering]

If I try adding hardware midi support for linux (using an external command) with Mix_SetMusicCMD(aplaymidi -p 128:0); under chocolate-doom-1.7.0/src/i_sdlmusic.c

static void I_SDL_PlaySong(void *handle, int looping)
{
    Mix_Music *music = (Mix_Music *) handle;
    int loops;

    if (!music_initialized)
    {
        return;
    }

    if (handle == NULL)
    {
        return;
    }

    if (Mix_SetMusicCMD("aplaymidi -p 128:0")==-1)
    {
    perror("Mix_SetMusicCMD");
    }

I get

Cannot open /tmp/doom.mid - No such file or directory

Looks like no file gets generated despite the code being there (specifically the filename code). Also get an error during ./configure (Mix_SetMusicCMD command not found error).

Any suggestions to fix that (I'm not really a programmer)?

BTW: Trying to reduce sound latency which is noticeable on my end. Changed MAX_SOUND_SLICE_TIME to 10 (and tried 30) from 70 but that doesn't seem to fix it (feels like it's using 4096 kb of buffer and it snaps once in a while). Have no problems with all other programs and sound except chocolate-doom (that's because I can edit source code though :P).

[fraggle]

Comment out the remove() call that deletes the temporary MID file and see if that fixes it.

You probably only need to call Mix_SetMusicCMD once during the initialization stage.

ixfd64 said:

This is probably a stupid question, but is the GUI launcher (the one that lets the user select the IWAD) exclusive to the Mac version? I can't seem to find it on Windows.

Yes. Only the Mac version has a launcher.

[printz]

Any possibility Chocolate Doom will use Eternity's SDL GL 2D engine backend? I can only run EE through 2880x1800f (or rather 2560x1600f until Q finishes the abstraction) resolution at good frame rate if I use that. THOUGH to be fair, Chocolate-Doom does not need or benefit from high resolutions. In any case, if I do set a high resolution, the image is strongly letter-boxed:

Application launchers are much better than going into Explorer and running a bat file with your wads. I wish they caught on on Windows too.

[Holering]

fraggle said:

Comment out the remove() call that deletes the temporary MID file and see if that fixes it.

That worked! Only now a doom.mid remains in the /tmp directory after closing chocolate-doom.

Didn't know sdl could call an external player. It's a lot of good because that provides hardware midi access via an external player (aplaymidi didn't loop on my end but pmidi works fine however) all with SDL (no need to change libraries or anything and it's easy); Linux users can have proper midi support this way and it can be done on every source port using SDL_mixer for music. Now I gotta get this going on Eternity!

All that's left is recognizing a variable (something standard like $MIDI; or $CHOCOLATE_DOOM_MIDI) to use whatever external player a user wants (pmidi, timidity++, etc.) instead of hard coding the desired program into i_sdlmusic.c. Old timidity built into sdl_mixer should be kept out on all distributions.

For now, Mix_SetMusicCMD(getenv("MIDI")) before Music = Mix_LoadMUS(filename); and commenting remove(filename); and Z_Free(filename); is a way to get proper midi playback in Linux like so:

     // Load the MIDI

    Mix_SetMusicCMD(getenv("MIDI"));
    music = Mix_LoadMUS(filename);
    if (music == NULL)
    {
        // Failed to load

        fprintf(stderr, "Error loading midi: %s\n", Mix_GetError());
    }

    // remove file now

//    remove(filename);

//    Z_Free(filename);

    return music;
} 

It is better to use timidity++ instead of pmidi (or similar) though, for those who don't have hardware midi players (such as roland modules or sound blaster cards). Don't know why Timidity++ was never included in sdl_mixer instead of old timidity after all this time but oh well. Notice in above example I turned timidity++'s volume down to 20 (-A20,100). That's because on my end timidity++ is really loud and clips (this happens with zdoom); don't know if it's my fault or a program fault. Also, Roland SC-8850 is is emulated with --module=4 (roland sc-55 can be used with --module=1 instead).

Regards

EDIT:
Changed code to read environment variable $MIDI instead. You can do

export MIDI="nameofmidiprogram withoptions"

this way and use whatever program to process the midi. It's up to developers to properly add something like this when linux OS is detected or make it an option, during ./configure (would greatly improve windows too since the bad default general-midi is used and users could set individual midi volume through the $MIDI variable if they use timidity++; zdoom lets you use timidity++ through cvar by giving it the timidity.exe location for instance). Suprised this isn't the default way of handling midi; many users are severely limited to sdl_mixers default choice without this option and get bad midi (some probably don't even know it and assume midi sounds bad in general; wonder what they'd think if they heard vanilla doom in dosbox with one of my pat sets).

Getting this to work on Eternity looks like re-writting some parts is neccessary;SDL_rwops and Set_MixLoadMUS_RW use pointers to memory instead of files=probably lots of work (easier than adding a library perhaps).

[twipley]

Hey, fraggle!

I was just wondering if you were planning implementing both of these below to the next version?

http://sourceforge.net/p/chocolate-doom/bugs/245/
http://sourceforge.net/p/chocolate-doom/bugs/246/

Just out of curiosity. For the sake of a classic game. :)

[Holering]

You could add support for playing external files. SDL already has support for popular audio codecs so that makes it even easier for ogg and mp3 (don't know about flac). The earlier post with the external program call could also play whatever sdl doesn't handle assuming you have the right program installed (command line version AFAIK). You'd have to look through the source code and find the music definitions and other stuff though; and change all of it accordingly.

[Ramon_Demestre]

Bug:
When playing "3 Heures d'agonie" (3hafinal.wad) with vanilla DOOM2.EXE v1.9, when I change level, just after Intermission screen, I get a crash with message:

Z_CheckHeap: block size does not touch the next block

The crash does not occur when playing with chocolate-doom, which is a compatibility bug.

[chungy]

You need to report it on the bug tracker, else it'll be quickly forgotten about just sitting here in a thread.

[hex11]

The Wolfenstein Sprites mod has some intermittent effects, where sometimes the Chocolate Doom screen will completely freeze up immediately after the officer starts to fire a rocket. The music keeps playing, but the game itself is frozen, and no menu can be accessed (at that point, have to "pkill -9 chocolate-doom" from another terminal). Has this happened before with other DeHackEd mods?

[andrewj]

It's possible to create infinite loops with DeHackEd state frames, since some action functions use P_SetMobjState() to set a new state, but P_SetMobjState() also immediately calls the action function of the new state if it has one.

[Dime]

If I place it on plutonia, map 1 and ultra-violence. Does that assume complevel 4 and I don't need it in the extra parameters if im recording a demo?

Just curious if I still need that in the extra parameter line

[Springy]

I think you need -gameversion final or something along those lines in chocolate doom.-complevel 4 is a PrBoom plus parameter. I was going to PM you with instructions on how to record as you seemed interested.

[Dime]

Yes, I am interested because im trying to do a 30 pl uv demo. And if you have not noticed, im a noob with demos. I just learnt today after testing that the turning radius changes completely lol.

Bit of a nasty surprise after only doing it on stream.

[Springy]

Well, I'm pretty certain I read somewhere that is the correct parameter and that -complevel is to do with PrBoom and it's successor PrBoom plus.

Off topic: It was only because I noticed somewhere before that you typed something about lack of knowledge on recording and then I forgot to send you a PM to help. Nice to see a new player around and I look forward to watching your demos. I also wish that I had the motivation to do a complete 30 max run.

[Dime]

Thanks Springy, appreciate it!

[duh]

[_bruce_]

XCOPY said:

Is there any compile flags to remove chocolate-doom's limits (visplanes, etc)?

The limits rely on '#define' statements.
e.g.: '#define MAXVISPLANES 128'

Somewhere on the forum should be my version of choco 1.7.0 with raised limits and opengl scaling.
Would have provided a link but I've skimmed through pages of the sourceport section but couldn't find it.

[hex11]

I was browsing a shovelware and found a small inconsistency with Chocolate Doom. The disc has a whole bunch of PWADs extracted into one directory, but trying to load any of them didn't work, because one of them is named TNT.WAD. But:
- this TNT.WAD is a PWAD
- DOOMWADDIR environment var points to a directory that has the registered DOOM v1.9 IWAD

It only works if I run it like this:
chocolate-doom -iwad /path/to/doom.wad -file tnt.wad

[andrewj]

hex11 said:

It only works if I run it like this:
chocolate-doom -iwad /path/to/doom.wad -file tnt.wad

Did you 'cd' into that directory full of wads?

i.e. I reckon this would work: cd $HOME; chocolate-doom -file /path/to/wads/tnt.wad

[hex11]

Yeah, I was browsing the disc with a file manager (vifm), so my working directory had all those wads (including tnt.wad). It does work from another directory, but:
- that makes browsing with file manager/launcher useless when using only DOOMWADDIR (rather than explicit -iwad argument)
- doom.exe doesn't care about tnt.wad - it just treats it like any other PWAD (ignores it completely unless you pass it with -file argument, and then it's playable)
I've been running doom.exe 1.2 mostly, but I also tried 1.9 and it behaves the same way.

Probably nobody will encounter this unless they browse the same shovelware...

Edit: found another shovelware with a big directory of unpacked files, including a DOOM1.WAD that somehow got mixed in with the PWADs. It's the unmodified v1.5 shareware IWAD, according to its MD5 hash. doom.exe doesn't care about it either, even if you copy it into C:\DOOM (it uses the registered IWAD instead).

[Dime]

So my demos seem to close themselves after around 15-16 minutes. The demo will record itself without pressing the "record demo button". Does this have to do with the option "Vanilla Demo Limit" in the options?

[Dragonsbrethren]

Yeah, vanilla Doom limited the demo file size to 128KB by default, that option will remove the limit. (You can also change the KB limit with the -maxdemo parameter, but there's no real reason to do so over removing the limit entirely on a modern HDD with plenty of space.)

[Average]

I don't know if this is a bug or not but I thought it worth mentioning. Batman Doom crashes at the title screen using the lastest Choco build r2610. There's no warning or message. It just crashes back to the desktop.

[exp(x)]

Are you following this? http://www.chocolate-doom.org/wiki/index.php/Batman_Doom

[Average]

^
Yeah. It used to run fine when I was using the official 1.6 release. I just copied the SVN build files into the same folder overwriting the old files.

I just tried a fresh install too. No go. :(

[Da Werecat]

Looks like this guide is now obsolete, because they've ditched gcc3 for good. Besides, I couldn't find gcc-mingw-core in their list. Since I know approximately bupkis about all this stuff, it took me a lot of time to figure out what is wrong, where to get all the removed packages, and how to install them properly.

[hex11]

Average said:

I don't know if this is a bug or not but I thought it worth mentioning. Batman Doom crashes at the title screen using the lastest Choco build r2610. There's no warning or message. It just crashes back to the desktop.

A local build (OpenBSD/amd64) of chocolate-doom-code-2605-branches-v2-branch works for me: Batman title screen is displayed, and then the demo starts playing. That was the current version when I downloaded the v2 branch a couple months ago.

[Dime]

Not sure if this happened in vanilla doom a lot or what, but everytime im doing gateway of hell map 30 for a plutonia movie, I seem to get errors on that map. Usually im using a bfg to take out the chaingunners when the moving wall is coming down. No error box comes up or anything. Just takes me out of doom completely.

[fraggle]

Average said:

^
Yeah. It used to run fine when I was using the official 1.6 release. I just copied the SVN build files into the same folder overwriting the old files.

I just tried a fresh install too. No go. :(

Please paste the contents of stdout.txt and stderr.txt (I assume you're using Windows).