[wiki=Compile ZDoom on Mac OS X]Or try compiling it yourself[/wiki]
Mac OS X 10.4-10.7 Intel/PPC is supported.
Finally, ZDoom is fully cross-platform!
This was actually a relatively painless process, thanks to CMake, and Mac OS X's recent Developer APIs have better support for cross-platform programs. I fixed some of the major issues with ZDoom on OS X, but keep on the lookout for any that I might have missed. For now, the launcher I used is based off of PrBoom+'s slick launcher for OS X. I figured there's no point in reinventing the wheel.
Will there be a Universal binary of ZDoom?
Yes, there will be. This means that the minimum requirement of ZDoom will hopefully bump down to a PowerPC processor! (10.3.9 support is out, due to some annoying SDK conflict)
I've managed to compile a PowerPC binary of ZDoom, but it strangely won't load WADs at all. I'll look into it as time goes on.
ZDoom OS X Changelog
- Replaced the bundled SDL library with a version compiled for Mac OS X 10.4 (Universal binary)
- Fixed a build mixup with the launcher, where it was still being built as a Mac OS X 10.5 application
- Made the launcher interface a little neater
- ZDoom OS X now supports Tiger (Mac OS X 10.4.x)
- Added a failsafe in the launcher if it is executed on a PowerPC Mac
- Log files, screenshots, and debug files are now written to ~/Library/Application Support/zdoom by default
- Added a comprehensive launcher for ZDoom, based on the Mac OS X launcher for PrBoom+
- Resolved a bug with ZDoom's renderer and mouselook in OS X (incorporated in ZDoom r1257)
- Preliminary release
Here's some screenshots:
Last edited by sniperchance on Sun Apr 26, 2009 6:40 pm, edited 26 times in total.
And I remember Neil's attempt at porting ZDoom to OS X a couple years ago having a similar issue with only being able to look up. Hopefully that can be fixed, as IIRC it resulted in some odd issues with accidentally firing rockets into the floor when you think you're looking straight-ahead
The look down issue is where I got stuck at. I tried trying to find the root of the problem, but frankly, I was delving into code I didn't understand. I suspect the issue is in the software renderer. I created a nib IWAD selector, but never got around to implementing the code for it. CMake, at least when I tried it, did not have fanstastic support for creating .app files either. The way I had to go about embedding the zdoom.pk3 and the FMOD Ex dylib was very hacky.
I know what you mean, plus Xcode seems to love Objective-C, something which zdoom's build chain does not. Honestly, my method was to generate Unix Makefiles, compile the zdoom executable, then copy zdoom and the libraries into a blank App. I'm sure there's a good way to set up a Mac app package though, since PrBoom+ was able to do it somehow.
As much as I'd like to share your disgust at Macs, let's be considerate of those who either have no choice, or for those artists who do prefer it over IBM-Compatible PCs. For instance, my webmaster's brother owns a Mac and loves it for what it does.
If you fix that up/down issue (probably SDL related) and add some sort of launcher to this then I want to have your children. This is goddamn awesome. I've wanted to be able to use ZDoom for a while but installing windows and rebooting just to run one program seemed... retarded. A few things I noticed though...
-Ultimate Doom is the IWAD selected if you just launch the program, which is at odds with every other port I use. I dunno if this is a recent ZDoom change or something that you did yourself but its rather irritating.
-As stated looking down is broke. I think this is an SDL issue. And to be perfectly honest if you're using FmodEX there's no reason you couldn't ditch SDL and simply use Cocoa (or Carbon), if you so desired to.
-Changing resolutions doesn't work (or at least switching from fullscreen to windowed mode) within the program. I have to change it, exit, and restart the program.
Anyways Intel Mac w/ Leopard here, ready and willing to test anything that you happen to want tested. Also I wonder if this could maybe possibly lead to Mac GZDoom.
The Ultimate Doom thing is only because I disabled the GTK IWAD selector, so it tries to use the terminal window for the IWAD prompt, but fails since you didn't run it in a terminal. Open up a Terminal window, and go to the ZDoom.app/Contents/MacOS folder. From there, you can run zdoom with any parameters you want, and the text IWAD prompt should show up.
The thing about SDL is that it still uses QuickDraw, so that's a good reason to switch to Cocoa SDL. I should check out the implementation in the PrBoom+ port.
And I think GZDoom could be possible on Mac OS; after all, it's supposed to have great OpenGL support.
I'm fairly certain SDL is NOT the issue. In terms of video, SDL is pretty much just been used as a framebuffer. Creating a native Cocoa alternate to the SDL code would be nice later down the track, but I hardly see it as a priority if the SDL code is not at fault. I think tracking down the look down issue, creating a clean as possible build proccess and implementing a GUI IWAD selector should all be done first.
k0da wrote:I'm fairly certain SDL is NOT the issue. In terms of video, SDL is pretty much just been used as a framebuffer. Creating a native Cocoa alternate to the SDL code would be nice later down the track, but I hardly see it as a priority if the SDL code is not at fault. I think tracking down the look down issue, creating a clean as possible build proccess and implementing a GUI IWAD selector should all be done first.
You're right. From the looks of it, it's definitely not SDL. It looks like the software renderer won't let the camera pitch down, whether it's mouse look or keyboard look.
Does this work as a Universal binary (i.e. will run on PPC Macs) or does it require an Intel Mac? I've got an older G3 running OS 10.3.9 that I could test it on (providing I can get the thing to boot and connect to the network).
The info pane for the app identifies it as an Intel application, and even if it were a PPC app I bet the SDK he's compiling with is either the 10.5 or 10.4u SDK, which means that using 10.3.9 is out =[