kmx git

Commit	Date	Message
36ba9248	2017-08-14T10:04:59	Fixed setting the texture blend mode in the OpenGL ES2 renderer
c59d9923	2017-08-14T05:51:44	Implemented more flexible blending modes for accelerated renderers This fixes bug 2594 - Propose new blend mode, SDL_BLENDMODE_BLEND_DSTA blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD, SDL_BLENDFACTOR_ZERO, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_ADD); This fixes bug 2828 - Subtractive Blending blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_SUBTRACT, SDL_BLENDFACTOR_ZERO, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_SUBTRACT); This goes partway to fixing bug 3684 - Add support for a pre-multiplied alpha blending mode blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_ONE, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD, SDL_BLENDFACTOR_ONE, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD);
f8e1874d	2017-08-13T22:50:23	Fixed bug 2646 - Problems with software renderer when SDL_SetRenderLogicalSize set Fixed setting the software renderer clip rectangle when a viewport is set
7af3786d	2017-08-13T21:55:42	Fixed bug 2755 - SDL2 fails to build on Solaris 10 u3 UX-admin I am compiling with the Sun Studio 12 u2 compiler. There are multiple issues with the build, but this particular issue appears to be that it is illegal to declare a union of a struct of floats and a float. While GCC 4.8.1 does not flag this as an error, Sun Studio is much more standards compliant and strict, halting further compilation with an error.
ca5c3048	2017-08-13T21:06:52	Fixed bug 3744 - missing SDLCALL in several functions Ozkan Sezer The attached patch adds missing SDLCALL to several functions, so that they properly match the headers as intended.
af9ec8f6	2017-08-13T20:13:11	Fixed copy-paste error, thanks Alen!
6f843b90	2017-08-12T12:59:22	Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0 Simon Hug The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white. The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.
4c239e55	2017-08-11T20:54:06	Fixed bug 3297 - Horizontal and Vertical flip swapped on PSP Littlefighter19 When trying to mirror something on the PSP, I've stumbled upon the problem, that using SDL_RenderCopyEx with SDL_FLIP_HORIZONTAL flips the image vertically, vise-versa SDL_FLIP_VERTICAL flips the image horizontally. Proposed patch would be swapping the check in line 944 with the one in line 948 in SDL_render_psp.c
6de66e98	2017-08-11T11:54:24	Fixed bug 3324 - SDL_RenderReadPixels: Wrong rect coordinates with software renderer Daniel SDL_RenderReadPixels with SDL_RENDERER_SOFTWARE reads pixels from wrong coordinates. SW_RenderReadPixels adjusts the rect coordinates according to the viewport. But since this is already done by SDL_RenderReadPixels, the final rect has x2 bigger X and Y.
ef54d5a8	2017-08-07T10:28:59	Fixed building on various versions of GCC - YUV MMX code is disabled for now
8aa147fa	2017-08-04T23:00:30	Fixed compiler warnings about type conversions. Found by buildbot.
9dbe5a96	2017-08-02T13:38:46	Fixed bug 3311 - Broken touch positions with SDL_RenderSetLogicalSize & HIGHDPI on iOS Eric wing Hi, I think I found a bug when using SDL_WINDOW_ALLOW_HIGHDPI with SDL_RenderSetLogicalSize on iOS. I use SDL_RenderSetLogicalSize for all my stuff. I just tried turning on SDL_WINDOW_ALLOW_HIGHDPI on iOS and suddenly all my touch/mouse positions are really broken/far-off-the-mark. I actually don't have a real retina device (still) so I'm seeing this using the iOS simulator with a 6plus template. Attached is a simple test program that can reproduce the problem. It uses RenderSetLogicalSize and draws some moving happy faces (to show the boundaries/space of the LogicalSize and that it is working correctly for that part). When you click/touch, it will draw one more happy face where your button point is. If you comment out SDL_WINDOW_ALLOW_HIGHDPI, everything works as expected. But if you compile with it in, the mouse coordinates seem really far off the mark. (Face appears far up and to the left.) Alex Szpakowski on the mailing list suggests the problem is "I believe this is a bug in SDL_Render?s platform-agnostic mouse coordinate scaling code. It assumes the units of the mouse coordinates are always in pixels, which isn?t the case where high-DPI is involved (regardless of whether iOS is used) ? they?re actually in ?DPI independent? coordinates (which matches the window size, but not the renderer output size)." Additionally, if this is correct, the Mac under Retina is also probably affected too and "as well as any other platform SDL adds high-dpi support for in the future".
18f2b27b	2017-07-26T13:54:11	Whoops, forgot to commit the actual fix. :)
7ecc48c3	2017-07-26T13:43:25	Disable MMX inline assembly on Clang for now. We should probably rewrite this with SSE compiler intrinsics or something anyhow.
36998b82	2017-07-20T10:48:57	Fixed bug 3689 - MMX YUV renderer crash felix The functions in src/render/SDL_yuv_mmx.c contain the following inline assembly snippet: /* tap dance to workaround the inability to use %%ebx at will... / / move one thing to the stack... / "pushl $0\n" / save a slot on the stack. / "pushl %%ebx\n" / save %%ebx. / "movl %0, %%ebx\n" / put the thing in ebx. / "movl %%ebx,4(%%esp)\n" / put the thing in the stack slot. / "popl %%ebx\n" / get back %%ebx (the PIC register). */ Here's how it ended up in a binary on my old laptop: 0xb5c17dbd <ColorRGBDitherYV12MMX1X+93>: push $0x0 0xb5c17dbf <ColorRGBDitherYV12MMX1X+95>: push %ebx 0xb5c17dc0 <ColorRGBDitherYV12MMX1X+96>: mov 0xc(%esp),%ebx 0xb5c17dc4 <ColorRGBDitherYV12MMX1X+100>: mov %ebx,0x4(%esp) 0xb5c17dc8 <ColorRGBDitherYV12MMX1X+104>: pop %ebx Apparently the compiler, oblivious to the fact that the assembly snippet manipulates the %esp register, decided to refer to the operand via that same register instead of via %ebp (I believe -fomit-frame-pointer enables this). This causes %ebx to be loaded with the wrong value, which later leads to a null pointer dereference. Recent GCC can use the %ebx register normally: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602#c16>. There is even an explicit constraint "b" for allocating it.
92889836	2017-06-06T14:06:40	Merged Eric Wing's overscan patch. Fixes Bugzilla #2799.
63b3e06f	2017-06-03T23:00:15	Corrected names of header file guards.
02773811	2017-05-18T21:00:11	render: GL_DestroyRender() should activate first. Otherwise, we might destroy a different GL context's resources.
266816b4	2017-03-26T21:00:19	Removed newlines from error messages.
ca0bf151	2017-03-03T16:38:17	Fix some more compiler warnings on armcc.
07519a6b	2017-02-26T00:40:04	Removed a bunch of unnecessary #ifdefs.
b13c443c	2017-02-24T20:49:14	WinRT: removed buildbot debug code, pending further research
f7bfa3b7	2017-02-24T20:19:28	WinRT: more buildbot debug code
ecb1eb82	2017-02-24T19:59:57	WinRT: added code to help debug a buildbot error
13433c4a	2017-01-27T21:23:27	Fixed bug 3569 - GL_UpdateViewport leaves PROJECTION matrix selected Tom Seddon GL_ActivateRenderer may call GL_UpdateViewport, which leaves the GL_PROJECTION matrix selected. But after GL_ResetState, the GL_MODELVIEW matrix is selected, suggesting that's the intended default state. It seems at least like these should be consistent. Presumably GL_UpdateViewport should be doing a glMatrixMode(GL_MODELVIEW) before it finishes.
9d9e92cf	2017-01-08T10:41:22	Fixed bug 3304 - Android black screen on resume Richard Russell Resuming from a suspended state results in a black screen. This only happens when using GLES 1.1 (GLES 2 resumes correctly) and when the render target has been changed using SDL_SetRenderTarget. This problem is new in 2.0.4. The attached test case demonstrates the issue. Sylvain Becker has apparently found a fix as follows: "In the opengles leaf function (in 'src/render/opengles/SDL_render_gles.c'), it appears there is a call to 'GLES_ActivateRenderer' in 'GLES_SetRenderTarget', which is not present in opengles2. When commenting out this 'GLES_ActivateRenderer', it seems to resume fine". This appears to fix the testcase perfectly, but I don't know whether it could have any undesirable side-effects.
c1ac4c68	2017-01-06T21:17:33	Better fix for static analysis issue in SDL_DestroyRenderer(). Follow up fix for Bugzilla #3544.
3df77ced	2017-01-06T00:40:22	Just roll back the entire portion of the commit from a8253d439914 which caused bug 3544 until we figure out what the right static analysis fix is.
356c2ead	2017-01-06T00:32:06	Fixed bug 3544 - Memory freeing bug in SDL_DestroyRenderer/SDL_DestroyTexture felix Here's a snippet of SDL_DestroyRenderer from hg revision 10746:7540ff5d0e0e: SDL_Texture texture = NULL; SDL_Texture nexttexture = NULL; /* ... */ for (texture = renderer->textures; texture; texture = nexttexture) { nexttexture = texture->next; SDL_DestroyTexture(texture); } SDL_DestroyTexture removes the texture from the linked list pointed to by the renderer and ends up calling SDL_DestroyTextureInternal, which contains this: if (texture->native) { SDL_DestroyTexture(texture->native); } If it happens that texture->native is an alias of nexttexture two stack frames up, SDL_DestroyRenderer will end up trying to destroy an already freed texture. I've had this very situation happen in dosemu2. Bug introduced in revision 10650:a8253d439914, which has a somewhat ironic description of "Fixed all known static analysis bugs"...
45b774e3	2017-01-01T18:33:28	Updated copyright for 2017
fb5fd67c	2016-11-24T21:41:09	Fixed all known static analysis bugs, with checker-279 on macOS.
e93e91f0	2016-11-23T21:52:48	Pacify some GCC strict-aliasing compiler warnings.
40c2a6fb	2016-11-23T11:49:26	Fixed more compiler warnings.
36156335	2016-11-20T21:34:54	Renaming of guard header names to quiet -Wreserved-id-macro Patch contributed by Sylvain
97aa5775	2016-11-16T22:08:51	Fixed empty parameter list in signatures of internal functions.
0d24495b	2016-11-15T01:24:58	Removed unused constants Except for SDL_bmp.c where they are historically interesting and I've left them in.
ab8bd3d9	2016-11-15T01:12:27	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.
57d01d7d	2016-11-13T22:57:41	Patch from Sylvain to fix clang warnings
77000ff8	2016-11-11T13:38:39	Fixed bug 1822 - Inconsistent renderer behaviour on rotation Sylvain 2016-11-07 08:49:34 UTC when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey. if you set a dummy colorkey, it will remove the line ... if you set a some alpha mod, the +90/-90 get transparent but not the 0/180 ...
057bca8a	2016-11-06T15:15:32	Better fix for last point in D3D11 renderer, thanks to Nader Golbaz
330e2952	2016-11-06T08:47:40	Fixed bug 2421 for D3D11 - SDL_RenderCopyEx off by one when rotating by 90 and -90. Nader Golbaz Updated patch for direct3d renderers
4ed4997c	2016-11-06T08:42:46	Fixed bug 2421 for D3D9 - SDL_RenderCopyEx off by one when rotating by 90 and -90 Nader Golbaz Updated patch for direct3d renderers
8e2634eb	2016-10-14T00:51:57	Fixed divide by zero if setting integer scale without setting logical width and height
662f966c	2016-10-13T08:46:34	Fixed bug 3355 - false "Invalid renderer" after creating an "opengles2" renderer. Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.
e4af8ce9	2016-10-13T04:57:31	Fixed typo getting the drawable size
36e40d30	2016-10-11T23:19:05	Fixed bug 2923 - Add SDL_PIXELFORMAT_RGBA32 for byte-wise 32bit RGBA data Daniel Gibson Ok, I followed the simple approach of just making SDL_PIXELFORMAT_RGBA32 an alias of SDL_PIXELFORMAT_RGBA8888/SDL_PIXELFORMAT_ABGR8888, depending on endianess. And I did the same for SDL_PIXELFORMAT_ARGB32, .._BGRA, .._ABGR. SDL_GetPixelFormatName() will of course return SDL_PIXELFORMAT_RGBA8888 (or SDL_PIXELFORMAT_ABGR8888) instead of SDL_PIXELFORMAT_RGBA32, but as long as that's mentioned in the docs it shouldn't be a problem.
564c790f	2016-10-11T17:31:29	Fixed a memory leak in function GL_RenderReadPixels
27d4f099	2016-10-07T23:40:44	Implemented SDL_GetHintBoolean() to make it easier to check boolean hints
9c483655	2016-10-07T18:00:30	Fixed bug 3029 - software renderer cuts off edges when rotate-blitting with a multiple of 90 degrees Adam M. When doing a rotated texture copy with the software renderer, where the angle is a multiple of 90 degrees, one or two edges of the image get cut off. This is because of the following line in sw_rotate.c: if ((unsigned)dx < (unsigned)sw && (unsigned)dy < (unsigned)sh) { which is effectively saying: if (dx >= 0 && dx < src->w-1 && dy >= 0 && dy < src->h-1) { As a result, it doesn't process pixels in the right column or bottom row of the source image (except when they're accessed as part of the bilinear filtering for nearby pixels). This causes it to look like the edges are cut off, and it's especially obvious with an exact multiple of 90 degrees.
bf076c22	2016-10-07T17:30:21	Fixed bug 2957 - De-reference rz_src without NULL check in SDLgfx_rotateSurface function Nitz In function SDLgfx_rotateSurface: rz_dst = SDL_CreateRGBSurface(SDL_SWSURFACE, dstwidth, dstheight + GUARD_ROWS, rz_src->format->Rmask, rz_src->format->Gmask, rz_src->format->Bmask, rz_src->format->Amask); Here rz_src get De-referenced without NULL check, which is risky.
67bf5cac	2016-10-02T22:32:35	Fixed wrong pixel format if reading pixels from OpenGL renderer.
969c3167	2016-10-01T18:49:15	Fixed MinGW-w64 build warnings in SDL_render_d3d11.c Some of these were legitimate bugs, including: - a malformed SDL_snprintf call - a probably-invalid enum comparison
702d9348	2016-10-01T15:23:43	Added SDL prefix to local IID constants
7851eb08	2016-10-01T18:10:15	Fixed bug 3437 - build error for WinRT/UWP .dlls, caused by fix for SDL bug 3336 This fix has been tested with both MinGW-w64, and Visual C++ 2012-2015.
fa0f4176	2016-10-01T14:48:18	Fixed build warnings and errors
c8cfccc2	2016-10-01T14:31:00	Fixed bug 3116 - renderer->hidden in SDL_RenderCopy(Ex) Daniel Seems like check of the visibility of renderer (renderer->hidden) is missing in SDL_RenderCopyEx. In SDL_RenderCopy it should be done much earlier (after checking support for RenderCopyEx, line 1750).
ecea3c4a	2016-10-01T13:33:32	Fixed bug 3169 - GLES2_CreateRenderer does not check SDL_GL_GetAttribute result, causing use of uninitialized data Yann Dirson When attempting to force use of opengles2 renderer with: int wanted_renderer = -1; for (int i = 0; i < numrenderers; i++) { SDL_RendererInfo renderer_info; if (SDL_GetRenderDriverInfo(i, &renderer_info) != 0) { SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't get renderer driver info: %s\n", SDL_GetError()); quit(2); } std::cerr << "Renderer " << i << " '" << renderer_info.name << "': flags=0x" << std::hex << renderer_info.flags << std::dec << ", " << renderer_info.num_texture_formats << " texture formats, max=" << renderer_info.max_texture_width << "x" << renderer_info.max_texture_height << "\n"; if (!strcmp(renderer_info.name, "opengles2")) { std::cerr << " selecting!\n"; wanted_renderer = i; } } renderer = SDL_CreateRenderer(window, wanted_renderer, 0); ... on banana pi or raspberry pi I get an error like the following (the actual context profile value varies, being used uninitialized) ERROR: Couldn't create renderer: Unknown OpenGL context profile 900 With this patch I get the following, which should help more pointing to a real problem: ERROR: Couldn't create renderer: Failed getting OpenGL glGetString entry point I pushed a patch (based on master branch of unofficial git mirror): https://github.com/O-Computers/SDL/commit/550389c89f4e73a0a5294f95b9f6e6c18ba48509 I'll be opening a different bug for the underlying issue.
67901f53	2016-10-01T13:29:30	Fixed bug 3174 - SDL_SetRenderTarget clip rect Marcel Bakker In SDL_SetRenderTarget(), i think the intended behavior was to clear the clip rect when a new target is set.
86b4319d	2016-10-01T13:07:36	Fixed bug 3422 - OpenGL ES 1.1 renderer: SDL_UpdateTexture breaks later function calls (missing glDisable) ny00 Using the OpenGL ES 1.1 renderer, after updating a texture with SDL_UpdateTexture (or SDL_UnlockTexture), a following call to SDL_RenderFillRect draws a rectangle with the wrong color (which appears to be the same as the texture's top-left pixel). Comparing SDL_render_gles.c:GLES_UpdateTexture to SDL_render_gl.c:GL_UpdateTexture, a missing call to glDisable appears to be the cause. After adding it back, the bug is resolved.
77305d47	2016-10-01T11:46:32	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.
89c868f4	2016-10-01T11:40:57	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.
061cc5e7	2016-10-01T11:38:53	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.
51d6371e	2016-10-01T11:34:04	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.
a42c396a	2016-10-01T11:04:45	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.
3f1b1629	2016-10-01T10:52:24	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 cc226dce7536 [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.
2ccb46ce	2016-10-01T10:43:01	Fixed bug 3373 - OpenGL implementation differences of glDrawTexfOES Simon Hug It seems not everyone implemented glDrawTexfOES the same. Intel and Mesa ignore the viewport entirely, whereas the Raspberry Pi implementation offsets the coordinates and does viewport clipping. The glDrawTexfOES extension text [1] for the function says "Xs and Ys are given directly in window (viewport) coordinates." I guess this wasn't clear enough. Alex Szpakowski Honestly I'd probably remove that codepath from SDL_Render entirely. It's an OpenGL ES 1-specific extension that isn't likely to give huge performance gains and adds additional maintenance overhead to SDL_Render while also having bugs in some drivers (as seen here).
b7e45f8a	2016-10-01T10:28:00	Fixed bug 3336 - Failure to build with MinGW-w64 Kai Sterker There are already patches available from mingw64 that fix the issue https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-SDL2 With those applied, I could compile SDL2 without problems. But of course, it would be preferable if SDL built cleanly from source.
86d4b099	2016-09-13T18:44:28	Fixed spacing
f0505766	2016-09-13T22:18:06	Initial Apple TV / tvOS support. The Apple TV remote is currently exposed as a joystick with its touch surface treated as two axes. Key presses are also generated when its buttons and touch surface are used. A new hint has been added to help deal with deciding whether to background the app when the remote's menu button is pressed: SDL_HINT_APPLE_TV_CONTROLLER_UI_EVENTS.
23af328b	2016-06-24T22:17:56	Fixed Bug 3147 - Windows: Crash when resizing Window since hg 1f9d57965528 Thanks for the fix, Gab!
bb3cb4f4	2016-04-04T19:25:24	overscan (feature for SDL_RenderSetLogicalSize): Fix to ignore overscan hint when using the Direct3D 9 backend. D39 does not support negative viewport values which the current implementation relies on. D3D11 does support negative viewport values so that will continue working. Refer to Bug 2799.
831597f7	2016-04-01T21:13:58	PSP: Fixed returning success from unsupported SDL_RenderReadPixels(). This also fixed the missing error message.
d1e48141	2016-04-01T21:12:37	PSP: Fixed returning success for unsupported SDL_SetTextureColorMod(). Partially fixes Bugzilla #3298.
0a1999df	2016-01-16T21:25:10	Fixed compile warnings about type conversion. Found by buildbot.
167cf14c	2016-01-05T16:39:18	SDL_RenderSetIntegerScale
42065e78	2016-01-02T10:10:34	Updated copyright to 2016
f893ce3d	2015-12-28T15:15:58	OpenGL+GLES renderers: Fixed incorrect clip rectangle coords (thanks, Marcel!). Fixes Bugzilla #2700.
9e9ef5ad	2015-12-27T17:55:45	Fixed bug 3202 - Fix renderer visibility on a window maximized directly from the minimized state Many thanks to id.zeta for details on the bug, and for the fix!
0c463d77	2015-12-10T20:25:34	SDL_GL_GetAttribute: If a GL context isn't active, only return failure when the specified attribute needs an active GL context to be queried.
25abce51	2015-11-29T19:33:11	WinRT: added Win10/UWP (Universal Windows Platform) support "UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs. This set of changes updates SDL's WinRT backends to support the Win10 flavor of WinRT. It has been tested on Win10 on a desktop. In theory, it should also support Win10 on other devices (phone, Xbox One, etc.), however further patches may be necessary. This adds: - a set of MSVC 2015 project files, for use in creating UWP apps - modifications to various pieces of SDL, in order to compile via MSVC 2015 + the Win10 API set - enables SDL_Window resizing and programmatic-fullscreen toggling, when using the WinRT backend - WinRT README updates
623898f7	2015-11-26T00:41:39	WinRT: lots of display and windowing related fixes This change-set fixes a lot of windowing related bugs, especially with regards to Windows 8.x apps running on Windows 10 (which was the driver for this work). The primary fixes include: * listed display modes were wrong, especially when launching apps into a non-fullscreen space * reported window flags were often wrong, especially on Windows 10 * fullscreen/windowed mode switches weren't failing (they are not programmatically possible in Win 8.x apps).
4c72d39c	2015-10-15T22:26:21	D3D11: Fixed SDL_RenderDrawPoints() ignoring input after the first 128 points. If a limit would be needed then count should be adapted before stack allocation.
0856a7ef	2015-08-21T23:50:37	Changed an error return value from 0 to NULL for consistency.
ded3a16e	2015-06-23T01:44:44	Fixed compiler warning about shadowed local variables.
0e45984f	2015-06-21T17:33:46	Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI().
d77a5573	2015-06-21T04:04:14	merged SDL 2.0.4 rc2
d763a9f6	2015-06-19T23:22:53	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.
b7ede6cc	2015-06-19T23:20:43	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.
82ae4f6f	2015-06-19T22:12:47	[mq]: 3027_rleperf.diff
27fab8f4	2015-06-17T20:03:08	merged SDL 2.0.4rc1+
a4eb0dea	2015-06-14T19:10:51	Fixed bug 2908 - Fix clang warnings Simon Deschenes My build system still shows warning as errors. The first warning says that the member named instances can never be false (or NULL) as it is a static array, and we should check for instances[index] which we do anyway.
fd8b7c1c	2015-06-05T19:41:18	Fixed comments at conditional compilation macros.
38549a7b	2015-06-04T00:56:11	Fixed bug 2625 - Direct3D9 with SDL_TEXTUREACCESS_TARGET textures causes an application crash Roberto I have debugged the code checking the function calls when Direct3D is the renderer, remember that with software and OpenGL renderers, this issue is not happening. - Create the texture: SDL_Texture *pTex = SDL_CreateTexture(pRenderer, iFormat, SDL_TEXTUREACCESS_TARGET, pSurf->w, pSurf->h); - Update the texture: SDL_UpdateTexture(pTex, NULL, pSurf->pixels, pSurf->pitch); SDL_render.c, SDL_UpdateTexture(): return renderer->UpdateTexture(renderer, texture, rect, pixels, pitch); SDL_render_d3d.c, D3D_UpdateTexture(): if (D3D_UpdateTextureRep(data->device, &texturedata->texture, texture->format, rect->x, rect->y, rect->w, rect->h, pixels, pitch) < 0) { SDL_render_d3d.c, D3D_UpdateTextureRep(): if (D3D_CreateStagingTexture(device, texture) < 0) { SDL_render_d3d.c, D3D_CreateStagingTexture(): result = IDirect3DDevice9_CreateTexture(..., D3DPOOL_SYSTEMMEM, ...) --> FAIL! with INVALIDCALL code After checking a bit the Microsoft documentation, I found this: D3DUSAGE_RENDERTARGET can only be used with D3DPOOL_DEFAULT. (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172625%28v=vs.85%29.aspx) The call that fails, is using D3DUSAGE_RENDERTARGET with D3DPOOL_SYSTEMMEM which is unsupported, hence the INVALIDCALL return code.
da190975	2015-05-28T18:57:10	Fixed clip rectangle calculation when there is a viewport offset
6a3ad8a9	2015-05-28T12:18:05	Fixed bug 2367 - Bad mouse motion coordinates with two windows where one has changed logical size Andreas Ragnerstam I have two windows where one has a renderer where the logical size has been changed with SDL_RenderSetLogicalSize. When I get SDL_MOUSEMOTION events belonging to the non-scaled window these will have been scaled with the factor of the scaled window, which is not expected. Adding some printf debugging to SDL_RendererEventWatch of SDL_render.c, where (event->type == SDL_MOUSEMOTION), I found that for every mouse motion SDL_RendererEventWatch is called twice and the event->motion.x and event.motion.y are set twice for the event, once for each renderer where only the last one set will be saved to the event struct. This will work fine if both renderers have the same scale, but otherwise the motion coordinates will be scaled for the renderer belonging to another window than the mouse was moved in. I guess one solution would be to check that window == renderer->window for SDL_MOUSEMOTION events, similar to what is done for when SDL_WINDOWEVENT events. I get the same error on both X11 and Windows. The same problem also exists for SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events.
d5a57853	2015-05-26T16:42:36	Drop out of SDL_UpdateTexture() early if the rectangle is zero pixels. Hopefully makes static analysis happy about a zero-byte malloc elsewhere.
2c4a6ea0	2015-05-26T06:27:46	Updated the copyright year to 2015
fcee3e73	2015-05-16T17:35:36	Code style cleanup in the GLES and GLES2 render backends.
b72938c8	2015-04-20T12:22:44	Windows: Always set the system timer resolution to 1ms by default. An existing hint lets apps that don't need the timer resolution changed avoid this, to save battery, etc, but this fixes several problems in timing, audio callbacks not firing fast enough, etc. Fixes Bugzilla #2944.
7d5147ba	2015-04-17T21:25:19	resync'd overscan patch with SDL mainline.

36ba9248

2017-08-14T10:04:59

Fixed setting the texture blend mode in the OpenGL ES2 renderer

c59d9923

2017-08-14T05:51:44

Implemented more flexible blending modes for accelerated renderers This fixes bug 2594 - Propose new blend mode, SDL_BLENDMODE_BLEND_DSTA blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD, SDL_BLENDFACTOR_ZERO, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_ADD); This fixes bug 2828 - Subtractive Blending blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_SUBTRACT, SDL_BLENDFACTOR_ZERO, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_SUBTRACT); This goes partway to fixing bug 3684 - Add support for a pre-multiplied alpha blending mode blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_ONE, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD, SDL_BLENDFACTOR_ONE, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD);

f8e1874d

2017-08-13T22:50:23

Fixed bug 2646 - Problems with software renderer when SDL_SetRenderLogicalSize set Fixed setting the software renderer clip rectangle when a viewport is set

7af3786d

2017-08-13T21:55:42

Fixed bug 2755 - SDL2 fails to build on Solaris 10 u3 UX-admin I am compiling with the Sun Studio 12 u2 compiler. There are multiple issues with the build, but this particular issue appears to be that it is illegal to declare a union of a struct of floats and a float. While GCC 4.8.1 does not flag this as an error, Sun Studio is much more standards compliant and strict, halting further compilation with an error.

ca5c3048

2017-08-13T21:06:52

Fixed bug 3744 - missing SDLCALL in several functions Ozkan Sezer The attached patch adds missing SDLCALL to several functions, so that they properly match the headers as intended.

af9ec8f6

2017-08-13T20:13:11

Fixed copy-paste error, thanks Alen!

6f843b90

2017-08-12T12:59:22

Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0 Simon Hug The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white. The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.

4c239e55

2017-08-11T20:54:06

Fixed bug 3297 - Horizontal and Vertical flip swapped on PSP Littlefighter19 When trying to mirror something on the PSP, I've stumbled upon the problem, that using SDL_RenderCopyEx with SDL_FLIP_HORIZONTAL flips the image vertically, vise-versa SDL_FLIP_VERTICAL flips the image horizontally. Proposed patch would be swapping the check in line 944 with the one in line 948 in SDL_render_psp.c

6de66e98

2017-08-11T11:54:24

Fixed bug 3324 - SDL_RenderReadPixels: Wrong rect coordinates with software renderer Daniel SDL_RenderReadPixels with SDL_RENDERER_SOFTWARE reads pixels from wrong coordinates. SW_RenderReadPixels adjusts the rect coordinates according to the viewport. But since this is already done by SDL_RenderReadPixels, the final rect has x2 bigger X and Y.

ef54d5a8

2017-08-07T10:28:59

Fixed building on various versions of GCC - YUV MMX code is disabled for now

8aa147fa

2017-08-04T23:00:30

Fixed compiler warnings about type conversions. Found by buildbot.

9dbe5a96

2017-08-02T13:38:46

Fixed bug 3311 - Broken touch positions with SDL_RenderSetLogicalSize & HIGHDPI on iOS Eric wing Hi, I think I found a bug when using SDL_WINDOW_ALLOW_HIGHDPI with SDL_RenderSetLogicalSize on iOS. I use SDL_RenderSetLogicalSize for all my stuff. I just tried turning on SDL_WINDOW_ALLOW_HIGHDPI on iOS and suddenly all my touch/mouse positions are really broken/far-off-the-mark. I actually don't have a real retina device (still) so I'm seeing this using the iOS simulator with a 6plus template. Attached is a simple test program that can reproduce the problem. It uses RenderSetLogicalSize and draws some moving happy faces (to show the boundaries/space of the LogicalSize and that it is working correctly for that part). When you click/touch, it will draw one more happy face where your button point is. If you comment out SDL_WINDOW_ALLOW_HIGHDPI, everything works as expected. But if you compile with it in, the mouse coordinates seem really far off the mark. (Face appears far up and to the left.) Alex Szpakowski on the mailing list suggests the problem is "I believe this is a bug in SDL_Render?s platform-agnostic mouse coordinate scaling code. It assumes the units of the mouse coordinates are always in pixels, which isn?t the case where high-DPI is involved (regardless of whether iOS is used) ? they?re actually in ?DPI independent? coordinates (which matches the window size, but not the renderer output size)." Additionally, if this is correct, the Mac under Retina is also probably affected too and "as well as any other platform SDL adds high-dpi support for in the future".

18f2b27b

2017-07-26T13:54:11

Whoops, forgot to commit the actual fix. :)

7ecc48c3

2017-07-26T13:43:25

Disable MMX inline assembly on Clang for now. We should probably rewrite this with SSE compiler intrinsics or something anyhow.

36998b82

2017-07-20T10:48:57

Fixed bug 3689 - MMX YUV renderer crash felix The functions in src/render/SDL_yuv_mmx.c contain the following inline assembly snippet: /* tap dance to workaround the inability to use %%ebx at will... */ /* move one thing to the stack... */ "pushl $0\n" /* save a slot on the stack. */ "pushl %%ebx\n" /* save %%ebx. */ "movl %0, %%ebx\n" /* put the thing in ebx. */ "movl %%ebx,4(%%esp)\n" /* put the thing in the stack slot. */ "popl %%ebx\n" /* get back %%ebx (the PIC register). */ Here's how it ended up in a binary on my old laptop: 0xb5c17dbd <ColorRGBDitherYV12MMX1X+93>: push $0x0 0xb5c17dbf <ColorRGBDitherYV12MMX1X+95>: push %ebx 0xb5c17dc0 <ColorRGBDitherYV12MMX1X+96>: mov 0xc(%esp),%ebx 0xb5c17dc4 <ColorRGBDitherYV12MMX1X+100>: mov %ebx,0x4(%esp) 0xb5c17dc8 <ColorRGBDitherYV12MMX1X+104>: pop %ebx Apparently the compiler, oblivious to the fact that the assembly snippet manipulates the %esp register, decided to refer to the operand via that same register instead of via %ebp (I believe -fomit-frame-pointer enables this). This causes %ebx to be loaded with the wrong value, which later leads to a null pointer dereference. Recent GCC can use the %ebx register normally: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602#c16>. There is even an explicit constraint "b" for allocating it.

92889836

2017-06-06T14:06:40

Merged Eric Wing's overscan patch. Fixes Bugzilla #2799.

63b3e06f

2017-06-03T23:00:15

Corrected names of header file guards.

02773811

2017-05-18T21:00:11

render: GL_DestroyRender() should activate first. Otherwise, we might destroy a different GL context's resources.

266816b4

2017-03-26T21:00:19

Removed newlines from error messages.

ca0bf151

2017-03-03T16:38:17

Fix some more compiler warnings on armcc.

07519a6b

2017-02-26T00:40:04

Removed a bunch of unnecessary #ifdefs.

b13c443c

2017-02-24T20:49:14

WinRT: removed buildbot debug code, pending further research

f7bfa3b7

2017-02-24T20:19:28

WinRT: more buildbot debug code

ecb1eb82

2017-02-24T19:59:57

WinRT: added code to help debug a buildbot error

13433c4a

2017-01-27T21:23:27

Fixed bug 3569 - GL_UpdateViewport leaves PROJECTION matrix selected Tom Seddon GL_ActivateRenderer may call GL_UpdateViewport, which leaves the GL_PROJECTION matrix selected. But after GL_ResetState, the GL_MODELVIEW matrix is selected, suggesting that's the intended default state. It seems at least like these should be consistent. Presumably GL_UpdateViewport should be doing a glMatrixMode(GL_MODELVIEW) before it finishes.

9d9e92cf

2017-01-08T10:41:22

Fixed bug 3304 - Android black screen on resume Richard Russell Resuming from a suspended state results in a black screen. This only happens when using GLES 1.1 (GLES 2 resumes correctly) and when the render target has been changed using SDL_SetRenderTarget. This problem is new in 2.0.4. The attached test case demonstrates the issue. Sylvain Becker has apparently found a fix as follows: "In the opengles leaf function (in 'src/render/opengles/SDL_render_gles.c'), it appears there is a call to 'GLES_ActivateRenderer' in 'GLES_SetRenderTarget', which is not present in opengles2. When commenting out this 'GLES_ActivateRenderer', it seems to resume fine". This appears to fix the testcase perfectly, but I don't know whether it could have any undesirable side-effects.

c1ac4c68

2017-01-06T21:17:33

Better fix for static analysis issue in SDL_DestroyRenderer(). Follow up fix for Bugzilla #3544.

3df77ced

2017-01-06T00:40:22

Just roll back the entire portion of the commit from a8253d439914 which caused bug 3544 until we figure out what the right static analysis fix is.

356c2ead

2017-01-06T00:32:06

Fixed bug 3544 - Memory freeing bug in SDL_DestroyRenderer/SDL_DestroyTexture felix Here's a snippet of SDL_DestroyRenderer from hg revision 10746:7540ff5d0e0e: SDL_Texture *texture = NULL; SDL_Texture *nexttexture = NULL; /* ... */ for (texture = renderer->textures; texture; texture = nexttexture) { nexttexture = texture->next; SDL_DestroyTexture(texture); } SDL_DestroyTexture removes the texture from the linked list pointed to by the renderer and ends up calling SDL_DestroyTextureInternal, which contains this: if (texture->native) { SDL_DestroyTexture(texture->native); } If it happens that texture->native is an alias of nexttexture two stack frames up, SDL_DestroyRenderer will end up trying to destroy an already freed texture. I've had this very situation happen in dosemu2. Bug introduced in revision 10650:a8253d439914, which has a somewhat ironic description of "Fixed all known static analysis bugs"...

45b774e3

2017-01-01T18:33:28

Updated copyright for 2017

fb5fd67c

2016-11-24T21:41:09

Fixed all known static analysis bugs, with checker-279 on macOS.

e93e91f0

2016-11-23T21:52:48

Pacify some GCC strict-aliasing compiler warnings.

40c2a6fb

2016-11-23T11:49:26

Fixed more compiler warnings.

36156335

2016-11-20T21:34:54

Renaming of guard header names to quiet -Wreserved-id-macro Patch contributed by Sylvain

97aa5775

2016-11-16T22:08:51

Fixed empty parameter list in signatures of internal functions.

0d24495b

2016-11-15T01:24:58

Removed unused constants Except for SDL_bmp.c where they are historically interesting and I've left them in.

ab8bd3d9

2016-11-15T01:12:27

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.

57d01d7d

2016-11-13T22:57:41

Patch from Sylvain to fix clang warnings

77000ff8

2016-11-11T13:38:39

Fixed bug 1822 - Inconsistent renderer behaviour on rotation Sylvain 2016-11-07 08:49:34 UTC when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey. if you set a dummy colorkey, it will remove the line ... if you set a some alpha mod, the +90/-90 get transparent but not the 0/180 ...

057bca8a

2016-11-06T15:15:32

Better fix for last point in D3D11 renderer, thanks to Nader Golbaz

330e2952

2016-11-06T08:47:40

Fixed bug 2421 for D3D11 - SDL_RenderCopyEx off by one when rotating by 90 and -90. Nader Golbaz Updated patch for direct3d renderers

4ed4997c

2016-11-06T08:42:46

Fixed bug 2421 for D3D9 - SDL_RenderCopyEx off by one when rotating by 90 and -90 Nader Golbaz Updated patch for direct3d renderers

8e2634eb

2016-10-14T00:51:57

Fixed divide by zero if setting integer scale without setting logical width and height

662f966c

2016-10-13T08:46:34

Fixed bug 3355 - false "Invalid renderer" after creating an "opengles2" renderer. Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.

e4af8ce9

2016-10-13T04:57:31

Fixed typo getting the drawable size

36e40d30

2016-10-11T23:19:05

Fixed bug 2923 - Add SDL_PIXELFORMAT_RGBA32 for byte-wise 32bit RGBA data Daniel Gibson Ok, I followed the simple approach of just making SDL_PIXELFORMAT_RGBA32 an alias of SDL_PIXELFORMAT_RGBA8888/SDL_PIXELFORMAT_ABGR8888, depending on endianess. And I did the same for SDL_PIXELFORMAT_ARGB32, .._BGRA, .._ABGR. SDL_GetPixelFormatName() will of course return SDL_PIXELFORMAT_RGBA8888 (or SDL_PIXELFORMAT_ABGR8888) instead of SDL_PIXELFORMAT_RGBA32, but as long as that's mentioned in the docs it shouldn't be a problem.

564c790f

2016-10-11T17:31:29

Fixed a memory leak in function GL_RenderReadPixels

27d4f099

2016-10-07T23:40:44

Implemented SDL_GetHintBoolean() to make it easier to check boolean hints

9c483655

2016-10-07T18:00:30

Fixed bug 3029 - software renderer cuts off edges when rotate-blitting with a multiple of 90 degrees Adam M. When doing a rotated texture copy with the software renderer, where the angle is a multiple of 90 degrees, one or two edges of the image get cut off. This is because of the following line in sw_rotate.c: if ((unsigned)dx < (unsigned)sw && (unsigned)dy < (unsigned)sh) { which is effectively saying: if (dx >= 0 && dx < src->w-1 && dy >= 0 && dy < src->h-1) { As a result, it doesn't process pixels in the right column or bottom row of the source image (except when they're accessed as part of the bilinear filtering for nearby pixels). This causes it to look like the edges are cut off, and it's especially obvious with an exact multiple of 90 degrees.

bf076c22

2016-10-07T17:30:21

Fixed bug 2957 - De-reference rz_src without NULL check in SDLgfx_rotateSurface function Nitz In function SDLgfx_rotateSurface: rz_dst = SDL_CreateRGBSurface(SDL_SWSURFACE, dstwidth, dstheight + GUARD_ROWS, rz_src->format->Rmask, rz_src->format->Gmask, rz_src->format->Bmask, rz_src->format->Amask); Here rz_src get De-referenced without NULL check, which is risky.

67bf5cac

2016-10-02T22:32:35

Fixed wrong pixel format if reading pixels from OpenGL renderer.

969c3167

2016-10-01T18:49:15

Fixed MinGW-w64 build warnings in SDL_render_d3d11.c Some of these were legitimate bugs, including: - a malformed SDL_snprintf call - a probably-invalid enum comparison

702d9348

2016-10-01T15:23:43

Added SDL prefix to local IID constants

7851eb08

2016-10-01T18:10:15

Fixed bug 3437 - build error for WinRT/UWP .dlls, caused by fix for SDL bug 3336 This fix has been tested with both MinGW-w64, and Visual C++ 2012-2015.

fa0f4176

2016-10-01T14:48:18

Fixed build warnings and errors

c8cfccc2

2016-10-01T14:31:00

Fixed bug 3116 - renderer->hidden in SDL_RenderCopy(Ex) Daniel Seems like check of the visibility of renderer (renderer->hidden) is missing in SDL_RenderCopyEx. In SDL_RenderCopy it should be done much earlier (after checking support for RenderCopyEx, line 1750).

ecea3c4a

2016-10-01T13:33:32

Fixed bug 3169 - GLES2_CreateRenderer does not check SDL_GL_GetAttribute result, causing use of uninitialized data Yann Dirson When attempting to force use of opengles2 renderer with: int wanted_renderer = -1; for (int i = 0; i < numrenderers; i++) { SDL_RendererInfo renderer_info; if (SDL_GetRenderDriverInfo(i, &renderer_info) != 0) { SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't get renderer driver info: %s\n", SDL_GetError()); quit(2); } std::cerr << "Renderer " << i << " '" << renderer_info.name << "': flags=0x" << std::hex << renderer_info.flags << std::dec << ", " << renderer_info.num_texture_formats << " texture formats, max=" << renderer_info.max_texture_width << "x" << renderer_info.max_texture_height << "\n"; if (!strcmp(renderer_info.name, "opengles2")) { std::cerr << " selecting!\n"; wanted_renderer = i; } } renderer = SDL_CreateRenderer(window, wanted_renderer, 0); ... on banana pi or raspberry pi I get an error like the following (the actual context profile value varies, being used uninitialized) ERROR: Couldn't create renderer: Unknown OpenGL context profile 900 With this patch I get the following, which should help more pointing to a real problem: ERROR: Couldn't create renderer: Failed getting OpenGL glGetString entry point I pushed a patch (based on master branch of unofficial git mirror): https://github.com/O-Computers/SDL/commit/550389c89f4e73a0a5294f95b9f6e6c18ba48509 I'll be opening a different bug for the underlying issue.

67901f53

2016-10-01T13:29:30

Fixed bug 3174 - SDL_SetRenderTarget clip rect Marcel Bakker In SDL_SetRenderTarget(), i think the intended behavior was to clear the clip rect when a new target is set.

86b4319d

2016-10-01T13:07:36

Fixed bug 3422 - OpenGL ES 1.1 renderer: SDL_UpdateTexture breaks later function calls (missing glDisable) ny00 Using the OpenGL ES 1.1 renderer, after updating a texture with SDL_UpdateTexture (or SDL_UnlockTexture), a following call to SDL_RenderFillRect draws a rectangle with the wrong color (which appears to be the same as the texture's top-left pixel). Comparing SDL_render_gles.c:GLES_UpdateTexture to SDL_render_gl.c:GL_UpdateTexture, a missing call to glDisable appears to be the cause. After adding it back, the bug is resolved.

77305d47

2016-10-01T11:46:32

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.

89c868f4

2016-10-01T11:40:57

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.

061cc5e7

2016-10-01T11:38:53

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.

51d6371e

2016-10-01T11:34:04

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.

a42c396a

2016-10-01T11:04:45

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.

3f1b1629

2016-10-01T10:52:24

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 cc226dce7536 [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.

2ccb46ce

2016-10-01T10:43:01

Fixed bug 3373 - OpenGL implementation differences of glDrawTexfOES Simon Hug It seems not everyone implemented glDrawTexfOES the same. Intel and Mesa ignore the viewport entirely, whereas the Raspberry Pi implementation offsets the coordinates and does viewport clipping. The glDrawTexfOES extension text [1] for the function says "Xs and Ys are given directly in window (viewport) coordinates." I guess this wasn't clear enough. Alex Szpakowski Honestly I'd probably remove that codepath from SDL_Render entirely. It's an OpenGL ES 1-specific extension that isn't likely to give huge performance gains and adds additional maintenance overhead to SDL_Render while also having bugs in some drivers (as seen here).

b7e45f8a

2016-10-01T10:28:00

Fixed bug 3336 - Failure to build with MinGW-w64 Kai Sterker There are already patches available from mingw64 that fix the issue https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-SDL2 With those applied, I could compile SDL2 without problems. But of course, it would be preferable if SDL built cleanly from source.

86d4b099

2016-09-13T18:44:28

Fixed spacing

f0505766

2016-09-13T22:18:06

Initial Apple TV / tvOS support. The Apple TV remote is currently exposed as a joystick with its touch surface treated as two axes. Key presses are also generated when its buttons and touch surface are used. A new hint has been added to help deal with deciding whether to background the app when the remote's menu button is pressed: SDL_HINT_APPLE_TV_CONTROLLER_UI_EVENTS.

23af328b

2016-06-24T22:17:56

Fixed Bug 3147 - Windows: Crash when resizing Window since hg 1f9d57965528 Thanks for the fix, Gab!

bb3cb4f4

2016-04-04T19:25:24

overscan (feature for SDL_RenderSetLogicalSize): Fix to ignore overscan hint when using the Direct3D 9 backend. D39 does not support negative viewport values which the current implementation relies on. D3D11 does support negative viewport values so that will continue working. Refer to Bug 2799.

831597f7

2016-04-01T21:13:58

PSP: Fixed returning success from unsupported SDL_RenderReadPixels(). This also fixed the missing error message.

d1e48141

2016-04-01T21:12:37

PSP: Fixed returning success for unsupported SDL_SetTextureColorMod(). Partially fixes Bugzilla #3298.

0a1999df

2016-01-16T21:25:10

Fixed compile warnings about type conversion. Found by buildbot.

167cf14c

2016-01-05T16:39:18

SDL_RenderSetIntegerScale

42065e78

2016-01-02T10:10:34

f893ce3d

2015-12-28T15:15:58

OpenGL+GLES renderers: Fixed incorrect clip rectangle coords (thanks, Marcel!). Fixes Bugzilla #2700.

9e9ef5ad

2015-12-27T17:55:45

Fixed bug 3202 - Fix renderer visibility on a window maximized directly from the minimized state Many thanks to id.zeta for details on the bug, and for the fix!

0c463d77

2015-12-10T20:25:34

SDL_GL_GetAttribute: If a GL context isn't active, only return failure when the specified attribute needs an active GL context to be queried.

25abce51

2015-11-29T19:33:11

WinRT: added Win10/UWP (Universal Windows Platform) support "UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs. This set of changes updates SDL's WinRT backends to support the Win10 flavor of WinRT. It has been tested on Win10 on a desktop. In theory, it should also support Win10 on other devices (phone, Xbox One, etc.), however further patches may be necessary. This adds: - a set of MSVC 2015 project files, for use in creating UWP apps - modifications to various pieces of SDL, in order to compile via MSVC 2015 + the Win10 API set - enables SDL_Window resizing and programmatic-fullscreen toggling, when using the WinRT backend - WinRT README updates

623898f7

2015-11-26T00:41:39

WinRT: lots of display and windowing related fixes This change-set fixes a lot of windowing related bugs, especially with regards to Windows 8.x apps running on Windows 10 (which was the driver for this work). The primary fixes include: * listed display modes were wrong, especially when launching apps into a non-fullscreen space * reported window flags were often wrong, especially on Windows 10 * fullscreen/windowed mode switches weren't failing (they are not programmatically possible in Win 8.x apps).

4c72d39c

2015-10-15T22:26:21

D3D11: Fixed SDL_RenderDrawPoints() ignoring input after the first 128 points. If a limit would be needed then count should be adapted before stack allocation.

0856a7ef

2015-08-21T23:50:37

Changed an error return value from 0 to NULL for consistency.

ded3a16e

2015-06-23T01:44:44

Fixed compiler warning about shadowed local variables.

0e45984f

2015-06-21T17:33:46

Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI().

d77a5573

2015-06-21T04:04:14

merged SDL 2.0.4 rc2

d763a9f6

2015-06-19T23:22:53

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.

b7ede6cc

2015-06-19T23:20:43

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.

82ae4f6f

2015-06-19T22:12:47

[mq]: 3027_rleperf.diff

27fab8f4

2015-06-17T20:03:08

merged SDL 2.0.4rc1+

a4eb0dea

2015-06-14T19:10:51

Fixed bug 2908 - Fix clang warnings Simon Deschenes My build system still shows warning as errors. The first warning says that the member named instances can never be false (or NULL) as it is a static array, and we should check for instances[index] which we do anyway.

fd8b7c1c

2015-06-05T19:41:18

Fixed comments at conditional compilation macros.

38549a7b

2015-06-04T00:56:11

Fixed bug 2625 - Direct3D9 with SDL_TEXTUREACCESS_TARGET textures causes an application crash Roberto I have debugged the code checking the function calls when Direct3D is the renderer, remember that with software and OpenGL renderers, this issue is not happening. - Create the texture: SDL_Texture *pTex = SDL_CreateTexture(pRenderer, iFormat, SDL_TEXTUREACCESS_TARGET, pSurf->w, pSurf->h); - Update the texture: SDL_UpdateTexture(pTex, NULL, pSurf->pixels, pSurf->pitch); SDL_render.c, SDL_UpdateTexture(): return renderer->UpdateTexture(renderer, texture, rect, pixels, pitch); SDL_render_d3d.c, D3D_UpdateTexture(): if (D3D_UpdateTextureRep(data->device, &texturedata->texture, texture->format, rect->x, rect->y, rect->w, rect->h, pixels, pitch) < 0) { SDL_render_d3d.c, D3D_UpdateTextureRep(): if (D3D_CreateStagingTexture(device, texture) < 0) { SDL_render_d3d.c, D3D_CreateStagingTexture(): result = IDirect3DDevice9_CreateTexture(..., D3DPOOL_SYSTEMMEM, ...) --> FAIL! with INVALIDCALL code After checking a bit the Microsoft documentation, I found this: D3DUSAGE_RENDERTARGET can only be used with D3DPOOL_DEFAULT. (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172625%28v=vs.85%29.aspx) The call that fails, is using D3DUSAGE_RENDERTARGET with D3DPOOL_SYSTEMMEM which is unsupported, hence the INVALIDCALL return code.

da190975

2015-05-28T18:57:10

Fixed clip rectangle calculation when there is a viewport offset

6a3ad8a9

2015-05-28T12:18:05

Fixed bug 2367 - Bad mouse motion coordinates with two windows where one has changed logical size Andreas Ragnerstam I have two windows where one has a renderer where the logical size has been changed with SDL_RenderSetLogicalSize. When I get SDL_MOUSEMOTION events belonging to the non-scaled window these will have been scaled with the factor of the scaled window, which is not expected. Adding some printf debugging to SDL_RendererEventWatch of SDL_render.c, where (event->type == SDL_MOUSEMOTION), I found that for every mouse motion SDL_RendererEventWatch is called twice and the event->motion.x and event.motion.y are set twice for the event, once for each renderer where only the last one set will be saved to the event struct. This will work fine if both renderers have the same scale, but otherwise the motion coordinates will be scaled for the renderer belonging to another window than the mouse was moved in. I guess one solution would be to check that window == renderer->window for SDL_MOUSEMOTION events, similar to what is done for when SDL_WINDOWEVENT events. I get the same error on both X11 and Windows. The same problem also exists for SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events.

d5a57853

2015-05-26T16:42:36

Drop out of SDL_UpdateTexture() early if the rectangle is zero pixels. Hopefully makes static analysis happy about a zero-byte malloc elsewhere.

2c4a6ea0

2015-05-26T06:27:46

fcee3e73

2015-05-16T17:35:36

Code style cleanup in the GLES and GLES2 render backends.

b72938c8

2015-04-20T12:22:44

Windows: Always set the system timer resolution to 1ms by default. An existing hint lets apps that don't need the timer resolution changed avoid this, to save battery, etc, but this fixes several problems in timing, audio callbacks not firing fast enough, etc. Fixes Bugzilla #2944.

7d5147ba

2015-04-17T21:25:19

resync'd overscan patch with SDL mainline.

kc3-lang/SDL/src/render

src/render

Log