Sat, 12 Aug 2017 16:44:00 -0700Fixed bug 3058 - Slight mistake in GetWindowStyle in SDL_windowswindow.c
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 16:44:00 -0700] rev 11251
Fixed bug 3058 - Slight mistake in GetWindowStyle in SDL_windowswindow.c

Coriiander

There's a slight mistake in the function "GetWindowStyle" found in file "SDL_windowswindow.c".

When a window is marked to be resizable, the resizable style is being added regardless of whether the window has a border or not. While for some arcane, hidden semantics this can be ok, it's still inconsistent in this case.

Sat, 12 Aug 2017 16:02:33 -0700Fixed bug 3158 - SDL display window scrambled over VNC
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 16:02:33 -0700] rev 11250
Fixed bug 3158 - SDL display window scrambled over VNC

Witek Jachimczyk

I'm using SDL to develop a video viewer for MATLAB. The window is scrambled while using thightVNC with its default mode of RGB656.

SDL does not correctly recognize the pixel mode.


I found a solution for this problem. The solution involves modifying
SDL/src/video/SDL_pixels.c

Adding the following "if statement" under case 16: of SDL_MasksToPixelFormatEnum resolves the issue:

if (Rmask == 0x003F &&
Gmask == 0x07C0 &&
Bmask == 0xF800 &&
Amask == 0x0000) {
return SDL_PIXELFORMAT_RGB565;
}

I hope that this helps someone. I took me a while to figure it out.

Sat, 12 Aug 2017 15:55:54 -0700Fixed bug 3173 - SDL_GL_GetAttribute overwrites error code from SDL_GL_GetProcAddress
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:55:54 -0700] rev 11249
Fixed bug 3173 - SDL_GL_GetAttribute overwrites error code from SDL_GL_GetProcAddress

Yann Dirson

When SDL_GL_GetProcAddress returns in error, the cause of the error is overwritten
in GL_GL_GetAttribute, reporting to the user "Failed getting OpenGL glGetString entry point", whereas the original "OpenGL library not loaded" never makes it
to the user.

Pushed a fix to:
https://github.com/O-Computers/SDL/commit/f94cb13708ef4d236f8a2a330135b9b3a47db204


Note that the "OpenGL library not loaded" error looks like no root cause either,
and I'm still puzzled by the code path used: I'm forcing opengles2 renderer on
the x11 video driver on a rpi2, as in https://bugzilla.libsdl.org/3169, and although I now know that I must force the use of the RPI video driver instead
of the x11 one, I suspect even more accurate info can be given to user.

Sat, 12 Aug 2017 15:45:46 -0700Added a note about number key keycodes always being SDLK_0...SDLK_9 even on AZERTY layouts
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:45:46 -0700] rev 11248
Added a note about number key keycodes always being SDLK_0...SDLK_9 even on AZERTY layouts
See bug 3188 for more discussion

Sat, 12 Aug 2017 15:41:03 -0700Fixed bug 3188 - AZERTY keyboard support broken and inconsistent
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:41:03 -0700] rev 11247
Fixed bug 3188 - AZERTY keyboard support broken and inconsistent

Daniel Gibson

AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ², &, é", ', (, -, è_, çà), = (with small differences between the France and Belgian variants). Numbers are reached via shift.

On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ç232 for ètc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY.
I don't know how other platforms behave.

So we have two problems:
1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned
2. Different platforms behave differently (Windows vs Linux/OSX)

It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)?
Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes?

This bug on the mailing list:
https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows)
https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).

Sat, 12 Aug 2017 15:21:26 -0700Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:21:26 -0700] rev 11246
Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey

Sylvain

Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation.
When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255).

I think SDL_ConvertSurface should strictly keeps the input format.


example
=======

SDL_Surface *input; // ... Set up a surface with ColorKey and no AlphaMod

SDL_Surface *output = SDL_ConvertSurface(input, input->format, input->flags);

// "output" surface has a ColorKey but *also* AlphaMod (BLEND, and Opaque 255).

Sat, 12 Aug 2017 15:00:33 -0700Fixed bug 3208 - Minor improvements to the configure script
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:00:33 -0700] rev 11245
Fixed bug 3208 - Minor improvements to the configure script

Rafal Muzylo

"if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)

Sat, 12 Aug 2017 13:05:26 -0700Note that texture contents are undefined when the texture is created.
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 13:05:26 -0700] rev 11244
Note that texture contents are undefined when the texture is created.

Sat, 12 Aug 2017 12:59:22 -0700Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:59:22 -0700] rev 11243
Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0

Simon Hug

The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white.

The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.

Sat, 12 Aug 2017 12:56:28 -0700Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:56:28 -0700] rev 11242
Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.