Fixed bug where the Steam overlay would generate an event and stop input processing for the frame.

This commit is contained in:
Sam Lantinga 2019-08-30 08:03:19 -07:00
parent 9c8e403f6b
commit afb9ff9507

View File

@ -1119,6 +1119,7 @@ WIN_PumpEvents(_THIS)
const Uint8 *keystate; const Uint8 *keystate;
MSG msg; MSG msg;
DWORD start_ticks = GetTickCount(); DWORD start_ticks = GetTickCount();
int new_messages = 0;
if (g_WindowsEnableMessageLoop) { if (g_WindowsEnableMessageLoop) {
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {
@ -1132,10 +1133,18 @@ WIN_PumpEvents(_THIS)
/* Make sure we don't busy loop here forever if there are lots of events coming in */ /* Make sure we don't busy loop here forever if there are lots of events coming in */
if (SDL_TICKS_PASSED(msg.time, start_ticks)) { if (SDL_TICKS_PASSED(msg.time, start_ticks)) {
/* We might get a few new messages generated by the Steam overlay or other application hooks
In this case those messages will be processed before any pending input, so we want to continue after those messages.
(thanks to Peter Deayton for his investigation here)
*/
const int MAX_NEW_MESSAGES = 3;
++new_messages;
if (new_messages > MAX_NEW_MESSAGES) {
break; break;
} }
} }
} }
}
/* Windows loses a shift KEYUP event when you have both pressed at once and let go of one. /* Windows loses a shift KEYUP event when you have both pressed at once and let go of one.
You won't get a KEYUP until both are released, and that keyup will only be for the second You won't get a KEYUP until both are released, and that keyup will only be for the second