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

Crispy Doom 6.0 (Update: Mar 31, 2023)

Recommended Posts

Nothing to do, seems i visited a bad page and it got screwed, fixed after a restart. It still sucks tough.

Share this post


Link to post

Noticing something strange with Zodo's new release where mouse movement is rather choppy in comparison to 2.7.1.

I've copied my mouse setup 1:1 with my 2.7.1 installation, made sure everything is set up just the same, but I've noticed that specifically when I'm strafing, and moving the mouse in the opposite direction, it's a noticeably choppy movement. Really obvious any time I'm circle-strafing something.

Share this post


Link to post
2 hours ago, The Civ said:

Noticing something strange with Zodo's new release where mouse movement is rather choppy in comparison to 2.7.1.

I've copied my mouse setup 1:1 with my 2.7.1 installation, made sure everything is set up just the same, but I've noticed that specifically when I'm strafing, and moving the mouse in the opposite direction, it's a noticeably choppy movement. Really obvious any time I'm circle-strafing something.

I guess you have Uncapped framerate turned off, and 35fps on 60 Hz screen may have such effect.

EDIT: If turning uncapped framerate on doesn't fix your issue, re-download the port as I have re-bundled it with daily autobuilder's DLLs.

Edited by Zodomaniac : Mentioned updated download

Share this post


Link to post

Just figured it out, the choppiness in the mouse movement has something to do with v-sync.

Installations 2.7.1 and prior didn't need v-sync enabled to avoid screen tearing. It simply never was a problem, even with the framerate uncapped.

Which is even more bizarre thinking on it. Were those versions running on a sort of borderless windowed style of fake fullscreen to avoid the need for v-sync?

Regardless, after checking the prior version of 2.7.2 as well, it seems that they all require v-sync to avoid screen tearing with the framerate uncapped now, but doing so introduces rather choppy mouse movement.

I'd actually run into a similar situation prior with PrBoom+ where enabling v-sync would cause a very similar problem, however the issue is far less pronounced in Crispy Doom so far. Only way around it was to find a branch of it someone had created that allowed it to run in borderless windowed mode.

Share this post


Link to post
4 minutes ago, The Civ said:

Just figured it out, the choppiness in the mouse movement has something to do with v-sync.

Installations 2.7.1 and prior didn't need v-sync enabled to avoid screen tearing. It simply never was a problem, even with the framerate uncapped.

Which is even more bizarre thinking on it. Were those versions running on a sort of borderless windowed style of fake fullscreen to avoid the need for v-sync?

Regardless, after checking the prior version of 2.7.2 as well, it seems that they all require v-sync to avoid screen tearing with the framerate uncapped now, but doing so introduces rather choppy mouse movement.

I'd actually run into a similar situation prior with PrBoom+ where enabling v-sync would cause a very similar problem, however the issue is far less pronounced in Crispy Doom so far. Only way around it was to find a branch of it someone had created that allowed it to run in borderless windowed mode.

 

You can try setting force_software_renderer to 1 in crispy-doom.cfg. This fixed screen tearing issues for me until I found a different solution.

Share this post


Link to post

Thanks, that fixed it right up.

That should be a quick toggle option in the setup, if not crispy menu (not sure if it would require a full restart of the program), because that fixed it for me.

Share this post


Link to post

I haven't played cripsy doom on my desktop since 5.4.  I am trying out 5.7.2 and I get the following error on launch:


The code execution cannot proceed because zlib1.dll was not found. Reinstalling the program may fix this problem.
 

If i copy all the missing DLLs from 5.4 to my 5.7.2 folder, the game launches fine, but I don't need to do this on my laptop.  Any idea what is causing this?  I can run chocolate doom 3.0.0 without zlib1.dll in the folder.

Share this post


Link to post

So I tried some previous releases, and I didn't get thew above error.

5.7 works fine without zlib1.dll

5.7.1 works fine as well, but crispy-doom-setup.exe is detected a malware by windows defender:

Threat detected: Trojan:Win32/Wacatac.C!ml

Share this post


Link to post

So is there a virus in this? I've also gotten an alert from windows defender when trying to launch crispy doom.

 

image.png

Share this post


Link to post
2 hours ago, The Civ said:

No, but it is missing several .dlls that need to be copied over from older versions.

Not older versions, the latest stable. Basically, overwrite the files of the official release with these files.

 

Edit: Guess I was wrong :D

Edited by VGA

Share this post


Link to post
On 3/29/2020 at 9:10 PM, The Civ said:

Just figured it out, the choppiness in the mouse movement has something to do with v-sync.

Installations 2.7.1 and prior didn't need v-sync enabled to avoid screen tearing. It simply never was a problem, even with the framerate uncapped.

Which is even more bizarre thinking on it. Were those versions running on a sort of borderless windowed style of fake fullscreen to avoid the need for v-sync?

Regardless, after checking the prior version of 2.7.2 as well, it seems that they all require v-sync to avoid screen tearing with the framerate uncapped now, but doing so introduces rather choppy mouse movement.

I'd actually run into a similar situation prior with PrBoom+ where enabling v-sync would cause a very similar problem, however the issue is far less pronounced in Crispy Doom so far. Only way around it was to find a branch of it someone had created that allowed it to run in borderless windowed mode.

 

On 3/29/2020 at 9:16 PM, maxmanium said:

 

You can try setting force_software_renderer to 1 in crispy-doom.cfg. This fixed screen tearing issues for me until I found a different solution.

This seems to reference the exact issue I encountered as described in my thread here: 

 

As you stated, setting force_software_renderer to 1 fixes the extreme warping/tearing that Linguica likened to a reverse rolling shutter effect. As I mentioned in the OP of that thread, this particular behavior seemed to been introduced between 5.5 and 5.6 (at least on my machine). I'm glad there's at least a temporary fix in Crispy Doom, but I'm curious as to why it seems to have been introduced in multiple SDL2 ports having not been present in past versions (or in other games), and if there's any possibility of solving the problem at the source (which seems to be related to SDL's use of hardware rendering).

 

As always thanks for the excellent work on this important port, fabian et al.

Share this post


Link to post

The warping never bothered me much tbh, I got used to it in PrBoom :p , even though it's stupid.

 

I keep wondering about the input lag though, because this was not always present in Crispy. I remember clearly that I used to not have issues with input lag when using VSync and uncapped framerate in older versions (5.4, 5.3 or something like that?) but it eventually started showing up in Crispy as well. Something changed at some point, and that probably introduced input lag. I think it happened around the time fabian stopped providing builds by himself.

 

It's all the more curious if changing the value of that line in the config fixes it, could it be related to GL which is preventing the frame interpolation from working correctly?

Edited by seed

Share this post


Link to post
31 minutes ago, seed said:

I keep wondering about the input lag though, because this was not always present in Crispy. I remember clearly that I used to not have issues with input lag when using VSync and uncapped framerate in older versions (5.4, 5.3 or something like that?) but it eventually started showing up in Crispy as well. Something changed at some point, and that probably introduced input lag.

After some testing, on my machine the significant input lag associated with VSync was introduced between 5.5 and 5.6 (input lag not present in 5.4/5.5 and present in 5.6), which as might be expected is concomitant with when this warping seems to have been introduced.

Share this post


Link to post

Ah so it does disable VSync too if you enable that? Huh, that's interesting.

 

4 minutes ago, vadrig4r said:

After some testing, on my machine the significant input lag associated with VSync was introduced between 5.5 and 5.6 (input lag not present in 5.4/5.5 and present in 5.6), which as might be expected is concomitant with when this warping seems to have been introduced.

 

Damn, so I was spot-on then, not half bad. I wonder what else changed then to make it go bonkers, and whether it's related to input or something else broke in the engine and that had an impact on it.

Share this post


Link to post

Here's the link to the Borderless Windowed "fake fullscreen" fork of PrBoom+ I use to circumvent it.

You have to insert it via a separate command in the shortcut or GUI launcher, but it works very well.

If there's no way around fixing this inherent issue with SDL2 ports, I feel like introducing an easily toggled option for Borderless Windowed mode as a video mode would be a really helpful workaround.

It's fixed the problem for me in both Eternity and PrBoom+. Hoping to see it get carried into an official Pr release in the future.

Share this post


Link to post
6 minutes ago, The Civ said:

Here's the link to the Borderless Windowed "fake fullscreen" fork of PrBoom+ I use to circumvent it.

You have to insert it via a separate command in the shortcut or GUI launcher, but it works very well.

If there's no way around fixing this inherent issue with SDL2 ports, I feel like introducing an easily toggled option for Borderless Windowed mode as a video mode would be a really helpful workaround.

It's fixed the problem for me in both Eternity and PrBoom+. Hoping to see it get carried into an official Pr release in the future.

 

It was added into Graf's fork as well. You can use it in my latest unofficial build I posted here, but it's only for the Software renderer.

 

But if that workaround actually works... then perhaps it should be incorporated in other ports if the input lag with SDL is truly unsolvable.

Share this post


Link to post

Is the HUD supposed to be transparent when using widescreen option? No matter what I do I cannot make it normal again

Share this post


Link to post
On 3/30/2020 at 8:19 AM, Zodomaniac said:

@fabian, I did as you asked and the program is reporting missing DLLs it had been linked against (as @The Civ reports).

So I'm bringing back my homebrew build with all the 29 DLLs.

Please let me know if you wish to replace it on Github.

crispy-doom-5.7.2-win32.zip

 

WIndows defender still flags that as a virus for me. 

Share this post


Link to post

Same here, now crispy-doom.exe. I think i'm going to compile it myself but first i need to fix compilation and do a PR.

Share this post


Link to post

Just popping in just to say thanks again to Fabian, Zodomaniac, and everyone else who has contributed to this wonderful source port! Also, my antivirus hasn't complained about anything related to Crispy Doom 5.7.2 or any of the autobuilds, nor has Smart Screen.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×