[NEW] Eternity macOS development builds (alternate)

Eternity development builds for macOS

 

Since the macOS development builds from DRDTeam macOS fail to be made without any possible explanation (empty log files), I've decided to try my own at providing macOS development builds.

 

You get them from my DropBox space.

 

Here's a list of caveats

1. The most recent build is at the bottom! Scroll down and pick the one with the latest date. 
2. The app packages are not signed at all. To be able to start them, you need to right click the app file in Finder and click "Open". Afterwards they'll work from double-clicking too.
3. I'm doing this from my MacBook Pro laptop using a daily Automator job, so it may be just as shabby as you'd expect. You will not get any updates if my Mac is turned off. Hopefully it will work each time it's woken up. I use it frequently enough.

Edited January 20, 2022 by printz

Thanks for putting out this distrib :>

Any chance we can commit the Mac frontend to the SVN repo?

I would appreciate it, if it's considered good enough for that. Note that it's not only a frontend, and the frontend is not a separate executable from Eternity (like PrBoom is), even though it might be useful for it to be (I'm a beginner with Cocoa and don't know all the techniques).

I've just noticed now that Finder is so dumb it cannot merge folders with the same name; it can only replace them. This means that any Eternity updates will remove your personal configurations FOREVER (no trash) -_- I need to change that. Next release will be a single app file, and the user settings will be saved somewhere in ~/Documents I guess.

It's even tougher, because sometimes Eternity changes its configuration format (see keys.csc and the need to delete it some times). This means that if I hide the user configs somewhere in a managed folder, I also need to delete it sometimes.

Works perfectly (so far) on a 10.8.2 retina MBP. Runs smoother that ZDoom (!).

The only minor issue was - as expected - loading disk icon, which made the first load of the application take its sweet time. After turning it off it loads fast, just as you said.

Thank you so very much for this! My favourite source port working on osx without the ./configure, make fuss.

Any chance of this incorporating the SDL midi workaround used by the other Mac ports? (That is, pumping it through QuickTime rather than trying to trust SDL with anything.)

esselfortium said:

Any chance of this incorporating the SDL midi workaround used by the other Mac ports? (That is, pumping it through QuickTime rather than trying to trust SDL with anything.)

If so it needs to be done as trunk work and not in some uncommittable form. We still don't have these Mac additions in the SVN repo so, if something happens to printz, that'll be the end of custom Mac builds forever more than likely.

If the code is not either released in .zip / .tar.gz form or submitted to me as a patch before the end of this month, I may be forced to resort to The Terms of the License, as it's not really right for a free software project to be in this situation. I already expressed my appreciation for this multiple times and I am maintaining an assumption of good faith, but really you do have to comply with the GPL if you're going to distribute modified code.

I've uploaded the source codes as ZIPs extracted directly from DMGs, for easier access for everyone. Sorry for not doing this initially.

IMPORTANT NOTE: they contain the source to the front-end only. I considered that putting the Eternity source is redundant, because its code is exactly the same as in the original, and if you load this one as an XCode project, you'll see grayed-out filenames corresponding to (missing) Eternity files. There is an easy command to change the folder they link to to the real Eternity source folder (Eternity engine source code downloaded from Quasar's links) and it will compile.

EDIT: I'm also totally OK on Quasar copying the source code to his repository.

Yay! Eternity Engine.app will not die!

Right, it will not.

Here's r2214: Binary / Source Code.

It should replace everything in your "/Applications/Eternity Engine" folder without killing any of your data. You don't have to download any old version prior to this. If you have one, it will be updated.

Please tell me if:
1) the installation works;
2) the new "Eternity Engine.app" has 7.568.520 bytes
3) to confirm that every non-Eternity file there is NOT deleted.

DUE TO POINT 3), PLEASE BACK UP YOUR OLDER INSTALL. I tested it and it did NOT kill data.

Here is the SVN patch for Quasar containing the source code: EE FE OSX PRINTZ

EDIT: second version added, for ref: http://files.drdteam.org/index.php/files/get/C85mKg8oh7/eefeosxprintz2.patch.zip

printz said:
(...)
It should replace everything in your "/Applications/Eternity Engine" folder without killing any of your data. You don't have to download any old version prior to this. If you have one, it will be updated.[/B]

Worked for me, DID NOT overwrite my previous settings (tho I have touched only a few options before updating)

Again - thank you so much for this!


EDIT:
I started playing around with some options and there are noticeable performance issues in resolutions higher than default 640x480. I turned off VSync, but the framerate still drops.
My MBP has both an integrated Intel HD 4400 and a dedicated GeForce 650M. EE uses the first one only (even when laptop is forced to use the dedicated one there's no difference) - which, as I understand, is probably because of how SDL works.

ellmo said:

Worked for me, DID NOT overwrite my previous settings (tho I have touched only a few options before updating)

Again - thank you so much for this!


EDIT:
I started playing around with some options and there are noticeable performance issues in resolutions higher than default 640x480. I turned off VSync, but the framerate still drops.

I'm happy that it works for you!

Is the performance worse than before (if you tried before), at the same resolution? On my MacBook it definitely runs worse on OS X Snow Leopard than on Windows XP from Boot Camp. But esselfortium told me that directly it runs better than by Windows via Parallels.

Question: is the Mac build OpenGL enabled?

EE_FEATURE_OPENGL is defined, if that's what you're asking. No command-line parameters that disable it are implicitly used. The gl_*.cpp source files are included in the project.

EDIT: I found this code in gl_includes.h:

#if defined(__MACOSX__)
 #include <OpenGL/gl.h>  /* Header File For The OpenGL Library */
#elif defined(__MACOS__)
 #include <gl.h>         /* Header File For The OpenGL Library */
#else
 #include <GL/gl.h>      /* Header File For The OpenGL Library */
#endif

By default, it doesn't compile: it doesn't find GL/gl.h. Then I forcedly defined __MACOS__ (even if it starts with __) and it worked. I'll see about this later...

EDIT: __MACOSX__ works too. I'm puzzled if those two header files (<OpenGL/gl.h> and <gl.h>) differ in content...

Do you think it should be __APPLE__?

printz said:

Is the performance worse than before (if you tried before), at the same resolution? On my MacBook it definitely runs worse on OS X Snow Leopard than on Windows XP from Boot Camp. But esselfortium told me that directly it runs better than by Windows via Parallels.

Performance is the same as it was before, i.e. when I used the r2157 Midgard package you linked in the first post. I'm playing on 640x480 and it's playable as long as you're not playing crazy detailed maps.
I have neither bootcamp nor parallels installed (yet), but I've seen how native windows executables perform and I've compiled EE for Ubuntu before. They all ran smooth as butter, but iirc both those OS series are nicely supported by SDL and OSX always gives me a lot of trouble when trying to compile something SDL dependent.
Still it just might be something about 10.8.2 or the Retina display.

I have another, older MBP with OSX 10.6.8 somewhere around. I'll try EE there and see how it works.

ellmo said:

Still it just might be something about 10.8.2 or the Retina display.

Hmm, nice. Judging from that, the port works even under Mountain Lion, slow as it may be. I'll keep having 10.6.8 until either I change my laptop (I hope I'll continue having a Mac, the software is awesome even if the hardware is terrible) or something urges me to get Lion (I cannot use Mountain Lion, presumably because of planned obsolescence).

printz said:

Do you think it should be __APPLE__?

You can try "#if defined(__MACOSX__) || defined(__APPLE__)"

Gez said:

You can try "#if defined(__MACOSX__) || defined(__APPLE__)"

Please do try that. If it works, we'll trunk it. I copied those defines out of SDL ass-u-me-ing they'd be correct :P

Gez said:

You can try "#if defined(__MACOSX__) || defined(__APPLE__)"

Confirmed, it works if I test for __APPLE__, it doesn't have to be explicitly defined.

I must be an idiot for not noticing this earlier, but I just found a way to run apps in low-resolution on MBPr :

http://www.doomworld.com/vb/showthread.php?postid=1116963#post1116963

This makes my EE run smooth as butter, never going below 35 fps.

Every time I update to a newer version with the installer, I lose all my keybindings and mouse options and most (or all) other settings. I have no idea why or how that's happening, because even when I try reverting to a backup cfg it's still giving me default settings everywhere until I give in and set it up again manually.

esselfortium: it probably reads the settings from elsewhere lol. I hope that now it's better, that it has ONE location from where to read.

I updated it. Now it uses a single file, no stupid INAPPROPRIATE-for-this-sort-of-thing installer.

The user folder is (if absent) copied into an Eternity-identified subfolder of Library/Application Support. Further versions will be more robust on this, trying to keep track of what needs to be added there. The player will be able to access that folder from a GUI button. No need to wade through Finder.

/Base can also be accessed from the GUI, but it's for mod developers only (it really goes inside the app bundle to get to /base, but you're not supposed to change anything there anyway).

Anyway, tell me if it works.

printz said:

esselfortium: it probably reads the settings from elsewhere lol. I hope that now it's better, that it has ONE location from where to read.

I updated it. Now it uses a single file, no stupid INAPPROPRIATE-for-this-sort-of-thing installer.

The user folder is (if absent) copied into an Eternity-identified subfolder of Library/Application Support. Further versions will be more robust on this, trying to keep track of what needs to be added there. The player will be able to access that folder from a GUI button. No need to wade through Finder.

/Base can also be accessed from the GUI, but it's for mod developers only (it really goes inside the app bundle to get to /base, but you're not supposed to change anything there anyway).

Anyway, tell me if it works.

Process:         Eternity Engine [58669]
Path:            /Applications/Eternity Engine.app/Contents/MacOS/Eternity Engine
Identifier:      com.eternity.Eternity-Engine
Version:         Alfheim 3.40.30
Code Type:       X86 (Native)
Parent Process:  launchd [166]
User ID:         501

Date/Time:       2013-01-13 18:31:03.115 +0100
OS Version:      Mac OS X 10.8.2 (12C3012)
Report Version:  10

Interval Since Last Report:          987851 sec
Crashes Since Last Report:           657
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      30588154-F6B0-9B6B-15F6-3691128C7AB0

Crashed Thread:  0

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: @rpath/SDL_net.framework/Versions/A/SDL_net
  Referenced from: /Applications/Eternity Engine.app/Contents/MacOS/Eternity Engine
  Reason: image not found

Binary Images:
    0x1000 -   0x23bfef +com.eternity.Eternity-Engine (Alfheim 3.40.30) <84A28074-9A35-38BD-9191-AAB62279B8ED> /Applications/Eternity Engine.app/Contents/MacOS/Eternity Engine
0x8fe54000 - 0x8fe86e57  dyld (210.2.3) <23516BE4-29BE-350C-91C9-F36E7999F0F1> /usr/lib/dyld
0x92a3d000 - 0x92a4bfff  com.apple.opengl (1.8.6 - 1.8.6) <1AD1AE7B-B57B-35B5-B571-32A34F0DA737> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x968c1000 - 0x968c1fff  com.apple.Cocoa (6.7 - 19) <354094F0-F36B-36F9-BF5F-FD60590FBEB9> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa

Model: MacBookPro10,1, BootROM MBP101.00EE.B02, 4 processors, Intel Core i7, 2.3 GHz, 8 GB, SMC 2.3f32
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 512 MB
Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533642465238432D50422020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533642465238432D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xEF), Broadcom BCM43xx 1.0 (5.106.98.100.14)
Bluetooth: Version 4.1.2f9 11046, 2 service, 11 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM256E, 251 GB
USB Device: hub_device, 0x8087  (Intel Corporation), 0x0024, 0x1d100000 / 2
USB Device: hub_device, 0x0424  (SMSC), 0x2512, 0x1d180000 / 3
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0263, 0x1d182000 / 5
USB Device: BRCM20702 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x1d181000 / 4
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8286, 0x1d181300 / 7
USB Device: hub_device, 0x8087  (Intel Corporation), 0x0024, 0x1a100000 / 2
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8510, 0x1a110000 / 3

Am I supposed to replace the previous folder with this single *.app or replace *.app in the folder with this *.app ?

Looks like I wrongly assumed it will automagically read from the bundled SDL* frameworks inside the .app. It seems that with the new Xcode version, I didn't set something for it to look for libraries inside.

Until the next release, I'd suggest this workaround:

- Right click "Eternity Engine.app" and select "Show Package Contents"
- Browse into Contents/Frameworks
- Inside the Frameworks folder, you'll see three SDL folders: SDL_mixer.framework, SDL_net.framework, SDL.framework
- Copy them into the folder /Library/Frameworks (going from the root folder in Finder, not from your user home folder). It may ask you for the admin password.

Sorry for the inconvenience, but I'm just too tempted to rush my releases. I have to put the same message on AutoWolf now too.

I should read the Apple developer documentation more thoroughly, all the answers are there.

Alright, I've updated r2352 of Eternity for Mac OS X. It has been tested on OS X 10.8, without any SDL frameworks installed, and it works.

Grabbing this right now
***
**
*
...loading


Working peeeeerfectly!

I'ma gonna record a playthrough of BTSX, so if any errors should occur I'll have it documented.


Thank you so much for doing this!

neat, I wasn't aware of this port. I've been looking around ever since I picked up a mbp with 10.8 on it, seeing as the os x binaries of prb+ don't play nice on lion due to some (I think) outdated sdl versions.

Most everything seems to work peachy keen, maybe I'm an idiot, but I can't seem to get it to run fullscreen, or to change resolution for that matter. related commandline / config options don't seem to have any effect. also anyway to have alwaysrun on by default?

I'm curious how you got the midi to sound decent, ever since 10.7 it seems like general midi playback for os x has been in the shitter. quicktime and also that old prb build seem to suffer the same problems of painfully low volume and screwed up dynamics (sounds like it's being passed through a limiter?), but as far as I can tell those problems aren't present in this port. I don't know too much about the audio inner workings, so sorry if my inquiry is misguided.

Anyways, cool project, I'll definitely try messing around with demos and such if I can get it fullscreen -.-

Does it crash when you attempt full screen (thus giving a message)? Also what kind of display do you use? Did you set resolution in Eternity display settings by typing something like 1280x800f (for example)? Try setting it to your display's maximum. Also did you set screen rendering to SDL GL instead of SDL software? I've been having slowdowns on both a Mac and a PC while using 'SDL software' mode.

The MIDI and other such features work here since I'm using the most up to date SDL versions. I've been using the same ones one version behind because I believe the original for Windows still uses those, but that turned out unwise.

Command line parameters from terminal: control click on the Eternity Engine application, select Show Package Contents, browse down to Resources. There you'll find Eternity.app. Copy that into a folder with base/, user/ (possibly downloaded from Eternity's source code) and doom.wad. Using Terminal, from that folder, type:

eternity.app/contents/macos/eternity

I believe you can also use the 'open' command on .app packages directly, and be able to use arguments too. I haven't studied that though.

printz said:

Does it crash when you attempt full screen (thus giving a message)? Also what kind of display do you use? Did you set resolution in Eternity display settings by typing something like 1280x800f (for example)? Try setting it to your display's maximum. Also did you set screen rendering to SDL GL instead of SDL software? I've been having slowdowns on both a Mac and a PC while using 'SDL software' mode.

Oh, hah, I don't think I've EVER used fullscreen in EE before, but I just went to check this one for you:
Fullscreen works fine, 2880x1800F is a slideshow, but 1440x900F 1280x800F work absolutely fine.

But, um... how does one enable SDL GL?

printz said:

The MIDI and other such features work here since I'm using the most up to date SDL versions. I've been using the same ones one version behind because I believe the original for Windows still uses those, but that turned out unwise.

Thanks for fixing the looping midi issue, by the way!