Crispy Doom 6.0 (Update: Mar 31, 2023)

[PKr]

14 hours ago, mikeday said:

I would say this is a bug, not an intentional design decision. Fortunately the fix is pretty is pretty easy:

 

  Reveal hidden contents

diff --git a/src/doom/am_map.c b/src/doom/am_map.c
index 4354aa6a..c32b52fc 100644
--- a/src/doom/am_map.c
+++ b/src/doom/am_map.c
@@ -1030,8 +1030,8 @@ void AM_changeWindowScale(void)
 void AM_doFollowPlayer(void)
 {
 
-       next_m_x = m_x = (viewx >> FRACTOMAPBITS) - m_w/2;
-       next_m_y = m_y = (viewy >> FRACTOMAPBITS) - m_h/2;
+       next_m_x = m_x = FTOM(MTOF(viewx >> FRACTOMAPBITS)) - m_w/2;
+       next_m_y = m_y = FTOM(MTOF(viewy >> FRACTOMAPBITS)) - m_h/2;
        m_x2 = m_x + m_w;
        m_y2 = m_y + m_h;
 

Good catch!

Ahhh! That makes sense. I've spent the whole evening yesterday trying to apply "this easy fix", but I used FTOM MTOF to the whole expression like this FTOM(MTOF((viewx >> FRACTOMAPBITS) - m_w/2) and couldn't understand why it wasn't working properly!

 

10 hours ago, fabian said:

 

Hm, but why does changing coordinate systems back and forth improve panning here? Especially if the change was introduced in a commit titled "Implement smooth automap scrolling":

https://github.com/fabiangreffrath/crispy-doom/commit/d587245e4b5ac8ae6f2cfaf0ae73a9becd4cb459

 

And why isn't Woof affected a well, doesn't it share the same code? 

This commit was definitely aimed at hires automap scrolling. On practice this prevents automap from skipping some coordinates for redrawing automap lines which made the original automap look "jumpy". So I believe the automap in Crispy Doom should work as it does now (unless you find a way to render it identically to non-follow mode), it's just that in low resolution it should fallback to the code which @mikeday proposed in his previous comment (since am is completely unusable in low resolution as you can see from the previous video).

 

However, it seems like the "perfect solution" has already been implemented in Crispy Doom... When follow mode is turned off map scrolling is still miles better compared to all current AM_doFollowPlayer implementations.

 

Here is another video comparing the automap with @mikeday's patch:

https://youtu.be/p07aLMOESGE

Edited September 5, 2022 by PKr

[mikeday]

8 hours ago, fabian said:

 

Hm, but why does changing coordinate systems back and forth improve panning here? Especially if the change was introduced in a commit titled "Implement smooth automap scrolling":

https://github.com/fabiangreffrath/crispy-doom/commit/d587245e4b5ac8ae6f2cfaf0ae73a9becd4cb459

 

And why isn't Woof affected a well, doesn't it share the same code? 

 

I think the idea with the FTOM(MTOF( operation is to round down to the nearest value for m_* such that there 0 fractional component on a subsequent MTOF() operation. This ensures that horizontal and vertical automap lines always have stable spacing between them. Hence, no wobbling.

 

Note that this seems to primarily be an issue at 320x200. It is present at 2x res but much less objectionable. Also, Woof does indeed exhibit this behavior as well.

 

7 hours ago, Julia Nechaevskaya said:

I suspect this is how precise coord system works. Vanilla code "FTOM(MTOF(viewx >> FRACTOMAPBITS))" is preventing walls wobbling by drawing them with logics "one automap pixel is one screen size pixel" which is not really smooth, and also will bring back awful player arrow wobbling while movement. Have a look at Pr+ with 8-bit 640x400 screen resolution (most of interpolation code comes from it) - wobbling is absolutely same.

 

Can it be fixed or improved somehow? Would be nice to know, honestly. We still limited by 640x400 pixels, which is taking it's price: there is simply no way to draw "more pixels" on same zooming level for providing more smooth re-drawing.

 

Also, about "FTOM(MTOF(" have a look how it's drawing diagonal walls or walls in 45° rotate mode. It's really rough.

 

Yes I see what you're saying. So perhaps that means we use FTOM(MTOF( only in low-res mode, like @PKr has suggested. A better solution is not jumping out at me yet. :)

 

2 hours ago, PKr said:

However, it seems like the "perfect solution" has already been implemented in Crispy Doom... When follow mode is turned off map scrolling is still miles better compared to all current AM_doFollowPlayer implementations. 

 

Non-follow mode map panning always moves the map an integer number of automap pixels, which is also what the FTOM(MTOF( operation is trying to accomplish.

[PKr]

Just so it won't go unnoticed:

 

While we're at it, I noticed a small bug... AM_drawCrosshair function doesn't take hires state changes into the account while in game. So, if you change hires to !hires, the crosshair will be drawn out of screen boundaries. And if you change !hires to hires it will be drawn at 1/4x and 1/4y coordinates.

[vadrig4r]

Is anyone experiencing being unable to alt-tab in Windows still? I believe this was an SDL bug introduced in 2020/2021 but I'm still experiencing it in 5.12 and the latest autobuild (20220909-win32). The same issue also affects the latest Chocolate Doom versions for me (3.0.1 release and 20220909-win32 autobuild).

 

Alt-tab simply leaves the full ingame image on the display (no visible taskbar) and brings up the OS cursor unable to interact with anything, requiring terminating the program. Using Alt+Enter to toggle between windowed and fullscreen still functions properly. Does anyone have a workaround for alt-tabbing besides switching to windowed mode? This is on a Win 7 x64 Pro machine.

[fabian]

On 9/5/2022 at 4:52 PM, mikeday said:

Yes I see what you're saying. So perhaps that means we use FTOM(MTOF( only in low-res mode, like @PKr has suggested. A better solution is not jumping out at me yet. :)

 

Could you please file a PR for this?

[Never_Again]

On 9/9/2022 at 3:12 AM, vadrig4r said:

Is anyone experiencing being unable to alt-tab in Windows still? I believe this was an SDL bug introduced in 2020/2021

 

The bug was introduced in SDL2 v2.0.14 (Dec 2020). There's a fix for it in src/i_video.c that checks the SDL2 version and turns on SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS for the affected versions. The fix was updated to cover v2.0.16; it hasn't been updated since as the bug was fixed on the SDL2 side with v2.0.18 (Nov 2021), IIRC.

 

It's possible that the bug only affected Win7 users (which includes me); I'd expect to have seen a lot more complaints otherwise.

 

 

On 9/9/2022 at 3:12 AM, vadrig4r said:

but I'm still experiencing it in 5.12 and the latest autobuild (20220909-win32)

 

You should not have this problem with autobuilds because they use v2.0.12 SDL libs. So, it's either a user error or your video drivers are a factor.

 

To rule out the former:

- Unzip a Crispy autobuild, including all the DLLs, into a new folder.

- Open a command-prompt session from that folder - under Win7 in Windows Explorer hold left SHIFT and right-click on that folder to get the "Open command window here" option in the pop-up menu.

- Execute

SET PATH=.

this is to prevent Crispy from picking up DLLs from any other folder that might be in your PATH

- Execute

crispy-doom.exe

with any command-line switches. If you don't have %DOOMWADDIR% set on your system pointing to the folder with IWADs you'll need to copy an IWAD into the autobuild folder as well.

 

If the above doesn't fix your problem there may be an SDL2 compatibility issue with your video driver. With the latest autobuild ALT+TAB and the WIN key function as expected for me. My system is

- Dual Xeon X5670 (Westmere EP, ca. 2010) / 48 GB RAM

- Quadro FX 3800 1 GB

- Win 7 x64 Pro SP1

- Nvidia display driver v342.01

 

 

Try the following test build of Crispy: crispy-doom-20220912-alltabfix-w32.zip

It unconditionally enables the ALT+TAB fix mentioned earlier, and you get console output as a bonus. Please follow the same steps as for the autobuild above and report the results.

 

[vadrig4r]

15 hours ago, Never_Again said:

 

The bug was introduced in SDL2 v2.0.14 (Dec 2020). There's a fix for it in src/i_video.c that checks the SDL2 version and turns on SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS for the affected versions. The fix was updated to cover v2.0.16; it hasn't been updated since as the bug was fixed on the SDL2 side with v2.0.18 (Nov 2021), IIRC.

Thank you very much for the comprehensive reply.

 

Following your procedure step-by-step with the crispy-doom-20220915-win32 autobuild resulted in the same failed Alt-Tab behavior referenced in my original post. (For completeness I had %DOOMWADDIR% already set with a directory containing only the final versions of the official IWADs)

 

Following your procedure with the test build that you provided, however, worked perfectly! Both Alt-Tab and the Windows key function as expected. Please let me know if you would like me to PM you any additional hardware or driver information that might be useful.

[NightFright]

Is it possible that an SDL update lowered max MIDI volume? With more recent Crispy/Woof snapshots, I have found that MIDI volume is suddenly much lower than before. I used to play with a setting of 10-12, now even the max (15) isn't enough.

Edited September 15, 2022 by NightFright

[rfomin]

3 hours ago, NightFright said:

Is it possible that an SDL update lowered max MIDI volume? With more recent Crispy/Woof snapshots, I have found that MIDI volume is suddenly much lower than before. I used to play with a setting of 10-12, now even the max (15) isn't enough.

Do you use Native MIDI and MS GS Wavetable Synth? The newest SDL should not affect MIDI volume.

[NightFright]

Native MIDI. To be more precise, I am using the Roland SCVA VSTi plugin with LoopMIDI (v1.0.16.27) and the Falcosoft MIDIPlayer (v6.1.1.0 x64).

[rfomin]

We have recently added additional resets to Native MIDI for compatibility with MIDI hardware, see: https://github.com/fabiangreffrath/woof/pull/706 I think Falcosoft MIDIPlayer has its own mixer where it's possible to change the volume.

[NightFright]

The thing is, I have maxed out volume in the MIDIPlayer *AND* ingame menu and I feel like I am still not getting the volume I had before. No idea what might have triggered it, but at this point I would need something that allows me to get 120% volume or even more...

[rfomin]

17 minutes ago, NightFright said:

The thing is, I have maxed out volume in the MIDIPlayer *AND* ingame menu and I feel like I am still not getting the volume I had before. No idea what might have triggered it, but at this point I would need something that allows me to get 120% volume or even more...

Does it work normally with previous versions of Crispy/Woof? Maybe we should remove some resets.

[NightFright]

I tried official Crispy 5.12.0 release and it seems to work there. Apparently the official build has more recent SDL dlls than the one I am using with my custom-compiled build.

[rfomin]

We don't use SDL for Native MIDI as of Crispy 5.11.0. I suggest creating a new GitHub issue in the Chocolate Doom repo (Choco, Crispy and Woof use the same code for Native MIDI)

[NightFright]

For now I'll keep observing and try to find out if I can get to the bottom of this. I didn't make any significant changes to my setup during the last few months, especially since I didn't play Doom at all. 

[ceski]

8 minutes ago, NightFright said:

For now I'll keep observing and try to find out if I can get to the bottom of this. I didn't make any significant changes to my setup during the last few months, especially since I didn't play Doom at all. 

 

The recent changes don't affect volume. It looks like when the music system was changed from SDL to native the volume behavior changed. I submitted a PR on GitHub to make all three source ports behave more like vanilla Doom.

 

Btw, I use the same config as you (SCVA + Falcosoft MidiPlayer + loopMIDI). I recommend adding LoudMax to MidiPlayer. It works well without making the music overly compressed. Try Thresh: -9.0 dB, Out: -3.0 dB. Seems to work okay for most music.

[NightFright]

Your Woof patch did the trick for me, volume definitely gets a boost! I hope this finds its way into Chocolate/Crispy ASAP, too.

[mikeday]

It doesn't make any sense to me that you're not also seeing this issue with the official 5.12.0 release. None of the commits since then have anything to do with midi. Also as mentioned earlier midi on Windows doesn't use SDL, so SDL version shouldn't have any effect on this either. Very strange!

[NightFright]

Maybe it is a rather subjective perception. The only thing I know for sure is that MIDI volume has been a lot lower lately and ceski's patch fixes it. Whether it came with a port-related code update or something else I am still unable to determine.

[ceski]

On 9/16/2022 at 3:57 AM, NightFright said:

Your Woof patch did the trick for me, volume definitely gets a boost! I hope this finds its way into Chocolate/Crispy ASAP, too.

 

After doing a lot more research, I decided to go back on this change for Chocolate/Crispy/Woof. I think I was too eager to find a solution before fully understanding the quirks of Vanilla Doom's music system (DMX). I wrote a very lengthy summary here, but briefly: it's good that it's quieter than Vanilla Doom and it'll be very close if you set the slider to max. If you still have volume issues, something else is causing it. Sorry about that.

Edited September 19, 2022 by ceski

[NightFright]

Well, in the worst case I still have those SimpleGain or LoudMax plugins for FSMP if I don't find out what caused the volume change for me. So one way or the other, there is a way to fix or at least compensate the issue.

 

On a side note: I tested with a different system and I didn't have any volume-related problems there. This means that ports are not to blame for this and I have to look at my system config to get to the root of it, apparently.

Edited September 19, 2022 by NightFright

[PKr]

48 minutes ago, NightFright said:

On a side note: I tested with a different system and I didn't have any volume-related problems there. This means that ports are not to blame for this and I have to look at my system config to get to the root of it, apparently.

Are you on Windows 10 by any chance?

 

If yes, give this a try:

1. regedit > \HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\LowRegistry\Audio\PolicyConfig\PropertyStore

2. Search for "crispy-doom.exe" there.

3. You will find a bunch of "1234abcd_0"-formatted branches (the data should start with "{2}.\\?\hdaudio#"-something-something).

4. Delete all crispy-doom related registries here.

Edited September 19, 2022 by PKr

[NightFright]

That might have actually done it. No idea what this did and why, but it seems MIDI volume got louder again across the board, in Crispy, Woof and even EDuke32. Thanks for the tip! Hopefully it won't happen again...

[PKr]

2 hours ago, NightFright said:

No idea what this did and why, but it seems MIDI volume got louder again across the board, in Crispy, Woof and even EDuke32.

Not sure how to reproduce this issue accurately but under some rare conditions after updating fluidsynth dll (or not updating, but simply recompiling and moving the dll file across different folders) MIDI volumes start interpreting the last used volume value as 100% volume. It can even mute the music completely if you set music to 0% and trigger this bug by manipulating the mentioned dll file. It seems like registries mentioned in my previous post are responsible for storing that "100% value" and that's why after deleting them the music starts behaving normally again.

 

That's my uneducated guess, but hey! It works... ¯\_(ツ)_/¯

[ceski]

5 hours ago, NightFright said:

That might have actually done it. No idea what this did and why,

 

2 hours ago, PKr said:

That's my uneducated guess, but hey! It works... ¯\_(ツ)_/¯

 

You're deleting the volume mixer settings so it resets to default. That means something changed it, maybe by accident.

 

Edited September 19, 2022 by ceski

[NightFright]

Well...that's hardly something I would have missed, I think. FSMP volume was and is always at 100% and general volume of Windows is at 20%. Still, MIDI volume lowered without changing ingame settings. The mystery continues.

[PKr]

1 hour ago, ceski said:

You're deleting the volume mixer settings so it resets to default. That means something changed it, maybe by accident.

Huh! You are right. It's indeed mixer settings that are getting changed here.

 

The reason why they change however is this (example made in Sprinkled Doom):

https://youtu.be/ctPdDcP2xrY

 

Can't reproduce it in Crispy at the moment though, so there might be multiple triggers that bug out mixer settings...

Edited September 19, 2022 by PKr

[mikeday]

On 9/19/2022 at 5:07 PM, PKr said:

Huh! You are right. It's indeed mixer settings that are getting changed here.

 

The reason why they change however is this (example made in Sprinkled Doom):

https://youtu.be/ctPdDcP2xrY

 

Can't reproduce it in Crispy at the moment though, so there might be multiple triggers that bug out mixer settings... 

 

As of this change, you should not be able to break Choco/Crispy volume with the procedure outlined in your video. I suspect you're correct though that there might still be other ways to do it.

[SaqCoyoy]

Why was the squat down on impact and weapon recoil thrust options removed from the menu? :-( I really loved those features in older Crispy Doom versions because they didn't drastically alter gameplay and made movement and firing your weapons really impactful. Any chance that they could be added back in? For  future update, I think a death camera option like the setting in GZDoom would be a neat visual feature too. But man I really wish that squat down on impact and weapon recoil thrust made the cut on this latest version.