A Collection of Doom Source Ports - Compiled and Packaged

[wesleyjohnson]

For the most part, DoomLegacy accesses existing libraries.  If a library is required then it is expected that the user will install the required library.

What you are referring to is for DoomLegacy to compile and supply the library.

Does not Windows have a "standard" library or installation that can be used for unzipping ?

Most people seem to have 7zip, does that not have some zip libraries ?

[Edward850]

That... what? You just compile them as static libraries in the program, that's how zlib and libzip are explicitly designed. You are so far over thinking it that it's not even funny. The operating system has absolutely no business providing them at all, they aren't ABI compatible libraries.

Edited February 8, 2022 by Edward850

[Graf Zahl]

Of course you can use zlib as a .DLL under Windows but you'd have to package the .DLL yourself. Normally it's just easier to add the source files and compile them along with the main project. That's how ZDoom has been doing it for 20 years and it never was an issue.

 

Of course 7zip has some code to handle decompression but it's internal to the application so you cannot access it. Windows does not work like Linux here tp provide globally visible libraries for such things.

 

[Redneckerz]

2 hours ago, wesleyjohnson said:

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.

Just chipping in here that @Gibbon took a stab at compiling the latest Legacy2 and couldn't get it to work, at all. He did mention in a post here to craft a build using MSYS, but its just full of issues. Which is kind of impressive.

 

Then again Gibbon is on bleeding edge libs, whereas (if i recall, am at work now) Legacy2 requires SDL 1.x. Gib mentioned that Fabian has those on his compile system but yeah.

 

So in absence of that, i tried some testing with the very old December 12, 2007 build by Exl and while it does start up, attempting to go into E1M1 results in a crash to desktop. Ill attribute this to Windows 10 and Legacy2 obviously not accounting for it, but still, safe to say that even the latest Legacy2 update from 2017 makes it very, very difficult to build in either case.

 

Which honestly, sucks a bit. For posterity i wanted to take high res shots of the normal mapping and lighting features (for the Wiki), but the only way that might work is setting up an old Windows 7 VM (Because i know Legacy2 atleast went in-game on that.)

 

Its a shame because those features are still pretty awesome to see even today. Then again, you will hear me say the same about ZDoomGL... Awesome looks do not equate usefulness - Which is where other high end ports like K8Vavoom and GZDoom are so much better in. Its not just good looks - Its actually useful.

[Edward850]

19 minutes ago, Redneckerz said:

attempting to go into E1M1 results in a crash to desktop. Ill attribute this to Windows 10 and Legacy2 obviously not accounting for it,

No that doesn't scan at all. If the game launches, Windows 10 compatibility is already not the problem. If it's crashing there in 10, it will also in 7 and likely even before. Simplest answer is usually the right one and such.

 

That is unless legacy2 is using some really fucky OS behavior standards, but given 7 and 10 have identical permissions and file system behaviors under Win32, that would be unheard of. As in stuff I haven't heard of developers doing since Windows 95 by mixing 2 different window management APIs.

Edited February 8, 2022 by Edward850

[Gibbon]

4 hours ago, wesleyjohnson said:

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

 

FreeBSD (like GNU/Linux) has ZLIB in its package manager (though it is installed alongside GCC and Make etc as developer tools).  Doom Legacy on FreeBSD uses the exact same libs as you would on Linux.  They are statically compiled into the executable.

 

Windows (like others have said) is also statically compiled into the executable, or you can provide zlib1.dll if you use zlib.lib instead of zlib_static.lib.

 

And yes, Legacy 2 is beyond anything I've ever seen.  A complete mess, built on top of more mess.  On Ubuntu 21.10 GCC as well as compiled libs of some of the crazy libraries that are used (tomscrypt?  Torque Net Library?) as well as its SDL dependencies.  It doesn't even compile the first file before hitting over 50 errors about basic things like C++ class declarations.  My guess is that it needs a pretty old GCC to work..  older than I am willing to use.

 

Whoever did it, well..  they clearly got bored of trying to fix it :P

Edited February 8, 2022 by Gibbon

[Redneckerz]

4 hours ago, Edward850 said:

No that doesn't scan at all. If the game launches, Windows 10 compatibility is already not the problem. If it's crashing there in 10, it will also in 7 and likely even before. Simplest answer is usually the right one and such.

Far as i remember Windows 7 atleast got it to playing. But i can't verify that anymore.

4 hours ago, Edward850 said:

That is unless legacy2 is using some really fucky OS behavior standards, but given 7 and 10 have identical permissions and file system behaviors under Win32, that would be unheard of. As in stuff I haven't heard of developers doing since Windows 95 by mixing 2 different window management APIs.

I mean.... the common consensus with current day Legacy is that in the case of Legacy 1, it targets whatever Wes's compiler targets. In case of Legacy 2, it is enough to put a systems maintainer into the doghouse (Hence that's where Pooch got made ;))

 

Its pity considering Legacy's err... Legacy.

[LexiMax]

9 hours ago, wesleyjohnson said:

What you are referring to is for DoomLegacy to compile and supply the library. 

 

If you are releasing software in 2022, you must know how to compile and ship your own libraries with your software.  If you don't know how, you need to learn how.  Relying solely on distro libraries is not something that works outside of the Linux bubble, and arguably only barely works inside it.

 

I think it's long past time you sat down and learned CMake.  15 years ago I learned CMake without knowing hardly any C++.  If I can do it, you can do it.

 

- CMake crash course blog post

- CMake build files authored by me for Woof! - this downloads SDL automatically on Windows, something similar could be done for ZLIB if you didn't want to compile it separately.

- Official CMake Reference - not organized very well, but if you look around it's shocking what cool things you can find inside

Edited February 8, 2022 by AlexMax

[Graf Zahl]

CMake alone won't be enough here. The code is also so full of ancient GCCism's that it needs a thorough cleanup to become compiler and platform independent.

Also, SDL 1.x is old enough to be a serious problem all by itself.

 

1 hour ago, AlexMax said:

- CMake build files authored by me for Woof! - this downloads SDL automatically on Windows, something similar could be done for ZLIB if you didn't want to compile it separately.

 

That's one way to handle it. What I'd really like to see is a way to automatically detect vcpkg and compile the needed dependencies in there without user intervention. If that was possible it'd solve most of the dependency problems on Windows.

[LexiMax]

21 minutes ago, Graf Zahl said:

CMake alone won't be enough here. The code is also so full of ancient GCCism's that it needs a thorough cleanup to become compiler and platform independent.

 

One step at a time. :)  Besides, the best way to attract outside contributors is to use a sane build system that automates as much preparation as possible.

 

21 minutes ago, Graf Zahl said:

That's one way to handle it. What I'd really like to see is a way to automatically detect vcpkg and compile the needed dependencies in there without user intervention. If that was possible it'd solve most of the dependency problems on Windows. 

 

I actually investigated vcpkg a while ago, and back then you couldn't really version your dependencies.  I think you can now, but we couldn't use it for Odamex since its version of wxWidgets (god help us) was not built correctly for our needs.

 

But that's just me.  Either way, there's loads of solutions out there for getting dependencies.  Bringing the library in-tree and compiling as you go, using something like conan or vcpkg, downloading ZIP files of development libraries, there are many options.

Edited February 8, 2022 by AlexMax

[Graf Zahl]

 

 

28 minutes ago, AlexMax said:

 

One step at a time. :)  Besides, the best way to attract outside contributors is to use a sane build system that automates as much preparation as possible.

 

Agreed. But the best build system does not help if the code depends on ancient compilers. You got to fix that first.

 

 

28 minutes ago, AlexMax said:

But that's just me.  Either way, there's loads of solutions out there for getting dependencies.  Bringing the library in-tree and compiling as you go, using something like conan or vcpkg, downloading ZIP files of development libraries, there are many options.

I know, but it can become quite a hassle if you need a large number of dependencies to get something compiled.

As an example, I had been investigating libzip to add better zip file support to GZDoom (like 64 bit support and other compression algorithms), but it comes with a string of dependencies itself that we'd have to ship in GZDoom, too. So, since I find that unappealing the only alternative would be to compile it as a DLL and only include the header and import library.

If it was easier to integrate with vcpkg it'd be a no-brainer.

 

[Edward850]

5 hours ago, Redneckerz said:

I mean.... the common consensus with current day Legacy is that in the case of Legacy 1, it targets whatever Wes's compiler targets. In case of Legacy 2, it is enough to put a systems maintainer into the doghouse (Hence that's where Pooch got made ;))

 

Its pity considering Legacy's err... Legacy.

Compiler doesn't mean shit, Win32 is Win32. However instead of making these weird claims of yours, seeing as you can compile it, it would make more sense to fire up some debugging tools and figure out the crash.

Edited February 8, 2022 by Edward850

[wesleyjohnson]

DoomLegacy dynamically links all libraries.  There are 38 library dependencies, some of which are (SDL, GL, GLU, pthread, dl), most of the others are indirect dependencies.

The libraries  zlib and libzip, are detected and loaded using dlopen, so those do not even appear in the output of ldd.

If the user does not have zlib or libzip, the program will continue without them, but will lose a feature, or ability.

 

I really get tired of all the false statements about legacy code.  You have not even noticed that it already has cmake.  It is only for SDL, and I cannot make it any more capable.  The whole has already gotten too complicated for cmake to cope with.  I would have to write some complicated interface to it just to accomplish what the Makefile is already doing.

 

[wesleyjohnson]

Legacy2 was rewritten to use C++ features.  They totally reorganized it, which is why I cannot find anything.   Other C++ versions of Doom have done the same thing. I have seen Eternity code and what they did to Mobj and Thinkers, making them classes.   I don't think the directory structuring helps.

Legacy2 is known to be missing the netcode.  I don't exactly what that means, but Legacy1 netcode was heavily rewritten so the version that Legacy2 has is probably a patched-up original netcode.

I have never encountered an existing program that did not look like a total mess.  Programs simply do not compose into neat boxes the way they try to teach.

However, it probably would take 6 months before it started to make sense.

The programmer is still a DoomLegacy administrator.  He probably got a family and thus other issues on his mind now, like another life.

 

[Jon]

IMHO, Legacy2 was an experiment which failed. To the extent that Legacy will live on at all, it'll be Legacy1, which is also conveniently its history.

[Gibbon]

Sorry for the slight delay.

 

Crispy Doom 5.11.1 has now been uploaded as a macOS Universal binary.

 

This still contains my Sprinkled Launcher to execute the individual programs inside the bundle.  Next release I will just point to the crispy-setup as the main executable.

[Gibbon]

An SVN build of Doom Legacy for Windows 64bit (using SDL):

https://github.com/atsb/source-port-builds/releases/download/1.0/doomlegacy-svn-r1620-win32-sdl-compat.zip

 

I built this with a custom SDL1.2 -> SDL2 compat library (that uses an SDL1.2 to SDL2 compat layer).

 

I have included a config file with sane defaults (use OpenGL on Windows).  But the framerate is better, the fullscreen stability on Windows 10/11 is better.

 

Update: Since OpenGL on Windows 10/11 is the only non-broken video mode.  I have hardcoded GL_NEAREST so you don't have to look through the smudge of vaseline to play.  Though, it was already broken as it was hardcoded to be GL_LINEAR no matter what (unless you selected Nearest again every time you load it up).  It at least gets it into a nice state for modern Windows.

Edited February 23, 2022 by Gibbon

[Gibbon]

Woof 9.0.0 and NuggetDoom 1.8.0 are now uploaded as macOS universal bundles.

 

Note, neither contain fluidsynth (because I don't have a universal binary of that yet).  I'll prepare one for the next round of their respective releases.

Edited March 6, 2022 by Gibbon

[Gibbon]

So a new one to the list.  A natively compiled Windows 64bit package of the excellent k8vavoom!  Ketmars' warnings and errors were no match for my monkey business.

 

https://github.com/atsb/source-port-builds/releases/download/1.0/k8vavoom-git-master_win64.zip

 

Compiled on MinGW 64bit using Windows 11.

Edited March 11, 2022 by Gibbon

[jval]

1 minute ago, Gibbon said:

 

Sure.  I compiled it as Release with Debug Info, so if there were any issues, they could be fixed, since I don't think there are any other 64bit versions for windows like this.  But I can do a Release build without debug info if space for you is an issue.

 

I'll plop it on my source port build thread so I don't pollute Ketmar's one with too much of my babbling :)

 

OK, this is not a problem, as long as this is a built with full optimizations enabled.

[Gibbon]

1 minute ago, jval said:

 

OK, this is not a problem, as long as this is a built with full optimizations enabled.

 

https://github.com/atsb/source-port-builds/releases/download/1.0/k8vavoom_gitmaster_win64_release.zip

 

Done :)

 

All optimisations applied and Release type set.  Binary is now 12MB.

[NightFright]

Any chance of updated Crispy Doom x64 builds for Windows (right now, I can only see one for macOS)?

Edited March 11, 2022 by NightFright

[Gibbon]

43 minutes ago, NightFright said:

Any chance of updated Crispy Doom x64 builds for Windows (right now, I can only see one for macOS)?

 

https://github.com/atsb/source-port-builds/releases/download/1.0/crispy-doom-all-git-master_win64.zip

 

Also a 32bit build

https://github.com/atsb/source-port-builds/releases/download/1.0/crispy-doom-all-git-master_win32.zip

Edited March 11, 2022 by Gibbon

[NightFright]

Excellent!

[ketmar]

5 hours ago, Gibbon said:

All optimisations applied and Release type set.  Binary is now 12MB.

just hope you didn't patched it to -O3, it will cause a lot of UBs. ;-)

[Gibbon]

22 minutes ago, ketmar said:

just hope you didn't patched it to -O3, it will cause a lot of UBs. ;-)

I never do that, too much optimisation usually causes a lot of issues.  Release on cmake uses -O2 so it should be all good.

[ketmar]

yeah, thank you. i didn't really thought that you did that, but it doesn't hurt to warn, i believe. just in case. ;-)

[Gibbon]

47 minutes ago, ketmar said:

yeah, thank you. i didn't really thought that you did that, but it doesn't hurt to warn, i believe. just in case. ;-)

I always prefer to optimise just enough.  For me, the code I write I prefer not to be scrambled by an overzealous optimisation flag.

[Steinkrauz]

On 3/11/2022 at 5:02 PM, Gibbon said:

All optimisations applied and Release type set.  Binary is now 12MB.

 

Fun fact: on Windows 10 freshly build k8vavoom.exe is 10.9MB

[Gibbon]

9 minutes ago, Steinkrauz said:

 

Fun fact: on Windows 10 freshly build k8vavoom.exe is 10.9MB

 

I never would have thought in 2022 people still complain about binary size :P