Sat, 20 Jun 2015 11:15:37 +0200 Added missing file and folder to the release archive.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Sat, 20 Jun 2015 11:15:37 +0200] rev 9770
Added missing file and folder to the release archive.
Sat, 20 Jun 2015 00:25:28 -0700 Added the docs directory to the release archive
Sam Lantinga <slouken@libsdl.org> [Sat, 20 Jun 2015 00:25:28 -0700] rev 9769
Added the docs directory to the release archive
Fri, 19 Jun 2015 23:53:33 -0700 GCC is warning about global functions with the same name as variables in the code, when using -Wshadow.
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 23:53:33 -0700] rev 9768
GCC is warning about global functions with the same name as variables in the code, when using -Wshadow. This is a little ridiculous because we have no idea what functions a given platform will provide, so we'll disable -Wshadow for now.
Fri, 19 Jun 2015 23:49:00 -0700 Use CLOCK_MONOTONIC_RAW, if available, which is not subject to adjustment by NTP
Sam Lantinga <slouken@libsdl.org> [Fri, 19 Jun 2015 23:49:00 -0700] rev 9767
Use CLOCK_MONOTONIC_RAW, if available, which is not subject to adjustment by NTP
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 */
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 tip