A Collection of Doom Source Ports - Compiled and Packaged

[Gibbon]

So since some source ports do not provide any binaries on other OSs than Windows, I thought it may be good to share builds on other platforms (since I own a multitude of computers each with different OSs).

 

Here:

https://github.com/atsb/source-port-builds/releases/tag/1.0

 

Edit: since there are now over 30 uploads, please follow the link to see what is built :)

 

For k8vavoom and its unportable cmake file, I'll have to fork and port it to MacOS and general Clang compilers (for FreeBSD).

 

I'll update these with Linux builds and FreeBSD builds too at a later date (I have only 2 arms and too many computers).  But I thought it would be nice to at least provide them, for those who cannot compile themselves (I know not all Linux users are developers).

 

Edited October 3, 2021 by Gibbon
Made more descriptive

[dmdr]

ooh nice. I'm not a Mac user but I know they've had restricted port choices for a while now so I'm sure this will help a lot of people.

 

Sort of tangential, but for linux users an easier way to make packages would be very helpful -- as far as I know only Eternity supports CPack, so perhaps some patches/pull requests to enable that on other ports would be more generally helpful than providing binaries? Compilation on loonix being p easy (usually), I can do it and I'm definitely not a developer

[Gibbon]

On 9/4/2021 at 2:50 AM, dmdr said:

ooh nice. I'm not a Mac user but I know they've had restricted port choices for a while now so I'm sure this will help a lot of people.

 

Sort of tangential, but for linux users an easier way to make packages would be very helpful -- as far as I know only Eternity supports CPack, so perhaps some patches/pull requests to enable that on other ports would be more generally helpful than providing binaries? Compilation on loonix being p easy (usually), I can do it and I'm definitely not a developer

Thing is, for developers, a build process can be a pretty personal thing.  Forcing a specific way on all cmake projects isn't right.  Plus, for mac users, having to open a DMG just to copy an app into applications is really getting old.

[Gibbon]

Since I was using it today, I did a few builds on FreeBSD (64bit of course).

These are:

* Woof

* Sprinkled Doom

* RanDOOM

* Crispy Doom

* Zip-Doom

 

Note: Woof and Crispy were compiled from the latest master not the latest release.

Edited September 11, 2021 by Gibbon

[Redneckerz]

Some additions to the above:

 

RanDOOM:

Thiis is a Choco Doom fork that has random respawning of monsters which are also randomly generated. Sounds bizarre, but it does yield an interesting idea: Every playthrough may see the first level with the Zombiemen changed to Imp's. Or Lost Souls. Or if you are unlucky, Cyberdemons. Definitely a novel idea.

 

Zip Doom:

This is Chocolate Doom 3.0 backported to SDL-1 instead of SDL-2, supposely to support older systems. It also adds module music support, so .mod, .s3m. Definitely something even more retro than stock Choco.

[Gibbon]

dsda-doom now has Mac Intel and Mac M1 builds uploaded due to the dsda team being awesome and finding the issue that prevented it from building.

 

Note: it is built from master so it isn't a release and hence, may not be indicative of the quality from a proper release.

[imustafin]

How do you build them? If you want, you can take a look at github actions to generate github releases and binaries automatically.

[Gibbon]

24 minutes ago, imustafin said:

How do you build them? If you want, you can take a look at github actions to generate github releases and binaries automatically.

I don't need CI for these, plus some of them needed manual fixing to compile.

 

I use my own machines for every binary I make.  That's the way I like to do it.  Plus, CI do not have every OS or architecture type.  It is good for those who only have one OS and just want to make a build but for a functional native binary that works on all platforms, you really need your own machines.

 

I have 5 OS across 6 computers.  That's how I roll.

[Gibbon]

So now we have a few more to the list.

 

I saw a post about Crispy Hexen that was wanted, so I just built them all (no idea why they aren't all included anyway):

 

https://github.com/atsb/source-port-builds/releases/download/1.0/crispy-doom-5.10.3_all_win64.zip

We have sDoomPort too. ZMemory and Clown Doom (Linux only).  See the original post for the link to the other assets.

Edited October 1, 2021 by Gibbon

[Master O]

@Gibbon You should get a mod to sticky this thread, since it will prove useful for people wanting binaries for non-Windows platforms.

[Gibbon]

Any Mod is welcome to, I just don't know who to ask

[Redneckerz]

3 hours ago, Gibbon said:

So now we have a few more to the list.

 

I saw a post about Crispy Hexen that was wanted, so I just built them all (no idea why they aren't all included anyway):

 

https://github.com/atsb/source-port-builds/releases/download/1.0/crispy-doom-5.10.3_all_win64.zip

We have sDoomPort too. ZMemory and Clown Doom (Linux only).  See the original post for the link to the other assets.

I do recall a user who did Crispy Hexen releases, but nevertheless, what the hell.

 

The Doom 0.5RE atleast runs, so many of these would warrant a new thread and then i am not even talking about ZDoom64.

It is great to work next to you and with you, Gibbon. I apologize for sounding giddy but its not often to have someone arrive at this community that so abruptly and so broadly breathes the community spirit like you do. Its people like you why i love coming back to this fine place for.

 

2 hours ago, Gibbon said:

Any Mod is welcome to, I just don't know who to ask

I have a faint recollection that every mod has its own sub-forum, but since summoning a mod costs one Nice Guy post from yours truly on a WAD they released, ill summon @Doomkid and @Major Arlene for these. Both of these users are fairly active here.

For reference, here is the Staff Directory - Perhaps you could wager a PM on it. Given your bizarre list of useful contribution, i am sure they would honor a request like this.

[Doomkid]

Could you please make the thread title more descriptive? If you do, I'll go right on ahead and pin it.

[Gibbon]

1 hour ago, Doomkid said:

Could you please make the thread title more descriptive? If you do, I'll go right on ahead and pin it.

Done.  I made it more descriptive but without being too wordy.

[bradharding]

Thank you for adding Mac binaries for Doom Retro, @Gibbon! I greatly appreciate it!

[Biodegradable]

You've been a real blessing to the port development side of the community since you arrived, Gibb. Good stuff!

[ketmar]

On 9/3/2021 at 11:44 PM, Gibbon said:

For k8vavoom and its unportable cmake file, I'll have to fork and port it to MacOS and general Clang compilers (for FreeBSD).

please, tell me if you'll succeed, so i could strenghten my protection measures. ;-)

 

joking aside, it is done this way because the code expects gcc, it was written assuming gcc codegen at times, it violates all "standards" (that's why there is a page-long gcc unfucking in cmake), and does alot of unaligned memory access via arbitrary casted pointers and such (completely breaking "aliasing analysis" by the way). most of that was added by me, and i don't have plans to "fix" it.

 

of course, i'm not against ports, or clang (insulting clang in cmake is just how my sense of humor works ;-), i tried to block that so people won't get something totally broken. and as i won't accept patches to fix that (for various reasons, but mostly because i cannot maintain them) — i'm not sure if there is any sense investing your time into such builds. i mean, there is only 24 hours in a day, and you have to sleep sometimes. ;-)

[Gibbon]

1 hour ago, ketmar said:

please, tell me if you'll succeed, so i could strenghten my protection measures. ;-)

 

joking aside, it is done this way because the code expects gcc, it was written assuming gcc codegen at times, it violates all "standards" (that's why there is a page-long gcc unfucking in cmake), and does alot of unaligned memory access via arbitrary casted pointers and such (completely breaking "aliasing analysis" by the way). most of that was added by me, and i don't have plans to "fix" it.

 

of course, i'm not against ports, or clang (insulting clang in cmake is just how my sense of humor works ;-), i tried to block that so people won't get something totally broken. and as i won't accept patches to fix that (for various reasons, but mostly because i cannot maintain them) — i'm not sure if there is any sense investing your time into such builds. i mean, there is only 24 hours in a day, and you have to sleep sometimes. ;-)

I noticed, the first time it hit those GCC specific things in the code I just went "ahh crap".  I carried on fixing it and probably I would say I am half way through but I'm not actively doing it.  Clang has almost no alternatives for some of these and I know it'll just end up as segfaults anyway.

Edited October 4, 2021 by Gibbon

[ketmar]

i think most code can be cleaned up of "gccisms", they aren't really vital. but i'm so used to gcc extensions, that i will inevitably reintroduce that back without even noticing it.

 

but tbh, the thing i feared most is non-standards-compliant code. i used to write code in the style "oh, forget about standards, and just do what any sane compiler writer would do in this case" ("alias analysis" and UB on signed integer overflows are most common examples, but there's much more; and no UBs on signed integers is vital for VavoomC VM to work right). now, while i'm almost sure that clang has "-fwrapv", for example, i don't know if it has all necessary flags to switch from "standards-compliant" to "sane compiler" mode. also, i sometimes know what gcc will do in some uncertain cases, and i'm exploiting that knowledge, but for clang, it's Terra Incognita for me.

 

besides that, macs have broken OpenGL and broken OpenAL. not broken enough to prevent my code from working, but enough to introduce some hard-to-catch bugs. that's why i think that mac k8vavoom builds aren't worth your efforts.  don't get me wrong, please, i'm not trying to tell you that "YOU ARE FORBIDDEN FROM DOING IT!", no. ;-) just wanted to explain a little the size of the gross mess you could accidentally step into. ;-)

[Graf Zahl]

5 hours ago, ketmar said:

i think most code can be cleaned up of "gccisms", they aren't really vital. but i'm so used to gcc extensions, that i will inevitably reintroduce that back without even noticing it.

 

 

 

 

Best thing to avoid this is to set up CI builds for the platforms you won't test yourself. Then you get immediate feedback when something went wrong and can rest assured it will compile on all supported platforms.

 

We do not really need another port like Doom Legacy which went GCC only a long time ago and dug itself into that hole ever deeper over time so now it is virtually impossible to compile with anything else.

 

5 hours ago, ketmar said:

but tbh, the thing i feared most is non-standards-compliant code. i used to write code in the style "oh, forget about standards, and just do what any sane compiler writer would do in this case" ("alias analysis" and UB on signed integer overflows are most common examples, but there's much more; and no UBs on signed integers is vital for VavoomC VM to work right). now, while i'm almost sure that clang has "-fwrapv", for example, i don't know if it has all necessary flags to switch from "standards-compliant" to "sane compiler" mode. also, i sometimes know what gcc will do in some uncertain cases, and i'm exploiting that knowledge, but for clang, it's Terra Incognita for me.

 

This is something that had me scratch my head repeatedly. For any normal person "sane compiler mode" should be the default choice - and signed int overflows in particular are so frequently exploited in x86/ARM code that going a different route seems very foolhardy, but seemingly those compiler developers often live in their own world where minuscule performance gains are more important than robust code.

 

5 hours ago, ketmar said:

besides that, macs have broken OpenGL and broken OpenAL. not broken enough to prevent my code from working, but enough to introduce some hard-to-catch bugs. that's why i think that mac k8vavoom builds aren't worth your efforts.  don't get me wrong, please, i'm not trying to tell you that "YOU ARE FORBIDDEN FROM DOING IT!", no. ;-) just wanted to explain a little the size of the gross mess you could accidentally step into. ;-)

 

For OpenAL you should use OAL Soft on macOS - that one works as one would expect. Their system OAL is an utterly worthless piece of trash.

[Gibbon]

It is definitely different, personally I go by strict standards compliance and that "all extensions by default are non-standard".  Though portability for me is of the utmost importance and my code should run on anything from a MIPS Malta board to a Sparc64 (through Linux, SunOS, BSD and Windows). Though if someone cares more for performance than portability, thats their prerogative.

 

It definitely makes for interesting discussions.  I'm not a compiler person so most of this is lost to me.

Edited October 4, 2021 by Gibbon

[ketmar]

3 hours ago, Graf Zahl said:

Best thing to avoid this is

but… i have no intention to avoid this! ;-) the only officially supported platform is 32-bit GNU/Linux (x86), with GCC6-GCC8, and this is what i'm testing. anything else is "may work for you, but no guarantees" territory. even windows builds are… semi-official (one cannot build k8vavoom windows binary on windows, i believe ;-). cmake script specifically checks for GCC, and warns the user:

  message(WARNING "Only GNU C/C++ compilers are supported to build k8vavoom and tools!")
  message(WARNING "Your compiler is not GNU, please, don't report bugs.")

 

3 hours ago, Graf Zahl said:

We do not really need another port like Doom Legacy which went GCC only a long time ago and dug itself into that hole ever deeper over time so now it is virtually impossible to compile with anything else.

that's where people are free to fork k8vavoom and fix it for their environment. i only have what i have, and i can only properly test against my own system. CI doesn't help in gameplay tests, and no devs with other systems stepped in to support them. so instead of making promises i cannot hold, i prefer to explicitly state that only this specific configuration is officially supported. that's also why i won't accept patches for this — because i cannot maintain them myself.

 

3 hours ago, Graf Zahl said:

and signed int overflows in particular are so frequently exploited in x86/ARM code that going a different route seems very foolhardy, but seemingly those compiler developers often live in their own world where minuscule performance gains are more important than robust code.

it all started in standards committee, where someone decided that there are a lot of CPUs with non-2-complement integer arithmetics and different overflow behaviour that the standard cannot specify the exact integer representation and overflow semantics. i mean, sure, we have a lot of such CPUs in wide use to justify the trobles for the minority with 2-complement ints.

 

but you're right that "pointer aliasing" insanity was happily supported by compiler writers to win some benchmarks. it was tested several times (sadly, i didn't saved the links to tests), and those tests (on real apps) clearly show that speed gain is well under even 1%.

 

and of course, we cannot have any way to access CPU carry flag from C, because hey, it's not like every CPU made since CPUs were invented has such feature. i mean, who needs easy overflow checks with a built-in language construct, yeah?

 

 

2 hours ago, Gibbon said:

It is definitely different, personally I go by strict standards compliance and that "all extensions by default are non-standard".  Though portability for me is of the utmost importance and my code should run on anything from a MIPS Malta board to a Sparc64 (through Linux, SunOS, BSD and Windows). Though if someone cares more for performance than portability, thats their prerogative.

i basically only care if it runs on the configurations i can test. those are "officially supported". sadly, we don't have a "sourceport test suite" (and i can't even imagine how to create one without rewriting all the ports out there), so each new OS/arch needs a dedicated developer willing to invest a lot of time in porting, testing and maintaining that. i'm trying to write the code that doesn't rely on pointer sizes and such, and Vavoom I/O framework should be endian-agnostic too, but again, it's almost impossible to be sure that it works as expected without a good test suite. if i'll ever get other systems i need to run k8vavoom on, i'll make sure that it works. but until then… volunteer maintainers are welcome. ;-)

[Phytolizer]

Very shocked you included my Rust implementation considering it's nowhere close to functional. Thanks anyway.

[Gibbon]

23 minutes ago, Phytolizer said:

Very shocked you included my Rust implementation considering it's nowhere close to functional. Thanks anyway.

I noticed, it was only included to kind of have it, but definitely I am probably going to remove the ones that don't work since it is pointless having them there.

 

I do love Rust though, beautiful language, but not for games.

 

@ketmar I have a test suite.  I have 4 computers and 3 virtualised environments across all those configurations.  I compile, test and package for each one.  Anyone wants an Illumos version?  PPCle/be?  But those are for very specialised code.  I don't think any doomers are rocking a PPCle system on Linux :)

Edited October 4, 2021 by Gibbon

[Graf Zahl]

51 minutes ago, ketmar said:

and no devs with other systems stepped in to support them. so instead of making promises i cannot hold, i prefer to explicitly state that only this specific configuration is officially supported. that's also why i won't accept patches for this — because i cannot maintain them myself. 

  

 

Of course not, because you make them run away right before they may want to consider it. It's all fine and well that you prefer to test on your own system, but the ultimate question is what you want to achieve. I can outright tell you that most Windows or Mac developers will take a hike if they have to put up with a project management that shows no interest in wide compiler/platform support.

Your hosting choice is also something that doesn't attract potential contributors - if you want help you got to host where the people are, and that is Github and Gitlab, but I think we had this discussion before.

 

[ketmar]

13 minutes ago, Graf Zahl said:

but the ultimate question is what you want to achieve

ah, that's easy: i want to have a sourceport that is fun to hack for me, and the one i will enjoy using. and if possible maintainers are so easily scared away… it's actually a good thing, because they may step in instead, make some noise, and run away scared by some another "inconvenience". i want to see some dedication before putting my trust into someone. ;-)

 

47 minutes ago, Gibbon said:

I have a test suite.

sorry, but i'm afraid you don't, at least not for a project like k8vavoom. "it builds and runs" is not even remotely enough. it takes me days (when i'm lucky ;-) to test what becomes a public build with a set of known "problematic" wads (and some hand-crafted tests that should hit some corner cases in the engine), and with different configurations, and it is still not enough to guarantee that everything is working as expected even on the one platform i "oficially support". and this process is not automatic, there's alot of manual work involved. and it is almost impossible to do by someone who is not "intimate" with the engine code, because they wouldn't know if what they see is a normal thing for that new arch, or a bug, or something that isn't even supposed to work there. that's where a good automatic test suite could help, but alas…

 

also, Janis left us with exactly zero tests for VavoomC compiler and VM. i added some regression tests, but it's not enough, and you can't even run them without knowing how to properly build and run vccrun binary. and a subtle bug in VM could ruin everything, because k8vavoom C++ code is nothing more than a wrapper and support library for VavoomC VM, which actually runs the whole playsim code. btw, this is one of the main reasons why i don't have a JIT yet, and didn't rewrote VM to be register-based — i am simply afraid of doing that without proper tests.

[Graf Zahl]

9 minutes ago, ketmar said:

i want to see some dedication before putting my trust into someone. ;-)

 

That sentiment may go both ways. Any potential contributor may choose the project they choose to work with by how easy it is to work with its maintainer and trust them not to screw things up for their contribution. That by definition means that cross-platform awareness is part of the package in most cases.

 

 

Quote

sorry, but i'm afraid you don't, at least not for a project like k8vavoom. "it builds and runs" is not even remotely enough.

 

Well, tests are mostly snake oil anyway.

Especially with complex programs like a game engine the possibility of inputs is endless, so how to set up these tests? I don't think that much more than "run some demos, see if they desync" can be done - and that's only an option on conservative ports.

 

At my day job there's a high reliance on both automated unit and regression testing, but the outcome is always the same: All tests pass because all they test is existing code and features - anything new will first require new tests to be set up, and once they pass once it's rare they break again.

A lot of work is invested here - the result is rather meager, though.

 

 

 

 

Edited October 4, 2021 by Graf Zahl

[ketmar]

15 minutes ago, Graf Zahl said:

That sentiment may go both ways.

sure. but they at least can count number of commits i made to the project during the years, and see my dedication. and i cannot do the same for them, so i expect them to show their dedication in some other way.

 

17 minutes ago, Graf Zahl said:

Well, tests are mostly snake oil anyway.

i'm not a proponent of TDD myself, but good regression tests usually can rule out majority of trivial bugs. i.e. "all tests passed" doesn't mean that the project is bug-free (and tests themselves have bugs, of course), but it is still way better than nothing at all. because "it didn't crashed on MAP01" is definitely not enough. ;-)

 

20 minutes ago, Graf Zahl said:

Especially with complex programs like a game engine the possibility of inputs is endless, so how to set up these tests? I don't think that much more than "run some demos, see if they desync" can be done - and that's only an option on conservative ports.

yeah, i don't know too. the whole thing should be designed with automatic testing in mind from the very beginning, and i still can't imagine a good architecture for this… but i can at least dream a little! ;-)

 

21 minutes ago, Graf Zahl said:

All tests pass because all they test is existing code and features - anything new will first require new tests to be set up, and once they pass once it's rare they break again.

yet it may help with porting to the new arch — there is everything new there. ;-) so "all tests passed on the new arch" gives at least some guarantees.

[dpJudas]

37 minutes ago, ketmar said:

i'm not a proponent of TDD myself, but good regression tests usually can rule out majority of trivial bugs. i.e. "all tests passed" doesn't mean that the project is bug-free (and tests themselves have bugs, of course), but it is still way better than nothing at all. because "it didn't crashed on MAP01" is definitely not enough. ;-)

For the majority of code the best way to avoid bugs is write the code in such a way that it becomes as close to mathematically impossible that it can fail. A simple example of this is RAII and smart pointers. Use those and it becomes far far more difficult to fuck up your memory allocs and free statements (*). If I keep having bugs in some part of the code it is time to reconsider my entire strategy.

 

Unfortunately those kinds of things are difficult to teach and standardize. So everyone pretends like it are the test suites that keeps the bug count low. It rarely is. There are some cases where you just can't guarantee stability without a good unit test though. That's mostly due to having a bug in some types of code can be extremely difficult to track down without the test suite. A register allocator bug in the JIT for example is not something you want to track down in a real program if you can avoid it. :)

[LexiMax]

5 hours ago, ketmar said:

sorry, but i'm afraid you don't, at least not for a project like k8vavoom. "it builds and runs" is not even remotely enough

 

It may not be comprehensive, or even considered "enough" but build-time CI for all supported configurations should be considered as a bare minimum for any project to catch silly mistakes.  Its importance grows as the number of supported platforms grows, and eventually you can parlay it into a buildbot, which I can not emphasize enough how amazing that has been for Odamex.

Edited October 4, 2021 by AlexMax