A Collection of Doom Source Ports - Compiled and Packaged

[Redneckerz]

1 hour ago, Lol 6 said:

@Redneckerz could you edit the crispy-doom's page of the Doomwiki, more specifically this? Looks like the link provided there is broken, so it'd be nice if it pointed to the GitHub page where they are :)

I assume you mean the link from this post? Its done by the way.

 

I know that a duo did Crispy Hexen -- I was wrong, they did make Crispy Heretic, see this post. That's what i get for keeping notes on practically everything on DW :P

 

52 minutes ago, Gibbon said:

And if you feel hesitant to do so, fear not, because these source ports will be maintained for a very long time.  I don't abandon things :)

 

Edit:

 

As promised, woof 7.0.0 for Intel and Arm64 M1 Macs has been uploaded.

Where have you been in this Doom's life? :) but yeah a Crispy-All build would be beneficial. Unlike most of the other ports though, i reckon these do need some testing beforehand?

 

PS: I do agree with Kraflab''s post that doing those Crispy-All's called Chunky Heretic/Hexen/Strife is a fun and deviating way to do so :)

[Gibbon]

All my crispy builds contain all the binaries (even the Mac ones) since it is all built together it kind of makes sense.  I named that windows one 'all' though since the link was also shared on GOG and it makes it look more explicit for others.

 

Yes, they do require testing.  I usually run through a level or two, change some settings etc..  very basic stuff to see if core functionality works.  The older /less maintained the source port, the more I test things.  I can trust Woof and Crispy to be pretty darn compatible though.  Props to their author.

[Gibbon]

Latest addition is DoomRetro 4.3 for Mac Intel (M1 is coming).

 

A PR for a compilation fix was raised: https://github.com/bradharding/doomretro/pull/684

 

EDIT: M1 version is also up.

Edited October 17, 2021 by Gibbon

[rzh]

Hmm, is it possible to get Crispy Hexen 32-bit?

[Gibbon]

4 hours ago, rzh said:

Hmm, is it possible to get Crispy Hexen 32-bit?

It is possible but not from me.  My entire toolchain is 64bit and I haven't made a 32bit binary for anything for nearly 10 years now.

 

Just to make it clear, it would mean I would need a 32bit project setup with 32bit SDL2 and other dependencies.  I won't do all that for just any minor reason.  

Edited October 24, 2021 by Gibbon

[rzh]

4 hours ago, Gibbon said:

It is possible but not from me.  My entire toolchain is 64bit and I haven't made a 32bit binary for anything for nearly 10 years now.

 

Just to make it clear, it would mean I would need a 32bit project setup with 32bit SDL2 and other dependencies.  I won't do all that for just any minor reason.  

I figured you would've already done it if it was easy to accomplish. Thank you for the quick response!

[Gibbon]

Tonight I'll be doing NuggetDoom for Mac Intel and Mac M1.

[Redneckerz]

10 hours ago, Gibbon said:

Tonight I'll be doing NuggetDoom for Mac Intel and Mac M1.

Bitchy mode complain: How about the Zdoom/Colormap stuff? Or should i PM you?

[Gibbon]

2 hours ago, Redneckerz said:

Bitchy mode complain: How about the Zdoom/Colormap stuff? Or should i PM you?

Feel free to do a PM.  Though some of my time is also taken up by my map contributions to Community Trunk.  It's a nice change of pace :)

 

EDIT: Done, Nugget Doom 1.4.0 for Mac Intel is up.  Next will be Linux and M1

Edited October 29, 2021 by Gibbon

[Mr.Rocket]

Have you looked into Managed-Doom? ~ a C# version, compiles cleanly on MSVS 2019.

Edited October 30, 2021 by Mr.Rocket

[Gibbon]

I have not.  These are for systems which the upstream developer doesn't compile for.  Since Managed Doom has a binary, then it won't be added.  I'm doubtful if the author coded C# in a way that makes it compatible with Mono, but that is a big if.

[Mr.Rocket]

16 hours ago, Gibbon said:

These are for systems which the upstream developer doesn't compile for.

Ah ok sorry about that.

[Gibbon]

No worries, I appreciate the thought.

[Warrex]

Thank you for this absolute treasure chest! I highly appreciate your effort in general and especially the Apple Silicon builds.

 

As the M1 is just a SoC you might want to to switch to "Intel / Apple Silicon" or "x64 / arm64" in your naming sceme.

[Gibbon]

15 minutes ago, Warrex said:

Thank you for this absolute treasure chest! I highly appreciate your effort in general and especially the Apple Silicon builds.

 

As the M1 is just a SoC you might want to to switch to "Intel / Apple Silicon" or "x64 / arm64" in your naming sceme.

I had a think about this and since Apple are bringing the new M series processors out, it makes sense to use Apple Silicon over M1.

 

Nugget Doom for Apple Silicon will also be done and it'll be the first using the new naming and the first on MacOS Monterey.  My Intel Mac is too old to update past BigSur.

 

Thanks for the suggestion!

Edited November 2, 2021 by Gibbon

[Gibbon]

Nugget Doom 1.5.0 for Apple Silicon on MacOS Monterey is done.

 

EDIT: I also did Crispy Doom 5.10.3 for Linux x64 (Ubuntu 21.10).  But I hear you ask "but why Gibbon when Crispy is on flatpak".  I'll tell you, because flatpak isn't a universal standard across all Linux distros (Crispy isn't on the snapcraft store for ubuntu derivatives).  That and not all distros correctly support flatpak (Trisquel and other GNU FSDG compliant distros and repositories).  So yeah, an easy to use pre-compiled binary that you can drag and drop anywhere and play is far better than having to pollute your system with flatpak just to play a single Doom source port.

 

Also, DoomRetro 4.3 is now compiled for Linux x64 (Ubuntu 21.10)

Spoiler

 

There is also Nugget Doom 1.5.0 on Linux x64 (Ubuntu 21.10):

Spoiler

To build on Linux, I had to change the 'quick_exit' config integer and setting to 'doom_quick_exit' as quick_exit is declared in the GCC stdlib on Linux.

An issue has been raised for @Alaux

Edited November 3, 2021 by Gibbon
typo

[Gibbon]

Our resident redneck @Redneckerz is to thank for these ones (for bringing them to my attention).

 

Gloome 1.8.10 is now compiled for MacOS (SDL2 backend as the Cocoa version is hopelessly broken), I fixed the CMakefile for MacOS and also applied some fixes to the OpenAL implementation that I did for ZedDoom.  So sound effects are via OpenAL but music can only be played from the choices of Fluidsynth, Gus or Timidity.

 

Linux and Windows versions are coming soon (tomorrow).

Edited November 6, 2021 by Gibbon
typo

[Redneckerz]

7 minutes ago, Gibbon said:

Our resident redneck @Redneckerz is to thank for these ones (for bringing them to my attention).

 

Gloome 1.8.10 is now compiled for MacOS (SDL2 backend as the Cocoa version is hopelessly broken), I fixed the CMakefile for MacOS and also applied some fixes to the OpenAL implementation that I did for ZedDoom.  So sound effects are via OpenAL but music can only be played from the choices of Fluidsynth, Gus or Timidity.

 

Linux and Windows versions are coming soon (tomorrow).

Small context;

GLOOME made the rounds in 2015 as an GPL-compliant version of GZDoom and launched with two standalone games. Another, Cursed Maze, was converted to it. GLOOME is by @TerminusEst13 and Marrub. -

Now, some things:

• GLOOME is based on a old GZDoom build (GZDoom 1.8.10). Its also OpenGL-only: GLOOME derives from GPLZDoom, a fork by LavenderMoon that removed this.
• Developed around the same time was GZDoom-GPL by Nash Muhandes. However, GLOOME specifically tailors towards custom games as an open engine, GZDoom-GPL was more a GPL-complaint fork.
• current day GZDoom is also GPL-complaint and with the GLES renderer also can target OpenGL cards.

So why GLOOME then?

• GLOOME didn't have much in the way of multi-platform support - Thanks to Gibbon, GLOOME can be on a lot more places now.
• GLOOME has some rather unique enhancements (ACS), renderer that makes it less compatible with GZDoom. It is primarily made towards new games, first and formost.
• GLOOME is discontinued, but these new builds include the latest commits, post-beta.
  • As a by-effect, GLOOME is also thus in a fixed state: It won't move beyond new features, making it easier to target for.
• GLOOME is also a lot more simple: It provides a unified platform with a fixed set of possibilities to work with.

Even though there are other alternatives, i believe GLOOME has a place, if only for the reasons above. With an updated 64 bit SDL2 build, GLOOME should be open once more for any aspiring game developer, despite its limitations.

[Gibbon]

Gloome 1.8.10 is now compiled and packaged for Windows 64bit.

Edited November 7, 2021 by Gibbon

[Redneckerz]

1 hour ago, Gibbon said:

Gloome 1.8.10 is now compiled and packaged for Windows 64bit.

!!!! You should make a separate thread of this. That's huge.

EDIT: See your PM!

Edited November 7, 2021 by Redneckerz

[Gibbon]

Just now, Redneckerz said:

!!!! You should make a separate thread of this. That's huge.

EDIT: See your PM!

Well, you are the better writer :)

[Redneckerz]

47 minutes ago, Gibbon said:

Well, you are the better writer :)

Then i may just take up your offer :)

[Gibbon]

32bit version of Sprinkled Doom (and all the others) is now up too, since I've seen quite a few people around here requesting 32bit builds.

Edited November 9, 2021 by Gibbon

[rzh]

13 hours ago, Gibbon said:

32bit version of Sprinkled Doom (and all the others) is now up too, since I've seen quite a few people around here requesting 32bit builds.

Well this is a surprise.

I played through Hexen.

I finished the first hub (+ secret level) and started the second (grabbed the Firestorm, went to Darkmere, finished the first visit there).

This is pretty much everything that I wanted.

Although, the crash mentioned here still happens with all limits removed, not sure why or if it's even caused by something that's within the scope of this port.

[Gibbon]

2 hours ago, rzh said:

Well this is a surprise.

I played through Hexen.

I finished the first hub (+ secret level) and started the second (grabbed the Firestorm, went to Darkmere, finished the first visit there).

This is pretty much everything that I wanted.

Although, the crash mentioned here still happens with all limits removed, not sure why or if it's even caused by something that's within the scope of this port.

No worries, glad you got to play it.

 

I'll check that out while running it through a debugger.

 

Since it happens on Choco, might be worth also @fabian having a look at the Choco code for that project too.

Edited November 10, 2021 by Gibbon

[Gibbon]

Also, I'll check the same on Strife.  I think these lesser-played games could have some issues.

 

EDIT: So, I checked through the code and it appears that the saves were throwing some null pointers while saving the numbers of mobs.

 

Lucky for us, @fabian had fixed it in Crispy (apparently) but Choco never took the fix.  What worked for sprinkled was this:

// [Dasperal] If the save is corrupted and the identity number is higher than the number of objects on the map restore it as a NULL pointer.

// This still potentially leaves complex objects broken but NULL is safer than garbage value.

else if (archiveNum < MobjCount)

{

*ptr = MobjList[archiveNum];

}

else

{

*ptr = NULL;

}

It now saves perfectly fine.  Pushed it to master.

Edited November 10, 2021 by Gibbon

[rzh]

Amazingly quick, perfect.

Since I play lots of Hexen I'll make sure I'll report anything weird that I might encounter.

There's at least one visual glitch that I'm aware of in choco, but I haven't checked in DOS to see if it happens there as well, because it might.

I'll see if I have time tonight to try to replicate it.

I don't like Strife though :P

[Gibbon]

Latest addition is the EDGE Classic Preview 1 for MacOS Intel on Big Sur.  Since I used hombrew for glew and sdl1 I have included both dynamic libraries so it will run.

[Warrex]

Gibbon, can you please enligten me how to actually run your Apple Silicon builds? Just tested the Doom Retro release unsuccessfully so far. This is what I get:

 

Last login: Sat Nov 20 16:50:39 on ttys000
/Users/user1/Downloads/DoomRetro_4.3_MacOS_M1/doomretro ; exit;
user1@Mac-mini-2020 ~ % /Users/user1/Downloads/DoomRetro_4.3_MacOS_M1/doomretro ; exit;
zsh: exec format error: /Users/user1/Downloads/DoomRetro_4.3_MacOS_M1/doomretro

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Gibbon]

5 minutes ago, Warrex said:

Gibbon, can you please enligten me how to actually run your Apple Silicon builds? Just tested the Doom Retro release unsuccessfully so far. This is what I get:

 

Last login: Sat Nov 20 16:50:39 on ttys000
/Users/user1/Downloads/DoomRetro_4.3_MacOS_M1/doomretro ; exit;
user1@Mac-mini-2020 ~ % /Users/user1/Downloads/DoomRetro_4.3_MacOS_M1/doomretro ; exit;
zsh: exec format error: /Users/user1/Downloads/DoomRetro_4.3_MacOS_M1/doomretro

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

Hmmm interesting..  it literally just crashes right?  I made sure to link to static libraries so I don't have to provide the .dylib files.  I'll package it up with all of them later just to be sure.

 

Naturally I don't have another non-dev M1 to test the builds on so this is helpful!

 

Just to make sure, are you setting the binary as executable and allowing gatekeeper to run it?

 

EDIT: Just had a thought, if you don't have the command line tools installed you won't get OpenGL Framework.  That could be it!

 

Ill definitely package up all the dependencies later for you and see if that works.  Nice to have another M1 user here!

Edited November 20, 2021 by Gibbon