gbDoom3 (Gibbon's Doom 3) source port

[Gibbon]

Why fork dhewm3

Well, I mostly use macOS and M1 and quickly discovered that dhewm3's macOS support is..  a little outdated.  One thing led to another and I did enough changes that really, for decent support, it would have to be my own.  So I decided to aim for a 'close to vanilla (2004 Doom 3) but still modern' goal.

 

So, a little description

gbDoom3 is a friendly fork of dhewm3 (great project) which intends to, as much as possible, function identically to Doom 3. Something like a 'Chocolate Doom 3'. This means I will start reverting any and all bug fixes, reverting all functionality that differed from Doom 3. I will however be keeping the QoL improvements from dhewm3 as a modern compromise.

I will also be heavily focusing on portability (especially on macOS) where I support Intel and M1 and reducing the amount of archaic standards that have been left in the code. What worked in 2004 doesn't really work now.

 

Changes (note, currently no bugs are reverted in 1.0.0)

1. All SSE/MMX/SSE2/3 etc.. SIMD instructions are removed
2. cpu.cpp code ported to Apple Silicon (some arm64 assembler is left for future enhancements in cpu identification)
3. Config file reading / writing has been reverted so it is identical to how vanilla Doom 3 functioned
4. Paths for files is renamed to 'Doom 3' so it can be used as a drag and drop replacement for Doom 3 itself
5. Code ported to modern macOS standards (cmakefile modernisation as well as Objective-C file modernisation (including IOKit) which is required now for SDK's 11.6 and higher
6. Apple PPC and 32bit code removed (some probably still remains somewhere)

 

So, release 1.0.0 is here

https://github.com/atsb/gbDoom3/releases

 

Binaries for Windows 64bit and macOS (Universal Intel and Apple Silicon).  I won't provide Linux binaries as I run a bleeding edge dev box and so my LIBC version probably won't work for anyone using 'old' LTS distro's or distro's which don't include the latest software.  However I can, if requested.

 

As far as I know, this is the only Doom 3 source port that supports the M1 Macs.

 

Why gbDoom3

It was the name of my first unreleased personal port back in 2012.

 

Enjoy!

~Gib

 

[Lippeth]

Looking forward to trying this out more and getting it to run on my mac (assuming it still runs on intel macs). I only spent a few minutes with it on windows, but everything seems to be in order, though I did have to rename zlib1.dll to zlib.dll for the program to get started.

 

Reverting the config file to be compatible with vanilla Doom 3 is actually really great, though saving it in My Documents like dhewm3 is still awkward to get to, I'm just glad it doesn't join the party in C:\Users\username\Saved Games\id Software because Doom 3 BFG 2019 also called Doom 3 which already causes issues.

 

If it's goal is to be more identical to vanilla Doom 3, I would recommend defaulting com_asyncSound to 2 for that classic weapon stutter.

 

I know virtually nothing about compiling programs, so forgive this next question: Is the removal of SIMD instructions what make this port's 64 bit"ness" to be possible on Windows? I've read a little about the subject and that's what I gathered was making it problematic to compile a 64 bit version, but I'm still curious. Either way, it sounds like a lot of hard work to clean up and modernize, and I commend your dedication!

 

Final question (sorry!) Does this port include all the changes and commits since the Mar 13 release? Edit: I assume with Github's compare feature that blue is edited, red is removed and green is added?

 

 

Edited December 23, 2021 by Lippeth

[Gibbon]

2 hours ago, Lippeth said:

Looking forward to trying this out more and getting it to run on my mac (assuming it still runs on intel macs). I only spent a few minutes with it on windows, but everything seems to be in order, though I did have to rename zlib1.dll to zlib.dll for the program to get started.

 

It definitely does, as a universal macOS binary it runs on Intel and Apple Silicon Macs.  I have both and it runs nicely, though the M1 Macs run it much better than my older Intel Mac does.

 

Hmm, I'll rename that.  ON my Windows dev machine it complained about zlib1.dll..  :) I'll rename it.

 

2 hours ago, Lippeth said:

Reverting the config file to be compatible with vanilla Doom 3 is actually really great, though saving it in My Documents like dhewm3 is still awkward to get to, I'm just glad it doesn't join the party in C:\Users\username\Saved Games\id Software because Doom 3 BFG 2019 also called Doom 3 which already causes issues.

 

It will save it in My Documents, however if it finds DoomConfig in your steam directory, it will use the DoomConfig there and won't put it anywhere else.  You could also put the binary next to Doom 3 in another directory as it will also look for 'base' in any directory it is in first.

 

2 hours ago, Lippeth said:

I know virtually nothing about compiling programs, so forgive this next question: Is the removal of SIMD instructions what make this port's 64 bit"ness" to be possible on Windows? I've read a little about the subject and that's what I gathered was making it problematic to compile a 64 bit version, but I'm still curious. Either way, it sounds like a lot of hard work to clean up and modernize, and I commend your dedication!

 

 

No.  dhewm3 made it 64bit compatible by largely using wider integers (uintptr_t rather than int).  The removal of SIMD was because, while Intel CPU's today still have support for it, the speed difference it once gave you is pretty much gone.  In fact, it can actually harm performance more than anything.

 

 

[Dusty_Rhodes]

Woah how'd I miss this? You're tackling Doom 3 ports now, awesome! 

Edited December 23, 2021 by Dusty_Rhodes

[Gibbon]

21 minutes ago, Dusty_Rhodes said:

Woah how'd I miss this? You're tackling Dokm 3 ports now, awesome! 

It is a nice switch-up after doing 2D things with classic Doom.  Nothing like 3D Math to wake you up :)

[Lippeth]

I just noticed that all the editing commands have been removed. One of dhewm3's biggest strengths is its stability when editing maps/particles/etc. Was this intentional or am I missing something?

[Gibbon]

13 minutes ago, Lippeth said:

I just noticed that all the editing commands have been removed. One of dhewm3's biggest strengths is its stability when editing maps/particles/etc. Was this intentional or am I missing something?

I mentioned that on the release page.

 

I use Visual Studio 2022 Preview, the MFC tools aren't yet there and so I cannot compile the editing tools at all.

[Lippeth]

Ah, I see it on the very last line, my bad! I wouldn't have ever known it was referring to the editing tools from the description, I even read through the page before posting the question.

Edited December 23, 2021 by Lippeth

[Gibbon]

The second MFC is there, it'll be compiled.

[Astronomical]

Developer of too many sourceports indeed.  Wouldn't have it any other way though.

[mjr4077au]

While a Chocolate Doom 3 port is interesting, I do hope you'll send a PR off to Dhewm3 for the updated macOS code. It's still an actively developed port and their macOS code is probably like GZDoom and Raze's, as good as the community who maintains it since only _mental_ has a production macOS device for GZDoom.

[Gibbon]

42 minutes ago, mjr4077au said:

While a Chocolate Doom 3 port is interesting, I do hope you'll send a PR off to Dhewm3 for the updated macOS code. It's still an actively developed port and their macOS code is probably like GZDoom and Raze's, as good as the community who maintains it since only _mental_ has a production macOS device for GZDoom.

I would but 2 things are stopping me.

 

1. DHEWM3 apparently still wants to target older 32bit macs as they have ungodly ancient MacOS SDK's in their cmake file.

2. My PR 'WILL' remove everything except modern 64bit macs and will add M1 support.

 

So that is why I did not.  Currently Dhewm3 does not and will not build on a Mac without my updates but it would help if someone from that team were active here.  I usually don't do PR's unless I know they will be merged as otherwise it's a waste of my time.

[Graf Zahl]

In that case you should ask Dhewm3's maintainer what they want. Is Mac support so bad because they want to keep it operational on this old hardware or just because nobody has maintained it.

With many projects the main problem is lack of interest by developers. See, you are basically the only man in town who seems to care with the ability to change things - so if you can help these projects to be up to date it'd help the community a lot more than creating yet another fork which most interested users are unlikely to ever notice.

 

I mean, look at the download numbers for this: https://tooomm.github.io/github-release-stats/?username=atsb&repository=gbDoom3

 

 

[Gibbon]

Sure, I guess I can throw Daniel a line on GitHub and see what he wants.  About the download numbers, yeah.  D3 is small enough already, though a few things about dhewm3 annoyed me enough that this is how I prefer to play it.

 

Lets see what he says and I'll do a super clean PR if he wants it plus a universal binary of the latest release.

[printz]

This seems to be really good news for me, as I was having too much trouble making dhewm3 work on my MacBook Pro with Retina display. They didn't even provide a build, I had to make one myself, and then I would either get a tiny display on the lower-left corner, or manage to make it fullscreen (by tweaking with code in ways I could understand) but at full pixel resolution (no matter how hard I tried), which makes gameplay too jerky when lots of stuff happen on screen. Did you get to test this on Retina display at fullscreen?

 

Edited December 26, 2021 by printz

[Gibbon]

The highest resolution Mac I have is a MacBook Air 13" M1 which has a Retina display at 2560x1600.  Fullscreen was fine as was various supported scaled windowed modes.

[printz]

37 minutes ago, Gibbon said:

The highest resolution Mac I have is a MacBook Air 13" M1 which has a Retina display at 2560x1600.  Fullscreen was fine as was various supported scaled windowed modes.

Can you render the entire screen, but pixelated to lower resolutions (such as half, e.g. 1280x800)?

[Gibbon]

No, but that isn't me.  It is MacOS and it's scaled resolutions.

 

For example fullscreen 800x600 pushes me to windowed 640x480 due to the resolution not being supported as scaled in MacOS.

Edited December 26, 2021 by Gibbon

[ReaperAA]

3 hours ago, Graf Zahl said:

With many projects the main problem is lack of interest by developers. See, you are basically the only man in town who seems to care with the ability to change things - so if you can help these projects to be up to date it'd help the community a lot more than creating yet another fork which most interested users are unlikely to ever notice.

 

I can't emphasize enough how much I agree with this.

[Gibbon]

15 minutes ago, ReaperAA said:

 

I can't emphasize enough how much I agree with this.

It doesn't always go that way though.  Forks are done with a purpose.  I highly doubt dhewm3 would revert their disastrous config file handling and remove all the decade-old SIMD crap that has been left there.  I forked it to clean it up and provide an 'original as possible' version, rather than 'everything plus the kitchen sink' approach.

 

I'm not really one who cares about usage, I largely use my own ports because I dislike something about the original.  Since I have the ability to pretty much do whatever I want, I actually only use my own ports for just about every game I play.

 

It would help the community more, if the dhewm3 team were on Doom World.  Hanging out on Github hoping for 'word of mouth' is just distancing yourself from your users.

[ReaperAA]

10 minutes ago, Gibbon said:

I'm not really one who cares about usage, I largely use my own ports because I dislike something about the original.  Since I have the ability to pretty much do whatever I want, I actually only use my own ports for just about every game I play.

 

Fair enough. My comment is meant to be more of a wishful thinking of different port authors working together to create a single great source port. Of course, no can really force the port authors what to do.

 

10 minutes ago, Gibbon said:

It would help the community more, if the dhewm3 team were on Doom World.  Hanging out on Github hoping for 'word of mouth' is just distancing yourself from your users.

 

No disagreement here at all. Really would help if the dhewm3 devs were able to communicate with you here on DW.

Edited December 26, 2021 by ReaperAA

[Graf Zahl]

Well, ok. After looking at Dhewm3 I found the commit telling me everything about what's important:

 

"Fix compatibility with Mac OSX 10.4 and 10.5 ", committed two months ago. In all honesty, when I see that I'd also take a hike and do my own thing.

 

 

[Gibbon]

33 minutes ago, Graf Zahl said:

Well, ok. After looking at Dhewm3 I found the commit telling me everything about what's important:

 

"Fix compatibility with Mac OSX 10.4 and 10.5 ", committed two months ago. In all honesty, when I see that I'd also take a hike and do my own thing.

 

 

;) that was what terrified me also.  These are computers that (if they cannot upgrade past that) are at least mid-2008 Macs (the second generation after the PPC migration).

 

In all honesty, I couldn't give two hoops to anyone using a Mac more than 6 years old.  I mean, my PR would basically remove the SIMD stuff since they hardcode this for all Macs (and we know ARM64 cannot execute i386/x86_64 assembler / SIMD instructions without the equivalent neon instructions).  I fixed it to compile without it, but really it isn't the same level of quality.

 

Supporting 10.4/10.5 is the equivalent of supporting Windows 2000.

Edited December 26, 2021 by Gibbon

[Dr. DiegO]

Hello there! I'm a Windows user, and i can't run the port. a error message appears and it says:

"The code execution cannot proceed because zlib.dll was not found. Reinstalling the program may fix this problem."

I don't know what's happening here. :( 

[Gibbon]

Interesting, it doesn't happen with me.  No worries, I'll repackage it with the missing dll.

[Dr. DiegO]

Just now, Gibbon said:

Interesting, it doesn't happen with me.  No worries, I'll repackage it with the missing dll.

 

Thanks, m8!

[Lippeth]

A short term solution is to remove the "1" from "zlib1.dll" so that it reads "zlib.dll", that does the trick for me.

[Dr. DiegO]

17 minutes ago, Lippeth said:

A short term solution is to remove the "1" from "zlib1.dll" so that it reads "zlib.dll", that does the trick for me.

 

Yeap! it works. thanks.

 

[Gibbon]

Yeah this is pretty hard to get right.  I have all my dev libraries in my path with no other windows machine to test it on, so I have to guess and rely on testers.  I'll make sure to link the next build statically so it won't require zlib dll's