Fri, 19 Jun 2015 23:12:13 -0700Fixed bug 3023 - setting a white and then non-white texture color mod breaks the texture with software renderer
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 23:12:13 -0700] rev 9761
Fixed bug 3023 - setting a white and then non-white texture color mod breaks the texture with software renderer

Adam M.

Okay, here is the problem, I think.

During the first blit, RLEAlphaSurface is called to do RLE conversion of the RGBA source into a format allowing it "to be quickly alpha-blittable onto dest". Since the destination is the screen, it has no alpha channel. RLEAlphaSurface calls copy_opaque(dst, src + runstart, len, sf, df) (where copy_opaque is copy_32), which has this code:

SDL_RLEaccel.c:984:
RGBA_FROM_8888(*src, sfmt, r, g, b, a);
PIXEL_FROM_RGBA(*d, dfmt, r, g, b, a);

On the first line, it reads the source pixel 0xFFFFFFFF. The second line drops the alpha value (because dfmt for the screen has no alpha channel) and writes 0x00FFFFFF. Later, when the RLE conversion is being undone, uncopy_32 is called, which has the following code:

SDL_RLEaccel.c:1001:
Uint32 pixel = *s++;
RGB_FROM_PIXEL(pixel, sfmt, r, g, b);
a = pixel >> 24;
PIXEL_FROM_RGBA(*dst, dfmt, r, g, b, a);

However, the the alpha channel has already been dropped by copy_opaque (= copy_32), so pixel = 0x00FFFFFF and 'a' becomes 0. Thus, all opaque pixels lose their alpha channel when being unRLE'd. (I don't know what happens to pixels with alpha from 1-254, but they should be checked too.)

So, that seems to be the problem, but I'm not sure what the solution should be. Since opaque pixels have alpha == 255, I'm thinking to create another uncopy function for opaque pixels that simply uses 255 for alpha.

However, there may be other problems here. For translucent pixels, uncopy_32 assumes the alpha channel is stored in the upper 8 bits, but copy_32 doesn't store it there. Instead, it stores it in whatever location is appropriate for the destination surface. Isn't one of their behaviors incorrect, given the other? I'm not sure which to change, however.

For translucent pixels, it seems that the blit function uses do_blend, which is the BLIT_TRANSL_888 macro, which also assumes alpha is in top 8 bits. It has the comment "we have made sure the alpha is stored in the top 8 bits...", but it seems that's not true (copy_32 doesn't make sure the alpha goes there).

Perhaps the correct fix is to make copy_32 put the alpha there, but then that seems to require that RLE conversion be limited to destination surfaces that don't use the upper 8 bits. However, looking further, it seems that has already been done: if (masksum != 0x00ffffff) return -1; /* requires unused high byte */

Fri, 19 Jun 2015 22:12:47 -0700[mq]: 3027_rleperf.diff
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 22:12:47 -0700] rev 9760
[mq]: 3027_rleperf.diff

Fri, 19 Jun 2015 21:17:00 +0200Added more entries and brackets to WhatsNew.txt for 2.0.4.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Fri, 19 Jun 2015 21:17:00 +0200] rev 9759
Added more entries and brackets to WhatsNew.txt for 2.0.4.

Thu, 18 Jun 2015 22:34:39 -0400CMake fixes for MingW (thanks, Ozkan!).
Ryan C. Gordon <icculus@icculus.org> [Thu, 18 Jun 2015 22:34:39 -0400] rev 9758
CMake fixes for MingW (thanks, Ozkan!).

- ignore DXSDK_DIR for mingw environment
- use dxerr8 instead of dxerr for mingw.

Partially fixes Bugzilla #3016.

Thu, 18 Jun 2015 12:20:46 -0300Updated WhatsNew.txt's 2.0.4 list to include a more detailed set of changes for iOS, and added a couple missing items to the OS X and Windows sections.
Alex Szpakowski <slime73@gmail.com> [Thu, 18 Jun 2015 12:20:46 -0300] rev 9757
Updated WhatsNew.txt's 2.0.4 list to include a more detailed set of changes for iOS, and added a couple missing items to the OS X and Windows sections.

Thu, 18 Jun 2015 00:44:57 -0400Moving some whitespace around to test something on the Mercurial server.
Ryan C. Gordon <icculus@icculus.org> [Thu, 18 Jun 2015 00:44:57 -0400] rev 9756
Moving some whitespace around to test something on the Mercurial server.

Wed, 17 Jun 2015 21:05:25 +0200Android: Fixed two warnings.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Wed, 17 Jun 2015 21:05:25 +0200] rev 9755
Android: Fixed two warnings.

Wed, 17 Jun 2015 13:02:41 -0400Whitespace fix.
Ryan C. Gordon <icculus@icculus.org> [Wed, 17 Jun 2015 13:02:41 -0400] rev 9754
Whitespace fix.

Wed, 17 Jun 2015 12:59:12 -0400Removed Edgar's name from SDL_haptic.h at his request.
Ryan C. Gordon <icculus@icculus.org> [Wed, 17 Jun 2015 12:59:12 -0400] rev 9753
Removed Edgar's name from SDL_haptic.h at his request.

Wed, 17 Jun 2015 00:07:45 -0700Partial fix for bug 2758 - Android issues with NDK r10c and API-21
Sam Lantinga <slouken@libsdl.org> [Wed, 17 Jun 2015 00:07:45 -0700] rev 9752
Partial fix for bug 2758 - Android issues with NDK r10c and API-21

Sylvain

When using API 21 and running on an old device (android < 5.0 ?) some function are missing.

functions are (at least) : signal, sigemptyset, atof, stpcpy (strcat and strcpy), srand, rand.


Very few modifications on SDL to get this working :

on SDL
======

Undefine android configuration :

HAVE_SIGNAL
HAVE_SIGACTION
HAVE_ATOF

In "SDL_systrhead.c", comment out the few block of lines with "sigemptyset".

Android.mk:
remove the compilation of "test" directory because it contains a few rand/srand calls

Also, there are more discussions about this in internet :
https://groups.google.com/forum/#!topic/android-ndk/RjO9WmG9pfE
http://stackoverflow.com/questions/25475055/android-ndk-load-library-cannot-locate-srand