Tue, 11 Feb 2020 16:23:43 -0800Fixed iOS and Android build
Sam Lantinga [Tue, 11 Feb 2020 16:23:43 -0800] rev 13510
Fixed iOS and Android build

Tue, 11 Feb 2020 16:14:02 -0800Implemented OpenSL-ES audio recording on Android
Sam Lantinga [Tue, 11 Feb 2020 16:14:02 -0800] rev 13509
Implemented OpenSL-ES audio recording on Android

Tue, 11 Feb 2020 10:35:14 -0800Attempt to make version detection safe for Mac OS X < 10.10
Sam Lantinga [Tue, 11 Feb 2020 10:35:14 -0800] rev 13508
Attempt to make version detection safe for Mac OS X < 10.10

Tue, 11 Feb 2020 10:21:31 -0800Workaround for bug 4822 - Broken visual output in full screen mode with OS X 10.15
Sam Lantinga [Tue, 11 Feb 2020 10:21:31 -0800] rev 13507
Workaround for bug 4822 - Broken visual output in full screen mode with OS X 10.15

sjordan

We did some investigations into a different direction which I would like to share. As mentioned previously the scaling setting in the preferences play an important role for our problem and they also hint towards an issue with point/pixel scaling factors.

We found an interesting correlation between our fail case and the behavior of [nsWindow.screen backingScaleFactor]. It turns out that whenever we encounter the fail case the scale factor is zero when we print it quickly after calling SDL_CreateWindow. After some time the value changes to a non-zero value. In the success case the scaling factor is nonzero 'immediately'. Note that we don't use that factor. We also find that the window backingScaleFactor does not show the strange behavior even in the fail case.

We have also attempted to find out whether any event triggers the transition from zero to non-zero. We found the transition happening when we call SDL_PollEvent. We can even force this to happen by explicitly adding a SDL_PollEvent at an early stage, but it will only happen if a certain amount of time elapsed, so we need to add some sleep before the call to trigger the transition at an earlier stage. All that seems to imply that the transition happens async and that SDL_PollEvent merely causes the system to update its internal state at that time.

We have also verified that the scaling setting in the preferences does NOT directly correlate to the scaling factor behavior. We find that a particular scaling setting can lead to a fail case for one resolution and a success case for another resolution. This shows that the scaling setting alone does not determine whether the problem will appear or not.

We have also verified on another Mac with 10.14 that the scaling factor is always non-zero and we always have the success case.

I have no idea how to interpret this initial-zero behavior and haven't found any usable information on the screen backing scale factor. It seems as 10.15 does some stuff more async than before and maybe the problem could be caused by unfortunate timings. I would be very interested to hear your opinion about that.

...

Finally we found the cause of all our problems: it's the origin hack in Cocoa_SetWindowFullscreen:

/* Hack to fix origin on Mac OS X 10.4 */
NSRect screenRect = [[nswindow screen] frame];
if (screenRect.size.height >= 1.0f) {
rect.origin.y += (screenRect.size.height - rect.size.height);
}

If we comment this one out our game and testdraw2 do behave correctly.

It turns out that if a window is not fully contained in the screen, it's screen property becomes zero and therefore we saw a zero when printing the backing scale factor (although it's not clear why it became nonzero later).

We suggest to add a runtime check which skips this code for 10.15 (or possibly earlier if you happen to know that the hack is not needed for certain older versions).

More info: consider the line

NSRect screenRect = [[nswindow screen] frame];

in Cocoa_SetWindowFullscreen. We found that this rect has the dimensions of the desktop
on our OS X 10.15 setup. This is true both for the success case and the fail case. It seems as the success case is actually a fail case in disguise.

On the other Mac with OS X 10.14 the same rect has the dimension of the newly created screen. This is what I would expect, because at that time the window has already been created successfully and there should be a newly created screen associated to the window.

What are the cases in which the whole origin conversion code for the fullscreen case is supposed to have a non-trivial result?

Today we found that if we print the dimensions of [nswindow screen] later, then we find them to be correct. So the conclusion seems to be that OS X 10.15 does indeed do the window/screen setup more async than before and that the origin correction code uses the [nswindow screen] at a time where the window/screen setup isn't finalized yet.

Tue, 11 Feb 2020 10:08:22 -0800Fixed bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work
Sam Lantinga [Tue, 11 Feb 2020 10:08:22 -0800] rev 13506
Fixed bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work

The problem here was calling ClipCursor() continuously in a tight loop. Fixed by only calling ClipCursor() if the clip area needs to be updated.

Tue, 11 Feb 2020 09:41:55 -0800Don't add a frame to borderless windows.
Sam Lantinga [Tue, 11 Feb 2020 09:41:55 -0800] rev 13505
Don't add a frame to borderless windows.
It was done to allow hotkey resizing of borderless windows, but Windows will sometimes draw it, regardless of our WM_* message handling. See bug 4466 for more details.

Tue, 11 Feb 2020 08:36:13 -0800Fixed bug 4709 - incorrect (not) handling of windows on-screen cursor keys
Sam Lantinga [Tue, 11 Feb 2020 08:36:13 -0800] rev 13504
Fixed bug 4709 - incorrect (not) handling of windows on-screen cursor keys

Alex Denisov

When using Win10 on-screen keyboard (tooltip.exe), the left and right cursor keys in it do not produce SDLK_LEFT and SDLK_RIGHT events.

Windows messages generated by the on-screen keyboard, for some reason, have their scancodes set to zeroes. Here is the log from Spy++:

WM_KEYDOWN nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
WM_KEYUP nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1

Regular physical keyboard produces VK_LEFT (ScanCode:4B) and VK_RIGHT (ScanCode:4D) which are interpreted correctly.

With on-screen keyboard, the switch statement in VKeytoScancode() does not check for VK_LEFT and VK_RIGHT, returning SDL_SCANCODE_UNKNOWN, which in turn does not get mapped to anything (because the scan codes are zeroes).

Tue, 11 Feb 2020 08:26:46 -0800Make it possible for the application to use different C runtime begin/end thread functions
Sam Lantinga [Tue, 11 Feb 2020 08:26:46 -0800] rev 13503
Make it possible for the application to use different C runtime begin/end thread functions

Tue, 11 Feb 2020 08:01:44 -0800Make sure SDL_CreateThread has the same signature regardless of how the DLL was created.
Sam Lantinga [Tue, 11 Feb 2020 08:01:44 -0800] rev 13502
Make sure SDL_CreateThread has the same signature regardless of how the DLL was created.

Mon, 10 Feb 2020 23:48:06 -0500wayland: Fix building with -fno-common (which is now the default in GCC 10).
Ryan C. Gordon [Mon, 10 Feb 2020 23:48:06 -0500] rev 13501
wayland: Fix building with -fno-common (which is now the default in GCC 10).

Fixes Bugzilla #4957.