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

4 minutes ago, fabian said:

Possible sure, but I won't work on this.

Then I may implement it in So Doom v6+ when I have sufficient programming skills.

Share this post


Link to post

Update Mar 13, 2020: Crispy Doom 5.7.2 is released!


Crispy Doom is a friendly fork of Chocolate Doom that provides a higher display resolution, removes the static limits of the Doom engine and offers further optional visual, tactical and physical enhancements while remaining entirely config file, savegame, netplay and demo compatible with the original.

 

Crispy Doom 5.7.2 has been released on March 13, 2020 to introduce the Compact HUD for widescreen rendering mode and bring some general improvements and fixes.

 

Please visit the Crispy Doom homepage for more information:
https://github.com/fabiangreffrath/crispy-doom/releases

Binaries for Windows (x86) are available here:
https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.7.2/crispy-doom-5.7.2-win32.zip

Have a lot of fun!

- Fabian

Share this post


Link to post

Hello.


I'm used to speedrunning doom in prboom+ and decided to try Crispy Doom (now that it supports widescreen) especially because of it's quick start advantage over prboom. However, after trying and experimenting with Crispy, there are 2 things that turned me away from it, and I would like to leave that feedback. If these things are fixed/supported in the future I will definitely reconsider Crispy Doom again.

 

 1) Bug: In the Crispy Doom Setup, both the "mouse-wheel-up" and the "mouse-browser-back" are called "BUTTON #4". Because of this, I'm unable to bind 2 different things to these 2 mouse buttons. (Same problem happens with "mouse-wheel-down" and "mouse-browser-forward", which are both called "BUTTON #5")

 

 2) Feature request: In the Crispy Doom Setup, I would like to be able to bind specific weapon selection to mouse buttons, in particular to "mouse-wheel-up" and "mouse-wheel-down". I know I can bind them to next / previous weapon, but that's inefficient for speedrunning for 2 reasons:

 - Next / Previous weapon depends on the current weapon, which is more difficult to create muscle memory around, since results will vary for each run / situation

 - Accidental multiple mouse-wheel inputs will do next / previous weapon multiple times, leading to mistakes that can kill the run

I know I can just bind weapon selection to the keyboard on my left hand, but there are not enough easily-reachable buttons around WASD to bind a total 7 weapons, and the mouse-wheel is very easily-reachable for 2 weapons.

 

Other than these 2 things, I really enjoyed the look & feel of Crispy and I'm really looking forward to making it my go-to source port for the foreseeable future, and replacing prboom.

PS - If this is the wrong place to leave suggestions/fixes let me know and I'll post this text where it's appropriate.

 

Share this post


Link to post

Ad 1) AFAIK it is only possible to bind max. 5 buttons with SDL.

Ad 2) For the reason pointed out above, it won't make sense to add a separate key binding for each weapon. But if you want something like a button for "favorite weapon" and a way to define this in the config file, that's something we could agree upon.

 

Thanks for the feedback! While I generally prefer requests or bug reports to be filed at the Github tracker, this here is a perfectly appropriate place as well.

Share this post


Link to post

In Crispy (and Chocolate) there's specific code to map mousewheel events to mouse buttons. I don't know why, other than to mimic SDL1 behaviour:

https://github.com/chocolate-doom/chocolate-doom/blob/master/src/i_input.c#L360

 

@Coincident You could maybe use autohotkey as a workaround? It's pretty easy to map mouse buttons/wheel to keyboard buttons, I can give you an example script if you want.

Share this post


Link to post
5 hours ago, fabian said:

Ad 1) AFAIK it is only possible to bind max. 5 buttons with SDL.

I see. I wasn't aware of that technical limitation; and I understand why 1) and 2) are not a reality. It's a pity because almost all modern mice have at least 7 button-inputs.

 

Thankfully there are workarounds, which leads me to...

5 hours ago, plums said:

 

@Coincident You could maybe use autohotkey as a workaround? It's pretty easy to map mouse buttons/wheel to keyboard buttons, I can give you an example script if you want.

I didn't remember that! I did use autohotkey a couple of years ago; I have to reinstall it and try out some scripts. It might solve both of my problems entirely. Thanks for the reminder!

Share this post


Link to post

This newest release seems to introduce a slew of bizarre issues that aren't present in my 5.7.1 download.

There's now some pretty excessive mouse-lag with vsync enabled, which never occurs in 5.7.1 for me, and the audio as a whole seems to be just not playing. No music either, which means it's not going to my midi driver in the first place it seems.

I still have my backend set to directsound, to circumvent the chipmunk audio bug from previous releases. So there shouldn't be any audio issues present at all.

Share this post


Link to post
On 3/17/2020 at 7:25 AM, The Civ said:

This newest release seems to introduce a slew of bizarre issues that aren't present in my 5.7.1 download.

There's now some pretty excessive mouse-lag with vsync enabled, which never occurs in 5.7.1 for me, and the audio as a whole seems to be just not playing. No music either, which means it's not going to my midi driver in the first place it seems.

I still have my backend set to directsound, to circumvent the chipmunk audio bug from previous releases. So there shouldn't be any audio issues present at all.

You're welcome to try So Doom 5.7.4 which is based on Crispy game-related codebase but probably with differently compiled audio DLLs.

Edited by Zodomaniac : Updated link

Share this post


Link to post

Ok so I just created a Doomworld account because of an issue I've encountered with CrispyDoom 5.7.2 and all source ports based on it (like SoDoom 5.7.4).

 

Today I decided to download the latest version of this source port since I haven't updated it in a while, so I came here, downloaded the files, and Windows Defender tells me there's a virus named Occamy.c inside the files, and that it was inside "midiproc.exe" (btw Windows Defender prevented me from downloading the files). At first I thought it was a false positive, but later when I decided to run a scan on my computer (just in case) I discovered that Occamy.c infected my computer. I was kinda confused since I've used this source port for the last two years with no issues like this, so I decided to investigate a bit further and... this is a 5.7.2 problem, this doesn't happen with CrispyDoom 5.7.1.

 

So Anyways, I got rid of the virus, I really don't know what's happening, and I hope it's just me being stupid, because I really like this source port.

Share this post


Link to post
2 hours ago, Danfun64 said:

Oh dear. So does the virus show up if you compiled it yourself?

 

I didn't try (and tbh I don't want to take the risk), but since this issue also appears in SoDoom 5.7.4 I'd have to guess that yes.

Share this post


Link to post

Holy shit, well that is indeed disturbing. If it was just Defender it could have easily been a false positive, but since everything says it's a virus on virustotal... 

Share this post


Link to post

This 27-engine detection happens with the crispy-midiproc.exe from 5.7.2 that was compiled with Choco auto-builder:

 

crispy midiproc.png

 

My home-built crispy-midiproc.exe and So Doom's so-midiproc.exe was suspected by only 3 engines:

 

so midiproc.png

Share this post


Link to post

Guys, the Crispy release binaries get compiled on @fraggle's auto-builder for Chocolate Doom. As far as I know, they are cross-compiled on an non-Windows system using MinGW, so the chance that they have been infected by an actual Windows virus are marginally low. Also, this setup hasn't really changed since at least the Chocolate Doom 3.0 release.

 

 

Share this post


Link to post
27 minutes ago, fabian said:

As far as I know, they are cross-compiled on an non-Windows system using MinGW

MinGW stands for Minimalist GCC for Windows, so how can it run on a non-Windows system?

Share this post


Link to post

Even if the possibility is really low, someone already said their computer got infected afterwards, if this is the first version where that happens then perhaps somehow it got in during any part of the process.

Share this post


Link to post

Registered here just now to report the same thing

 

Microsoft Security Essentials is deleting the "crispy-midiproc.exe" file from the latest 5.7.2 release as of today, classing it as "Trojan:Win32/Occamy.C".

 

The other two EXE files, "crispy-doom.exe" and "crispy-doom-setup.exe" are both currently detected in their cloud AI scanning as "Trojan:Win32/Wacatac.C!ml!", so Windows 10 users will start to see both of these automatically deleted too.  (As will Windows 8 and 7 users with Microsoft Security Essentials once the offline "client" definition sets are updated to include this).

 

These are the current detections for the named EXEs of the 5.7.2 latest release:

crispy-doom.exe: https://www.microsoft.com/en-us/wdsi/submission/9eeb1182-735e-4f8b-ae9a-861ebf8b3f29

crispy-doom-setup.exe: https://www.microsoft.com/en-us/wdsi/submission/e1bb40f3-5a2d-47c6-aab2-54d118f858e4

crispy-midiproc.exe: https://www.microsoft.com/en-us/wdsi/submission/6f7cb940-424f-421f-88f0-b00034f6b39c

Share this post


Link to post

Here are the results of the latest 5.7.2 release for Windows from VirusTotal.

All 3 of the main EXE files have issues:

 

crispy-doom.exe flagged by 16 AV scanners

https://www.virustotal.com/gui/file/c6fdc7d5fdc4f20cdc0057815872cf5e045da2c7d7ab286567f382fe74726573/detection

 

crispy-doom-setup.exe flagged by 26 AV scanners

https://www.virustotal.com/gui/file/0d04ea528114e9b0349b2acaff497c3fd95855562b401eecce4dba42c1f89bdc/detection

 

crispy-midiproc.exe flagged by 34 AV scanners

https://www.virustotal.com/gui/file/8e5ea61d338984037ee8c7e4f74f2ad5cb590bd4b15abc9eb23d54d8600a643d/detection

Share this post


Link to post

The crispy-midiproc.exe file from v 5.7.2 has 2 bytes altered compared to v.5.7.1:

 

image.png.409fd526c780af331c87e00661171db6.png

 

 

Share this post


Link to post

And this this the hex view of v. 5.7.1 at position 216:

 

Spoiler

image.png.63dce097627c8df50fc2ce58026dc2ea.png

 

And at position 11428 is just the version:

Spoiler

image.png.2f9faa83acf54d74f7703f95285060a1.png

 

 

Share this post


Link to post

This still needs to be solved though, because there's just too many reports and that basically means it triggers ALL AV software.

 

And no, sorry, I am not disabling my AV, that's a very dumb move.

Share this post


Link to post

Ok so I downloaded So-Doom 5.7.4 again couple of minutes ago and its fine. I must of fucked up yesterday to think it had the same problems, so sorry to Zodomaniac.

Still don't know what's happening with Crispy Doom 5.7.2, completely agree with seed (post above), still really weird.

 

Share this post


Link to post

Avast gave me shit too when I downloaded 5.7.2 a couple of weeks ago or so. Scanned the URL on VirusTotal and it found nothing so I figured it was just Avast being a bitch and forgot about it. I'm not sure what to think now.

Share this post


Link to post

I always build my releases myself and i got just two positives on virustotal, must be false as in the case of So-Doom. The file is not flagged by Defender.

Share this post


Link to post

If it's only one or two, it's probably a false-positive, yes.

 

But the 20/30+ reports to also be false-positives is highly questionable, so something's surely wrong there, either with the detection or Crispy itself.

Edited by seed

Share this post


Link to post

Just to point out, as might be some confusion here: Zodomaniac reports only 2-3 in a file called "so-midiproc.exe"

 

I'm not familiar with this file. I obtain Crispy DOOM for Windows via the "releases" section here on GitHub:

https://github.com/fabiangreffrath/crispy-doom/releases

 

(expand "Assets" at the bottom to find a download called "crispy-doom-5.7.2-win32.zip")

 

There is no file in there called "so-midiproc.exe" but is one called "crispy-midiproc.exe"

 

The links I posted earlier for the three EXE files and how many AVs on VirusTotal are of flagging issues is based on this source

Share this post


Link to post
18 minutes ago, dftf said:

Just to point out, as might be some confusion here: Zodomaniac reports only 2-3 in a file called "so-midiproc.exe"

 

I'm not familiar with this file. I obtain Crispy DOOM for Windows via the "releases" section here on GitHub:

https://github.com/fabiangreffrath/crispy-doom/releases

 

(expand "Assets" at the bottom to find a download called "crispy-doom-5.7.2-win32.zip")

 

There is no file in there called "so-midiproc.exe" but is one called "crispy-midiproc.exe"

 

The links I posted earlier for the three EXE files and how many AVs on VirusTotal are of flagging issues is based on this source

 

Zodomaniac was talking about his source port called So-Doom 1.7.4, which his based on the CrispyDoom source code. I originally thought it inherited CrispyDoom 1.7.2's issues because of that, but after his research and me re-testing his source port, it works fine, he probably only got some false positives.

 

"so-midiproc.exe" is the So-Doom equivalent of "crispy-midioproc.exe". If you want to see to download the So-Doom source port to check, it's here:

https://github.com/Zodomaniac/So-Doom/releases/download/so-doom-5.7.4/so-doom-5.7.4-win32.zip

 

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
×