Sat, 01 Oct 2016 11:48:15 -0700Fixed bug 3338 - console_wmain doesn't null terminate the argv array
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 11:48:15 -0700] rev 10409
Fixed bug 3338 - console_wmain doesn't null terminate the argv array

Simon Hug

The function console_wmain in src/main/windows/SDL_windows_main.c does not null terminate the argument list it is creating. As specified by the C standard, "argv[argc] shall be a null pointer."

The SDLTest framework makes use of that null pointer and some test programs can cause an access violation because it's missing.

Sat, 01 Oct 2016 11:46:32 -0700Fixed bug 3345 - SDL_RenderClear inconsistency with ClipRect
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 11:46:32 -0700] rev 10408
Fixed bug 3345 - SDL_RenderClear inconsistency with ClipRect

Simon Hug

The description of the SDL_RenderClear function in the SDL_render.h header says the following:

"This function clears the entire rendering target, ignoring the viewport."

The word "entire" implies that the clipping rectangle set with SDL_RenderSetClipRect also gets ignored. This is left somewhat ambiguous if only the viewport is mentioned. Minor thing, but let's see what the implementations actually do.

The software renderer ignores the clipping rectangle when clearing. It even has a comment on this: /* By definition the clear ignores the clip rect */

Most other render drivers (opengl, opengles, opengles2, direct3d, and psp [I assume. Can't test it.]) use the scissor test for the ClipRect and don't disable it when clearing. Clearing will only happen within the clipping rectangle for these drivers.

An exception is direct3d11 which uses a clear function that ignores the scissor test.

Sat, 01 Oct 2016 11:40:57 -0700Fixed bug 3347 - OpenGL ES renderer doesn't flip projection matrix for target textures
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 11:40:57 -0700] rev 10407
Fixed bug 3347 - OpenGL ES renderer doesn't flip projection matrix for target textures

Simon Hug

When updating the viewport in GLES_UpdateViewport, the OpenGL ES renderer doesn't flip the projection matrix for target textures. The lines, rectangles and textures (if drawn with glDrawArrays) are upside down when drawing to target textures.

Sat, 01 Oct 2016 11:38:53 -0700Fixed bug 3349 - GLES2_RenderReadPixels doesn't use target texture format
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 11:38:53 -0700] rev 10406
Fixed bug 3349 - GLES2_RenderReadPixels doesn't use target texture format

Simon Hug

The OpenGL ES 2 renderer does not check the target texture format when using SDL_RenderReadPixels and just always uses ABGR8888. This can result in swapped or wrong colors.

The attached patch adds a check and selects the target texture format, if a texture is set as the target.

Sat, 01 Oct 2016 11:34:04 -0700Fixed bug 3350 - GL renderers don't need to flip rows after reading back pixels from the target texture
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 11:34:04 -0700] rev 10405
Fixed bug 3350 - GL renderers don't need to flip rows after reading back pixels from the target texture

Simon Hug

All OpenGL renderers always flip the rows of the pixels that come from glReadPixels. This is unnecessary for target textures since these are already top down.

Also, the rect->y value can be used directly for target textures for the same reason. I don't see any code that would handle the logical render size for target textures. Or am I missing something?

The attached patch makes the renderers only the flip rows if the data comes from the default framebuffer.

Sat, 01 Oct 2016 11:29:13 -0700Fixed bug 3352 - Adding alpha mask support to SDL_SaveBMP_RW
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 11:29:13 -0700] rev 10404
Fixed bug 3352 - Adding alpha mask support to SDL_SaveBMP_RW

Simon Hug

The current SDL_SaveBMP_RW function that saves surfaces to a BMP uses an old bitmap header which doesn't officially support alpha channels. Applications just ignore the byte where the alpha is stored. This can easily be extended by using a newer header version and setting the alpha mask.

The attached patch has these changes:

- Extending the description of the function in the SDL_surface.h header with the supported formats.
- Refining when surfaces get stored to a 32-bit BMP. (Must have bit depth of 8 or higher and must have an alpha mask or colorkey.)
- Fixing a small bug that saves 24-bit BGR surfaces with a colorkey in a 24-bit BMP.
- Adding code that switches to the bitmap header version 4 if the surface has an alpha mask or colorkey. (I chose version 4 because Microsoft didn't lose its documentation behind a file cabinet like they did with version 3.)
- Adding a hint that can disable the use of the version 4 header. This is for people that need the legacy header or like the old behavior better. (I'm not sure about the hint name, though. May need changing if there are any rules to that.)

Sat, 01 Oct 2016 11:22:39 -0700Only use GCC pragmas when we're building with GCC
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 11:22:39 -0700] rev 10403
Only use GCC pragmas when we're building with GCC

Sat, 01 Oct 2016 11:04:45 -0700Fixed bug 3361 - Texture color modulation doesn't work with active NONE blend mode (opengl and opengles)
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 11:04:45 -0700] rev 10402
Fixed bug 3361 - Texture color modulation doesn't work with active NONE blend mode (opengl and opengles)

Simon Hug

The GL_SetBlendMode and GLES_SetBlendMode functions of the opengl and opengles renderers call the glTexEnvf to set the texture env mode to either GL_MODULATE (the default) or GL_REPLACE for the NONE blend mode. Using GL_REPLACE disables color and alpha modulation for textures.

These glTexEnv calls were put in the SetBlendMode function back in 2006 [1], but there the NONE code still used the GL_DECAL mode. The GL_REPLACE mode came in 2008 [2]. I'm a bit confused why that wasn't always GL_MODULATE and a bit surprised nobody reported that yet (unless I missed it). I guess only a few use the gles renderer and the newish shaders mask the issue.

Sat, 01 Oct 2016 10:52:24 -0700Fixed bug 3362 - OpenGL renderer doesn't check if framebuffers are supported when creating target textures
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 10:52:24 -0700] rev 10401
Fixed bug 3362 - OpenGL renderer doesn't check if framebuffers are supported when creating target textures

Simon Hug

The GL_CreateTexture function doesn't have any checks for the case where the driver doesn't support the framebuffer object extension. It will call into GL_GetFBO which will call the non-existent glGenFramebuffersEXT.

Also, for some reason GL_CreateContext always sets the SDL_RENDERER_TARGETTEXTURE info flag, even if it is not supported. Changeset 6e6bd53feff0 [1] makes this change, but doesn't explain why. It seems to me like the code would already have taken care of this [2].

The attached patch adds some checks and stops SDL from reporting render target support if there is none. The application can then properly inform the user instead of just crashing.

Sat, 01 Oct 2016 10:46:10 -0700Fixed bug 3368 - SDL_Blit_Slow doesn't ignore alpha values in colorkey comparison
Sam Lantinga <slouken@libsdl.org> [Sat, 01 Oct 2016 10:46:10 -0700] rev 10400
Fixed bug 3368 - SDL_Blit_Slow doesn't ignore alpha values in colorkey comparison

Simon Hug

When the SDL_Blit_Slow function compares the pixel to the color key it does so without removing the alpha component from the pixel value and the key. This is different from the optimized 32-bit blitters which create a rgb mask and apply it to both to filter the alpha out. SDL_Blit_Slow will only skip the pixels with the exact alpha value of the key instead of all pixels with the same color.

The attached test case blits a surface with a color key and prints the pixel values to the console. The third row is expected to be skipped.