The official "ZDoom on Mac OS X" thread.

[esselfortium]

@Johann: Doomsday Engine required (probably still does) you to "install" PWADs in order to use them with its launcher. It is/was a pain in the ass, and I wouldn't want to see any other ports require it. I also remember having to put PWADs in Mac Legacy's Resources folder inside its application package in order for it to care about them, which was about as bad, and not intuitive at all.

[sniperchance]

I guess it wouldn't be terribly bad if I added "[Same Directory as ZDoom.app]/WADs" to the search path, and kept the folder in Application Support as well.

I noticed out of most programs ported from Windows -> Mac OS X (emulators), some of them used their own relative folders, while others used their own folder within Application Support. It almost seems like a toss-up.

And you know, you can easily access that folder via the launcher. Click on Tools->Show Game Folder or press ⌘O.

[Johann Smidt]

@Johann: Doomsday Engine required (probably still does) you to "install" PWADs in order to use them with its launcher. It is/was a pain in the ass, and I wouldn't want to see any other ports require it. I also remember having to put PWADs in Mac Legacy's Resources folder inside its application package in order for it to care about them, which was about as bad, and not intuitive at all.

K well it was just a thought. I'd much rather be able to user define a directory for everything more than any other option, but lacking that I'm personally of the opinion that dumping wad files in the same folder as ZDoom.app is not the best solution.

[Grubber]

IMO you should follow the standards on any platform. Don't pervert it with Windows manners.

[Gez]

To reiterate: ZDoom, on Windows and on Linux, is able to look for the iwads in several directories, and there is no reason that ZDoom on MacOS shouldn't be able to look in several directories as well. Some people want to put the iwad in the same dir as ZDoom itself because that's how Doom ports everywhere works? No problem. Other want it to follow Mac traditions and look for iwads in user/library/application support? Not a problem either.

Why shouldn't it be able to do both so that everyone can place the wads where they think they should be?

[sniperchance]

Alright, for the next version, I'm merging in the OpenGL functionality from GZDoom (Patching my current code and praying it works), as well as a better method of IWAD selection. Instead of a dropdown box in the launcher, I'll enable users to pick their own IWAD via Finder. I'm keeping the Application Support folder to store any files created by ZDoom (save games, log files, screenshots, etc).

I haven't had much success with the PPC build yet, unfortunately. Xcode can't debug Power PC executables directly.

[sniperchance]

Great Success! (Almost)

I've compiled ZDoom OS X with GZDoom's OpenGL renderer. There's a few things to work out, most importantly what you see in the screenshot.

Linux users, take note: This is one step closer to GZDoom on Linux.

---

[Shadelight]

Awesome, this could be a GZDoom port for OS X as well . would stuff like UTNT work on it?

[Blzut3]

Linux users, take note: This is one step closer to GZDoom on Linux.

Umm... GZDoom works just fine on Linux just not under 64-bit. Apparently it doesn't agree with Compiz Fusion (at least with Emerald) very well though.

---

[sniperchance]

Oh. I never tried Skulltag in Linux, but the current SVN revision of GZDoom wasn't really Unix-friendly.

[Macil]

Linux users, take note: This is one step closer to GZDoom on Linux.

Umm... GZDoom works just fine on Linux just not under 64-bit. Apparently it doesn't agree with Compiz Fusion (at least with Emerald) very well though.

Gzdoom has worked fine for me under 64-bit in the past - recent revisions seem to be broken but more due to not being set up for unix/linux; the big 64-bit bugs were fixed in r132 iirc unless new ones have been thrown in.

Does this Mac version compile using the cmake system, or did you hack your own thing together? If you changed the cmakelists file at all, make sure to get the changes put in to the normal zdoom source.

[Csonicgo]

Linux users, take note: This is one step closer to GZDoom on Linux.

Umm... GZDoom works just fine on Linux just not under 64-bit. Apparently it doesn't agree with Compiz Fusion (at least with Emerald) very well though.

It also doesn't agree with any color depth besides 32. 16 bit color isn't working at all, when it very well should.

[sniperchance]

Does this Mac version compile using the cmake system, or did you hack your own thing together? If you changed the cmakelists file at all, make sure to get the changes put in to the normal zdoom source.

I used CMake to generate Makefiles, and I pretty much just disabled the rt GetTime function in the CMakeList file.

[TheDarkArchon]

It also doesn't agree with any color depth besides 32. 16 bit color isn't working at all, when it very well should.

Who the Hell uses 16 bit colour on their monitors in this day and age?

[chr1z]

Are you gonna post the source?