[NEW] Eternity macOS development builds (alternate)

ellmo said:

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?

Go into display settings (inside Eternity, same place where you'd change resolution) and page-down (Fn+down) until you see a SDL field where you choose between software and GL 2D. Then restart Eternity.

Also I assume you have a discrete GPU. It's possible that the NVidia card is too lazy and lets the retarded Intel chip do the work. You may need to go into system preferences at power saving settings (light bulb) and deactivate automatic video card switching. Or have an OpenGL (for example) application running at the same time to wake up the GPU. I don't know whose fault is for this laziness: SDL's or Apple/Intel/NVidia's. I guess I can place a dummy OpenGL control at the main window to wake up the NVidia, but it's very hard for me to test it.

NOTE: this version of Eternity is modified by me to support resolutions higher than 2560xsomething. For GPL compliance I provided a patch that shows what I changed, inside "source diff/" folder from the DMG.

Also, I wish I knew how to make fancy DMGs — the kind with artwork. But I'm not a graphic artist!

printz said:

Go into display settings (inside Eternity, same place where you'd change resolution) and page-down (Fn+down) until you see a SDL field where you choose between software and GL 2D. Then restart Eternity.

Oh man, what a nab. I didn't notice video settings go for more than trhee pages.

I forced OSX to use the dedicated GPU, switched to GL2D, set resolution to 2880x1800F...
it looks and works marvelous!

ellmo said:

I forced OSX to use the dedicated GPU, switched to GL2D, set resolution to 2880x1800F...
it looks and works marvelous!

Does it work fine even if you don't force OSX to do that?… Or will you eventually get to see the entire display stretched beyond your monitor?

printz said:

Does it work fine even if you don't force OSX to do that?… Or will you eventually get to see the entire display stretched beyond your monitor?

That's exactly what happens if I leave GPU switch to automatic - I believe it's still 2880x1800 but not hiDPI, so it expects 4 times the screen size.

(I'm using gfxCardStatus to make quick GPU changes)

interesting project you have here

Some will be happy to know that EE works in Homebrew! Be sure to compile GCC4.x (do NOT use the apple Clang!) and set your CC flags accordingly. Works in Mavericks with no problems.

For the OS X builds, where are prerefences saved? Where are screenshots stored? Does this change if I invoke the binary within the App from a terminal (or from within another program like wadc)?

Did you try the "Screenshots and Configs" button from the dialog box? It will open a Finder window. To see where you are, you can right click the icon on the Finder window title bar.

If you want to invoke the app from the terminal, you have two choices:

1 -> open -a "Eternity Engine" --args <list of Doom arguments>

This is the recommended way. Make sure to mention "-iwad" because it may not be obvious.

2 -> locate the "eternity" executable from inside the .app. In that case you WILL have to specify the -base and -user folder, because what you're running is really just the bare executable, with no UI wrapper.

Thanks for your response. I was doing the latter, but I'll try the former.

A bit further on

Lancement:open -a Eternity.app --args -iwad /Users/jon/games/doom2.wad -nosound -warp 1 -file /Users/jon/git/wadc/examples/logo.wad


not quite working yet though

Edit: OK the wrapper doesn't seem to like to receive doom arguments this way. The -file stuff isn't going through (getting /1 instead of the path). Ideally I'd skip right past the launcher to the game proper.

So back to method 2); I wasn't aware of -base or -user so I'll look at those. thanks!

Edit:

OK trying this now
Lancement:/Users/jon/Applications/Eternity Engine.app/Contents/Resources/eternity -base /Users/jon/.eternity/base -user /Users/jon/.eternity/user -iwad /Users/jon/games/doom2.wad -nosound -warp 1 -file /Users/jon/git/wadc/examples/logo.wad

it works, which is good.

Eternity takes an age to start up (in R_Init), which is bad. But I guess that's another problem! I tweaked the vide options to turn on particles etc., I'll try turning them off.

btw I think it's ignoring -base, because ~/.eternity/base is empty (I just created it),but it's loading the pk3 and edf stuff from the Application location. Also -user, because no cfg file is being read or written to ~/.eternity/user.

What is the name of the .app file? You have to say its actual name without the extension (I think), i.e. if it's "Eternity Engine.app" you say open -a "Eternity Engine" (and not Eternity.app). I did try myself, and using --args to set parameters skips the dialog box right into the game successfully.

The base folder is within the app. The user folder is created inside ~/Library/Application Support.

printz said:

What is the name of the .app file? You have to say its actual name without the extension (I think), i.e. if it's "Eternity Engine.app" you say open -a "Eternity Engine" (and not Eternity.app). I did try myself, and using --args to set parameters skips the dialog box right into the game successfully.

I renamed the app to Eternity.app for the experiment, the reason is that wadc (now) has two options for composing a doom command: doomexe and doomargs. The latter is split on white space, which means the arguments within can't contain spaces themselves. Therefore with this mode of operation doomexe is set to "open" and the app name needs to be in doomargs so I renamed the app to remove the spaces.

I tested the open command in a terminal and it launched fine (with .app) but I didn't test passing arguments manually so it's possible that only works if you omit .app. I'll test again.

The base folder is within the app. The user folder is created inside ~/Library/Application Support.

Thanks. I thought -base and -user would override these, but it doesn't seem to be.

OK I explored a bit more last night and I found out what was going on. Although these got created

Library/Application Support/com.eternity.Eternity-Engine
Library/Preferences/com.eternity.Eternity-Engine.LSSharedFileList.plist
Library/Preferences/com.eternity.Eternity-Engine.plist

Eternity is not actually using them, and it's ignoring both -base and -user, and instead writing inside the app itself:

Applications/Eternity Engine.app/Contents/Resources/user/shots/etrn00.png

I can live with this for now, but I might see if I can help fix this later.

That's fishy. Where and when did you get Eternity?

printz said:

That's fishy. Where and when did you get Eternity?

From http://eternity.mancubus.net/ee-3.40.46-osx.dmg on 2015-04-22T16:55:45Z:

tharsis$ ls -lh ee-3.40.46-osx.dmg
-rw-r--r--@ 1 jon  staff   4.2M 19 Jan  2014 ee-3.40.46-osx.dmg
tharsis$ shasum ee-3.40.46-osx.dmg
dad262efb9a9debd466b5b33826884c5a97f6594  ee-3.40.46-osx.dmg
tharsis$ xattr -p com.apple.metadata:kMDItemWhereFroms ee-3.40.46-osx.dmg | xxd -r -p | LANG=C tr -c '[:print:]' "\n" | grep http
/http://eternity.mancubus.net/ee-3.40.46-osx.dmg_
Khttp://www.doomworld.com/vb/eternity/67069-eternity-engine-3-40-46-bifrost/
tharsis$ xattr -p com.apple.metadata:kMDItemDownloadedDate ee-3.40.46-osx.dmg | xxd -r -p | plutil -convert xml1 - -o -| awk '-F[><]' '/date/ { print $3 }'
2015-04-22T16:55:45Z

Hmm. I wonder if it wouldn't be better to take the up-to-date builds from http://devbuilds.drdteam.org/eternity-mac/. It's possible that that old version, even if "official", not to be very well verified against bugs such as this. Maybe a notice should be posted on the page where you downloaded it, that there are newer versions…

IMPORTANT: see the first post, I've provided my own development builds for macOS.

I want to inform you that, until now, the uploads on the OP link were actually broken. I fixed it now; the new download link should work.

The last couple of builds from the Dropbox link don't work, they can't be extracted after downloading. So I'm currently using the latest at drdteam website (Feb 05, 2023) and I'm wondering what's new exactly in this build? 

My daily script tends to put garbage stuff sometimes for some reason. If a latest build is broken, pick the one before it.