|
13433c4a
|
2017-01-27T21:23:27
|
|
Fixed bug 3569 - GL_UpdateViewport leaves PROJECTION matrix selected
Tom Seddon
GL_ActivateRenderer may call GL_UpdateViewport, which leaves the GL_PROJECTION matrix selected. But after GL_ResetState, the GL_MODELVIEW matrix is selected, suggesting that's the intended default state.
It seems at least like these should be consistent. Presumably GL_UpdateViewport should be doing a glMatrixMode(GL_MODELVIEW) before it finishes.
|
|
|
9d9e92cf
|
2017-01-08T10:41:22
|
|
Fixed bug 3304 - Android black screen on resume
Richard Russell
Resuming from a suspended state results in a black screen. This only happens when using GLES 1.1 (GLES 2 resumes correctly) and when the render target has been changed using SDL_SetRenderTarget. This problem is new in 2.0.4.
The attached test case demonstrates the issue.
Sylvain Becker has apparently found a fix as follows:
"In the opengles leaf function (in 'src/render/opengles/SDL_render_gles.c'), it appears there is a call to 'GLES_ActivateRenderer' in 'GLES_SetRenderTarget', which is not present in opengles2. When commenting out this 'GLES_ActivateRenderer', it seems to resume fine".
This appears to fix the testcase perfectly, but I don't know whether it could have any undesirable side-effects.
|
|
c1ac4c68
|
2017-01-06T21:17:33
|
|
Better fix for static analysis issue in SDL_DestroyRenderer().
Follow up fix for Bugzilla #3544.
|
|
|
3df77ced
|
2017-01-06T00:40:22
|
|
Just roll back the entire portion of the commit from a8253d439914 which caused bug 3544 until we figure out what the right static analysis fix is.
|
|
|
356c2ead
|
2017-01-06T00:32:06
|
|
Fixed bug 3544 - Memory freeing bug in SDL_DestroyRenderer/SDL_DestroyTexture
felix
Here's a snippet of SDL_DestroyRenderer from hg revision 10746:7540ff5d0e0e:
SDL_Texture *texture = NULL;
SDL_Texture *nexttexture = NULL;
/* ... */
for (texture = renderer->textures; texture; texture = nexttexture) {
nexttexture = texture->next;
SDL_DestroyTexture(texture);
}
SDL_DestroyTexture removes the texture from the linked list pointed to by the renderer and ends up calling SDL_DestroyTextureInternal, which contains this:
if (texture->native) {
SDL_DestroyTexture(texture->native);
}
If it happens that texture->native is an alias of nexttexture two stack frames up, SDL_DestroyRenderer will end up trying to destroy an already freed texture. I've had this very situation happen in dosemu2.
Bug introduced in revision 10650:a8253d439914, which has a somewhat ironic description of "Fixed all known static analysis bugs"...
|
|
|
45b774e3
|
2017-01-01T18:33:28
|
|
Updated copyright for 2017
|
|
|
fb5fd67c
|
2016-11-24T21:41:09
|
|
Fixed all known static analysis bugs, with checker-279 on macOS.
|
|
|
e93e91f0
|
2016-11-23T21:52:48
|
|
Pacify some GCC strict-aliasing compiler warnings.
|
|
|
40c2a6fb
|
2016-11-23T11:49:26
|
|
Fixed more compiler warnings.
|
|
|
36156335
|
2016-11-20T21:34:54
|
|
Renaming of guard header names to quiet -Wreserved-id-macro
Patch contributed by Sylvain
|
|
97aa5775
|
2016-11-16T22:08:51
|
|
Fixed empty parameter list in signatures of internal functions.
|
|
|
0d24495b
|
2016-11-15T01:24:58
|
|
Removed unused constants
Except for SDL_bmp.c where they are historically interesting and I've left them in.
|
|
|
ab8bd3d9
|
2016-11-15T01:12:27
|
|
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx
Simon Hug
The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.)
Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient.
The following blend modes have issues when drawn at an angle.
NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode.
MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations.
BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is.
This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function.
There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers.
The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode...
It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster?
As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode.
I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
|
|
|
57d01d7d
|
2016-11-13T22:57:41
|
|
Patch from Sylvain to fix clang warnings
|
|
|
77000ff8
|
2016-11-11T13:38:39
|
|
Fixed bug 1822 - Inconsistent renderer behaviour on rotation
Sylvain 2016-11-07 08:49:34 UTC
when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey.
if you set a dummy colorkey, it will remove the line ...
if you set a some alpha mod, the +90/-90 get transparent but not the 0/180 ...
|
|
|
057bca8a
|
2016-11-06T15:15:32
|
|
Better fix for last point in D3D11 renderer, thanks to Nader Golbaz
|
|
|
330e2952
|
2016-11-06T08:47:40
|
|
Fixed bug 2421 for D3D11 - SDL_RenderCopyEx off by one when rotating by 90 and -90.
Nader Golbaz
Updated patch for direct3d renderers
|
|
|
4ed4997c
|
2016-11-06T08:42:46
|
|
Fixed bug 2421 for D3D9 - SDL_RenderCopyEx off by one when rotating by 90 and -90
Nader Golbaz
Updated patch for direct3d renderers
|
|
|
8e2634eb
|
2016-10-14T00:51:57
|
|
Fixed divide by zero if setting integer scale without setting logical width and height
|
|
|
662f966c
|
2016-10-13T08:46:34
|
|
Fixed bug 3355 - false "Invalid renderer" after creating an "opengles2" renderer.
Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.
|
|
|
e4af8ce9
|
2016-10-13T04:57:31
|
|
Fixed typo getting the drawable size
|
|
|
36e40d30
|
2016-10-11T23:19:05
|
|
Fixed bug 2923 - Add SDL_PIXELFORMAT_RGBA32 for byte-wise 32bit RGBA data
Daniel Gibson
Ok, I followed the simple approach of just making SDL_PIXELFORMAT_RGBA32 an alias of SDL_PIXELFORMAT_RGBA8888/SDL_PIXELFORMAT_ABGR8888, depending on endianess. And I did the same for SDL_PIXELFORMAT_ARGB32, .._BGRA, .._ABGR.
SDL_GetPixelFormatName() will of course return SDL_PIXELFORMAT_RGBA8888 (or SDL_PIXELFORMAT_ABGR8888) instead of SDL_PIXELFORMAT_RGBA32, but as long as that's mentioned in the docs it shouldn't be a problem.
|
|
564c790f
|
2016-10-11T17:31:29
|
|
Fixed a memory leak in function GL_RenderReadPixels
|
|
|
27d4f099
|
2016-10-07T23:40:44
|
|
Implemented SDL_GetHintBoolean() to make it easier to check boolean hints
|
|
|
9c483655
|
2016-10-07T18:00:30
|
|
Fixed bug 3029 - software renderer cuts off edges when rotate-blitting with a multiple of 90 degrees
Adam M.
When doing a rotated texture copy with the software renderer, where the angle is a multiple of 90 degrees, one or two edges of the image get cut off. This is because of the following line in sw_rotate.c:
if ((unsigned)dx < (unsigned)sw && (unsigned)dy < (unsigned)sh) {
which is effectively saying:
if (dx >= 0 && dx < src->w-1 && dy >= 0 && dy < src->h-1) {
As a result, it doesn't process pixels in the right column or bottom row of the source image (except when they're accessed as part of the bilinear filtering for nearby pixels). This causes it to look like the edges are cut off, and it's especially obvious with an exact multiple of 90 degrees.
|
|
|
bf076c22
|
2016-10-07T17:30:21
|
|
Fixed bug 2957 - De-reference rz_src without NULL check in SDLgfx_rotateSurface function
Nitz
In function SDLgfx_rotateSurface:
rz_dst =
SDL_CreateRGBSurface(SDL_SWSURFACE, dstwidth, dstheight + GUARD_ROWS,
rz_src->format->Rmask, rz_src->format->Gmask,
rz_src->format->Bmask, rz_src->format->Amask);
Here rz_src get De-referenced without NULL check, which is risky.
|
|
|
67bf5cac
|
2016-10-02T22:32:35
|
|
Fixed wrong pixel format if reading pixels from OpenGL renderer.
|
|
969c3167
|
2016-10-01T18:49:15
|
|
Fixed MinGW-w64 build warnings in SDL_render_d3d11.c
Some of these were legitimate bugs, including:
- a malformed SDL_snprintf call
- a probably-invalid enum comparison
|
|
|
702d9348
|
2016-10-01T15:23:43
|
|
Added SDL prefix to local IID constants
|
|
|
7851eb08
|
2016-10-01T18:10:15
|
|
Fixed bug 3437 - build error for WinRT/UWP .dlls, caused by fix for SDL bug 3336
This fix has been tested with both MinGW-w64, and Visual C++ 2012-2015.
|
|
|
fa0f4176
|
2016-10-01T14:48:18
|
|
Fixed build warnings and errors
|
|
|
c8cfccc2
|
2016-10-01T14:31:00
|
|
Fixed bug 3116 - renderer->hidden in SDL_RenderCopy(Ex)
Daniel
Seems like check of the visibility of renderer (renderer->hidden) is missing in SDL_RenderCopyEx.
In SDL_RenderCopy it should be done much earlier (after checking support for RenderCopyEx, line 1750).
|
|
|
ecea3c4a
|
2016-10-01T13:33:32
|
|
Fixed bug 3169 - GLES2_CreateRenderer does not check SDL_GL_GetAttribute result, causing use of uninitialized data
Yann Dirson
When attempting to force use of opengles2 renderer with:
int wanted_renderer = -1;
for (int i = 0; i < numrenderers; i++) {
SDL_RendererInfo renderer_info;
if (SDL_GetRenderDriverInfo(i, &renderer_info) != 0) {
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't get renderer driver info: %s\n",
SDL_GetError());
quit(2);
}
std::cerr << "Renderer " << i << " '" << renderer_info.name << "': flags=0x"
<< std::hex << renderer_info.flags << std::dec
<< ", " << renderer_info.num_texture_formats << " texture formats, max="
<< renderer_info.max_texture_width << "x"
<< renderer_info.max_texture_height << "\n";
if (!strcmp(renderer_info.name, "opengles2")) {
std::cerr << " selecting!\n";
wanted_renderer = i;
}
}
renderer = SDL_CreateRenderer(window, wanted_renderer, 0);
... on banana pi or raspberry pi I get an error like the following (the actual
context profile value varies, being used uninitialized)
ERROR: Couldn't create renderer: Unknown OpenGL context profile 900
With this patch I get the following, which should help more pointing to a real problem:
ERROR: Couldn't create renderer: Failed getting OpenGL glGetString entry point
I pushed a patch (based on master branch of unofficial git mirror):
https://github.com/O-Computers/SDL/commit/550389c89f4e73a0a5294f95b9f6e6c18ba48509
I'll be opening a different bug for the underlying issue.
|
|
|
67901f53
|
2016-10-01T13:29:30
|
|
Fixed bug 3174 - SDL_SetRenderTarget clip rect
Marcel Bakker
In SDL_SetRenderTarget(),
i think the intended behavior was to clear the clip rect when a new target is set.
|
|
|
86b4319d
|
2016-10-01T13:07:36
|
|
Fixed bug 3422 - OpenGL ES 1.1 renderer: SDL_UpdateTexture breaks later function calls (missing glDisable)
ny00
Using the OpenGL ES 1.1 renderer, after updating a texture with SDL_UpdateTexture (or SDL_UnlockTexture), a following call to SDL_RenderFillRect draws a rectangle with the wrong color (which appears to be the same as the texture's top-left pixel).
Comparing SDL_render_gles.c:GLES_UpdateTexture to SDL_render_gl.c:GL_UpdateTexture, a missing call to glDisable appears to be the cause. After adding it back, the bug is resolved.
|
|
|
77305d47
|
2016-10-01T11:46:32
|
|
Fixed bug 3345 - SDL_RenderClear inconsistency with ClipRect
Simon Hug
The description of the SDL_RenderClear function in the SDL_render.h header says the following:
"This function clears the entire rendering target, ignoring the viewport."
The word "entire" implies that the clipping rectangle set with SDL_RenderSetClipRect also gets ignored. This is left somewhat ambiguous if only the viewport is mentioned. Minor thing, but let's see what the implementations actually do.
The software renderer ignores the clipping rectangle when clearing. It even has a comment on this: /* By definition the clear ignores the clip rect */
Most other render drivers (opengl, opengles, opengles2, direct3d, and psp [I assume. Can't test it.]) use the scissor test for the ClipRect and don't disable it when clearing. Clearing will only happen within the clipping rectangle for these drivers.
An exception is direct3d11 which uses a clear function that ignores the scissor test.
|
|
|
89c868f4
|
2016-10-01T11:40:57
|
|
Fixed bug 3347 - OpenGL ES renderer doesn't flip projection matrix for target textures
Simon Hug
When updating the viewport in GLES_UpdateViewport, the OpenGL ES renderer doesn't flip the projection matrix for target textures. The lines, rectangles and textures (if drawn with glDrawArrays) are upside down when drawing to target textures.
|
|
|
061cc5e7
|
2016-10-01T11:38:53
|
|
Fixed bug 3349 - GLES2_RenderReadPixels doesn't use target texture format
Simon Hug
The OpenGL ES 2 renderer does not check the target texture format when using SDL_RenderReadPixels and just always uses ABGR8888. This can result in swapped or wrong colors.
The attached patch adds a check and selects the target texture format, if a texture is set as the target.
|
|
|
51d6371e
|
2016-10-01T11:34:04
|
|
Fixed bug 3350 - GL renderers don't need to flip rows after reading back pixels from the target texture
Simon Hug
All OpenGL renderers always flip the rows of the pixels that come from glReadPixels. This is unnecessary for target textures since these are already top down.
Also, the rect->y value can be used directly for target textures for the same reason. I don't see any code that would handle the logical render size for target textures. Or am I missing something?
The attached patch makes the renderers only the flip rows if the data comes from the default framebuffer.
|
|
|
a42c396a
|
2016-10-01T11:04:45
|
|
Fixed bug 3361 - Texture color modulation doesn't work with active NONE blend mode (opengl and opengles)
Simon Hug
The GL_SetBlendMode and GLES_SetBlendMode functions of the opengl and opengles renderers call the glTexEnvf to set the texture env mode to either GL_MODULATE (the default) or GL_REPLACE for the NONE blend mode. Using GL_REPLACE disables color and alpha modulation for textures.
These glTexEnv calls were put in the SetBlendMode function back in 2006 [1], but there the NONE code still used the GL_DECAL mode. The GL_REPLACE mode came in 2008 [2]. I'm a bit confused why that wasn't always GL_MODULATE and a bit surprised nobody reported that yet (unless I missed it). I guess only a few use the gles renderer and the newish shaders mask the issue.
|
|
|
3f1b1629
|
2016-10-01T10:52:24
|
|
Fixed bug 3362 - OpenGL renderer doesn't check if framebuffers are supported when creating target textures
Simon Hug
The GL_CreateTexture function doesn't have any checks for the case where the driver doesn't support the framebuffer object extension. It will call into GL_GetFBO which will call the non-existent glGenFramebuffersEXT.
Also, for some reason GL_CreateContext always sets the SDL_RENDERER_TARGETTEXTURE info flag, even if it is not supported. Changeset cc226dce7536 [1] makes this change, but doesn't explain why. It seems to me like the code would already have taken care of this [2].
The attached patch adds some checks and stops SDL from reporting render target support if there is none. The application can then properly inform the user instead of just crashing.
|
|
|
2ccb46ce
|
2016-10-01T10:43:01
|
|
Fixed bug 3373 - OpenGL implementation differences of glDrawTexfOES
Simon Hug
It seems not everyone implemented glDrawTexfOES the same. Intel and Mesa ignore the viewport entirely, whereas the Raspberry Pi implementation offsets the coordinates and does viewport clipping.
The glDrawTexfOES extension text [1] for the function says "Xs and Ys are given directly in window (viewport) coordinates." I guess this wasn't clear enough.
Alex Szpakowski
Honestly I'd probably remove that codepath from SDL_Render entirely. It's an OpenGL ES 1-specific extension that isn't likely to give huge performance gains and adds additional maintenance overhead to SDL_Render while also having bugs in some drivers (as seen here).
|
|
|
b7e45f8a
|
2016-10-01T10:28:00
|
|
Fixed bug 3336 - Failure to build with MinGW-w64
Kai Sterker
There are already patches available from mingw64 that fix the issue
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-SDL2
With those applied, I could compile SDL2 without problems. But of course, it would be preferable if SDL built cleanly from source.
|
|
|
86d4b099
|
2016-09-13T18:44:28
|
|
Fixed spacing
|
|
f0505766
|
2016-09-13T22:18:06
|
|
Initial Apple TV / tvOS support.
The Apple TV remote is currently exposed as a joystick with its touch surface treated as two axes. Key presses are also generated when its buttons and touch surface are used.
A new hint has been added to help deal with deciding whether to background the app when the remote's menu button is pressed: SDL_HINT_APPLE_TV_CONTROLLER_UI_EVENTS.
|
|
|
23af328b
|
2016-06-24T22:17:56
|
|
Fixed Bug 3147 - Windows: Crash when resizing Window since hg 1f9d57965528
Thanks for the fix, Gab!
|
|
|
831597f7
|
2016-04-01T21:13:58
|
|
PSP: Fixed returning success from unsupported SDL_RenderReadPixels().
This also fixed the missing error message.
|
|
|
d1e48141
|
2016-04-01T21:12:37
|
|
PSP: Fixed returning success for unsupported SDL_SetTextureColorMod().
Partially fixes Bugzilla #3298.
|
|
|
0a1999df
|
2016-01-16T21:25:10
|
|
Fixed compile warnings about type conversion.
Found by buildbot.
|
|
167cf14c
|
2016-01-05T16:39:18
|
|
SDL_RenderSetIntegerScale
|
|
|
42065e78
|
2016-01-02T10:10:34
|
|
Updated copyright to 2016
|
|
|
f893ce3d
|
2015-12-28T15:15:58
|
|
OpenGL+GLES renderers: Fixed incorrect clip rectangle coords (thanks, Marcel!).
Fixes Bugzilla #2700.
|
|
|
9e9ef5ad
|
2015-12-27T17:55:45
|
|
Fixed bug 3202 - Fix renderer visibility on a window maximized directly from the minimized state
Many thanks to id.zeta for details on the bug, and for the fix!
|
|
|
0c463d77
|
2015-12-10T20:25:34
|
|
SDL_GL_GetAttribute: If a GL context isn't active, only return failure when the specified attribute needs an active GL context to be queried.
|
|
|
25abce51
|
2015-11-29T19:33:11
|
|
WinRT: added Win10/UWP (Universal Windows Platform) support
"UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs.
This set of changes updates SDL's WinRT backends to support the Win10 flavor
of WinRT. It has been tested on Win10 on a desktop. In theory, it should
also support Win10 on other devices (phone, Xbox One, etc.), however further
patches may be necessary.
This adds:
- a set of MSVC 2015 project files, for use in creating UWP apps
- modifications to various pieces of SDL, in order to compile via MSVC 2015 +
the Win10 API set
- enables SDL_Window resizing and programmatic-fullscreen toggling, when using
the WinRT backend
- WinRT README updates
|
|
|
623898f7
|
2015-11-26T00:41:39
|
|
WinRT: lots of display and windowing related fixes
This change-set fixes a lot of windowing related bugs, especially with
regards to Windows 8.x apps running on Windows 10 (which was the driver for
this work). The primary fixes include:
* listed display modes were wrong, especially when launching apps into a
non-fullscreen space
* reported window flags were often wrong, especially on Windows 10
* fullscreen/windowed mode switches weren't failing (they are not
programmatically possible in Win 8.x apps).
|
|
|
4c72d39c
|
2015-10-15T22:26:21
|
|
D3D11: Fixed SDL_RenderDrawPoints() ignoring input after the first 128 points.
If a limit would be needed then count should be adapted before stack allocation.
|
|
|
0856a7ef
|
2015-08-21T23:50:37
|
|
Changed an error return value from 0 to NULL for consistency.
|
|
|
ded3a16e
|
2015-06-23T01:44:44
|
|
Fixed compiler warning about shadowed local variables.
|
|
|
0e45984f
|
2015-06-21T17:33:46
|
|
Fixed crash if initialization of EGL failed but was tried again later.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
|