Tue, 15 Nov 2016 01:30:08 -0800Fixed bug 1646 - Warnings from clang with -Weverything
Sam Lantinga <slouken@libsdl.org> [Tue, 15 Nov 2016 01:30:08 -0800] rev 10616
Fixed bug 1646 - Warnings from clang with -Weverything

Tue, 15 Nov 2016 01:24:58 -0800Removed unused constants
Sam Lantinga <slouken@libsdl.org> [Tue, 15 Nov 2016 01:24:58 -0800] rev 10615
Removed unused constants
Except for SDL_bmp.c where they are historically interesting and I've left them in.

Sun, 13 Nov 2016 10:39:04 +0100[qtwayland] Set orientation and window flags via SDL hints
Thomas Perl <m@thp.io> [Sun, 13 Nov 2016 10:39:04 +0100] rev 10614
[qtwayland] Set orientation and window flags via SDL hints

Tue, 15 Nov 2016 01:14:30 -0800Fixed bug 3490 - Build failure with --enable-video-directfb
Sam Lantinga <slouken@libsdl.org> [Tue, 15 Nov 2016 01:14:30 -0800] rev 10613
Fixed bug 3490 - Build failure with --enable-video-directfb

felix

Building SDL 2.0.5, or even the Mercurial snapshot (r10608) with GCC 6.2.1 and --enable-video-directfb generates a number of compiler diagnostics and fails.

Tue, 15 Nov 2016 01:12:27 -0800Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx
Sam Lantinga <slouken@libsdl.org> [Tue, 15 Nov 2016 01:12:27 -0800] rev 10612
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx

Simon Hug

The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.)

Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient.

The following blend modes have issues when drawn at an angle.

NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode.

MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations.

BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is.

This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function.

There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers.

The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode...

It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster?

As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode.

I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.

Sun, 13 Nov 2016 23:09:42 -0800Fixed build error with missing function prototype in the SDL_test_harness.h header
Sam Lantinga <slouken@libsdl.org> [Sun, 13 Nov 2016 23:09:42 -0800] rev 10611
Fixed build error with missing function prototype in the SDL_test_harness.h header

Sun, 13 Nov 2016 23:04:47 -0800Fixed unresolved symbol on Visual Studio
Sam Lantinga <slouken@libsdl.org> [Sun, 13 Nov 2016 23:04:47 -0800] rev 10610
Fixed unresolved symbol on Visual Studio

Sun, 13 Nov 2016 22:57:41 -0800Patch from Sylvain to fix clang warnings
Sam Lantinga <slouken@libsdl.org> [Sun, 13 Nov 2016 22:57:41 -0800] rev 10609
Patch from Sylvain to fix clang warnings

Sun, 13 Nov 2016 00:09:02 -0800Fixed bug 3488 - Random crashes (because Memory overlap in audio converters detected by Valgrind)
Sam Lantinga <slouken@libsdl.org> [Sun, 13 Nov 2016 00:09:02 -0800] rev 10608
Fixed bug 3488 - Random crashes (because Memory overlap in audio converters detected by Valgrind)

Vitaly Novichkov

Okay, when I researched code and algorithm, I tried to replace condition "while(dst >= target)" with "while(dst > target)" and crashes are gone.
Seems on some moments it tries to write into the place before memory block begin, therefore phantom crashes appearing after some moments.

Fri, 11 Nov 2016 13:47:40 -0800Fixed build on various platforms
Sam Lantinga <slouken@libsdl.org> [Fri, 11 Nov 2016 13:47:40 -0800] rev 10607
Fixed build on various platforms