kmx git

Commit	Date	Message
838bbf1f	2020-03-17T09:35:42	Fixed bug 5037 - Regression 2.0.12 Alpha value of 0 on palette may become opaque (see also bug 3827)
21a2e0c7	2020-02-25T06:53:51	Fix compilation C90 mixed declarations and code (Thanks Cameron Gutman !)
e2b132ca	2020-02-24T21:57:03	Better fix to set the palette opaque, when there is also a colorkey (see bug 3827)
f4857660	2020-02-23T23:07:15	Fix: set to opaque when a palette surface is converted to an alpha format.
bf8aa1ed	2020-02-23T22:38:08	Fix regression: when a palette + colorkey is converted, it needs a blend mode. - Regression of test_1.c of bug 3827, after fix from bug 4798. - Blending is also needed when the palette contains alpha value, but not necessarily colorkey. - Clean up SDL_ConvertColorkeyToAlpha which doesn't seem to need 'ignore_alpha' parameter any-more. (see bug 3827)
7df22cf2	2020-01-21T21:33:40	A few #defines to reduce SDL2 footprint. Only applied when library is statically linked
a8780c6a	2020-01-16T20:49:25	Updated copyright date for 2020
981e0d36	2020-01-16T08:52:59	Fixed bug 4903 - Lack of color multiply with alpha (SDL_BLENDMODE_MOD + SDL_BLENDMODE_BLEND) blending mode for all renderers Konrad This kind of blending is rather quite useful and in my opinion should be available for all renderers. I do need it myself, but since I didn't want to use a custom blending mode which is supported only by certain renderers (e.g. not in software which is quite important for me) I did write implementation of SDL_BLENDMODE_MUL for all renderers altogether. SDL_BLENDMODE_MUL implements following equation: dstRGB = (srcRGB * dstRGB) + (dstRGB * (1-srcA)) dstA = (srcA * dstA) + (dstA * (1-srcA)) Background: https://i.imgur.com/UsYhydP.png Blended texture: https://i.imgur.com/0juXQcV.png Result for SDL_BLENDMODE_MOD: https://i.imgur.com/wgNSgUl.png Result for SDL_BLENDMODE_MUL: https://i.imgur.com/Veokzim.png I think I did cover all possibilities within included patch, but I didn't write any tests for SDL_BLENDMODE_MUL, so it would be lovely if someone could do it.
b060b2ea	2019-10-18T08:56:54	Fixed whitespace
1b4de45d	2019-10-16T08:45:54	Fixed bug 4785 - SDL_CreateRGBSurface creates 1-bit surfaces with zero pitch Sylvain Seems to be a regression in this commit: https://hg.libsdl.org/SDL/rev/7fdbffd47c0e SDL_CalculatePitch() was using format->BytesPerPixel, now it uses SDL_BYTESPERPIXEL(). The underlying issue is that "surface->format->BytesPerPixel" is not always the same as SDL_BYTESPERPIXEL(format); BytesPerPixel defined as format->BytesPerPixel = (bpp + 7) / 8; vs #define SDL_BYTESPERPIXEL(format) ... (format & 0xff) Because of SDL_pixels.h format definitions, one is giving a BytesPP 1, the other 0.
79e388bf	2019-09-10T17:12:34	Fixed bug 4798 - PNG w/transparency breaks in SDL 2.0.10 but works in SDL 2.0.9
8728ce44	2019-06-08T14:54:37	Fixed bug 4557 - SDL_SIMDAlloc and *Free should be in the public interface Martin Gerhardy These functions are really useful and should get exposed imo.
670f3d33	2019-02-04T09:11:07	Fixed bug 4484 - use SIMD aligned memory for SDL_Surface Surfaces are allocated using SDL_SIMDAlloc() They are marked with SDL_SIMD_ALIGNED flag to appropriatly free them with SDL_SIMDFree() (Flag is cleared when pixels is free'd in RLE, in case user would hijack the pixels ptr) When providing its own memory pointer (SDL_CreateRGBSurfaceFrom()) and clearing SDL_PREALLOC to delegate to SDL the memory free, it's the responsability of the user to add SDL_SIMD_ALIGNED or not, whether the pointer has been allocated with SDL_malloc() or SDL_SIMDAlloc().
9292dc7c	2019-02-04T08:43:37	Fix include path compilation
9a98dcc5	2019-02-04T08:34:24	Rename surface aligned memory flag to SDL_SIMD_ALIGNED
e5d194e9	2019-01-31T11:45:31	Add SDL_MEMALIGNED flag for SDL_Surface using aligned memory. If an SDL_Surface has an aligned memory pointers, it should be freed using SDL_SIMDFree() (will be used by SDL_ttf).
5b07148f	2019-01-30T16:36:47	Fixed failing SDL_ConvertSurface() when blit has failed. Some blit combination are not supported (eg ARGB8888 -> SDL_PIXELFORMAT_INDEX1MSB) So prevent SDL_ConvertSurface from creating a broken surface, which cannot be blitted
2bd26b8d	2019-01-21T18:45:15	Fixed bug 3827 - issue with MapRGB, palette and colorkey For a palettized surface, prevent SDL_MapRGB() value to change whether colorkey is set or not.
5e13087b	2019-01-04T22:01:14	Updated copyright for 2019
7df0f4fd	2018-09-27T14:56:29	Fixed bug 4277 - warnings patch Sylvain Patch a few warnings when using: -Wmissing-prototypes -Wdocumentation -Wdocumentation-unknown-command They are automatically enabled with -Wall
ef347048	2018-09-24T16:41:55	Fixed bug 4264 - SDL_CreateTextureFromSurface generates error message but returns ok Anthony @ POW Games SDL_CreateTextureFromSurface makes an internal call to SDL_GetColorKey which can return an error and spams the error log with "Surface doesn't have a colorkey" even though the original function didn't return an error.
e3cc5b2c	2018-01-03T10:03:25	Updated copyright for 2018
18577a70	2017-12-12T16:37:23	Fixed bug 3992 - SDL_GetColorKey doesn't set error message Luke A. Guest SDL_GetColorKey does not set an error message on failure. The current source just returns -1. The documentation https://wiki.libsdl.org/SDL_GetColorKey?highlight=%28%5CbCategoryAPI%5Cb%29%7C%28SDLFunctionTemplate%29 says to call SDL_GetError but that is useless in this case.
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.
e4ef1885	2017-10-16T14:57:42	Fixed bug 3890 - Incomplete fix for CVE-2017-2888 Felix Geyer http://hg.libsdl.org/SDL/rev/a31ee4d64ff6 tries to fix CVE-2017-2888. Unfortunately compilers may optimize the second condition "(size / surface->pitch) != surface->h" away. See https://bugzilla.redhat.com/show_bug.cgi?id=1500623#c2 I've verified that this is also the case on Debian unstable (gcc 7.2).
d2a2b0c1	2017-10-07T15:26:55	Fixed bug 3857 - SDL_ConvertPixels misses YUV conversions Sylvain There are various YUV-RGB conversion coefficients, according to https://www.fourcc.org/fccyvrgb.php I choose the first (from Video Demystified, with integer multiplication), but the current SDL2 Dither functions use in fact the next one, which follows a specifications called CCIR 601. Here's a patch to use the second ones and with previous warning corrections. There are less multiplications involved because Chroma coefficient is 1. Also, doing float multiplication is as efficient with vectorization. In the end, the YUV decoding is faster: ~165 ms vs my previous 195 ms. Moreover, if SDL2 is compiled with -march=native, then YUV decoding time drops to ~130ms, while older ones remains around ~220 ms. For information, from jpeg-9 source code: jpeg-9/jccolor.c * YCbCr is defined per CCIR 601-1, except that Cb and Cr are * normalized to the range 0..MAXJSAMPLE rather than -0.5 .. 0.5. * The conversion equations to be implemented are therefore * Y = 0.29900 * R + 0.58700 * G + 0.11400 * B * Cb = -0.16874 * R - 0.33126 * G + 0.50000 * B + CENTERJSAMPLE * Cr = 0.50000 * R - 0.41869 * G - 0.08131 * B + CENTERJSAMPLE jpeg-9/jdcolor.c * YCbCr is defined per CCIR 601-1, except that Cb and Cr are * normalized to the range 0..MAXJSAMPLE rather than -0.5 .. 0.5. * The conversion equations to be implemented are therefore * * R = Y + 1.40200 * Cr * G = Y - 0.34414 * Cb - 0.71414 * Cr * B = Y + 1.77200 * Cb
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
d9e1036e	2017-10-06T16:17:50	Fixed potential overflow in surface allocation (thanks Yves!)
db20e71d	2017-10-02T10:50:33	Fixed bug 3855 - Memory leak in SDL_FreeSurface
aad58c62	2017-09-29T07:44:30	Fixed bug 3852 - SDL_FreeSurface deallocates surface->map even if the surface is not yet freed Evgeny Kapun Commit 490bb5b49f11 [1], which was a fix for bug #3790, introduced a new bug: now, calling SDL_FreeSurface(surface) deallocates surface->map even if there are other references to the surface. This is bad, because some functions (such as SDL_ConvertSurface) assume that surface->map is not NULL.
76176486	2017-09-14T08:37:27	surface: Make sure SDL_ConvertSurface() deals with palettes (thanks, Sylvain!). Fixes Bugzilla #3826. Fixes Bugzilla #2979.
67f9348b	2017-09-04T11:46:14	Fixed bug 3790 - Memory leak with surfaces blitting on each other bastien.bouclet When creating two surfaces and blitting them onto the other, SDL's internal reference counting fails, and one of the surfaces is not freed when calling SDL_FreeSurface. Example code : SDL_Surface s1 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888); SDL_Surface s2 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888); SDL_BlitSurface(s1, NULL, s2, NULL); SDL_BlitSurface(s2, NULL, s1, NULL); SDL_FreeSurface(s2); SDL_FreeSurface(s1); With this example, s1 is not freed after calling SDL_FreeSurface, its refcount attribute is still positive.
f142a796	2017-08-14T13:37:14	Fixed bug 2441 - SDL_DuplicateSurface Rainer Deyke I've written a small patch that adds a small SDL_DuplicateSurface function to SDL. I've written the function as part of a larger (as yet unfinished) patch, but I think this function is useful enough that it merits inclusion in SDL on its own.
7bab2913	2017-08-12T17:01:14	Fixed Windows build
05facb3d	2017-08-12T16:59:00	Fixed bug 2979 - SDL_ConvertSurface does not convert color keys consistently Edmund Horner When a 16-bit "565 format" surface has a colour key set, it will blit with correct transparency. If, however, it has its colour key set then is converted to a 32-bit ARGB format surface, the colour key in the converted image will not necessarily be the same pixel value as the transparent pixels. It may not blit correctly, because the colour key does not match the right pixels. In my case, with an image using 0xB54A for transparency, the colour key was converted to 180,170,82; but the corresponding pixels (with the same original value) were converted to 180,169,82. Blitting the converted image did not use transparency where expected. I have attached a test case. The bug has been replicated on both x86_64 Linux (SDL 2.0.2), and 32-bit MS C++ 2010 on Windows (SDL 2.0.0).
1a544145	2017-08-12T15:21:26	Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey Sylvain Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation. When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255). I think SDL_ConvertSurface should strictly keeps the input format. example ======= SDL_Surface input; // ... Set up a surface with ColorKey and no AlphaMod SDL_Surface output = SDL_ConvertSurface(input, input->format, input->flags); // "output" surface has a ColorKey but also AlphaMod (BLEND, and Opaque 255).
45b774e3	2017-01-01T18:33:28	Updated copyright for 2017
4905cd9c	2016-11-30T22:06:05	Fixed bug 3340 - SDL_BlitScaled causes access violation in some cases. Simon Hug The SDL_BlitScaled function runs into an access violation for specific blit coordinates and surface sizes. The attached testcase blits a 800x600 surface to a 1280x720 surface at the coordinates -640,-345 scaled to 1280x720. The blit function that moves the data then runs over and reads after the pixel data from the src surface causing an access violation. I can't say where exactly it goes wrong, but I think it could have something to do with the rounding in SDL_UpperBlitScaled. final_src.y is 288 and final_src.h is 313. Together that's 601, which I believe is one too much, but I just don't know the code enough to make sure that's the problem. Sylvain I think this patch fix the issue, but maybe it's worth re-writing "SDL_UpperBlitScaled" using SDL_FRect.
d2676c29	2016-10-07T17:04:58	Fixed bug 2924 - SDL_CreateRGBSurface[From] versions that take SDL_PIXELFORMAT enum Daniel Gibson Currently, SDL_CreateRGBSurface() and SDL_CreateRGBSurfaceFrom() take Uint32 masks for RGBA to "describe" the Pixelformat of the surface. Internally those value are only used to map to one of the SDL_PIXELFORMAT_* enum values that are used for further processing. I think it would be both handy and more efficient to be able to specify SDL_PIXELFORMAT_* yourself without using SDL_PixelFormatEnumToMasks() to create masks first, so I implemented functions that do that: SDL_CreateRGBSurfaceWithFormat() and SDL_CreateRGBSurfaceWithFormatFrom() which are like the versions without "WithFormat" but instead of taking 4 Uint32s for R/G/B/A masks, they take one for a SDL_PIXELFORMAT_* enum value. Together with https://bugzilla.libsdl.org/show_bug.cgi?id=2923 creating a SDL_Surface* from RGBA data (e.g. from stb_image) is as easy as surf = SDL_SDL_CreateRGBSurfaceWithFormat(0, w, h, bppToUse*8, SDL_PIXELFORMAT_RGBA32);
42065e78	2016-01-02T10:10:34	Updated copyright to 2016
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().
2c4a6ea0	2015-05-26T06:27:46	Updated the copyright year to 2015
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.
fe6c797c	2015-04-10T23:30:31	Fixed an iOS view orientation issue when SDL_GL_CreateContext or SDL_CreateRenderer is called.
b88ca1b4	2015-02-10T16:28:56	the last parameter of XChangeProperty is the number of elements.. and when the element format is 32.. the element is "long" so we have 5 long elements here. Yes this seems confusing as on mac+linux Long is either 32 or 64bits depending on the architecture, but this is how the X11 protocol is defined. Thus 5 is the correct value for the nelts here. Not 5 or 10 depending on the architecture. More info on the confusion https://bugs.freedesktop.org/show_bug.cgi?id=16802
b48e54aa	2015-01-26T22:00:29	Fixed bug 2802 - [patch] Fix android build compiling in wrong filesystem implementation Jonas Kulla The configure script didn't differentiate between Linux and Android, unconditionally compiling in the unix implementation of SDL_sysfilesystem.c. I'm probably one of the very few people building SDL for android using classic configure + standalone toolchain, so this has gone undetected all along.
a830fbc7	2014-12-06T00:17:52	Fixed warnings about possible loss of data in conversion.
70438be2	2014-12-03T10:55:23	WinRT: fixed bug whereby SDL would override an app's default orientation WinRT apps can set a default, preferred orientation via a .appxmanifest file. SDL was overriding this on app startup, and making the app use all possible orientations (landscape and portrait). Thanks to Eric Wing for the heads up on this!
9c398852	2014-11-22T22:20:40	Corrected header file documentation comment.
24c86b55	2014-09-11T19:24:42	[X11] Reconcile logical keyboard state with physical state on FocusIn since the window system doesn't do it for us like other platforms. This prevents sticky keys and missed keys when going in and out of focus, for example Alt would appear to stick if switching away from an SDL app with Alt-Tab and had to be pressed again. CR: Sam
1ea86978	2014-08-17T13:11:55	Removed SDL_round() because the license wasn't compatible with zlib
8272ed18	2014-08-16T23:25:02	Fixed bug 2687 - SDL_BlitScaled does not handle clipping correctly Patch from Benoit Pierre: video: fix clipping handling in SDL_UpperBlitScaled - honor destination clipping rectangle - update both destination and source rectangles when clipping source rectangle to source surface and destination rectangle to destination clip rectangle - don't change scaling factors when clipping N.B.: - when no scaling is involved (source and destination width/height are the same), SDL_UpperBlit is used (so SDL_BlitScaled behaves like SDL_BlitSurface) - the final destination rectangle after all clipping is performed is saved back to dstrect (like for SDL_UpperBlit)
6fef39d6	2014-08-06T11:34:54	Added NV12 and NV21 texture support for OpenGL and OpenGL ES 2.0 renderers
0c8e3376	2014-07-07T21:21:05	Fixed bug 2628 - invalidate surface->map in SDL_SurfacePalette() Wei Mingzhi surface->map should be invalidated in SDL_SetSurfacePalette(), otherwise the palette would not be effective when blitting to another non-8bit surface which we previously blitted to.
3dcb451f	2014-04-09T21:29:19	Added a README file regarding WinRT support To note, this file is currently formatted with CRLF line endings, rather than LF, to allow the file to be viewed with Notepad.
58edac3e	2014-02-02T00:53:27	Fixed bug 2374 - Update copyright for 2014... Is it that time already??
f848adff	2013-11-29T10:06:08	Improve Android pause/resume behavior.
7e1289af	2013-11-24T23:56:17	Make internal SDL sources include SDL_internal.h instead of SDL_config.h The new header will include SDL_config.h, but allows for other global stuff.
08fa8da7	2013-10-20T21:56:15	Fixed bug 2129 - fix for bug 2121 breaks linking for mingw and throws multiple warnings Andreas Ertelt The problem in question is caused by changeset 7771 (http://hg.libsdl.org/SDL/rev/5486e579872e / https://bugzilla.libsdl.org/show_bug.cgi?id=2121) The redefinition of __inline__ (introduced by the addition of begin_code.h:128's "\|\| __STRICT_ANSI__") results in mingw's gcc throwing multiple warning: always_inline function might not be inlinable [-Wattributes] as well as a whole bunch of redefinitions of mingw internals which break linking of projects including the SDL2 headers.
379c0054	2013-10-18T00:47:22	Fixed bug 2123 - SDL_BlitScaled crashes in src/video/SDL_blit_N.c:2145 We need to reset the blit function when switching between scaled and unscaled blits.
b63d11ce	2013-09-04T23:40:11	The SDL_PixelFormat* passed to SDL_ConvertSurface() should be const.
f79fc33a	2013-08-29T08:29:21	Christoph Mallon: Remove pointless if (x) before SDL_free(x)
1e49b1ed	2013-08-21T09:47:10	OCD fixes: Adds a space after /* (glory to regular expressions!)
695344d1	2013-08-21T09:43:09	OCD fixes: Adds a space before */
dad42067	2013-08-12T11:13:50	Fixes #2022, do not resume on Android when surfaceChanged If the app is in landscape mode and the user presses the power button, a pause is followed immediately by a surfaceChanged event because the lock screen is shown in portrait mode. This triggers a "false" resume. So, we just pause and resume following the onWindowFocusChanged events. Also, wait for SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERBACKGROUND before blocking the event pump.
1ad936eb	2013-08-11T19:56:43	Fixed bug 2027 - Full-screen appears to be broken - hang in SDL_DestroyWindow() Rainer Deyke I'm running Linux Mint 15 with the Cinnamon window manager. SDL_DestroyWindow consistently locks up for me when the window if fullscreen.

838bbf1f

2020-03-17T09:35:42

Fixed bug 5037 - Regression 2.0.12 Alpha value of 0 on palette may become opaque (see also bug 3827)

21a2e0c7

2020-02-25T06:53:51

Fix compilation C90 mixed declarations and code (Thanks Cameron Gutman !)

e2b132ca

2020-02-24T21:57:03

Better fix to set the palette opaque, when there is also a colorkey (see bug 3827)

f4857660

2020-02-23T23:07:15

Fix: set to opaque when a palette surface is converted to an alpha format.

bf8aa1ed

2020-02-23T22:38:08

Fix regression: when a palette + colorkey is converted, it needs a blend mode. - Regression of test_1.c of bug 3827, after fix from bug 4798. - Blending is also needed when the palette contains alpha value, but not necessarily colorkey. - Clean up SDL_ConvertColorkeyToAlpha which doesn't seem to need 'ignore_alpha' parameter any-more. (see bug 3827)

7df22cf2

2020-01-21T21:33:40

A few #defines to reduce SDL2 footprint. Only applied when library is statically linked

a8780c6a

2020-01-16T20:49:25

Updated copyright date for 2020

981e0d36

2020-01-16T08:52:59

Fixed bug 4903 - Lack of color multiply with alpha (SDL_BLENDMODE_MOD + SDL_BLENDMODE_BLEND) blending mode for all renderers Konrad This kind of blending is rather quite useful and in my opinion should be available for all renderers. I do need it myself, but since I didn't want to use a custom blending mode which is supported only by certain renderers (e.g. not in software which is quite important for me) I did write implementation of SDL_BLENDMODE_MUL for all renderers altogether. SDL_BLENDMODE_MUL implements following equation: dstRGB = (srcRGB * dstRGB) + (dstRGB * (1-srcA)) dstA = (srcA * dstA) + (dstA * (1-srcA)) Background: https://i.imgur.com/UsYhydP.png Blended texture: https://i.imgur.com/0juXQcV.png Result for SDL_BLENDMODE_MOD: https://i.imgur.com/wgNSgUl.png Result for SDL_BLENDMODE_MUL: https://i.imgur.com/Veokzim.png I think I did cover all possibilities within included patch, but I didn't write any tests for SDL_BLENDMODE_MUL, so it would be lovely if someone could do it.

b060b2ea

2019-10-18T08:56:54

Fixed whitespace

1b4de45d

2019-10-16T08:45:54

Fixed bug 4785 - SDL_CreateRGBSurface creates 1-bit surfaces with zero pitch Sylvain Seems to be a regression in this commit: https://hg.libsdl.org/SDL/rev/7fdbffd47c0e SDL_CalculatePitch() was using format->BytesPerPixel, now it uses SDL_BYTESPERPIXEL(). The underlying issue is that "surface->format->BytesPerPixel" is *not* always the same as SDL_BYTESPERPIXEL(format); BytesPerPixel defined as format->BytesPerPixel = (bpp + 7) / 8; vs #define SDL_BYTESPERPIXEL(format) ... (format & 0xff) Because of SDL_pixels.h format definitions, one is giving a BytesPP 1, the other 0.

79e388bf

2019-09-10T17:12:34

Fixed bug 4798 - PNG w/transparency breaks in SDL 2.0.10 but works in SDL 2.0.9

8728ce44

2019-06-08T14:54:37

Fixed bug 4557 - SDL_SIMDAlloc and *Free should be in the public interface Martin Gerhardy These functions are really useful and should get exposed imo.

670f3d33

2019-02-04T09:11:07

Fixed bug 4484 - use SIMD aligned memory for SDL_Surface Surfaces are allocated using SDL_SIMDAlloc() They are marked with SDL_SIMD_ALIGNED flag to appropriatly free them with SDL_SIMDFree() (Flag is cleared when pixels is free'd in RLE, in case user would hijack the pixels ptr) When providing its own memory pointer (SDL_CreateRGBSurfaceFrom()) and clearing SDL_PREALLOC to delegate to SDL the memory free, it's the responsability of the user to add SDL_SIMD_ALIGNED or not, whether the pointer has been allocated with SDL_malloc() or SDL_SIMDAlloc().

9292dc7c

2019-02-04T08:43:37

Fix include path compilation

9a98dcc5

2019-02-04T08:34:24

Rename surface aligned memory flag to SDL_SIMD_ALIGNED

e5d194e9

2019-01-31T11:45:31

Add SDL_MEMALIGNED flag for SDL_Surface using aligned memory. If an SDL_Surface has an aligned memory pointers, it should be freed using SDL_SIMDFree() (will be used by SDL_ttf).

5b07148f

2019-01-30T16:36:47

Fixed failing SDL_ConvertSurface() when blit has failed. Some blit combination are not supported (eg ARGB8888 -> SDL_PIXELFORMAT_INDEX1MSB) So prevent SDL_ConvertSurface from creating a broken surface, which cannot be blitted

2bd26b8d

2019-01-21T18:45:15

Fixed bug 3827 - issue with MapRGB, palette and colorkey For a palettized surface, prevent SDL_MapRGB() value to change whether colorkey is set or not.

5e13087b

2019-01-04T22:01:14

Updated copyright for 2019

7df0f4fd

2018-09-27T14:56:29

Fixed bug 4277 - warnings patch Sylvain Patch a few warnings when using: -Wmissing-prototypes -Wdocumentation -Wdocumentation-unknown-command They are automatically enabled with -Wall

ef347048

2018-09-24T16:41:55

Fixed bug 4264 - SDL_CreateTextureFromSurface generates error message but returns ok Anthony @ POW Games SDL_CreateTextureFromSurface makes an internal call to SDL_GetColorKey which can return an error and spams the error log with "Surface doesn't have a colorkey" even though the original function didn't return an error.

e3cc5b2c

2018-01-03T10:03:25

Updated copyright for 2018

18577a70

2017-12-12T16:37:23

Fixed bug 3992 - SDL_GetColorKey doesn't set error message Luke A. Guest SDL_GetColorKey does not set an error message on failure. The current source just returns -1. The documentation https://wiki.libsdl.org/SDL_GetColorKey?highlight=%28%5CbCategoryAPI%5Cb%29%7C%28SDLFunctionTemplate%29 says to call SDL_GetError but that is useless in this case.

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.

e4ef1885

2017-10-16T14:57:42

Fixed bug 3890 - Incomplete fix for CVE-2017-2888 Felix Geyer http://hg.libsdl.org/SDL/rev/a31ee4d64ff6 tries to fix CVE-2017-2888. Unfortunately compilers may optimize the second condition "(size / surface->pitch) != surface->h" away. See https://bugzilla.redhat.com/show_bug.cgi?id=1500623#c2 I've verified that this is also the case on Debian unstable (gcc 7.2).

d2a2b0c1

2017-10-07T15:26:55

Fixed bug 3857 - SDL_ConvertPixels misses YUV conversions Sylvain There are various YUV-RGB conversion coefficients, according to https://www.fourcc.org/fccyvrgb.php I choose the first (from Video Demystified, with integer multiplication), but the current SDL2 Dither functions use in fact the next one, which follows a specifications called CCIR 601. Here's a patch to use the second ones and with previous warning corrections. There are less multiplications involved because Chroma coefficient is 1. Also, doing float multiplication is as efficient with vectorization. In the end, the YUV decoding is faster: ~165 ms vs my previous 195 ms. Moreover, if SDL2 is compiled with -march=native, then YUV decoding time drops to ~130ms, while older ones remains around ~220 ms. For information, from jpeg-9 source code: jpeg-9/jccolor.c * YCbCr is defined per CCIR 601-1, except that Cb and Cr are * normalized to the range 0..MAXJSAMPLE rather than -0.5 .. 0.5. * The conversion equations to be implemented are therefore * Y = 0.29900 * R + 0.58700 * G + 0.11400 * B * Cb = -0.16874 * R - 0.33126 * G + 0.50000 * B + CENTERJSAMPLE * Cr = 0.50000 * R - 0.41869 * G - 0.08131 * B + CENTERJSAMPLE jpeg-9/jdcolor.c * YCbCr is defined per CCIR 601-1, except that Cb and Cr are * normalized to the range 0..MAXJSAMPLE rather than -0.5 .. 0.5. * The conversion equations to be implemented are therefore * * R = Y + 1.40200 * Cr * G = Y - 0.34414 * Cb - 0.71414 * Cr * B = Y + 1.77200 * Cb

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

d9e1036e

2017-10-06T16:17:50

Fixed potential overflow in surface allocation (thanks Yves!)

db20e71d

2017-10-02T10:50:33

Fixed bug 3855 - Memory leak in SDL_FreeSurface

aad58c62

2017-09-29T07:44:30

Fixed bug 3852 - SDL_FreeSurface deallocates surface->map even if the surface is not yet freed Evgeny Kapun Commit 490bb5b49f11 [1], which was a fix for bug #3790, introduced a new bug: now, calling SDL_FreeSurface(surface) deallocates surface->map even if there are other references to the surface. This is bad, because some functions (such as SDL_ConvertSurface) assume that surface->map is not NULL.

76176486

2017-09-14T08:37:27

surface: Make sure SDL_ConvertSurface() deals with palettes (thanks, Sylvain!). Fixes Bugzilla #3826. Fixes Bugzilla #2979.

67f9348b

2017-09-04T11:46:14

Fixed bug 3790 - Memory leak with surfaces blitting on each other bastien.bouclet When creating two surfaces and blitting them onto the other, SDL's internal reference counting fails, and one of the surfaces is not freed when calling SDL_FreeSurface. Example code : SDL_Surface *s1 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888); SDL_Surface *s2 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888); SDL_BlitSurface(s1, NULL, s2, NULL); SDL_BlitSurface(s2, NULL, s1, NULL); SDL_FreeSurface(s2); SDL_FreeSurface(s1); With this example, s1 is not freed after calling SDL_FreeSurface, its refcount attribute is still positive.

f142a796

2017-08-14T13:37:14

Fixed bug 2441 - SDL_DuplicateSurface Rainer Deyke I've written a small patch that adds a small SDL_DuplicateSurface function to SDL. I've written the function as part of a larger (as yet unfinished) patch, but I think this function is useful enough that it merits inclusion in SDL on its own.

7bab2913

2017-08-12T17:01:14

Fixed Windows build

05facb3d

2017-08-12T16:59:00

Fixed bug 2979 - SDL_ConvertSurface does not convert color keys consistently Edmund Horner When a 16-bit "565 format" surface has a colour key set, it will blit with correct transparency. If, however, it has its colour key set then is converted to a 32-bit ARGB format surface, the colour key in the converted image will not necessarily be the same pixel value as the transparent pixels. It may not blit correctly, because the colour key does not match the right pixels. In my case, with an image using 0xB54A for transparency, the colour key was converted to 180,170,82; but the corresponding pixels (with the same original value) were converted to 180,169,82. Blitting the converted image did not use transparency where expected. I have attached a test case. The bug has been replicated on both x86_64 Linux (SDL 2.0.2), and 32-bit MS C++ 2010 on Windows (SDL 2.0.0).

1a544145

2017-08-12T15:21:26

Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey Sylvain Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation. When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255). I think SDL_ConvertSurface should strictly keeps the input format. example ======= SDL_Surface *input; // ... Set up a surface with ColorKey and no AlphaMod SDL_Surface *output = SDL_ConvertSurface(input, input->format, input->flags); // "output" surface has a ColorKey but *also* AlphaMod (BLEND, and Opaque 255).

45b774e3

2017-01-01T18:33:28

Updated copyright for 2017

4905cd9c

2016-11-30T22:06:05

Fixed bug 3340 - SDL_BlitScaled causes access violation in some cases. Simon Hug The SDL_BlitScaled function runs into an access violation for specific blit coordinates and surface sizes. The attached testcase blits a 800x600 surface to a 1280x720 surface at the coordinates -640,-345 scaled to 1280x720. The blit function that moves the data then runs over and reads after the pixel data from the src surface causing an access violation. I can't say where exactly it goes wrong, but I think it could have something to do with the rounding in SDL_UpperBlitScaled. final_src.y is 288 and final_src.h is 313. Together that's 601, which I believe is one too much, but I just don't know the code enough to make sure that's the problem. Sylvain I think this patch fix the issue, but maybe it's worth re-writing "SDL_UpperBlitScaled" using SDL_FRect.

d2676c29

2016-10-07T17:04:58

Fixed bug 2924 - SDL_CreateRGBSurface[From] versions that take SDL_PIXELFORMAT enum Daniel Gibson Currently, SDL_CreateRGBSurface() and SDL_CreateRGBSurfaceFrom() take Uint32 masks for RGBA to "describe" the Pixelformat of the surface. Internally those value are only used to map to one of the SDL_PIXELFORMAT_* enum values that are used for further processing. I think it would be both handy and more efficient to be able to specify SDL_PIXELFORMAT_* yourself without using SDL_PixelFormatEnumToMasks() to create masks first, so I implemented functions that do that: SDL_CreateRGBSurfaceWithFormat() and SDL_CreateRGBSurfaceWithFormatFrom() which are like the versions without "WithFormat" but instead of taking 4 Uint32s for R/G/B/A masks, they take one for a SDL_PIXELFORMAT_* enum value. Together with https://bugzilla.libsdl.org/show_bug.cgi?id=2923 creating a SDL_Surface* from RGBA data (e.g. from stb_image) is as easy as surf = SDL_SDL_CreateRGBSurfaceWithFormat(0, w, h, bppToUse*8, SDL_PIXELFORMAT_RGBA32);

42065e78

2016-01-02T10:10:34

Updated copyright to 2016

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

2c4a6ea0

2015-05-26T06:27:46

Updated the copyright year to 2015

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.

fe6c797c

2015-04-10T23:30:31

Fixed an iOS view orientation issue when SDL_GL_CreateContext or SDL_CreateRenderer is called.

b88ca1b4

2015-02-10T16:28:56

the last parameter of XChangeProperty is the number of elements.. and when the element format is 32.. the element is "long" so we have 5 long elements here. Yes this seems confusing as on mac+linux Long is either 32 or 64bits depending on the architecture, but this is how the X11 protocol is defined. Thus 5 is the correct value for the nelts here. Not 5 or 10 depending on the architecture. More info on the confusion https://bugs.freedesktop.org/show_bug.cgi?id=16802

b48e54aa

2015-01-26T22:00:29

Fixed bug 2802 - [patch] Fix android build compiling in wrong filesystem implementation Jonas Kulla The configure script didn't differentiate between Linux and Android, unconditionally compiling in the unix implementation of SDL_sysfilesystem.c. I'm probably one of the very few people building SDL for android using classic configure + standalone toolchain, so this has gone undetected all along.

a830fbc7

2014-12-06T00:17:52

Fixed warnings about possible loss of data in conversion.

70438be2

2014-12-03T10:55:23

WinRT: fixed bug whereby SDL would override an app's default orientation WinRT apps can set a default, preferred orientation via a .appxmanifest file. SDL was overriding this on app startup, and making the app use all possible orientations (landscape and portrait). Thanks to Eric Wing for the heads up on this!

9c398852

2014-11-22T22:20:40

Corrected header file documentation comment.

24c86b55

2014-09-11T19:24:42

[X11] Reconcile logical keyboard state with physical state on FocusIn since the window system doesn't do it for us like other platforms. This prevents sticky keys and missed keys when going in and out of focus, for example Alt would appear to stick if switching away from an SDL app with Alt-Tab and had to be pressed again. CR: Sam

1ea86978

2014-08-17T13:11:55

Removed SDL_round() because the license wasn't compatible with zlib

8272ed18

2014-08-16T23:25:02

Fixed bug 2687 - SDL_BlitScaled does not handle clipping correctly Patch from Benoit Pierre: video: fix clipping handling in SDL_UpperBlitScaled - honor destination clipping rectangle - update both destination and source rectangles when clipping source rectangle to source surface and destination rectangle to destination clip rectangle - don't change scaling factors when clipping N.B.: - when no scaling is involved (source and destination width/height are the same), SDL_UpperBlit is used (so SDL_BlitScaled behaves like SDL_BlitSurface) - the final destination rectangle after all clipping is performed is saved back to dstrect (like for SDL_UpperBlit)

6fef39d6

2014-08-06T11:34:54

Added NV12 and NV21 texture support for OpenGL and OpenGL ES 2.0 renderers

0c8e3376

2014-07-07T21:21:05

Fixed bug 2628 - invalidate surface->map in SDL_SurfacePalette() Wei Mingzhi surface->map should be invalidated in SDL_SetSurfacePalette(), otherwise the palette would not be effective when blitting to another non-8bit surface which we previously blitted to.

3dcb451f

2014-04-09T21:29:19

Added a README file regarding WinRT support To note, this file is currently formatted with CRLF line endings, rather than LF, to allow the file to be viewed with Notepad.

58edac3e

2014-02-02T00:53:27

f848adff

2013-11-29T10:06:08

Improve Android pause/resume behavior.

7e1289af

2013-11-24T23:56:17

Make internal SDL sources include SDL_internal.h instead of SDL_config.h The new header will include SDL_config.h, but allows for other global stuff.

08fa8da7

2013-10-20T21:56:15

Fixed bug 2129 - fix for bug 2121 breaks linking for mingw and throws multiple warnings Andreas Ertelt The problem in question is caused by changeset 7771 (http://hg.libsdl.org/SDL/rev/5486e579872e / https://bugzilla.libsdl.org/show_bug.cgi?id=2121) The redefinition of __inline__ (introduced by the addition of begin_code.h:128's "|| __STRICT_ANSI__") results in mingw's gcc throwing multiple warning: always_inline function might not be inlinable [-Wattributes] as well as a whole bunch of redefinitions of mingw internals which break linking of projects including the SDL2 headers.

379c0054

2013-10-18T00:47:22

Fixed bug 2123 - SDL_BlitScaled crashes in src/video/SDL_blit_N.c:2145 We need to reset the blit function when switching between scaled and unscaled blits.

b63d11ce

2013-09-04T23:40:11

The SDL_PixelFormat* passed to SDL_ConvertSurface() should be const.

f79fc33a

2013-08-29T08:29:21

Christoph Mallon: Remove pointless if (x) before SDL_free(x)

1e49b1ed

2013-08-21T09:47:10

OCD fixes: Adds a space after /* (glory to regular expressions!)

695344d1

2013-08-21T09:43:09

OCD fixes: Adds a space before */

dad42067

2013-08-12T11:13:50

Fixes #2022, do not resume on Android when surfaceChanged If the app is in landscape mode and the user presses the power button, a pause is followed immediately by a surfaceChanged event because the lock screen is shown in portrait mode. This triggers a "false" resume. So, we just pause and resume following the onWindowFocusChanged events. Also, wait for SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERBACKGROUND before blocking the event pump.

1ad936eb

2013-08-11T19:56:43

Fixed bug 2027 - Full-screen appears to be broken - hang in SDL_DestroyWindow() Rainer Deyke I'm running Linux Mint 15 with the Cinnamon window manager. SDL_DestroyWindow consistently locks up for me when the window if fullscreen.

kc3-lang/SDL/src/video/SDL_surface.c

src/video/SDL_surface.c

Log