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

[Bogatyr]

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.

That's good to know, thanks. When debugging I'm mostly running in a window, is there a setting where the vsync wait can be disabled? Do you happen to know where in the code the timer tick is adjusted for vsync? Also, good to know about keyboard input changes, I'll take a look at the newer code. I was thinking that polling keyboard events, as I see in git tag 1.90, is very inefficient and can miss key presses if the press is very short. But still it doesn't explain the difference in keyboard behavior between the official 1.90 build and my 1.90 build. Perhaps the official 1.90 build was highly tweaked, and not just a direct build of the source repository at tag 1.90? Having this knowledge of the details of how the 1.90 official release was built would really help and perhaps save a lot of time...

Another potential plan is to merge as much of trunk as is possible, just without the renderer change, into an "it works on mac" branch that tries to track top of tree as much as it can.

I've verified that the released 1.90 never misses a key press, no matter how short it is, even when the game tick is apparently set to a target of 60fps. Either the key handling in the released 1.90 is fundamentally different than what I see in github tag 1.90, or there is something borked about my build, or there is yet another factor I'm still missing.

As it stands in the github tag 1.90 keyboard code, events can be easily dropped because the design contains a race condition between the event receiving and the event processing -- event processing is tied to game tick, and if the key up event happens before the next game tick, the key press is lost, and that explains my "laggy key handling" behavior that I'm seeing in my build. Adding a direct scheduling of the next game tick in the key down code as a hack/experiment may reduce that race to zero. Ideal of course is to remember the key press in the event code, so that it can be processed on the next game tick and not lost in case of such a race.

[Bogatyr]

...
Adding a direct scheduling of the next game tick in the key down code as a hack/experiment may reduce that race to zero. Ideal of course is to remember the key press in the event code, so that it can be processed on the next game tick and not lost in case of such a race.

This worked great!

I tried adding this:

Code: Select all

    [_gameController performSelectorOnMainThread:@selector(performGameTick:) withObject:nil waitUntilDone:NO];

at the bottom of

Code: Select all

@implementation OoliteApp
- (void)sendEvent:(NSEvent *)theEvent

and keyboard presses are seemingly never dropped.

It requires a bit more finesse in the implementation on when exactly to do this, for example, definitely not when entering the planet names on the long range chart -- this felt a bit laggy, that code should not invoke the game tick per keypress, definitely, but that may be the only case where key presses are completely processed outside of the game tick). (Yes, this worked great, only schedule the game tick if not "allowStringInput" in [MyOpenGLView keyDown:].

Note that mouse clicks suffer the same race condition: if the click is too fast, then it's lost. Adding a call to gametick in the case of mouse down should also fix this.

[hiran]

If you are getting familiar with the code maybe you could have a look at game startup.

On Windows and Linux you can run

oolite -load <savegame>

and Oolite would load and start that savegame. It does not work on the Mac version but is an important feature for using OoliteStarter. I suspect the root cause is there are two different entry points that support different parameters.
https://ooliteproject.github.io/oolite/index.html

[Bogatyr]

If you are getting familiar with the code maybe you could have a look at game startup.

On Windows and Linux you can run

oolite -load <savegame>

and Oolite would load and start that savegame. It does not work on the Mac version but is an important feature for using OoliteStarter. I suspect the root cause is there are two different entry points that support different parameters.
https://ooliteproject.github.io/oolite/index.html

Maybe it would be good to file an issue on github so that things like this are not lost in forum thread. Also, this perhaps may depend on solving the OpenGL issue on top of trunk first.

[another_commander]

That's good to know, thanks. When debugging I'm mostly running in a window, is there a setting where the vsync wait can be disabled? Do you happen to know where in the code the timer tick is adjusted for vsync? Also, good to know about keyboard input changes, I'll take a look at the newer code. I was thinking that polling keyboard events, as I see in git tag 1.90, is very inefficient and can miss key presses if the press is very short. But still it doesn't explain the difference in keyboard behavior between the official 1.90 build and my 1.90 build. Perhaps the official 1.90 build was highly tweaked, and not just a direct build of the source repository at tag 1.90? Having this knowledge of the details of how the 1.90 official release was built would really help and perhaps save a lot of time...

I don't know how Mac handles it, but for Windows it's a command line option. Default is vsync on, -novsync on command line turns it off. Vsync on win/lin is set by the SDL attribute SDL_GL_SWAP_CONTROL which is non existent in the Mac build. Note that Mac and Windows/Linux get their input, timing and window management code from different places so they are allowed to be very different. Speaking of timers, this reminds me that I should probably raise the tick limit to 240 hz now that we have monitors that can easily hit this frequency.

As for how the official 1.90 build for Mac was made, I know for a fact that it is a direct build of the 1.90 source with zero modifications.