Chocolate Doom

@Rohit_N - Glad to hear the SDL2 port is working well for you. If you find any bugs please don't hesitate to report them.

fabian said:

Jon, Simon: I think we should really hide the "Window Resolution" selection if "Fullscreen" is enabled. See how confusing this is.

Yep, I agree.

I have a different sfx issue with Chocolate Doom. When I'm playing, once in a while the sound gets incredibly loud for a split second. I guess I can try recording the sound to show it if necessary.

If you can reproduce it with a demo recording, you should post it on the GitHub issues tracker with your *.cfg files and information about what operating system and hardware you use. All of them can be helpful.

So here's a weird bug, where I was able to record a demo (and exit recording normally, with the Q key), but when it gets played back, the game freezes halfway through the demo. It's DEMO3 in the WAD file linked from this post:
https://www.doomworld.com/vb/post/1613155

kuchitsu said:

I have a different sfx issue with Chocolate Doom. When I'm playing, once in a while the sound gets incredibly loud for a split second. I guess I can try recording the sound to show it if necessary.

It would be extremely helpful to know if you are using a released version, a daily build or maybe even a build of the sdl2-branch? Also, do you have libsamplerate support built in and/or enabled? Do you have sound pitching enabled? Thanks!

hex11 said:

So here's a weird bug, where I was able to record a demo (and exit recording normally, with the Q key), but when it gets played back, the game freezes halfway through the demo. It's DEMO3 in the WAD file linked from this post:
https://www.doomworld.com/vb/post/1613155

Hm, I fail to reproduce the freeze. Does it work for you in Crispy Doom?

fabian said:

Hm, I fail to reproduce the freeze. Does it work for you in Crispy Doom?

I don't have that port yet, maybe I can try to build it tomorrow.
Btw, I should mention this freeze only happens if you let the other two demos run beforehand, by loading it like this:
chocolate-doom -file ud94beta.wad
(without appending -playdemo demo3). The same exact thing also happens in dosbox, so I'm not even sure this is a "bug". Howevever the demo was recorded with Chocolate Doom, and maybe there's a bug in the recording code, rather than playback.
I did try PrBoom+ and it plays all the demos back fine, without freezing up.
OS is OpenBSD 5.9, amd64, and I'm just using the binary packages provided for all this (chocolate-doom, dosbox, prboom-plus).
My config also has this set, but the demo3 recording lasted under a minute, so no chance of hitting it:
vanilla_demo_limit 1
When the freeze happens, music keeps playing, but the keyboard is unresponsive. Can't hit Escape to get menu, or use the function keys. Have to kill -9 the process.

I believe this is due to the Demon Speed Bug:
http://doomwiki.org/wiki/Demon_speed_bug

DEMO1 and DEMO2 were recorded in Nightmare difficulty and apparently this isn't properly reset when loading DEMO3, which leads to an infinite loop in the chase state sequence.

Hmm, demo3 was recorded with -skill 4 -fast
I couldn't remember if I used that or -skill 5 on the first two demos, so that's why there's a difference.
I just checked the header for demo3.lmp and it has the -fast option set (byte 6 is 4), at least if the info here is correct:
http://doomwiki.org/wiki/Demo
Is there actually a speed difference between NM and UV+fast?

fabian said:

Jon, Simon: I think we should really hide the "Window Resolution" selection if "Fullscreen" is enabled. See how confusing this is.

The "window resolution" option still has an impact on the output for fullscreen, right? As in, it alters one of the scale operations, or am I mistaken?

Nope, it has no effect now.

fabian said:

It would be extremely helpful to know if you are using a released version, a daily build or maybe even a build of the sdl2-branch? Also, do you have libsamplerate support built in and/or enabled? Do you have sound pitching enabled? Thanks!

I'm not kuchitsu, but I've had this problem. I think Doom Retro retains it (it's based on 1.x, IIRC). Chocorenderlimits definitely has it.

Unfortunately, I don't remember if it was present in 2.x - I stopped using Chocolate Doom when it started reading mouse input from the Windows cursor. It seems that the volume gets cranked up to the max momentarily (I'm playing with a very low volume otherwise).

Da Werecat said:

when it started reading mouse input from the Windows cursor.

Gross. I prefer raw input, it's much smoother. There's no options to change it back?

Da Werecat said:

Unfortunately, I don't remember if it was present in 2.x - I stopped using Chocolate Doom when it started reading mouse input from the Windows cursor.

When was this, and did you file a bug?

The mouse being affected by Windows acceleration settings? Around the time 2.0.0 came out, IIRC.

No, I did not file a bug. PrBoom(-Plus) was like this since forever, so I just gave up without even thinking about saying something.

Okay. No offence intended here but it's really frustrating when people make comments like this - passive aggressive complaints about bugs which haven't even been reported. I want to fix things like this but if you don't tell me about them there's nothing I can do.

IIRC I switched to using cursor movement way before v2.0 and the approach was taken from PrBoom+. I'm surprised to hear it became a problem with v2. The sdl2-branch currently in development (which will eventually become Chocolate Doom v3) I believe switches to reading raw mouse movement which should be unaffected by Windows cursor acceleration, so maybe give it a try.

I wouldn't call it a bug. And I'm sorry if it came out as passive-aggressive.

Mmmm chocolate doom...

my second fave source port

@Da Werecat: Are you able to get onto the #chocolate-doom IRC so we might be able to narrow down when your mouse issues started?

The door that closes after 30 seconds on Monster Condo does not rebound off the players head and raise indefinitely.

Randy87 said:

The door that closes after 30 seconds on Monster Condo does not rebound off the players head and raise indefinitely.

Depends on uninitialized data, IIRC.

so i have windows 10 64 bit.

Basically, whenever I try to play chocolate doom or PR/GLBoom in software mode, I'm getting less than 35 fps, about like, 25 or 30 when I should be getting 35. This seems to be due to 64bit-ness. I'd hope a 64bit compatible version of chocolate doom and PR/GLboom would show up

StalkerZHS said:

so i have windows 10 64 bit.

Basically, whenever I try to play chocolate doom or PR/GLBoom in software mode, I'm getting less than 35 fps, about like, 25 or 30 when I should be getting 35. This seems to be due to 64bit-ness. I'd hope a 64bit compatible version of chocolate doom and PR/GLboom would show up

Nope, nothing to do with 64bit at all (that would make no sense ever unless it was a 64bit build you were running in the first place), or even Windows 10 (again, nonsense). You should start looking at your drivers, and their configuration.

StalkerZHS said:

so i have windows 10 64 bit.

Basically, whenever I try to play chocolate doom or PR/GLBoom in software mode, I'm getting less than 35 fps, about like, 25 or 30 when I should be getting 35. This seems to be due to 64bit-ness. I'd hope a 64bit compatible version of chocolate doom and PR/GLboom would show up

The next major release of chocolate doom uses hardware scaling for "software" rendering, so should perform better for you.

Jon said:

The next major release of chocolate doom uses hardware scaling for "software" rendering, so should perform better for you.

May have nothing to do with performance, may be a screen refresh rate timing issue just like I have on my laptop.

If Chocolate-Doom can't render at 35 FPS at 1080p on your computer, you may have a very slow Pentium 4.

axdoom1 said:

May have nothing to do with performance, may be a screen refresh rate timing issue just like I have on my laptop.

If Chocolate-Doom can't render at 35 FPS at 1080p on your computer, you may have a very slow Pentium 4.

Well, possibly, but they said that it only happened in software mode - suggesting that they did not have problems in hardware mode. So, it seems to me that with the scaling being done on the GPU they should be OK.

Ok everyone, heres how it is. I have an old computer and a new computer.

Old Comp: PLAYS FINE
Windows 7 Pro 32 bit
AMD A8-3850
Radeon R9 270x
4gb Ram
60hz monitor
--------------------------------------------------------------------------
New Comp: HAS PROBLEMS
Windows 10 home 64 bit
AMD FX-8320 Black edition
Radeon R9 270X (the same card from old comp, still got low fps on it)
GTX 970 2.0 +140 (after upgrade, still low fps)
8gb ram
60hz monitor

I had a similar issue with PR/GLboom. When playing in default opengl renderer, everything was okay, but when playing in default software, everything wasnt.
HOWEVER: playing glboom in software mode with "use GL surface for software mode" turned ON, everything becomes normal again. Also Zdoom and Zandronum work fine in software as well.

CONCLUSION: There is a disagreement between the fact that my operating system is 64-bit, and something about how ChocoDoom and PR/BLboom handle stuff

I have a similar issue with Chocolate-Doom

https://github.com/chocolate-doom/chocolate-doom/issues/693

https://github.com/chocolate-doom/chocolate-doom/issues/662

https://youtu.be/nXkQwQ14qZo?t=36s

Go in chocolate-doom.cfg and change video_driver to "directx". By default it's "". See if it fixes your issue with the framerate.

@axdoom

your solution was perfect.
many thanks!

Hello,

Today I set the mouse speed to 20 in the setup program and this is what the mouse sensitivity slider looks like:



Is this a glitch?

Thanks