|
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.
|
|
97aa5775
|
2016-11-16T22:08:51
|
|
Fixed empty parameter list in signatures of internal functions.
|
|
|
57d01d7d
|
2016-11-13T22:57:41
|
|
Patch from Sylvain to fix clang warnings
|
|
|
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
|
|
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
|
|
|
67bf5cac
|
2016-10-02T22:32:35
|
|
Fixed wrong pixel format if reading pixels from OpenGL renderer.
|
|
|
fa0f4176
|
2016-10-01T14:48:18
|
|
Fixed build warnings and errors
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
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.
|
|
|
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().
|