Resurrecting the Mac build

[Bogatyr]

Starting a new thread on my findings and experiments and fixes for bringing the mac build back to life (even if only for older versions like 1.90).

So I've recently submitted some bugfixes to the Oolite repo in the branch 1.90-mac-build-bugfix [commit 282c3d865], applied on top of the repo tag 1.90 [commit 0b1ff49a7]. The game builds and runs now at least on my 2018 MacBook Pro running Mojave (10.14.6) using XCode 11.3.1. I've also confirmed that it runs on my late 2009 mac mini running MacOS 10.8.5. My hope is that bringing the build environment back to life will serve as the basis for some continued mac development or fixes.

But I have noticed one oddity so far that is annoying: the keyboard in the game is much less responsive compared to the official 1.90 mac download on oolite.space. Keypresses are frequently dropped seemingly. Rapidly pressing up/down arrow to traverse lists, which is how I like to play as opposed to clicking with the mouse, is much less responsive. The only changes are the macos deployment target (10.7, bumped from the previous 10.6) and the move to the clang libc++ c++ standard library.

So, there is more work to do, perhaps make sure I'm building it with the correct arguments, etc.

[hiran]

I think you already achieved something that should go into the wiki here:
https://wiki.alioth.net/index.php/Developer%27s_Corner

Having such information just in threads gets difficult to lookup later.

[Bogatyr]

Yes I'll add this to the wiki soon.

[Bogatyr]

Done, the mac compiling oolite links now has a page with my recent build experiences and the results of my fixes.

[hiran]

[Bogatyr]

Well I figured out the "what is happening" with the dropped keystrokes in my mac build of 1.90

Oolite doesn't handle key events for most keys (exception below), it polls key status instead in the [PlayerEntityControls pollApplicationControls] function. If the poll function doesn't run in between the time a key is pressed and released, then the key press is invisible to the app. The exception to this is typing in planet names on the long range scanner: those key presses are handled in the key down event handler, and no key presses are ever dropped or missed in that case (and Command-Q and Command-F / F12).

I also noted that the keyDown and keyUp functions are always called twice, because the [OoliteApp sendEvent :event] function calls [gameView keyDown (and keyUp) :event], then calls [super sendEvent:event], which ends up calling [MyOpenGLView keyDown/keyUp] a second time. Since there is very little processing in the keyDown/keyUp functions, it's not horrible, but still seems wasteful.

Now for "why is this happening": I don't know yet. Either the application main loop timer is running more slowly (firing less often) in my build, or the processing of game tick is much slower, or a combination of these two. Checking project compile settings to see that proper optimization parameters are being invoked is one thing to check (I did see some reports of clang binaries running a zillion times slower on one release of XCode, and it seemed to have come down to they changed how the optimization command line parameters worked).

It would be helpful to know exactly how the 1.90 mac binary on oolite.space was built: os, xcode version, git commit / source version, compiler settings, etc. If the mac builds have been "private magic" for a while (involving lobsters?), this info may not be available.

[maik]

Very encouraging results, thank you for putting in your time!

[Bogatyr]

You're welcome! I've been wanting to contribute for a long time and now that I'm semi-sorta-retired, I can actually do that .

It's really odd what I'm seeing with the laggy key presses, it will take more digging. The main game loop timer is set to fire every 5 milliseconds, but I instrumented the main game tick function entry and exit times, and see that from the time the previous game tick loop exits to the start of the next one, is averaging 15 milliseconds.

[another_commander]

Do you have Vsync enabled? 5ms is the tick it will try to achieve when the framerate is uncapped, maxing it out to 200fps.15ms is close to 16.67ms which is 60fps.

[hiran]

phkb actually reworked the way keyboard input is handled/mapped to functions in Oolite.
Not sure when exactly, but I believe all of this post 1.90. As an effect, the above analysis might be outdated already.

Here are some links that may lead you to the activities:
- viewtopic.php?p=296948#p296948
- viewtopic.php?p=292494#p292494
- viewtopic.php?p=290441#p290441
- viewtopic.php?t=21398&hilit=keyboard
- https://github.com/OoliteProject/oolite ... 59b991d51a