Fri, 19 Jun 2015 23:40:23 -0700 Android has clock_gettime() - thanks Michael Labbe!
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 23:40:23 -0700] rev 9766
Android has clock_gettime() - thanks Michael Labbe!
Fri, 19 Jun 2015 23:32:37 -0700 Cleaned up Xcode rules a little more
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 23:32:37 -0700] rev 9765
Cleaned up Xcode rules a little more
Fri, 19 Jun 2015 23:27:35 -0700 Simplified Mercurial ignore rules for Xcode build products
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 23:27:35 -0700] rev 9764
Simplified Mercurial ignore rules for Xcode build products
Fri, 19 Jun 2015 23:22:53 -0700 Fixed bug 2538 - SDL_SetTextureAlphaMod does not work with SDL_FlipMode or rotation in the software renderer
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 23:22:53 -0700] rev 9763
Fixed bug 2538 - SDL_SetTextureAlphaMod does not work with SDL_FlipMode or rotation in the software renderer Adam M. When setting a texture alpha mod other than 255 and also specifying a flip mode in the software renderer, the rendering fails. When the texture has an alpha channel, it becomes invisible when flipped. When the texture does not have an alpha channel, it is flipped but the colors are wrong: the alpha mod makes the texture darker rather than more translucent. 0) Initialize a software renderer. 1) Load 16-bit 565 or 32-bit texture. 2) Set texture blend mode to BLEND. 3) Set texture alpha mod to 150. 4) Draw the texture flipped horizontally and/or vertically.
Fri, 19 Jun 2015 23:20:43 -0700 Fixed bug 1550 - SDL_RenderCopy/CopyEx in software should optionally render 8bit alpha
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 23:20:43 -0700] rev 9762
Fixed bug 1550 - SDL_RenderCopy/CopyEx in software should optionally render 8bit alpha Adam M. There are three problems in the code that I see. 1. SW_RenderCopyEx enables a color key on surface_scaled even if the source surface didn't have a color key. 2. SW_RenderCopyEx doesn't copy blend mode, color mod, or alpha mod from src to surface_scaled. 3. When SDL_BlitScaled(src, srcrect, surface_scaled, &tmp_rect) is called, it blends the src pixels into surface_scaled instead of overwriting them (if src has blending, etc. enabled). I've attached a patch that 1) fixes the three problems that I mentioned, 2) adds the requested performance improvement of using the regular blit function if no rotation or flipping is needed, 3) avoids cloning the source surface if no stretching is required, and simplifies the rotation code slightly.
Fri, 19 Jun 2015 23:12:13 -0700 Fixed 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 +0200 Added 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 -0400 CMake 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 -0300 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.
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.
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 tip