Need help compiling Crispy Doom

[jmpt16]

I'm trying to modify Cripsy Doom to make a custom fork of it, but I can't seem to get it to compile. I'm using this tutorial, along with Cmake, But everytime I do it says "Configuring incomplete, errors occurred!". Can anyone please help me?

[fabian]

Please try this instead:

 

https://github.com/fabiangreffrath/crispy-doom/wiki/Building-on-Windows

[NightFright]

What I am missing a bit is the part that comes after you set up msys2 (Win64 system). 

 

In particular:

1) What to do with the source files once downloaded? I copied the folder into my home dir, but what then? Where's the makefile?

2) How to prepare and compile x64 builds?

3) How to enable the truecolor option?

 

I don't want to bother others to compile new builds whenever I feel like it, so I also want zo do it on my own.

[dasho]

You'll need mingw-w64-i686-cmake installed, then you can run something along the lines of:

 

> cmake -B build -G "MSYS Makefiles"

> cmake --build build (-j# optional, I usually do my number of cores + 2 for this number)

 

From the cloned repo directory.

 

64-bit is largely the same set of instructions, but you'll need to substitute x86_64 for i686 in all the package names.

 

Truecolor appears to be an option you can pass to cmake or edit in the CMakeLists.txt file.

 

EDIT: YMMV, this is how I build programs in general with MSYS2, I admittedly haven't built Crispy Doom.

Edited March 16, 2022 by dasho

[NightFright]

Actually that part with renaming the package names was one of the few things I managed to figure out on my own. Basically, my interest is exclusively in building the x64 version since there are x86 autobuilds available.

 

There is this line in CMakeLists.txt residing in the root dir:

option(CRISPY_TRUECOLOR "True color rendering" OFF)

It's enough to change OFF to ON and save?

 

Still doesn't tell me which commands to actually run, though.

Edited March 16, 2022 by NightFright

[jmpt16]

4 hours ago, fabian said:

Please try this instead:

 

https://github.com/fabiangreffrath/crispy-doom/wiki/Building-on-Windows

Well, I did, and I got this:

 

Can't exec "aclocal": No such file or directory at /usr/share/autoconf-2.71/Autom4te/FileUtils.pm line 274.
autoreconf-2.71: error: aclocal failed with exit status: 1
./autogen.sh: line 4: ./configure: No such file or directory

 

[dasho]

What happens when you try the cmake commands I posted? That's usually enough if you have the dependencies in order.

[jmpt16]

2 hours ago, dasho said:

You'll need mingw-w64-i686-cmake installed, then you can run something along the lines of:

 

> cmake -B build -G "MSYS Makefiles"

> cmake --build build (-j# optional, I usually do my number of cores + 2 for this number)

 

 

 

$ cmake -B build -G "MSYS Makefiles"
-bash: $'cm\357\273\277ake': command not found

 

[dasho]

Did you copy and paste from the forum post? That seems bizarre. I would try hand typing it then.

Edited March 17, 2022 by dasho

[Gibbon]

Why use msys at all?  Just use cmake and either MinGW or Visual Studio.  I’ve always found they are easier to setup and really if software can compile with native tools, they should be used.  MSYS is generally for software that isn’t properly windows compatible.

Edited March 17, 2022 by Gibbon

[fabian]

13 hours ago, NightFright said:

What I am missing a bit is the part that comes after you set up msys2 (Win64 system). 

 

Oh, sure, sorry. I have just replaced the very unhelpful "now do the rest of the stuff" part with actual build instructions. 

[NightFright]

For me, Github cloning only works if I use HTTP instead of HTTPS:

git clone http://github.com/fabiangreffrath/crispy-doom.git

Otherwise, it will ask for username and password, which will not get me anywhere.

 

Then, when I try to execute autoreconf -fiv, I get this:

zsh: command not found: autoreconf

The other commands after that won't work, either, ofc. I followed the instructions before to the letter. Is there anything (like another package) that still needs to be installed which isn't mentioned in the instructions?

 

I can for example compile another project, YamagiQ2, without any issues by just typing "make" in its source dir. It also has a makefile, guess that's the problem here since it cannot be created.

Edited March 17, 2022 by NightFright

[fabian]

Okay, you'll need the mingw-w64-i686-autotools package (or replace i686 with your target arch).

[fabian]

Also, https shouldn't ask you for a user name unless you're trying to push something,  strange. 

[NightFright]

Mission successful! 

So, to be on the safe side, I suggest the following adjustments to your compilation instructions:

1) Mention that if git clone https://github.com/fabiangreffrath/crispy-doom.git doesn't work, use HTTP only
2) Add autotools package to step 4: pacman -S mingw-w64-i686-autotools
3) Mention to replace all "i686" instances with "x86_64" in case you want to do a 64-bit build

 

One last question:
I guess compiling Strife doesn't make much sense right now since it didn't receive any considerable optimizations compared to ChocoStrife (besides 2x res, but without widescreen options), but how would it be if one would want to compile it, anyway?

Edited March 17, 2022 by NightFright

[jmpt16]

2 hours ago, fabian said:

 

Oh, sure, sorry. I have just replaced the very unhelpful "now do the rest of the stuff" part with actual build instructions. 

Ok, so I did a fresh install of msys64 and followed the new tutorial you made. It worked! Thank you so much!

[fabian]

1 hour ago, NightFright said:

So, to be on the safe side, I suggest the following adjustments to your compilation instructions:

 

Done so, thank you for your input. 

 

 

1 hour ago, NightFright said:

I guess compiling Strife doesn't make much sense right now since it didn't receive any considerable optimizations compared to ChocoStrife (besides 2x res, but without widescreen options), but how would it be if one would want to compile it, anyway?

 

cd src

make -C strife

make crispy-strife.exe

[NightFright]

I still wonder why my binaries turn out to be so... "bloated". File size of the executables is 5-7 MB, whereas the originals are not larger than 1 MB.

[dasho]

Have you stripped the executable of debug symbols, etc?

[NightFright]

Found it. Basically just strip <executable name>. Excellent! Maybe also something to add to the instructions, as optional measure. (Has been done by now, thanks!)

 

Otherwise:

Does it pay off at all to create x64 binaries for this? It has been mentioned a few times that the advantages over the official x86 binaries are negligible. Are they?

Edited March 17, 2022 by NightFright

[wesleyjohnson]

Warning:

MinGW installs a make.

MSYS installs its own make.

They are not intercompatible.

 

>> make

This command will get you the MSYS make.

It will usually fail with all kinds of strange messages because it does not understand all the GNU makefile stuff (as far as I can tell).

MSYS interprets the command line for its own usage first.

 

If you have MSYS installed, you must invoke the MinGW make by

>>  mingw32-make

or some variation on that.  Look into the MinGW installation bin dirs.

 

Otherwise the MSYS commands are helpful, if you are not used to the DOS command line.

Adds some useful commands like grep.

The DOS command line is really painful to use when multiple directories are involved.

 

Edited March 19, 2022 by wesleyjohnson

[NightFright]

One question I still have:

How do I get the DLLs? I mean, I see where they are after I installed the necessary packages, but they don't end up in the Crispy Doom release dir, so is there a way to transfer anything that's necessary to that location?

[Gibbon]

Find them and copy / paste them into the root directory.  Don't forget the Msys dll file.

 

Also, great to see you able to compile it.  I guess I can drop crispy on Windows from my source port builds since everyone seems to have it down, one less thing to do :)

Edited March 23, 2022 by Gibbon

[fabian]

The packaging script does the most reasonable things:

 

make -C pkg/win32

 

Then look in pkg/win32/staging-doom

[NightFright]

This also works with x64 binaries or it's a different cmd, then? (Update: It produces 64-bit dlls, so I guess it's the same.)

 

Side note:
If you compile with truecolor enabled, it seems it generates Heretic/Hexen/Strife binaries in truecolor as well, which makes those binaries unusable. Ideally, with truecolor enabled, it should only generate Doom binaries at this point, actually (that or Heretic/Hexen will be 8-bit, no matter what).

 

Right now, one would have to compile with ./configure --enable-truecolor, only take the Doom binaries and discard the others, then do another run with ./configure and just pick Heretic/Hexen/Strife. That seems a bit complicated to me.

 

(Besides that, Doom in truecolor works great. I haven't been running into a single bug for weeks after that issue with the ep.3 scroller had been fixed.)

Edited March 27, 2022 by NightFright