OSX 10.9 issues and questions

We’ve had a Mac version of our game in beta testing for a while and a few issues have come up when running on OSX 10.9 (Mavericks). I’m not sure if they are interrelated or not:

1. The console is spammed with the following message:

2014-03-09 21:18:25.728 p3dpython[464:507] unlockFocus called too many times. Called on <CocoaPandaView: 0x2b791910>.

This message appears to be logged at least once per frame.

2. XQuartz must be installed to run the game. Is there any other option here, or am I stuck requiring users to install additional software in order to run the game?

3. Although I am unable to reproduce it myself, multiple users who are running the game on OSX 10.9 report that when pressing keys on the keyboard to move the character, the character continues moving after the key is released. This leads me to suspect that the key up event is not firing. I accept keyboard input with the following code:

button_node = game.buttonThrowers[0].node()
button_node.setButtonDownEvent('buttonDown')
button_node.setButtonUpEvent('buttonUp')
button_node.setKeystrokeEvent('keystroke')
game.accept('buttonDown', self.key_down)
game.accept('buttonUp', self.key_up)
game.accept('keystroke', self.typekey)

Why might this not work for some users?

1. I haven’t seen this, but I’ll look into it. We call lockFocusIfCanDraw followed by unlockFocus, so perhaps if “canDraw” does not hold, it considers the unlockFocus to be one too many.
   Poke me if I don’t get back to you about this as I’m very busy and this could easily slip off my radar.

2. This is because we link with the stock libpng and libfreetype, which reside in /usr/X11, and therefore create a runtime dependency on X11. The solution is to link with libpng and libfreetype from another location (or copying them into the thirdparty dir). I’ll look into doing this for the public build.

3. I did happen to check in improved keyboard handling on Cocoa yesterday*, which had to do with some up events not being sent properly, but this was only the case while the Command key was pressed. Could it be the case that the users had the Command key pressed?

• This might be interesting for you: I’ve also checked in a new set of ‘raw’ keyboard events (raw-w, raw-a, etc.) that allows one to listen for WASD as they would be placed on an ANSI US keyboard, ignoring any user keyboard layout or modifier keys. When playing Signal Ops, I was forced to manually change my key mapping to match my dvorak layout in order not to have to stretch my fingers all over the keyboard, and this would prevent that.
  I’m also currently working on some changes that allows one to query the current keyboard layout from the OS that could be used to initialise the default keyboard mapping as an alternative way to fix this.

1. Could we be seeing this message due to use of render buffers? Perhaps it is not an issue otherwise.
2. Since we maintain our own build, and do not use freetype, will dropping libpng in the thirdparty dir be picked up automatically or do I need to edit makepanda somewhere?
3. This is possible, I will try out the new changes and let you know how it works out.

1. Can you reproduce the issue yourself? Is there perhaps a way for me to reproduce it?
2. Dropping it in thirdparty packages would be sufficient, I think. Keep in mind to clear built/lib/* so that any old link references are cleared. To be sure, make sure that it is not adding -L/usr/X11/lib or -L/usr/X11R6/lib on the command-line, and if you want to verify that there are no references to libraries in /usr/X11/lib, run “otool -L built/lib/libpanda.dylib” to get a listing of dependent libraries.
3. Okay, well, it’s probably unlikely that this was the issue, but it was my best guess anyway.

1. This spam message seems to happen on both 10.6 and 10.9, as long as cocoa is being used. It is not related to render buffers, I get it on a simple hello world program.
2. Still trying to figure out the keyboard input issue which is really the main game-breaking bug.
   I cut out my keyboard input code here: [url]Assistance needed testing keyboard input code on OSX 10.9].
   I tried updating to the latest source but it appears to no longer compile with Python 2.6 which we are still using.

Ah, I was never able to reproduce the unlockFocus error in my regular builds, but I just ran into it today when testing optimize-4 builds for the impending 1.9 release. After some poking around, it suddenly hit me:

    nassertr([_view lockFocusIfCanDraw], false);

nassertr() is compiled out in optimize 4 builds. Replacing it with nassertr_always() makes the error go away. Just pushed the fix.

This issue is purely a product of my stupidity. My apologies.