Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Janizdreg

Chocolate Doom

Recommended Posts

When I run Chocolate Doom full screen and exit, the system stays with Chocolate's resolution and I have to fix it in my system settings. I'm using Ubuntu 12.04.

Edit: Never mind, this got fixed somehow... maybe after PrBoom got installed, which I think got installed with the Eureka editor.

Share this post


Link to post

All Chocolate programs seem to suffer a bug whereby stereo sound is stereo on the left channel only. For example, on MAP01 of Doom 2, turn left so that the zombiemen are at your right, fire your pistol, and the monsters' wake-up sound will seem to come from the centre. Much more obvious with headphones on.

Share this post


Link to post

I'm having some weird problems running the latest version of NOVA (https://www.mediafire.com/?897cmyoh3l45qa0) in fabian's Chocolate Doom port, that also exist in normal Chocolate Doom. (Some maps exceed vanilla limits but at least the starts of maps 01 and 02 are OK.)

If music is set to OPL, the title screen plays no music, the music of the first map is really off, and trying to IDCLEV to another level results in lots of system lag until I exit the game.

If music is set to Native MIDI, music plays fine and changing levels causes no problems.

I don't have vanilla doom2 to test (only Doom95, ecch) but doom2plus running in DOSBox works fine using OPL music.


Somewhat relatedly, trying to set the music device to Native MIDI will sometimes try to put "(null)" as the value for the Timidity configuration file. MIDI playback doesn't work unless I clear that field with backspace.

Share this post


Link to post

Are there any plans to take advantage of SDL2's new features? Specifically, there is a separation between logical resolution and actual resolution that seems to almost be made specifically to support Chocolate Doom.

Share this post


Link to post

How do I get Timidity soundfonts to work with Chocolate Doom?

My timidity cfg file is in /etc/timidity/timidity.cfg and contains the following content:

soundfont /usr/share/sounds/sf2/gm.sf2
In ~/.chocolate-doom/chocolate-doom.cfg I have this line:
timidity_cfg_path             "/etc/timidity/timidity.cfg"
Replacing the above line with the following allows me to here music through timidity but not with the soundfont gm.sf2:
timidity_cfg_path             "/etc/timidity/freepats.cfg"
I can here midi music played through timidity with gm.sf2 in DOSBox just fine (dosbox-0.74.conf contains the line "midiconfig=129:0") so I know timidity can is using the soundfont properly.

While searching on the Internet I could find people with similar problems but couldn't find a solution.

Chocolate Doom version: 2.0.0
OS: Debian GNU/Linux 7.4 amd64

Thanks!

Share this post


Link to post

@Archy: Chocolate Doom does not invoke Timidity++ directly, it uses an ancient version of Timidity built in to SDL_mixer that doesn't support soundfont files. However, as of SDL_mixer 1.2.12, there is an environment variable you can set to make it use fluidsynth instead, which DOES support soundfonts.

Use:

export SDL_SOUNDFONTS=/usr/share/sounds/sf2/gm.sf2
Hope this helps.

Share this post


Link to post

I typed in "export SDL_SOUNDFONTS=/usr/share/sounds/sf2/gm.sf2" in terminal without quotes and installed fluidsynth from the Debian repository. Do I need to configure fluidsynth or Chocolate Doom in some way to make this work? What do I need to put in for "Timidity configuration file:" in chocolate-doom-setup?

Share this post


Link to post

Last week, I tried Chocolate-Doom on Linux-Mint. I built v2.0, since the available package is out of date. It ran fine, but I had a couple of problems.

The executable "chocolate-doom" was 2.24 MB in size and "chocolate-doom-setup" was 565KB. Other games had similar sizes. It looks very big to me, the files from v1.7 were much smaller I think. That may be a bug. It happened one time with the Windows built.

I had a problem when I left Chocolate-Doom. That was the first time I ran it on the machine, so the resolution was set to 640x480 (that resolution is sometimes set to 320x200 on other machines). When I left the game, the resolution didn't went back to 1600x900, which was my desktop resolution. I had the same problem with Freedoom, which was bundled with a old version of PrBoom. I couldn't see anything so I opened the console and I typed "xrandr -s 1600x900" to solve my problem. Is that a problem with my video drivers or a problem with SDL?

So after this problem, I came up with the idea that Chocolate-Doom should detect and use the desktop's resolution the first time it's launch. That would also avoid the delay when the screen needs to change its resolution.
320x200 and 640x480 are the resolutions that Chocolate-Doom uses when it launches for the first time. These two are stretched on LCD monitors and they look very blurry.

I like to play Chocolate-Doom on Linux, one thing I saw and I can't explain, is that the frame rate looks smother on Linux (verified on Ubuntu and Mint) than it does on Windows. I know the game runs at 35 FPS, but is there something like motion blur between frames?
(i.e.: Older movies were recorded at 24 FPS, but you can't see the frames change on your 60Hz screen because of progressive scan)

Share this post


Link to post
axdoom1 said:

Last week, I tried Chocolate-Doom on Linux-Mint. I built v2.0, since the available package is out of date. It ran fine, but I had a couple of problems.

The executable "chocolate-doom" was 2.24 MB in size and "chocolate-doom-setup" was 565KB. Other games had similar sizes. It looks very big to me, the files from v1.7 were much smaller I think. That may be a bug. It happened one time with the Windows built.

Typical size for the main executable should be under a megabyte. I expect the Mint packages aren't being stripped (ie. they contain debug symbols).

I had a problem when I left Chocolate-Doom. That was the first time I ran it on the machine, so the resolution was set to 640x480 (that resolution is sometimes set to 320x200 on other machines). When I left the game, the resolution didn't went back to 1600x900, which was my desktop resolution. I had the same problem with Freedoom, which was bundled with a old version of PrBoom. I couldn't see anything so I opened the console and I typed "xrandr -s 1600x900" to solve my problem. Is that a problem with my video drivers or a problem with SDL?

Could be the graphics drivers. Can you at least confirm that Chocolate Doom exited cleanly? ie. it doesn't crash and bomb out with an error, you get the ENDOOM screen shown.

So after this problem, I came up with the idea that Chocolate-Doom should detect and use the desktop's resolution the first time it's launch. That would also avoid the delay when the screen needs to change its resolution.
320x200 and 640x480 are the resolutions that Chocolate-Doom uses when it launches for the first time. These two are stretched on LCD monitors and they look very blurry.

I agree, these aren't good defaults any more. Using the desktop resolution is probably sensible, but some people have very high res screens now and the software scaling isn't enough. What's needed is hardware (OpenGL) scaling, which I keep meaning to look at.

I like to play Chocolate-Doom on Linux, one thing I saw and I can't explain, is that the frame rate looks smother on Linux (verified on Ubuntu and Mint) than it does on Windows. I know the game runs at 35 FPS, but is there something like motion blur between frames?
(i.e.: Older movies were recorded at 24 FPS, but you can't see the frames change on your 60Hz screen because of progressive scan)

There's nothing like motion blur. I don't know what this can be.

Share this post


Link to post
Archy said:

I typed in "export SDL_SOUNDFONTS=/usr/share/sounds/sf2/gm.sf2" in terminal without quotes and installed fluidsynth from the Debian repository. Do I need to configure fluidsynth or Chocolate Doom in some way to make this work?


Usually not. In Debian, the SDL_SOUNDFONTS variable is preset to the two reasonable sound fonts available in Debian. I am currently not sure if you also need to additionally set SDL_FORCE_SOUNDFONTS=1 on the command line if you specify another font. Could you please try this?

What do I need to put in for "Timidity configuration file:" in chocolate-doom-setup?


Well, nothing. If you are using fluidsynth you are *not* using timidity. It's one or the other.

Share this post


Link to post
Wagi said:

Are there any plans to take advantage of SDL2's new features? Specifically, there is a separation between logical resolution and actual resolution that seems to almost be made specifically to support Chocolate Doom.

Because I feel like this didn't get noticed, I second this. It'd be nice to see some source ports start to migrate towards SDL2. Support both 1.2 and 2.0, if anything.

Share this post


Link to post
fraggle said:

Typical size for the main executable should be under a megabyte. I expect the Mint packages aren't being stripped (ie. they contain debug symbols).

How can I build a version that is not debug? I used these instructions. (Note: I couldn't get it to work with "./configure", so I used "./autogen.sh" instead)

EDIT: Building under Fedora also generates a 2.2MB executable.

Could be the graphics drivers. Can you at least confirm that Chocolate Doom exited cleanly? ie. it doesn't crash and bomb out with an error, you get the ENDOOM screen shown.

I got rid of this glitch. Chocolate-Doom exits correctly now.


There's nothing like motion blur. I don't know what this can be.

I tried on another computer and I couldn't reproduce it. Might be something with the video drivers or the integrated graphics chip. I'll try to install alternative drivers later and I'll also do more tests.

Share this post


Link to post

Why isn't DMENUPIC used as the TITLEPIC substitute in the BFG Edition of Doom 2? It's a pretty neat piece of art, and is unique to simply reusing INTERPIC.

Share this post


Link to post
axdoom1 said:

How can I build a version that is not debug? I used these instructions. (Note: I couldn't get it to work with "./configure", so I used "./autogen.sh" instead)

EDIT: Building under Fedora also generates a 2.2MB executable.


You'll just need to run "strip src/chocolate-*" manually to get rid of the debugging symbols.

Share this post


Link to post
Sodaholic said:

Why isn't DMENUPIC used as the TITLEPIC substitute in the BFG Edition of Doom 2? It's a pretty neat piece of art, and is unique to simply reusing INTERPIC.

Isn't Doom 3: BFG Edition using INTERPIC as the title pic? That may be why Fraggle chose to use this one. I don't know where DMENUPIC is used in BFG edition on the PC, I only have the PS3 version.

chungy said:

You'll just need to run "strip src/chocolate-*" manually to get rid of the debugging symbols.

Thanks! That's what I needed.

Share this post


Link to post
axdoom1 said:

Isn't Doom 3: BFG Edition using INTERPIC as the title pic? That may be why Fraggle chose to use this one. I don't know where DMENUPIC is used in BFG edition on the PC, I only have the PS3 version.

This is indeed the reason. Though I've considered using DMENUPIC as the title screen as well.

Thanks! That's what I needed.

For reference, unless you have some good reason to need a smaller executable, it would be a good idea to keep the debugging symbols. If there's a crash or other bug that needs investigating, the debug symbols will allow you to get a full stack trace, and given how often you seem to find bugs that could be very useful :)

Share this post


Link to post

@fabian

I exported SDL_FORCE_SOUNDFONTS=1 but nothing happened.

I played prboom-plus with preferred midi device set to sdl and I couldn't hear anything either.

Share this post


Link to post
fraggle said:

This is indeed the reason. Though I've considered using DMENUPIC as the title screen as well.


The soon-to-be-officially-released Crispy Doom will use DMENUPIC as the title screen if invoked with "-file nerve.wad".

Share this post


Link to post
Archy said:

@fabian

I exported SDL_FORCE_SOUNDFONTS=1 but nothing happened.

I played prboom-plus with preferred midi device set to sdl and I couldn't hear anything either.


Is this on Debian? Do you have either fluid-soundfont-gm or musescore-soundfont-gm packages installed? Did you export both SDL_FORCE_SOUNDFONTS=1 and SDL_SOUNDFONTS=/path/to/soundfont?

Share this post


Link to post
fabian said:

Is this on Debian? Do you have either fluid-soundfont-gm or musescore-soundfont-gm packages installed? Did you export both SDL_FORCE_SOUNDFONTS=1 and SDL_SOUNDFONTS=/path/to/soundfont?


"expot SDL_FORCE_SOUNDFONTS=1" did it! Thanks!

Edit: As soon as I close the terminal, I lose both exports and have to retype them each time I play chocolate-doom. Is there a way to make them permanent?

Share this post


Link to post

One thing chocolate doom needs is the ability to toggle run/walk, most source ports just let you use the caps lock for this. Other than that choc doom is amazing, I am glad it keeps certain glitches that allow for grabbing keys, shortcuts, etc. that add depth to speedrunning.

Share this post


Link to post
babo said:

One thing chocolate doom needs is the ability to toggle run/walk, most source ports just let you use the caps lock for this.


Chocolate-Doom's goal is to maintain an experience as close as possible to the original .exe. Adding features like that isn't really part of the goal. Maybe you should check out Doom Retro, a source port based on Chocolate-Doom that adds some extra things here and there, including run/walk toggle.

http://www.doomretro.com/

Share this post


Link to post

You can already put autorun in ChocoDoom. Reasoning: it was possible to do that in vanilla by doing some hex voodoo in the configuration file.

Share this post


Link to post

Yeah but he's talking about a toggle, like how you can press caps lock to turn it on and off in PrBoom or Doom Retro.

Share this post


Link to post
Archy said:

Edit: As soon as I close the terminal, I lose both exports and have to retype them each time I play chocolate-doom. Is there a way to make them permanent?


Hm, could you show me the output of

dpkg -l libsdl\* | awk '/^ii/ {print $2 " " $3}'

Share this post


Link to post

Thanks fraggle!

Launch from .desktop files however still produces no music, though it doesn't really matter since I always run my games with arguments anyways.

@fabian:

$  dpkg -l libsdl\* | awk '/^ii/ {print $2 " " $3}'
libsdl-image1.2:amd64 1.2.12-2
libsdl-image1.2-dev:amd64 1.2.12-2
libsdl-mixer1.2:amd64 1.2.12-3
libsdl-mixer1.2-dev:amd64 1.2.12-3
libsdl-net1.2:amd64 1.2.8-2
libsdl-net1.2-dev:amd64 1.2.8-2
libsdl-sound1.2:amd64 1.0.3-6
libsdl-ttf2.0-0:amd64 2.0.11-2
libsdl1.2-dev 1.2.15-5
libsdl1.2debian:amd64 1.2.15-5

Share this post


Link to post
Archy said:

libsdl-mixer1.2:amd64 1.2.12-3


I see, would you mind installing package libsdl-mixer1.2 version 1.2.12-10 from testing? Drop me a PM if you don't know how to do that.

Also, what does this line print:
dpkg -l \*soundfont\* | awk '/^ii/ {print $2 " " $3}'

Share this post


Link to post

Chocolate Doom LAN game is extremely slow!

Background:
Me and a friend were playing Chocolate Doom over LAN when all the sudden the game would freeze for about thirty seconds (we could access the in-game menus and send messages [not receive until after the freeze] but everything else was frozen, even Doom guy's eyes) and then work fine for about 30 seconds then freeze for about thirty seconds. Everything was working before this point so it was very odd. I plugged in my computer to the router vie Ethernet CAT 5e as opposed to wireless and that still didn't work. I tried a different router and not only did that not work, but the thirty seconds where the game was working was lagging like hell. The lag was very smooth and consistent, it was like playing TAS at 20% speed, but then it would completely lock up again. I figured that this was just due to the crappy old (10 year) router so I then restarted the original router but the original router still didn't work even after the reset. However not only did it not fix the freezes but the lag that had occurred under the ~10-year-old router was persistent. This led me to believe that it was not a network issue and I did a checksum on our pwads and sure enough they where different. After getting the same pwads to both of us I assumed the lag would stop but it didn't, only the freezes no longer occurred. I tried playing in DOSBox over LAN and the game was flawless besides Vanilla Doom's own “natural” lag so I don't think it's a network problem. I reset both computers but Chocolate Doom is still laggy.

Any ideas as to what the problem might be?

P.S.: I created new Linux user accounts (we are both using Linux and Chocolate Doom 2.0.0. btw) on both computers so that all settings would be default. I created a LAN game between the two new accounts and it was much less laggy but still way more laggy than usual. We have been playing Chocolate Doom over LAN for the past two months and never have we had any noticeable lag till this past game. Hopefully it's just a fluke and will correct it's self in a day or two.

P.S. #2: The two new accounts very quickly became just as laggy as the original accounts we were using. On the original accounts I deleted both of or .chocolate-doom folders to start anew and at first the game is less laggy than normal but after about 40 seconds its just as laggy as before. This is very odd.

P.S #3: When every I exit Chocolate Doom on my system, my mouse cursor goes away (right now I'm typing this with no cursor, navigating Iceweasel mouseless is interesting...). My WM/DE is LXDE (Openbox) if that helps you debug my situation. The cursor is actually still existent, just invisible.

@fabian: I'll get back to you a bit later.

Share this post


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