A Collection of Doom Source Ports - Compiled and Packaged

[speedy206]

The process of cross-platform porting is a new concept to me. Is it Crispy Doom's own code that determines to use ~/Application Support/crispy-doom/ as the location for the config file and other supporting files or is this something that's translated during the cross-platform porting process, @Gibbon, to make it compatible with macOS?

 

If it's part of Crispy Doom code, then how does that work given that Crispy Doom is written for Windows?

 

If it's during the porting process, then wouldn't it be possible to make a change to tell Crispy Doom to somehow read/write its cfg files with prefixes of the WAD files or placed in subfolders with the name of the WAD? For example, doom2-crispy-doom.cfg, plutonia-crispy-doom.cfg, and tnt-crispy-doom.cfg. Or another example could be to use folders such as config/doom2/crispy-doom.cfg, config/plutonia/crispy-doom.cfg, and config/tnt/crispy-doom.cfg.

Edited November 25, 2021 by speedy206

[Gibbon]

I would not call this porting.  Crispy Doom is cross-platform without any changes, due to it using SDL2 and sane paths and decent, portable coding standards.  I guess the author(s) just don't want to spend 1200 euro's on a Mac :P

 

Crispy (like Chocolate Doom) implement different paths for different operating systems, putting the config file into Application Support/crispy-doom is a 'mac-like' path.  It is where all our stuff should be going.  This is crispy doom's code.

 

I would say, if you raise an issue about it and ask for a new config setting to be added, it at least gets the ball rolling.  Fabian is a pretty reasonable person I think.

Edited November 24, 2021 by Gibbon

[Warrex]

On 11/23/2021 at 7:16 AM, Gibbon said:

DoomRetro 4.3(latest git) is now a universal app bundle.  @Warrex this should be way better than your last try.

 

Tested it and yeah it is a much better experience. I still wonder why it asks for permisson to access the keyboard input of all apps. If I deny it then Doom Retro still works but there is another problem I noticed from playing just a few minutes. Long pressing "a" for example while circle strafing will overlay a keyboard menu where you can choose which variant of "a" you want (like à or ä). You know this from your iPhone.

[Gibbon]

Yeah it is the only source port that does these two things.  Could be down to how it is using SDL or whatever differences it has.  I haven't really looked at the doomretro code that much so cannot say for sure.

 

Edit: I've taken a peek and it is using quite a lot of 'NS' stuff for the Apple code.  Looks like it is being as 'Mac' as possible but this interferes with the native keyboard handling.  I'll try and track down the exact piece of code (unless Brad see's this and beats me to it) ;)

Edited November 26, 2021 by Gibbon

[speedy206]

@Gibbon could you possibly also compile Crispy Heretic and Hexen?

[Gibbon]

1 hour ago, speedy206 said:

@Gibbon could you possibly also compile Crispy Heretic and Hexen?

For M1?

 

@speedy206 - Done.

 

Crispy Doom 5.10.3 has a brand spanking new .app bundle with all binaries included, compiled with arm64 and x86_64 (MacOS Universal 'fat' binary), thus is a Universal app bundle.

 

I also modified Sprinkled Launcher to execute the crispy doom executables instead of not having a launcher at all.  Makes playing it on a Mac actually bearable.

Edited December 5, 2021 by Gibbon

[speedy206]

54 minutes ago, Gibbon said:

For M1?

That would be awesome. There isn't currently a build of either for Intel Macs either from what I can tell, but they have historically been compiled for old versions. Is there any reason to not just do it as a Universal version so anyone can run it?

Edited December 5, 2021 by speedy206

[Gibbon]

12 minutes ago, speedy206 said:

That would be awesome. There isn't currently a build of either for Intel Macs either from what I can tell, but they have historically been compiled for old versions. Is there any reason to not just do it as a Universal version so anyone can run it?

I just did :P

 

Edit: I also did a Universal bundle of DoomRetro 4.4.

Edited December 5, 2021 by Gibbon

[speedy206]

7 hours ago, Gibbon said:

I just did :P

 

Edit: I also did a Universal bundle of DoomRetro 4.4.

Thank you! Where can I download it though? I just looked on the GitHub page and didn't see it listed there. 

[Gibbon]

3 hours ago, speedy206 said:

Thank you! Where can I download it though? I just looked on the GitHub page and didn't see it listed there. 

https://github.com/atsb/source-port-builds/releases/download/1.0/CrispyDoom-5.10.3_Universal.app.zip

 

https://github.com/atsb/source-port-builds/releases/download/1.0/DoomRetro-4.4_Universal.app.zip

Edited December 6, 2021 by Gibbon

[Gibbon]

So a few days ago, @PBeGood4 raised a bug with dsda on Mac on the source port builds repo.  Rather then have two locations (his launcher is way better than the stock one) I've decided that it is just better to use https://github.com/Pedro-Beirao/dsda-launcher on a Mac.  So I'll pull my dsda builds for Mac from source port builds.

 

Hats off to you!  That Launcher is sexy!

[PBeGood]

Thanks! I made this launcher because the older one gave me nothing but problems.

Also, there is a problem with the Woof universal build.

It crashes on M1. But it does work when running with Rosetta

 

The problem seems to be that for arm64, it is linking to x64 dylibs

Also, otool -L reveals that for arm64, libSDL2-2.0.0.dylib is linked to /usr/local/lib/libSDL2-2.0.0.dylib instead of @executable_path/libSDL2-2.0.0.dylib

 

Oh, and how did you manage to compile Woof? Last time I tried it I got a lot of errors

Edited December 12, 2021 by PBeGood4

[Gibbon]

7 minutes ago, PBeGood4 said:

Thanks! I made this launcher because the older one gave me nothing but problems.

Also, there is a problem with the Woof universal build.

It crashes on M1. But it does work when running with Rosetta

 

The problem seems to be that for arm64, it is linking to x64 dylibs

Also, otool -L reveals that for arm64, libSDL2-2.0.0.dylib is linked to /usr/local/lib/libSDL2-2.0.0.dylib instead of @executable_path/libSDL2-2.0.0.dylib

 

Oh, and how did you manage to compile Woof? Last time I tried it I got a lot of errors

I swore I got that changed with the install change tool.  All my SDL2 dynamic libraries are smashed together using lipo to create universal dylibs.  I'll check that then.  Sometimes if I'm doing 3 at a time, I'll forget to do something :)

[Gibbon]

Thanks @PBeGood4!  Woof 8.1.0 is now a Universal .app bundle.

 

You were right, I had forgotten to use the install_name_tool to change the path of the dynamic libs.  I tested it on my Intel and M1 Mac, works like a dream now.

 

One thing to point out when analysing those dylibs, it will only show the slice for your architecture.  On M1 it'll show the ARM64 slice, on Intel it'll show the X86_64 slice.  I'll be happy to throw them all up onto a repo to provide those universal dylibs.

[PBeGood]

Yep its working now.

Its great to see so many ports available for macOS. Nice job!

[Gibbon]

22 minutes ago, PBeGood4 said:

Yep its working now.

Its great to see so many ports available for macOS. Nice job!

And thanks for also raising those issues!

 

+1 to the MacUserMasterRace :P

[Gibbon]

new source port built:

 

Russian-Doom-Heretic-Hexen-5.1_macOS_universal.zip (contains all three as separate universal (arm64/intel) bundles.  All self-contained).

 

Issue raised:

https://github.com/JNechaevsky/russian-doom/issues/299

 

Otherwise it is perfectly playable.

 

Licenses, Docs etc..  are contained within the bundles.  Looks badass in cyrillic.

Edited December 27, 2021 by Gibbon

[wesleyjohnson]

Hello.

DoomLegacy supports some older OS as ports, but we no longer have developers with those machines.   We do not supply binaries for those ports.

 

I you have any plans to compile some of the missing binaries for DoomLegacy, you should contact me at SourceForge, or a doomworld message.

 

The MAC SDL port (SDL 1.2 on a MAC) was not working.  I was working with a volunteer who offered to compile, but he then wanted to dictate patches and wanted them done right away, so that ended.   I have a debugging version of the source for working on MAC-SDL, which I could update to 1.48.10.   It has some changes for the Mac, and some instrumentation.

 

The macos port has not been compiled recently.  I keep patching it, but do not know how much has become broken in the last 10 years.

 

The OSX port is more likely to run, but has not been compiled lately either.   Also has been patched as best I can.  It seems to be very similar to the DOS port.

 

I have FreeDOS, and have plans to work on the DOS port (djgppdos), one of these years.

Likely will have to change it to support a different compiler now.

 

Compiling with Microsoft products on Windows is not covered (I compile using MinGW32 on a WinXP).

The features that use LIBZIP, and ZLIB are only supported on Linux, and do not work on Windows, because I do not know what the equivalent libraries on Windows would be.

This is also true for the other OS, like Mac and OSX.

 

I expect that any effort to compile these missing binaries will be more than you were planning to invest in this.

If you do any compile, I would appreciate getting the error listing, so I can at least patch up a few of the more obvious compiling bugs.

 

I develop using 32 bit on Slackware Linux.

We already have some users with 64 bit machines, and they submit bug reports on that for Linux.

We also have some BSD and NetBSD users who submit bug reports on those.

One user prefers to  use Clang, so I get bug reports on that compiler too.

I have a WinXP machine with MinGW32.  That is the source of the Win32 SDL binaries.

 

A source code package is in the FILES at SourceForge.

https://sourceforge.net/projects/doomlegacy/files/1.48.10/

I recommend just getting the source code package.

 

We use SVN.

The path for 1.48.10 is under  SVN/legacy_one  (This is the one I work on).

The Legacy2 code is under  SVN/legacy (C++, with Hexen, but lacking Net play and a few things).

I do not know what that is under GIT, but it looks vaguely like old Legacy2 stuff.

 

You must use MAKE and the make_options_xxx files.

Read the docs/README_Compiling.txt, follow the instructions.

The Makefile is very complicated, supporting many options.

 

Do not try using CMAKE unless you want to spend some time getting it to work.  It is only for SDL (and probably only works for Linux), and does not support options.  I patched the cmake files, trying to bring it up to date, but I don't know how to get cmake to do the things the Makefile does.

 

Thank You

Wesley Johnson, Doom Legacy development team.

 

Edited January 21, 2022 by wesleyjohnson

[Gibbon]

I'll take a look at that on macOS.  I'm working with SDL1.2 also recently on MacOS since I forked Hammer of Thyrion, so there isn't anything more to setup.

 

Let's see if we can get a Mac build for it working :)

[Gibbon]

@wesleyjohnson

 

Done, it was easy actually.  So props to you and your developers for keeping it relatively compatible without having Macs of your own.

 

Spoiler

 

I have DM'd you a patch.

 

App Bundle: https://github.com/atsb/source-port-builds/releases/download/1.0/DoomLegacy-1.48.10_mac_Intel.app.zip

 

I will do an M1 build later.

Edited January 21, 2022 by Gibbon

[Redneckerz]

On 1/21/2022 at 2:07 PM, Gibbon said:

I'll take a look at that on macOS.  I'm working with SDL1.2 also recently on MacOS since I forked Hammer of Thyrion, so there isn't anything more to setup.

 

Let's see if we can get a Mac build for it working :)

I don't want to convolute, but have a look (if you may) at the Legacy 2 code aswell.

 

I know, its old, Wesley isn't working on it, but it was worked on in 2007 and constitutes a renderer rewrite.  The last build is an alpha build from December 12, 2007, but its not mentioned anywhere. Simply put, Legacy2 is barely visible these days.

 

Older versions are listed here and here. The direct TeamHellSpawn link may work, but archive.org also has them kept up.

 

But there has been some work ever since and i think its worthwhile to keep. The Legacy2 branch is somewhat confusingly known as the legacy branch, here. It shows that work was done by smite-meister till 2014. In 2017, the original programmer did some additional progress.

 

Here is the official features list (Use Download this file to have it more viewable). I got that link from a @Mr.Rocket post :)

 

• It has Hexen support (unlike Legacy 1)
• It also has some then-advanced rendering paradigms:
  • Normal mapping
  • Per-pixel lighting

The only low-res screenshot i have is the one below showing a normal map.

 

And here is a link with links to those shots.

 

Other planned features of Legacy 2.0:
 

Quote

• Hexen support.
• ACS and BEX.
• New netcode, based on OpenTNL, used in Tribes 1 and 2.
• 4 player splitscreen, support for modern joysticks and gamepads.
• Multiple maps can be run simultaneously on a server, with the players moving back and forth between them.
• New OpenGL renderer with support for GLSL shaders.
• High resolution textures in compliance to the JDS Joint Texture Standard draft.
• PNG-based textures with alpha channel.
• JPEG-based textures.
• Ogg Vorbis, mp3 and several module music formats are supported.
• MD3 models.
• Partial DECORATE support.
• ZIP/PK3 files can be used in addition to WADs.
• OpenGL skyboxes.
• More compatibility with ZDoom.

 

Edited January 22, 2022 by Redneckerz

[Gibbon]

@Redneckerz is there any updated links to source code?  Considering webarchive links don't work.  No source = no build.

[Redneckerz]

2 hours ago, Gibbon said:

@Redneckerz is there any updated links to source code?  Considering webarchive links don't work.  No source = no build.

My many post-edits probably made it miss you, but this is the latest one i believe, confusingly named Legacy - https://sourceforge.net/p/doomlegacy/svn/HEAD/tree/legacy

 

EDIT: But that's not what the 2017 edits look like. Here is a GIT: https://sourceforge.net/p/doomlegacy/legacy2/ci/master/tree/

 

But the Master Server GIT has 2016 timestamps: https://sourceforge.net/p/doomlegacy/masterserver/ci/master/tree/

 

Check also this post by @fabian - https://www.doomworld.com/vb/post/1352901 Maybe he can give some further pointers.

 

EDIT:  I found the edits from this this post from 2017:

 

They are somewhat hidden and part of this parent. Here they are:

• dac3dc
• 2e4d92
• 279c7f
• 8ce3af

I know that Legacy 2.0 as-is does not have a lot of its planned features, but the OpenGL renderer atleast was pretty complete.

Edited January 22, 2022 by Redneckerz
Updated it with correct commits.

[Gibbon]

I'll take a dive then.  Yeah, about that legacy.wad.  That was never a problem for me, I saw what paths there were and added it to the right one.

 

I very rarely need pointers ;)

 

Edit: So yeah, I won't be doing this for macOS.  The entire build is working only on GCC.  Even when disabled, it requires utter dependency hell, that's not something I'm going to be spending my time on.

Edited January 22, 2022 by Gibbon

[Redneckerz]

1 hour ago, Gibbon said:

I'll take a dive then.  Yeah, about that legacy.wad.  That was never a problem for me, I saw what paths there were and added it to the right one.

 

I very rarely need pointers ;)

 

Edit: So yeah, I won't be doing this for macOS.  The entire build is working only on GCC.  Even when disabled, it requires utter dependency hell, that's not something I'm going to be spending my time on.

I think Legacy2 never was meant for MacOS - Unlike Legacy 1, 2 is a complete rewrite and targets Windows/Linux.

 

Its kind of damning that its most glaring features - Normal mapping/Per-pixel lights are still quite novel, even today.

[Gibbon]

I'll see about doing that for Windows (MSYS2) only.

 

As for Wesley's legacy one branch.  There is now a Universal (Intel/M1) app bundle.

 

Edit:

DoomLegacy is now ported back to FreeBSD.

https://github.com/atsb/source-port-builds/releases/download/1.0/doomlegacy-1.48.10-freebsd-x86_64.tar

 

Oh and I did a new Doom Retro version a few days ago.

Edited January 27, 2022 by Gibbon

[Gibbon]

So, since I was doing some arm stuff yesterday, below are a few builds for the Raspberry Pi 3 (Raspbian 32bit):

 

doomretro-4.4.3-rpi3.zip
nugget-doom-git-master-010222-rpi3.zip (latest git master as of today)
woof-8.1.0-rpi3.zip

 

All are compiled and optimised specifically for the RPI3's CPU (Cortex-A53).

 

Woof and Nugget have Music (via OPL).  Apparently Doom Retro doesn't have OPL music and so that has no available music (RPI cannot do music via SDL) for some reason..

 

Crispy has a horrible issue with micro stutters, so I have not provided that.

 

For Doom Retro, I have provided a cfg file with decent presets to allow it to run at 60fps locked.  Nugget and Woof both run (windowed) at 60fps (without widescreen and hires).  All builds have a custom rpath and SDL2 libraries contained.

[wesleyjohnson]

DoomLegacy uses ZLIB and LIBZIP to provide some zip services, but only available under Linux, because I do not know how to handle those libraries under other OS.

I am a Linux programmer, and do only limited work in Windows.

LIBZIP is the important one as it allows DoomLegacy to read zipped wads.

ZLIB is only used for compressed ZDoom nodes, and its importance is marginal due to lack of wads using that format.

 

I assume that the current zip code should work for FreeBSD and for the Mac.

So did you provide ZLIB and LIBZIP when you compiled DoomLegacy under  FreeBSD ?

 

Do you know of any ports that have provided ZLIB and LIBZIP library access on Windows, or have provided a substitute.

I want to see how they did it.

 

Thank You

 

[wesleyjohnson]

I have several problems with myself working on Legacy2.

• It was rewritten in C++.  Most of my projects use C++, but I do objects differently.
• I find object-oriented programming, the way most people do it, to be counter-productive.  Boiler-plate style object-oriented programming is an abuse of the concept.  I would be forced to either tolerate all that or fix it all.
• It uses oxygen, the commenting style for managers.  Oxygen is an annoyance.
• This would not just be a few patches and leave.  I would be doing so much work on it, that I would have to marry the code and bring it into my home.  If I am not committed, I probably should not touch it.
• The guy that did much of the coding is still the DoomLegacy administrator.  He would be looking over my shoulder at everything I did to it.

[Edward850]

22 minutes ago, wesleyjohnson said:

Do you know of any ports that have provided ZLIB and LIBZIP library access on Windows, or have provided a substitute.

Zlib is literally just a pile of ordinary C files, you can compile it on anything that has a C compiler, operating system has absolutely nothing to do with it. Though I've never used it, Libzip looks much the same and in fact has less files.

Your only concern for these sorts of libraries would frankly be ARM/64, due to the differences in char behaviour (char is unsigned on ARM, signed on x86) and signed/unsigned casts. Though zlib for us definitely didn't run into such an issue when porting stuff to the Switch (Doom angles on the other hand, yeesh).

Edited February 8, 2022 by Edward850