Forums » Bugs
Still losing key events on OS X with GL 4 driver
With the GKGL 4 driver, I'm still missing about ⅓ of keypresses. I was debugging it with ray for a while, but I got distracted, and now I can't find the thread.
This includes both keyup and keydown, so sometimes it'll miss keypresses and sometimes it'll just hold a key down forever. This makes the game largely unusable.
I'm on the latest OS X on a Late 2013 Retina MacBook Pro with a GeForce 750M. I've never experienced this problem in another game or application. This has been happening across multiple OS X versions since the release of the OpenGL 4 driver.
If I edit config.ini to switch back to the pre-OpenGL 4 driver, everything's totally fine (although much less pretty).
It occurs both at native resolution (2880x1800), half-native resolution (1440x900), and scaled in-between (1680x1050).
All of my logs are at https://gist.github.com/Roguelazer/2790d56f6b8d6e0714147729d7918c1e if that's helpful.
This includes both keyup and keydown, so sometimes it'll miss keypresses and sometimes it'll just hold a key down forever. This makes the game largely unusable.
I'm on the latest OS X on a Late 2013 Retina MacBook Pro with a GeForce 750M. I've never experienced this problem in another game or application. This has been happening across multiple OS X versions since the release of the OpenGL 4 driver.
If I edit config.ini to switch back to the pre-OpenGL 4 driver, everything's totally fine (although much less pretty).
It occurs both at native resolution (2880x1800), half-native resolution (1440x900), and scaled in-between (1680x1050).
All of my logs are at https://gist.github.com/Roguelazer/2790d56f6b8d6e0714147729d7918c1e if that's helpful.
I think this is one of the related threads, as well as the recurring mouse-hold problem. Debugging this will likely require a pretty deep dive on some of the other example code out there, and try and figure out what Apple has done. The fact that other games don't display the same behaviour (and some have, as my thread mentions) isn't really here or there.. it just means they already addressed the problem, or they use a framework that has addressed it.
Anyway, we're aware it's still a problem, and using the GL2 driver is really the only solution on Mac for the moment. We will address it, but it's a bit of a black-box issue.
Anyway, we're aware it's still a problem, and using the GL2 driver is really the only solution on Mac for the moment. We will address it, but it's a bit of a black-box issue.
Well, let me know if there's anything I can do to help debug. I can confirm (as per the other thread) that killing everything else before running VO doesn't fix it, so it doesn't seem like it's an issue with a background application. I'm on 10.11.5, but I can probably wrangle up a test machine to put the 10.12 beta on if you want to see what happens under the new OS.
Anecdotally, I can also confirm that just about every other 3D game I've played in the last two or so years has switched to the "new" (as of 10.7) full-screen-as-a-space system.
Anecdotally, I can also confirm that just about every other 3D game I've played in the last two or so years has switched to the "new" (as of 10.7) full-screen-as-a-space system.
Would it seem to happen more often when you're typing text or when flying in space?
I notice it more when typing text (it makes logging in really hard sometimes), but I think it's about equal. I just typed the letter 'a' 10 times at the password form and got 7 asterisks; that feels like about the normal rate of key-loss.
I am still unable to reproduce the problem on our mac mini running 10.11.5.
I dragged my finger across the rows an all keys showed up. I rapidly typed 'a' 10 times and they all showed up.
I suppose I can try making a test version of the client that prints all characters to the errors.log file throughout the key event processing pipe to see where it gets lost, but I can't do that right now.
I dragged my finger across the rows an all keys showed up. I rapidly typed 'a' 10 times and they all showed up.
I suppose I can try making a test version of the client that prints all characters to the errors.log file throughout the key event processing pipe to see where it gets lost, but I can't do that right now.
Rogue, one of the differences I can see is that your Late-2013 MBP has dual GPUs. Just out of curiosity, have you tried running the game on the Iris 5100 (integrated Intel), instead of the GeForce 750M?
Obviously, it's not desirable for usability, but if the GPU usage made a difference it would help narrow down the issue.
We have multiple Intel Minis, none of which exhibit this issue, but none of them have discrete graphics either (or dual graphics, for that matter).
Obviously, it's not desirable for usability, but if the GPU usage made a difference it would help narrow down the issue.
We have multiple Intel Minis, none of which exhibit this issue, but none of them have discrete graphics either (or dual graphics, for that matter).
I'm ashamed to say that I didn't think of testing that. Even though, in retrospect, it's blindingly obvious.
I may have identified the bug.
When I ran with the Iris 5100, the game did not drop any input (I tested by typing out the alphabet). However, it wasn't really playable at 20fps, so I dropped the resolution to 1024x640 to continue testing. That brought the FPS up to my framerate cap (60fps)... and brought back the dropped input. Is the framerate cap somehow causing the dropped input? If I turn off vsync and turn off the framerate cap, the input dropping goes away... both on the Iris 5100 and on the GeForce 750!
I can create key drops on-demand just by setting the framerate cap to something less than the max my GPU can do for a given scene. Yay! I love successful debugging!
I may have identified the bug.
When I ran with the Iris 5100, the game did not drop any input (I tested by typing out the alphabet). However, it wasn't really playable at 20fps, so I dropped the resolution to 1024x640 to continue testing. That brought the FPS up to my framerate cap (60fps)... and brought back the dropped input. Is the framerate cap somehow causing the dropped input? If I turn off vsync and turn off the framerate cap, the input dropping goes away... both on the Iris 5100 and on the GeForce 750!
I can create key drops on-demand just by setting the framerate cap to something less than the max my GPU can do for a given scene. Yay! I love successful debugging!
Interesting. We can certainly set the frame limit on our hardware, and hopefully reproduce the problem.
Had you set it to 60fps? I thought the frame limit default on PC was 120, but maybe it's different on Mac for some reason.
Had you set it to 60fps? I thought the frame limit default on PC was 120, but maybe it's different on Mac for some reason.
Even with frame limiter at 120, presumably vsync will cap at 60? I can experiment more with /fps if you want.
Okay, I dropped my settings low enough so that I get a consistent >120fps at the login screen for testing.
No VSync, No Frame Limiter: no drops, 125fps
VSync, No Frame Limiter: no drops, 60fps
No VSync, Frame Limiter @ 60fps: drops, 58fps
VSync, Frame Limiter @ 60fps: drops, 58fps
VSync, Frame Limiter @ 90fps: no drops, 60fps
Basically, it seems that it's only a problem when the frame limiter is the thing actually limiting framerate.
No VSync, No Frame Limiter: no drops, 125fps
VSync, No Frame Limiter: no drops, 60fps
No VSync, Frame Limiter @ 60fps: drops, 58fps
VSync, Frame Limiter @ 60fps: drops, 58fps
VSync, Frame Limiter @ 90fps: no drops, 60fps
Basically, it seems that it's only a problem when the frame limiter is the thing actually limiting framerate.
System vsync may cap at 60, given your laptop/LCD. But That may be different from whatever is causing the key dropouts.
Mostly, I'm just curious if the default 120 setting still causes issues or not.
[EDIT], ok, what happens if it's set to no-vsync and 120fps frame limiter?
Mostly, I'm just curious if the default 120 setting still causes issues or not.
[EDIT], ok, what happens if it's set to no-vsync and 120fps frame limiter?
No vsync, 120fps frame limiter: fewer (but still some) drops, ~115fps
There are definitely a lot fewer drops when the frame limiter is set near the natural fps than when the frame limiter is set lower than the natural fps. I imagine that it's just dropping events received during skipped frames?
Anyhow, for now I've just set the frame limiter to 200fps and turned on vsync, and I am not experiencing any key drops.
There are definitely a lot fewer drops when the frame limiter is set near the natural fps than when the frame limiter is set lower than the natural fps. I imagine that it's just dropping events received during skipped frames?
Anyhow, for now I've just set the frame limiter to 200fps and turned on vsync, and I am not experiencing any key drops.
Ok, now I am able to reproduce the dropped keys. Thanks.
We're releasing a patch today that should fix this issue. Please give it a try and let us know if you're still having dropped key/mouse events.
This seems to be fixed or at least unnoticeable now. However window focus is still messed up with the GL4 driver both in fullscreen and windowed mode as per this thread: https://www.vendetta-online.com/x/msgboard/2/30161
Thanks. Yeah, that other issue is still on our list to fix.
Another thing of slight annoyance: The client hangs when changing back to the old reference driver, so the only way to change back was to edit the config.ini file.
The window/cursor behavior is just too annoying as it is with GL4.
The window/cursor behavior is just too annoying as it is with GL4.
Key-drops seem completely fixed. I even dropped my FPS limit way down to 30 and no drops.
Thanks, ray!
Thanks, ray!