kmx git

Commit	Date	Message
a452a084	2018-01-01T19:40:29	iOS: fix build
639ea9fd	2018-01-01T19:37:16	metal: Use sampler state objects instead of shader-declared samplers for linear vs nearest filtering. This avoids a ton of shader duplication once multiple shaders that use samplers are added (e.g. the currently missing YUV shaders).
cf45cf70	2018-01-01T18:06:27	metal: Add support for custom blend modes.
85470a2f	2017-12-31T21:06:16	metal: implement SDL_RenderCopyEx, and fix a memory leak in SDL_CreateTexture.
047d387b	2017-12-31T15:30:08	metal: Use the existing cocoa code for creating a Metal view on macOS. Fixes the renderer size when the window is resized.
42b19c97	2017-12-30T22:39:55	metal: Respect the vsync flag on macOS 10.13+.
e24dc905	2017-12-30T20:32:22	metal: use a projection matrix instead of manually transforming vertices into clip space on the CPU.
49df65c2	2017-12-30T18:48:07	metal: only 4 (instead of 5) vertices are needed to draw rectangles and textures, and only 3 (instead of 5) vertices are needed to cover the screen for the 'full-screen quad' when clearing.
87894224	2017-12-12T16:34:16	Fixed bug 3981 - Inverted logic bug in SDL_renderer "overscan" feature Eric wing There is a tiny bug in the new overscan code for the SDL_renderer. In SDL_renderer.c, line 1265, the if check for SDL_strcasecmp with "direct3d" needs to be inverted. Instead of: if(SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) { It should be: if(0 == SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) { This bug causes the "overscan" mode to pretty much be completely ignored in all cases and all things remain letterboxed (as before the feature).
e8bbbb37	2017-12-12T12:52:17	Added support for Android video textures
bed7fd80	2017-12-12T12:52:09	Merged latest changes from rel/streaming_client
7ac46a74	2017-12-11T11:34:53	The newer compilers generate the property boilerplate automatically
358e4d9c	2017-12-11T11:02:51	Fixed Mac OS X build
c2cc9c16	2017-12-09T19:48:38	Backed out using pixel texture coordinates, it had weird visual side effects
8aad4923	2017-12-09T19:41:08	Fixed normalized coordinates when the viewport is set
441d3095	2017-12-09T15:00:41	Added support for linear sampling and pixel coordinates in the metal renderer
f55c9988	2017-12-09T12:58:41	Fixed pixel positioning and size for the Metal renderer
7dac177c	2017-12-09T03:28:23	metal: fixed render target support.
85d12d8f	2017-12-09T03:27:52	metal: Added some comments and FIXMEs.
686fc093	2017-12-08T18:26:26	metal: Cleaned up some reference count politics.
cf3d4503	2017-12-08T14:30:10	Added SDL_RenderGetMetalLayer() and SDL_RenderGetMetalCommandEncoder()
c403c0fa	2017-12-08T13:20:20	Fixed Metal renderer memory leak
b733dcc2	2017-12-08T12:02:23	Minor cleanup
5182c23c	2017-12-08T11:35:19	Fixed minor memory leak in the Metal renderer
cac4e312	2017-12-08T11:34:32	Added check for failure of D3D_ActivateRenderer()
1a1cd8c1	2017-12-08T11:09:05	Fixed bug 1878 - Scaled texture draws with filtering produce wrapping artifacts. Yuri K. Schlesner When using texture filtering, there are filtering artifacts visible on the edges of scaled textures, where the texture filtering pulls in texels from the other side of the texture. Using clamping texture modes wouldn't completely fix this since source rectangles don't need to cover the whole texture. (See screenshot attached in next post.) The opengl driver uses clamping on textures and so avoid this at least in the cases where the source rect is the whole texture. The direct3d driver does not and so has problems in every case. I'm not sure if it can actually completely be fixed, but at least enabling clamping for direct3d would be one step in the right direction.
81a33985	2017-12-08T14:03:36	metal: Don't check if Metal is available if targeting modern macOS versions.
dc04f290	2017-12-08T08:58:02	Defer getting the next drawable until we actually start rendering This works better for games where there may be a bunch of simulation logic that needs to be run before the next rendering pass, and prevents blocking if the next drawable is busy.
104decd1	2017-12-07T18:08:51	Fixed runtime errors on iOS
ba9c336e	2017-12-07T17:47:01	Fixed building for simulators or older iOS SDKs
6deb1e75	2017-12-07T17:12:03	Fixed compiling Metal renderer on iOS
1ae73a2b	2017-12-07T16:08:47	Added iOS and OSX versions of the Metal shaders
b2859af6	2017-12-07T16:08:09	Enable building the Metal renderer by default, and weak link the Metal framework so the SDL library is safe to use on older Macs Also generate iOS versions of the Metal shaders
a6a4e27a	2017-11-12T22:51:12	Updated SDL's YUV support, many thanks to Adrien Descamps New functions get and set the YUV colorspace conversion mode: SDL_SetYUVConversionMode() SDL_GetYUVConversionMode() SDL_GetYUVConversionModeForResolution() SDL_ConvertPixels() converts between all supported RGB and YUV formats, with SSE acceleration for converting from planar YUV formats (YV12, NV12, etc) to common RGB/RGBA formats. Added a new test program, testyuv, to verify correctness and speed of YUV conversion functionality.
9fd0d619	2017-10-18T08:52:04	Fixed bug 3821 - Allow SDL_CreateWindow and SDL_CreateRenderer with OpenGL ES 3.0 (GLES3) for Angle (Windows) Carlos Angle supports GLES3 but when using these functions (SDL_CreateWindow and SDL_CreateRenderer), defaults again to GLES2.0. A current workaround (hack) to retrieve a GLES3.0 context with Angle is: 1) set SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0); after InitSDL AND after calling SDL_CreateWindow (before SDL_CreateRenderer) 2) Comment lines 2032-2044 in SDL_render_gles2.c, funtion GLES2_CreateRenderer window_flags = SDL_GetWindowFlags(window); if (!(window_flags & SDL_WINDOW_OPENGL) \|\| profile_mask != SDL_GL_CONTEXT_PROFILE_ES \|\| major != RENDERER_CONTEXT_MAJOR \|\| minor != RENDERER_CONTEXT_MINOR) { changed_window = SDL_TRUE; SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, RENDERER_CONTEXT_MAJOR); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, RENDERER_CONTEXT_MINOR); if (SDL_RecreateWindow(window, window_flags \| SDL_WINDOW_OPENGL) < 0) { goto error; } } This retrives a GLES3 context as confirmed using glGetString(GL_VERSION). This should be fixed by modifying a few if's.
a7c79c5e	2017-10-12T08:37:55	Normalize touch events to the render viewport (thanks Sylvain!)
e9652b19	2017-10-06T16:50:24	Fixed bug 3857 - SDL_ConvertPixels misses YUV conversions Sylvain Few issues with YUV on SDL2 when using odd dimensions, and missing conversions from/back to YUV formats. 1) The big part is that SDL_ConvertPixels() does not convert to/from YUV in most cases. This now works with any format and also with odd dimensions, by adding two internal functions SDL_ConvertPixels_YUV_to_ARGB8888 and SDL_ConvertPixels_ARGB8888_to_YUV (could it be XRGB888 ?). The target format is hard coded to ARGB888 (which is the default in the internal of the software renderer). In case of different YUV conversion, it will do an intermediate conversion to a ARGB8888 buffer. SDL_ConvertPixels_YUV_to_ARGB8888 is somehow redundant with all the "ColorDitherMod". But it allows some completeness of SDL_ConvertPixels to handle all YUV format. It also works with odd dimensions. Moreover, I did some benchmark(SDL_ConvertPixel vs Color32DitherYV12Mod1X and Color32DitherYUY2Mod1X). gcc-6.3 and clang-4.0. gcc performs better than clang. And, with gcc, SDL_ConvertPixels() performs better (20%) than the two C function Color32Dither(). For instance, to convert 10 times a 3888x2592 image, it takes ~195 ms with SDL_ConvertPixels and ~235 ms with Color32Dither(). Especially because of gcc vectorize feature that optimises all conversion loops (-ftree-loop-vectorize). Nb: I put no image pitch for the YUV buffers. because it complexify a little bit the code and the API : There would be some ambiguity when setting the pitch exactly to image width: would it a be pitch of image width (for luma and chroma). or just contiguous data ? (could set pitch=0 for the later). 2) Small issues with odd dimensions: If width "w" is odd, luma plane width is still "w" whereas chroma planes will be "(w + 1)/2". Almost the same for odd h. Solution is to strategically substitute "w" by "(w+1)/2" at the good places ... - In the repository, SDL_ConvertPixels() handles YUV only if yuv source format is exactly the same as YUV destination format. It basically does a memcpy of pixels, but it's done incorrectly when width or height is odd (wrong size of chroma planes). This is fixed. - SDL Renderers don't support odd width/height for YUV textures. This is fixed for software, opengl, opengles2. (opengles 1 does not support it and fallback to software rendering). This is not* fixed for D3D and D3D11 ... (and others, psp ?) Only two Dither function are fixed ... not sure if others are really used. - This is not possible to create a NV12/NV12 texture with the software renderer, whereas other renderers allow it. This is fixed, by using SDL_ConvertPixels underneath. - It was not possible to SDL_UpdateTexture() of format NV12/NV21 with the software renderer. this is fixed. Here's also two testcases: - that do all combination of conversion. - to test partial UpdateTexture
5ae90ef6	2017-09-21T01:22:40	Fixed bug 3788 - software renderer crashes in SDL_RenderCopyEx with rotation and dstrect w or h is 0 Anthony This is what's making the software renderer crash with rotated destination rectangles of w or h = 0: SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "2");
e98fc897	2017-09-10T12:54:40	Fixed bug 3812 - Fallthrough warnings gcc-7
30d554e3	2017-08-19T03:07:44	Fixed building SDL applications with Visual Studio and the clang toolset Also fixed building 64-bit SDL with clang. 32-bit doesn't build because of the inline assembly for C runtime support.
c68d3ab7	2017-08-17T21:35:46	Watcom supports __FUNCTION__ identifier (and surely not __PRETTY_FUNCTION__) Partially fixes Bugzilla #3758.
04e76499	2017-08-14T20:37:07	Fixed build warning
9451cd81	2017-08-14T20:07:30	Fixed compiler warnings
aebe17d3	2017-08-14T16:34:54	Fixed bug 2344 - CHECK_WINDOW_MAGIC should include __FILE__ and __LINE__ Martin Gerhardy just for easier debugging issues in the own code... SDL_CreateRenderer should maybe also use this macro Ryan C. Gordon I'll go one better: it should have an SDL_assert().
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).

a452a084

2018-01-01T19:40:29

iOS: fix build

639ea9fd

2018-01-01T19:37:16

metal: Use sampler state objects instead of shader-declared samplers for linear vs nearest filtering. This avoids a ton of shader duplication once multiple shaders that use samplers are added (e.g. the currently missing YUV shaders).

cf45cf70

2018-01-01T18:06:27

metal: Add support for custom blend modes.

85470a2f

2017-12-31T21:06:16

metal: implement SDL_RenderCopyEx, and fix a memory leak in SDL_CreateTexture.

047d387b

2017-12-31T15:30:08

metal: Use the existing cocoa code for creating a Metal view on macOS. Fixes the renderer size when the window is resized.

42b19c97

2017-12-30T22:39:55

metal: Respect the vsync flag on macOS 10.13+.

e24dc905

2017-12-30T20:32:22

metal: use a projection matrix instead of manually transforming vertices into clip space on the CPU.

49df65c2

2017-12-30T18:48:07

metal: only 4 (instead of 5) vertices are needed to draw rectangles and textures, and only 3 (instead of 5) vertices are needed to cover the screen for the 'full-screen quad' when clearing.

87894224

2017-12-12T16:34:16

Fixed bug 3981 - Inverted logic bug in SDL_renderer "overscan" feature Eric wing There is a tiny bug in the new overscan code for the SDL_renderer. In SDL_renderer.c, line 1265, the if check for SDL_strcasecmp with "direct3d" needs to be inverted. Instead of: if(SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) { It should be: if(0 == SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) { This bug causes the "overscan" mode to pretty much be completely ignored in all cases and all things remain letterboxed (as before the feature).

e8bbbb37

2017-12-12T12:52:17

Added support for Android video textures

bed7fd80

2017-12-12T12:52:09

Merged latest changes from rel/streaming_client

7ac46a74

2017-12-11T11:34:53

The newer compilers generate the property boilerplate automatically

358e4d9c

2017-12-11T11:02:51

Fixed Mac OS X build

c2cc9c16

2017-12-09T19:48:38

Backed out using pixel texture coordinates, it had weird visual side effects

8aad4923

2017-12-09T19:41:08

Fixed normalized coordinates when the viewport is set

441d3095

2017-12-09T15:00:41

Added support for linear sampling and pixel coordinates in the metal renderer

f55c9988

2017-12-09T12:58:41

Fixed pixel positioning and size for the Metal renderer

7dac177c

2017-12-09T03:28:23

metal: fixed render target support.

85d12d8f

2017-12-09T03:27:52

metal: Added some comments and FIXMEs.

686fc093

2017-12-08T18:26:26

metal: Cleaned up some reference count politics.

cf3d4503

2017-12-08T14:30:10

Added SDL_RenderGetMetalLayer() and SDL_RenderGetMetalCommandEncoder()

c403c0fa

2017-12-08T13:20:20

Fixed Metal renderer memory leak

b733dcc2

2017-12-08T12:02:23

Minor cleanup

5182c23c

2017-12-08T11:35:19

Fixed minor memory leak in the Metal renderer

cac4e312

2017-12-08T11:34:32

Added check for failure of D3D_ActivateRenderer()

1a1cd8c1

2017-12-08T11:09:05

Fixed bug 1878 - Scaled texture draws with filtering produce wrapping artifacts. Yuri K. Schlesner When using texture filtering, there are filtering artifacts visible on the edges of scaled textures, where the texture filtering pulls in texels from the other side of the texture. Using clamping texture modes wouldn't completely fix this since source rectangles don't need to cover the whole texture. (See screenshot attached in next post.) The opengl driver uses clamping on textures and so avoid this at least in the cases where the source rect is the whole texture. The direct3d driver does not and so has problems in every case. I'm not sure if it can actually completely be fixed, but at least enabling clamping for direct3d would be one step in the right direction.

81a33985

2017-12-08T14:03:36

metal: Don't check if Metal is available if targeting modern macOS versions.

dc04f290

2017-12-08T08:58:02

Defer getting the next drawable until we actually start rendering This works better for games where there may be a bunch of simulation logic that needs to be run before the next rendering pass, and prevents blocking if the next drawable is busy.

104decd1

2017-12-07T18:08:51

Fixed runtime errors on iOS

ba9c336e

2017-12-07T17:47:01

Fixed building for simulators or older iOS SDKs

6deb1e75

2017-12-07T17:12:03

Fixed compiling Metal renderer on iOS

1ae73a2b

2017-12-07T16:08:47

Added iOS and OSX versions of the Metal shaders

b2859af6

2017-12-07T16:08:09

Enable building the Metal renderer by default, and weak link the Metal framework so the SDL library is safe to use on older Macs Also generate iOS versions of the Metal shaders

a6a4e27a

2017-11-12T22:51:12

Updated SDL's YUV support, many thanks to Adrien Descamps New functions get and set the YUV colorspace conversion mode: SDL_SetYUVConversionMode() SDL_GetYUVConversionMode() SDL_GetYUVConversionModeForResolution() SDL_ConvertPixels() converts between all supported RGB and YUV formats, with SSE acceleration for converting from planar YUV formats (YV12, NV12, etc) to common RGB/RGBA formats. Added a new test program, testyuv, to verify correctness and speed of YUV conversion functionality.

9fd0d619

2017-10-18T08:52:04

Fixed bug 3821 - Allow SDL_CreateWindow and SDL_CreateRenderer with OpenGL ES 3.0 (GLES3) for Angle (Windows) Carlos Angle supports GLES3 but when using these functions (SDL_CreateWindow and SDL_CreateRenderer), defaults again to GLES2.0. A current workaround (hack) to retrieve a GLES3.0 context with Angle is: 1) set SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0); after InitSDL AND after calling SDL_CreateWindow (before SDL_CreateRenderer) 2) Comment lines 2032-2044 in SDL_render_gles2.c, funtion GLES2_CreateRenderer window_flags = SDL_GetWindowFlags(window); if (!(window_flags & SDL_WINDOW_OPENGL) || profile_mask != SDL_GL_CONTEXT_PROFILE_ES || major != RENDERER_CONTEXT_MAJOR || minor != RENDERER_CONTEXT_MINOR) { changed_window = SDL_TRUE; SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, RENDERER_CONTEXT_MAJOR); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, RENDERER_CONTEXT_MINOR); if (SDL_RecreateWindow(window, window_flags | SDL_WINDOW_OPENGL) < 0) { goto error; } } This retrives a GLES3 context as confirmed using glGetString(GL_VERSION). This should be fixed by modifying a few if's.

a7c79c5e

2017-10-12T08:37:55

Normalize touch events to the render viewport (thanks Sylvain!)

e9652b19

2017-10-06T16:50:24

Fixed bug 3857 - SDL_ConvertPixels misses YUV conversions Sylvain Few issues with YUV on SDL2 when using odd dimensions, and missing conversions from/back to YUV formats. 1) The big part is that SDL_ConvertPixels() does not convert to/from YUV in most cases. This now works with any format and also with odd dimensions, by adding two internal functions SDL_ConvertPixels_YUV_to_ARGB8888 and SDL_ConvertPixels_ARGB8888_to_YUV (could it be XRGB888 ?). The target format is hard coded to ARGB888 (which is the default in the internal of the software renderer). In case of different YUV conversion, it will do an intermediate conversion to a ARGB8888 buffer. SDL_ConvertPixels_YUV_to_ARGB8888 is somehow redundant with all the "Color*Dither*Mod*". But it allows some completeness of SDL_ConvertPixels to handle all YUV format. It also works with odd dimensions. Moreover, I did some benchmark(SDL_ConvertPixel vs Color32DitherYV12Mod1X and Color32DitherYUY2Mod1X). gcc-6.3 and clang-4.0. gcc performs better than clang. And, with gcc, SDL_ConvertPixels() performs better (20%) than the two C function Color32Dither*(). For instance, to convert 10 times a 3888x2592 image, it takes ~195 ms with SDL_ConvertPixels and ~235 ms with Color32Dither*(). Especially because of gcc vectorize feature that optimises all conversion loops (-ftree-loop-vectorize). Nb: I put no image pitch for the YUV buffers. because it complexify a little bit the code and the API : There would be some ambiguity when setting the pitch exactly to image width: would it a be pitch of image width (for luma and chroma). or just contiguous data ? (could set pitch=0 for the later). 2) Small issues with odd dimensions: If width "w" is odd, luma plane width is still "w" whereas chroma planes will be "(w + 1)/2". Almost the same for odd h. Solution is to strategically substitute "w" by "(w+1)/2" at the good places ... - In the repository, SDL_ConvertPixels() handles YUV only if yuv source format is exactly the same as YUV destination format. It basically does a memcpy of pixels, but it's done incorrectly when width or height is odd (wrong size of chroma planes). This is fixed. - SDL Renderers don't support odd width/height for YUV textures. This is fixed for software, opengl, opengles2. (opengles 1 does not support it and fallback to software rendering). This is *not* fixed for D3D and D3D11 ... (and others, psp ?) Only *two* Dither function are fixed ... not sure if others are really used. - This is not possible to create a NV12/NV12 texture with the software renderer, whereas other renderers allow it. This is fixed, by using SDL_ConvertPixels underneath. - It was not possible to SDL_UpdateTexture() of format NV12/NV21 with the software renderer. this is fixed. Here's also two testcases: - that do all combination of conversion. - to test partial UpdateTexture

5ae90ef6

2017-09-21T01:22:40

Fixed bug 3788 - software renderer crashes in SDL_RenderCopyEx with rotation and dstrect w or h is 0 Anthony This is what's making the software renderer crash with rotated destination rectangles of w or h = 0: SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "2");

e98fc897

2017-09-10T12:54:40

Fixed bug 3812 - Fallthrough warnings gcc-7

30d554e3

2017-08-19T03:07:44

Fixed building SDL applications with Visual Studio and the clang toolset Also fixed building 64-bit SDL with clang. 32-bit doesn't build because of the inline assembly for C runtime support.

c68d3ab7

2017-08-17T21:35:46

Watcom supports __FUNCTION__ identifier (and surely not __PRETTY_FUNCTION__) Partially fixes Bugzilla #3758.

04e76499

2017-08-14T20:37:07

Fixed build warning

9451cd81

2017-08-14T20:07:30

Fixed compiler warnings

aebe17d3

2017-08-14T16:34:54

Fixed bug 2344 - CHECK_WINDOW_MAGIC should include __FILE__ and __LINE__ Martin Gerhardy just for easier debugging issues in the own code... SDL_CreateRenderer should maybe also use this macro Ryan C. Gordon I'll go one better: it should have an SDL_assert().

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

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).

kc3-lang/SDL/src/render

src/render

Log