Oolite Bulletins

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.

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.

Yes I'll add this to the wiki soon.

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

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.

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

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.

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.

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

another_commander wrote: ↑Fri Sep 20, 2024 6:57 pm

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.