Archy said:

Has someone made a Doom+ equivalent version of Chocolate-Doom? With the following changes:

limit                         : old    * k   = new
-------------------------------------------------------
visplanes[MAXVISPLANES]       : 128    * 8   = 1024
drawsegs[MAXDRAWSEGS]         : 256    * 8   = 2048
SAVEGAMESIZE                  : 180224 * 16  = 2883584
activeplats[MAXPLATS]         : 30     * 256 = 7680
vissprites[MAXVISSPRITE]      : 128    * 8   = 1024
linespeciallist[MAXLINEANIMS] : 64     * 256 = 16384
openings[MAXOPENINGS]         : 16384  * 4   = 65536
(MAXVISSPRITE is the most important one for me, HR2 map 32 is getting annoying.)

I personally think this should be included as an option in the official release because increasing savegame limits, recording long ticks, and altering weapon keys (plus other things) have also been implemented as options but I'm not going to push for it beyond humbly stating my opinion. As long as a version exists, I'm fine.

PS. I took a look at this but I don't understand how to compile it into the Chocolate-Doom source code (sorry if I just said something stupid, I don't understand any of this programing business, anything more complex than QBASIC is completely foreign to me) or if it's even what I'm looking for. I have read the last 3-4 pages of this thread so I kinda understand the previous discussion that took place here.

Myk talked of Strawberry Doom but I don't like it's lack of Vanillaness.


My puristic ChocolorDoom is an offspring of ChocolateDoom - found here on the source forum though it may be more you've bargained for and it's not in it's final form yet.
I can compile/send a clean 1.6.0 with enhanced limits to you.

Btw, Fraggle - Fabien Sanglard has gone the Chocolate Duke route while reviewing the build/duke engine.
Chocolate is a truly inspirational port.

Share this post


Link to post
_bruce_ said:

I can compile/send a clean 1.6.0 with enhanced limits to you.

I would like that very much, and yes, I am aware of this. Also, not that it matters to me but I'm just curious as to why 1.6.0 when 1.70 exists? Any reason? Is it just for convenience?

_bruce_ said:

Btw, Fraggle - Fabien Sanglard has gone the Chocolate Duke route while reviewing the build/duke engine.
Chocolate is a truly inspirational port.

How wonderful. This is something that has been lacking from the Duke community.

Share this post


Link to post

@exp(x)

*** Your compiler (gcc) does not produce Win32 executables!
Here's the full text. (Lots of nos).

I selected the following packages:
automake1.8
autoconf2.5
bash
gcc-mingw-core
gcc-mingw-g++
make
python
subversion
wget
w32api
During the installation, my DNS expired so I had to re-install. I don't know if that has anything to do with the error, but on some of the packages, it said "keep" instead of "install" so I just left it at "keep."

Share this post


Link to post

You can switch cygwin between gcc3 and gcc4.
Try using /usr/bin/set-gcc-default-3.sh

I don't think cygwin's gcc4 will work for win32 executables.

Share this post


Link to post

I read the documentation and all but I'm still a big confused, is "-gameversion final" the same as "-complevel 4?"

Share this post


Link to post
Archy said:

I read the documentation and all but I'm still a big confused, is "-gameversion final" the same as "-complevel 4?"

Yes it is. When Grazza split the Plutonia 2 -nomonsters demo pack into it's own thread he said you can use the executable, PrBoom + with -complevel 4 OR Chocolate Doom with -gameversion final.

Share this post


Link to post

Now this happened:

i_sdlsound.c:38:24: samplerate.h: No such file or directory
i_sdlsound.c: In function `SRC_ConversionMode':
i_sdlsound.c:122: error: `SRC_LINEAR' undeclared (first use in this function)
i_sdlsound.c:122: error: (Each undeclared identifier is reported only once
i_sdlsound.c:122: error: for each function it appears in.)
i_sdlsound.c:124: error: `SRC_ZERO_ORDER_HOLD' undeclared (first use in this function)
i_sdlsound.c:126: error: `SRC_SINC_FASTEST' undeclared (first use in this function)
i_sdlsound.c:128: error: `SRC_SINC_MEDIUM_QUALITY' undeclared (first use in this function)
i_sdlsound.c:130: error: `SRC_SINC_BEST_QUALITY' undeclared (first use in this function)
i_sdlsound.c: In function `I_PrecacheSounds_SRC':
i_sdlsound.c:488: error: `SRC_DATA' undeclared (first use in this function)
i_sdlsound.c:488: error: parse error before "src_data"
i_sdlsound.c:494: error: `src_data' undeclared (first use in this function)
i_sdlsound.c:523: warning: implicit declaration of function `src_simple'
Makefile:670: recipe for target `i_sdlsound.o' failed
make[2]: *** [i_sdlsound.o] Error 1
make[2]: Leaving directory `/home/Archy/chocolate-doom/build/chocolate-doom-1.7.0/src'
Makefile:377: recipe for target `all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Archy/chocolate-doom/build/chocolate-doom-1.7.0'
Makefile:289: recipe for target `all' failed
make: *** [all] Error 2
Full text.

Share this post


Link to post
Archy said:

Look at the first line:
build-chocolate-doom: line 365: sdl-config: command not found

You need to properly have the SDL development headers and libraries installed.

Share this post


Link to post
fabian said:

Look at the first line:
build-chocolate-doom: line 365: sdl-config: command not found

You need to properly have the SDL development headers and libraries installed.

That's irrelevant: the build script builds the SDL libraries for you. You can safely ignore that message.

It looks like it's trying to build against libsamplerate for some reason. Do you have that installed?

You can see that it detects the library:

checking for src_new in -lsamplerate... yes
But it can't seem to find the header for it.

If that's not enough info to fix it, can you post the contents of build/chocolate-doom-1.7.0/config.log somewhere?

Share this post


Link to post

Sorry, I meant to get back to you about this.

If you look here:

configure:3953: checking for src_new in -lsamplerate
configure:3978: gcc -o conftest.exe -O2 -g -Wall  
-I/home/Archy/chocolate-doom/install/include/SDL 
-I/usr/include/mingw -mno-cygwin -Dmain=SDL_main 
-I/home/Archy/chocolate-doom/install/include 
-I/home/Archy/chocolate-doom/install/include/SDL -Wl,-rpath 
-Wl,/home/Archy/chocolate-doom/install/lib 
-L/home/Archy/chocolate-doom/install/lib  
-L/home/Archy/chocolate-doom/install/lib -lmingw32 -lSDLmain 
-lSDL -mno-cygwin -mwindows conftest.c -lsamplerate   >&5
configure:3978: $? = 0
configure:3987: result: yes

You can see that it successfully finds an install of the libsamplerate library. Did you install that in Cygwin setup or something like that? There might be a libsamplerate devel package that you need to also install - otherwise remove the non-devel package from your system.

Share this post


Link to post

Any chance of implementing proper midi support in Linux? It'd be nice to select alsa midi ports or have timidity++ support (like zdoom or dosbox) instead of the not so good SDL mixer.

Share this post


Link to post

The game audio somehow goes mute whenever I launch a multiplayer game using the v2-branch r2591 build. What could be causing this?

Share this post


Link to post

I downloaded Chocolate Doom to my Windows XP laptop, and it works perfectly. However, the Mac version immediately crashes on my MacBook Pro.

Anyone have a solution?

Share this post


Link to post

What version of OS X? Does it help if you run the game in windowed mode instead of fullscreen?

Share this post


Link to post

Windowed mode works. I'm using Mac OS X 10.6.8.

Share this post


Link to post

The Aliens (v2) UV Speed demo on DSDA (atcude2-801.lmp) makes chocolate-doom 1.7.0 freeze half way through E2M5.

Share this post


Link to post

Could portmidi please be added to chocolate-doom? It's not funny but, sdl_mixer is so fubar'ed (literally) that midi playback is completely broken and has been for way too long (we're talking years here). It's a shame too considering chocolate-doom is so good at behaving similarly to vanilla doom (there's so many wads out there that have unique midi music it's just not right to avoid portmidi).

There's been countless threads about prboom-plus's midi problems in the past and they've all been due to sdl_mixer's midi code. Prboom-plus with portmidi was such a fantastic refreshment and improvement when they added it (you could finally send midi data to a software or hardware module properly without any bs whatsoever). Portmidi makes everything wonderful on every platform (Windows, Mac OS and Linux). I personally use Linux and can say portmidi does wonders for midi playback and it doesn't seem bloated with dependencies.

See my post here for examples and reference; beware however, sdl_mixer is sad and gruesome:
http://www.doomworld.com/vb/eternity/64554-could-portmidi-be-added-to-eternity-pretty-please/

Share this post


Link to post
Holering said:

Portmidi makes everything wonderful on every platform (Windows, Mac OS and Linux).


That's only a few platforms... On others, it doesn't even exist.

But let me suggest that there is another solution than trying to jump onto yet another library-du-jour. Check out the old musserver code that someone hacked-up for the old LinuxDoom binaries. It's a simple architecture: the game spawns a mussserver child process and sends it some music data via a pipe, which it plays in a loop until it gets a signal to stop playing. Those days it only handled midi/mus lumps, and only real midi hardware (even if just OPL chip). You can use a similar but more flexible architecture, by making it detect what format the music lump is in. Chocolate Doom only understands MUS/MIDI format and plays them internally. You can let that stand as default behavior, but override those if the user has configured other players. Example musserver configuration file:

MIDI = /usr/local/bin/timidity -l -Od -id -s 44100 %s
MOD = /usr/local/bin/xmp -l %s
The config details above aren't important, it's just an illustration. The only thing that matters is that the external players can loop the music file, and can be killed by the musserver when the map ends (or intermission music ends...) And the sdl_mixer code that's now in Chocolate Doom would just be in the musserver instead (to act as default internal player).

I think you would have better luck implementing something like that as a Chocolate Doom hack than trying to find a single library that works 100% across all platforms. You could also try to fix the SDL bugs that are causing issues on your platform (or at least keep reporting them, and work with the developers to test out their new builds so they can get feedback).

Share this post


Link to post

So basically you're saying it'll probably be easier to hack musserver into chocolate-doom, or tell chocolate-doom how to call musserver?

Sounds great but a problem with me is that I'm a fresh newb with programming. I've written some Linux scripts and hacking something like musserver on my own would be pretty hard I think. That doesn't mean I won't try but damn... Can't even get musserver to compile on 64-bit (Slackware).

I'm wondering if midi code in source ports generally suck because everyone needs windows (something about large latency). Heard odamex may have better code to follow in their recent release.

The problem just aint chocolate-doom either. My favorite source port eternity (besides prboom-plus) also depends on sdl_mixer for midi playback which is kind of why I suggested a library such as portmidi. Sdl_mixer for midi should just be tossed IMO... Hopefully it'll improve for Linux and Mac users in the long run...

Share this post


Link to post

That musserver code from 1996 is quite useless as-is. It's just an architecture example. But something similar wouldn't be terribly difficult to make. Of course there are a few details to iron out, like for example how to control the volume? These days there are many music player front-ends that call upon separate programs to do the dirty work of actually playing an audio file, so it's a reasonable expectation. But there is also the matter of having separate streams for music and soundfx. So you can't just control a single mixer. Either the OS has to have some kind of server that allows multiplexed audio, or you have to fake it somehow in the musserver.

Some might not like this idea, because it sounds "dirty". It means people would have things configured in many different ways. But that flexibility is also its strength, because it means that a reasonable, working configuration should be possible for any system. Throwing away SDL to go with PortMidi or FMOD, or whatever else will just move the problem around a bit. Now maybe your machine will have good music, but someone else's won't. And those other things aren't even as portable as SDL. You'd be better off just fixing the SDL bugs if you wanted a "clean" one-size-fits-all solution.

Of course, in my example, you'd want to fix the SDL bugs anyway, since it would make a good default internal player for the musserver.

Share this post


Link to post

Sounds like there are bugs in SDL_mixer. Rather than trying to convince the maintainers of every Doom source port that uses it to convert to a different sound library, it would be easier to just fix SDL_mixer's MIDI playback to be better. You can file a bug at libsdl.org.

Share this post


Link to post
fraggle said:

Sounds like there are bugs in SDL_mixer. Rather than trying to convince the maintainers of every Doom source port that uses it to convert to a different sound library, it would be easier to just fix SDL_mixer's MIDI playback to be better. You can file a bug at libsdl.org.

Been trying that for a few years now, myself >_>

I am probably going to try implementing portmidi; Odamex has some good clean looking code to make use of it and, looking at the comments and the source of the library itself, it's immediately clear the author has a very solid sense of the serious issues in the Win32 MMSYSTEM API and of how to work around them.

IMO the best thing for SDL 2.0 to do would actually be to integrate portmidi directly.

Share this post


Link to post
fraggle said:

Sounds like there are bugs in SDL_mixer. Rather than trying to convince the maintainers of every Doom source port that uses it to convert to a different sound library, it would be easier to just fix SDL_mixer's MIDI playback to be better.

*cough*

Share this post


Link to post
Quasar said:

Been trying that for a few years now, myself >_>

I am probably going to try implementing portmidi; Odamex has some good clean looking code to make use of it and, looking at the comments and the source of the library itself, it's immediately clear the author has a very solid sense of the serious issues in the Win32 MMSYSTEM API and of how to work around them.

IMO the best thing for SDL 2.0 to do would actually be to integrate portmidi directly.


That is so awesome that you're going to try that! Seriously! SDL_mixer has such fubar'ed midi (at least on linux) it's not even funny. It makes GUS pats appear worse than they are too (I have custom pat sets over several gigs in size that blow away many soundfonts; they're much easier to edit unlike soundfonts that need bloated and expensive software (you can't even choose which bank to use with soundfonts; most probably don't even know they only use one out of possibly dozens of instrument sets when they use a soundfont for games). Someone even made extensions to gus pats so they can have missing features only soundfonts provide, and timidity++ can use compressed pat sets which is unlike sdl_mixer). It's a real shame not being able to use my pat sets with a favorite source port.

I agree that SDL should integrate portmidi. I think letting developers choose what dependencies they want to include would be the best choice. Having a built-in midi player that's based on a really old and limited piece of obsolete software is a bad way to develop a library IMO. Think the greatness of a library is to let developers make their own programs and add desired features at will; not include programs already made. Let alone a broken one.

Share this post


Link to post

If the novert option was implemented to emulate novert.com's behaviour, shouldn't vertical mouse movement be disabled in menus too? Atm you can scroll through menu options by moving the mouse, with novert enabled.

Share this post


Link to post
manny said:

If the novert option was implemented to emulate novert.com's behaviour, shouldn't vertical mouse movement be disabled in menus too? Atm you can scroll through menu options by moving the mouse, with novert enabled.

If this is true, please file a bug.

Share this post


Link to post
fraggle said:

If this is true, please file a bug.


Done. For some reason I couldn't select 'None' as a milestone, only 'v1.0 (example)'. I hope that doesn't mess up your administration.

Share this post


Link to post

Thanks, I just committed a fix. Sourceforge recently "upgraded" the project to (among other things) their new bug tracking system. The version field isn't really used.

Share this post


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