Jump to content

A Collection of Doom Source Ports - Compiled and Packaged


Gibbon

Recommended Posts

4 minutes ago, Gibbon said:

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

 

Yes, both.

 

PrBoom and Woof also do not work. The x64 build of Doom Retro misses SDL2:

 

Last login: Sat Nov 20 16:51:05 on ttys000
/Users/user1/Downloads/DoomRetro_4.3_MacOS_Intel/doomretro ; exit;              
user1@Mac-mini-2020 ~ % /Users/user1/Downloads/DoomRetro_4.3_MacOS_Intel/doomretro ; exit;
dyld[64284]: Library not loaded: /usr/local/lib/libSDL2-2.0.0.dylib
  Referenced from: /Users/user1/Downloads/DoomRetro_4.3_MacOS_Intel/doomretro
  Reason: tried: '/usr/local/lib/libSDL2-2.0.0.dylib' (no such file), '/usr/lib/libSDL2-2.0.0.dylib' (no such file)
zsh: abort      /Users/user1/Downloads/DoomRetro_4.3_MacOS_Intel/doomretro

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

Share this post


Link to post

Oh nuts I must have linked that to the dynamic libraries and didn't notice.  Drat, I'll redo them all and package every dependency with it.  Thanks for this!

Edited by Gibbon

Share this post


Link to post

Ok @Warrex I have uploaded a new M1 build of Doom Retro 4.3 (same file name as before) but with OpenGL.framework and all the SDL2 Dynamic libraries added.

Share this post


Link to post

Does not work either. At least to without copying the files to the given path which I did not try. If you want more people to use your builds on the Mac the releases should be application bundles (.app) like with GZDoom.

 

Also signing/notarizing would help alot but you probably know this and it is to much of a hassle.

 

Last login: Sat Nov 20 17:08:57 on ttys000
/Users/user1/Downloads/DoomRetro_4.3_MacOS_M1\ 2/doomretro ; exit;              
user1@Mac-mini-2020 ~ % /Users/user1/Downloads/DoomRetro_4.3_MacOS_M1\ 2/doomretro ; exit;
dyld[65431]: Library not loaded: /usr/local/lib/libSDL2-2.0.0.dylib
  Referenced from: /Users/user1/Downloads/DoomRetro_4.3_MacOS_M1 2/doomretro
  Reason: tried: '/usr/local/lib/libSDL2-2.0.0.dylib' (no such file), '/usr/lib/libSDL2-2.0.0.dylib' (no such file)
zsh: abort      /Users/user1/Downloads/DoomRetro_4.3_MacOS_M1\ 2/doomretro

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

Edited by Warrex

Share this post


Link to post

Well the issue with .app bundles is if they aren't created automatically, then it is a manual job.  That and Apple don't allow C programs anymore for .app bundles on Xcode.  I can do it manually but in my experience it is not very stable, unless they have a gui launcher included, it would also mean you cannot switch the iwads.  Woof for example has no iwad gui, so you have to use the terminal.  I know most Apple users are scared of it, but it's there for a reason.

 

Signing means a 100$ annual payment + my personal details for a signing certificate.

 

For GZDoom it's alright, any software with a huge following gets people to do this.  Of course, if anyone is willing to do this for all these projects, fine.  But apparently I'm the only Mac user bothering to even compile it.  Let alone get Apple's janky distribution process working ;)

 

I know the issue, I'll just change the path in the executable to point to the directory it is in.

Edited by Gibbon

Share this post


Link to post

Don't get me wrong. It is a great project and thank you again for the effort.

 

I am personally looking for stable Apple Silicon Mac builds which continue to be maintained and which I could ideally also recommend to other people who are novice Mac users and who do not know what Gatekeeper is etc.

 

Besides GZDoom I currently mainly care for Doom Retro and PrBoom Plus um. DSDA Doom, Woof and an Apple Silicon build of Eternity would also be nice.

Edited by Warrex

Share this post


Link to post

Well PRBoom, DSDA have the gui so a .app is possible (it is created as part of cmake).  However Woof doesn't have a gui so that is a traditional console app, doomretro has a project but my M1 is the 128GB model and thus, no space for Xcode on that.

 

But yeah, I won't be signing them at all.  Like GZDoom, that would be the responsibility of the project as signing them means you are vouching for the integrity.

 

I don't think kraflab, fabien etc..  use macs let alone sign the builds.  Only GZDoom currently does this.

 

I'll fix all the builds with changing the library paths etc..  but as far as making them novice friendly, unfortunately not.

 

 

Edited by Gibbon

Share this post


Link to post

So (For Intel Mac) Doom Retro 4.3 and Woof 8.0.0 are fixed and completely self-contained.  I have setup a clean-room environment on my Mac(s) so that I can test without having globally accessible libraries.  Each one is tested twice, once in the clean room and again in the main directory before I zip them up.

 

I'll do them in order of popularity / importance.  So next (probably tomorrow) I'll do the same but for M1.

 

Big thanks to Warrex for finding out my stupid mistake :)

Edited by Gibbon

Share this post


Link to post

Phew..  setup another clean room environment on my M1, Doom Retro 4.3 is now working on M1 self-contained.  No app bundle due to the save issue but once it's solved I will start doing app bundles for it.

Share this post


Link to post

I started Doom Retro and Gatekeeper told me that it could not search for malious software in one of the .dylib files. So I had to right click + open on every single one of those 4 files.

 

Then Doom Retro opens with a finder window without telling me what to do. I assume that I am supposed to point to an IWAD but I cannot choose doom2.wad ("Open" stays greyed out") in a subfolder of "documents". A window which asks for folder access rights does not appear and even giving Doom Retro full disc access does not help. I then still cannot choose the IWAD.

Share this post


Link to post
34 minutes ago, Warrex said:

I started Doom Retro and Gatekeeper told me that it could not search for malious software in one of the .dylib files. So I had to right click + open on every single one of those 4 files.

 

Then Doom Retro opens with a finder window without telling me what to do. I assume that I am supposed to point to an IWAD but I cannot choose doom2.wad ("Open" stays greyed out") in a subfolder of "documents". A window which asks for folder access rights does not appear and even giving Doom Retro full disc access does not help. I then still cannot choose the IWAD.

Yeah I cannot do anything about that.  If you do ./doomretro -iwad <iwad file> it will start.  The iwad gui works from a .app bundle but you cannot currently save so I didn't add it.  No idea why the gui window doesn't work from the command line, likely some permissions that a bundle allows.  Gatekeeper is a real bitch, Apple lost their mind when they thought that was a good idea.

 

But yeah, even if I could sign it, it would be wrong to provide bundles that are not signed by the project lead, the whole point of signing is about ownership, Brad would have to do it really because then if a third-party is offering signed bundles, it defeats the purpose of it being signed in the first place ;)

 

So basically ./doomretro -iwad DOOM2.WAD -file <.WAD/.DEH etc..> -skill 1 - 5 -warp 1 - 31

Edited by Gibbon

Share this post


Link to post

Okay, this kinda works. Doom Retro starts but I am greeted with a window which is layed on top of the app stating that terminal.app wants to capture the input of all apps (I am freely translating from German). I cannot click on this window or use the keyboard on it. After having given terminal the permission under settings (which is probably not a good idea from a security perspective I would assume) and restarting Doom Retro it finally seems to work fine. Activity monitor also shows that Doom Retro runs indeed natively.

 

To be quite frank this is all just to crude for me and more like a proof of concept that Doom Retro can be compiled for macOS just fine.

 

Gatekeeper and other attempts by Apple to harden macOS against malicious software are a reality which won't go away no matter how developers, power users and anyone who questions Apples ethics behind it feel about it. Signing and notarizing sucks for OSS projects and even smaller developers. I do understand that. Eugene Roshal the dev of RAR told me that they have so few users under macOS that he was not sure if it was worth the hassle of signing and notarizing (Apple Silicon builds are available).

 

Maybe Brad and you can work something out as he reacted positively to your posts several times. I donated to him the past and I am willing to sponsor this with 99 USD for the developer account in case that there is any interest by him.

Share this post


Link to post

I completely agree with you and yes it is crude.  Under a .app it works a bit better but still it is far from perfect.

 

I see Brad lurking, he must have some filter that gives him notifications everytime Doom Retro is spoken of :) but as for users, I'm fairly sure Myself and you are the only Mac users (and certainly the only M1 users) who have ever run Doom Retro.  So it also may not be totally worth it.  It sucks that it is this way and Apple are slowly moving Macs away from gaming and onto tasks more representative of what they want.  It is highly probable that one day, it simply won't be worth putting up with that stuff anymore and it'll just be Windows and Linux.

 

The choice is there (which is why I am mostly doing this).  It is a shame it is limited to power users and I'm guessing 95 percent of the Mac doomers are using GZDoom.

Edited by Gibbon

Share this post


Link to post

I am personally looking to move away from Windows as much as I can. My two main desktop computers are still x64 based Windows 10 machines but I am fed up with Microsoft and all their telemetry BS, etc. and I am deeply invested in the whole Apple eco system and love it for the most part. I do not want to make this another Mac vs PC discussion though so let's just say that I am trying to take the software I like with me.

 

Doom is a top priority as I can say that it is the game that I have played the most since 1993 - every year. I do like GZDoom the most and also have an emotional attachment to it cosidering I have been using ZDoom since the days of its early DOS releases. Mailing bug reports to Randy has been a great experience as she was very responsive back then which the GZDoom team still is today. So I am glad they have a macOS build which is maintained.

 

Sometimes using another port like Doom Retro or Prboom um breathes in some fresh air or takes you back in a nostalgic way. This is why I hope to see more macOS releases in the future.

Edited by Warrex

Share this post


Link to post

Couldn't agree more and yeah, I am also invested heavily in Apple (pretty much every gadget except a Magic Mouse).

 

I will definitely keep doing Mac builds and I will put more effort into making .app bundles too.  I'm not planning on stopping my Mac usage ever so count on it continuing.  

Share this post


Link to post

@Gibbon Thank you! 

 

I initially couldn't get Crispy Doom to run until I installed the following dependencies from Homebrew:

https://formulae.brew.sh/formula/sdl2 

https://formulae.brew.sh/formula/sdl2_mixer

https://formulae.brew.sh/formula/sdl2_net

https://formulae.brew.sh/formula/libpng 

 

Crispy Doom is now running flawlessly on Apple Silicon:

549755505_ScreenShot2021-11-21at8_04_32PM.png.30b396cece70b20697d98c201a529f2e.png

 

I also noticed that you can't pin the Unix Executables in these builds to the macOS dock so I used 'Script Editor.app' to create .app files with the following AppleScript:

to run
	do shell script "~/Applications/Doom/crispy-doom"
end run

 

NOTE: Use a double-backslash if you have a space in your directory path. For example, a directory called "Doom II" would need to look like this: 

to run
	do shell script "~/Applications/Doom\\ II/crispy-doom"
end run

 

This is what it the .app files look like in macOS that you can then pin to your dock (custom icons can be used like in the following picture by pasting a square transparent background PNG over the icon in the Get Info window):

image.png.5c000bbeba9ebeaa29b8cdf1d419b99b.png

Edited by speedy206

Share this post


Link to post

No problem at all.  Yeah you cannot pin raw executables, I am doing .app bundles for crispy, just that it doesn't have a gui to choose your iwads.  And yeah, crispy was one of those that I got fixed pretty quickly :)

 

What you've done looks pretty awesome!  I've never used AppleScript so I may pinch that and credit you for those bundles that I'll do.

Edited by Gibbon

Share this post


Link to post
13 minutes ago, Gibbon said:

What you've done looks pretty awesome!  I've never used AppleScript so I may pinch that and credit you for those bundles that I'll do.

Thanks!

 

With that said, I don't think the AppleScript method would work for bundling the .app file for other people since I couldn't get it use relative directories, but that could be my own ignorance. I just used AppleScript because it's what I'm familiar with though. You may want to look at using Platypus if you want to try something that might work for bundling with downloads.

 

I think someone else said they'd be willing to sponsor an Apple Developer account so you could build legit signed .app files for these with Xcode. I'd also be willing to go in on sponsoring that if you put together a Patreon or some sort of donation link. 

Share this post


Link to post

So I just tried it, hot damn I had no idea it was possible!  I've always manually created the bundles by hand or with xcode.  I'll get crispy clean-room compiled on the M1 and I'll make some Mac-Specific icons for the bundle too.  I'll give you credit.

 

But yeah, I'll do manual bundles and compare them.

 

I can codesign, that is fine, but Apple expect you to codesign as the project leader not as a contributor.  So the leads of these projects would need the certificate and I would use it to codesign.  Not sure if that is priority at all for the developers of Crispy/Woof etc..

 

Edit: I read the Apple Developer Program docs and while it does state it should be from a project lead, it isn't mandatory.  I guess it would depend on if Fabien and Brad (after fixing some Mac only issues) would be happy with me codesigning their software or not.

Edited by Gibbon

Share this post


Link to post

So Crispy Doom / Heretic / Hexen / Strife are all clean-room compiled and (thanks to @speedy206 I have made .app bundles for each one) and manually customised it so each bundle is self-contained

 

1. You must put the iwad into the Contents/MacOS/ directory or use some DOOMWADDIR path instead.

2. You must run the bundles from ~/Applications

 

I also took the official Crispy Doom logo and edited it to that it looks nice on a Mac (we don't like ugly square icons).

 

One more added to the M1 masterrace library ;)

Edited by Gibbon

Share this post


Link to post

So I have no idea what @bradharding did but the latest git master of Doom Retro is probably the best Mac version yet.  I've uploaded a nice .app bundle with one of the official iconsets he provides and it correctly saves everything inside the bundle (screenshots, savegames, configs).

 

I mean, damn.  Apart from GZDoom, no other source port even comes close (not even mine :D ) in terms of Mac'ness'.

 

So it is up there now and later tonight I'll throw up an Apple Silicon version too.

 

Edit: I have decided I'll go the whole way and do proper universal bundles of everything.  I capitulated and Xcode is installed, so from the next build, it'll hopefully be a lot less janky.

 

Linux builds are also coming of Nugget Doom.

Edited by Gibbon

Share this post


Link to post
12 hours ago, Gibbon said:

So I have no idea what @bradharding did but the latest git master of Doom Retro is probably the best Mac version yet.  I've uploaded a nice .app bundle with one of the official iconsets he provides and it correctly saves everything inside the bundle (screenshots, savegames, configs).

 

I mean, damn.  Apart from GZDoom, no other source port even comes close (not even mine :D ) in terms of Mac'ness'.

 

So it is up there now and later tonight I'll throw up an Apple Silicon version too.

 

Edit: I have decided I'll go the whole way and do proper universal bundles of everything.  I capitulated and Xcode is installed, so from the next build, it'll hopefully be a lot less janky.

 

Linux builds are also coming of Nugget Doom.

Not really sure I did anything to the code since the release of the last version that would help with this tbh. I'm glad it's working though! :)

Share this post


Link to post

Yeah I was confused looking at your commits and not seeing anything suspicious :)

 

So, it is due to not being run in the Applications folder.  Once you put it there, it behaves.  Guess you learn something new..

 

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

 

I'll get on with the others.

Edited by Gibbon

Share this post


Link to post

So today:

 

Nugget Doom 1.6 - Universal .app bundle and Linux.

Woof 8.0.0 - Universal .app bundle and Linux.

EDGE-Classic Preview (git master) - Mac Intel .app bundle (M1 support isn't possible at all).

Eternity Engine 4.02 - Linux.

EDGE (3dfx git master) - Linux.

Russian Doom 5.0.0 - Linux (I do have a universal .app bundles but I'm working on it as the paths for saving configs etc..  is a disaster on a Mac).

 

May not seem like a lot but half of my time was spent on rebuilding every-single-dependency into universal .dylibs, frameworks and getting my new toolchain setup.

 

Phew!

 

Edited by Gibbon

Share this post


Link to post
12 hours ago, Gibbon said:

Yeah I was confused looking at your commits and not seeing anything suspicious :)

 

So, it is due to not being run in the Applications folder.  Once you put it there, it behaves.  Guess you learn something new..

 

It might also be a good idea to put that information on your downloads page, so that Mac users know about it.

Share this post


Link to post

I just realized you can create self-contained apps with your WAD files included by placing everything in the Resources folder of the .app generated by Script Editor.app:

image.png.7538f0e99adeb5a32d979e58c18c3417.png

 

For example, here's how I setup a subfolder in the Resources folder for Doom.app:

112438280_ScreenShot2021-11-23at11_40_21PM.png.2be02f53561b954722b286f8828a7e48.png

 

Then the Apple Script just needs to be created as something like this which allows the .app file to run anywhere on the system (I still prefer ~/Applications):

to run
	set doom to path to resource "crispy-doom/crispy-doom"
	do shell script quoted form of (POSIX path of doom)
end run

My question at this point is how to use separate Music Packs for Crispy Doom? I'm running into issues with this because the executable wants to place the config file in ~/Application Support/crispy-doom/crispy-doom.cfg for all copies of Crispy Doom on the system. This is problematic because if you want to run Doom II, Plutonia, and TNT on the same system then their Music Packs would conflict as they'd all need to be placed in ~/Application Support/crispy-doom/music-packs/ and would have name conflicts. 

 

Would it be possible to fix this by having Crispy Doom somehow read/write its cfg files with prefixes of the WAD files. For example, doom2-crispy-doom.cfg, plutonia-crispy-doom.cfg, and tnt-crispy-doom.cfg, etc? 

Edited by speedy206

Share this post


Link to post

Maybe @fabian could give us Mac users some love?

 

Edit: Yeah I see what you mean.  I guess a workaround would be to duplicate the 'crispy-doom' into each .app bundle (one for Doom, one for Doom2, one for Plutonia and one for TNT).  That way, they won't conflict as each 'crispy-doom' binary would be self-contained into its own .app bundle.

Edited by Gibbon

Share this post


Link to post
8 hours ago, Gibbon said:

I guess a workaround would be to duplicate the 'crispy-doom' into each .app bundle (one for Doom, one for Doom2, one for Plutonia and one for TNT).  That way, they won't conflict as each 'crispy-doom' binary would be self-contained into its own .app bundle.

That’s actually what I already did; you can see in my screenshot above 😁 

 

The problem is that Crispy Doom still uses the same CFG file location even when you do this. 

Share this post


Link to post
1 hour ago, speedy206 said:

That’s actually what I already did; you can see in my screenshot above 😁 

 

The problem is that Crispy Doom still uses the same CFG file location even when you do this. 

Ahh, I get it..  well that sucks.  Guess you could raise a github issue on the repo for crispy?

Share this post


Link to post
Guest
This topic is now closed to further replies.
×
×
  • Create New...