kmx git

Commit	Date	Message
3b191580	2022-06-27T17:19:39	Windows GDK Support (#5830) * Added GDK * Simplfied checks in SDL_config_wingdk.h * Added testgdk sample * Added GDK readme * Fixed error in merge of SDL_windows.h * Additional GDK fixes * OpenWatcom should not export _SDL_GDKGetTaskQueue * Formatting fixes * Moved initialization code into SDL_GDKRunApp
adc68758	2022-06-17T10:22:28	Added SDL_copyp to avoid size mismatch when copying values (thanks @1bsyl!) Closes https://github.com/libsdl-org/SDL/pull/5811
981e1e3c	2022-04-23T10:32:40	Fixed logical size synchronization issue on macOS https://discourse.libsdl.org/t/sdl-2-0-22-prerelease/35306/6
cb816308	2022-04-08T02:21:52	render: Update the size/scale/viewport on moves, in addition to resizes. For OpenGL this means resetting the viewport state shadowing flag too. Fixes #1504
95c0fec5	2022-03-31T12:35:17	Vita: PVROGL: fix indentation and ifdef guards
8c542a35	2022-03-29T19:08:56	Desktop OpenGL 1.X/2.X PSVita Support
3f8b450d	2022-02-05T12:22:34	extend the code hidden by SDL_HAVE_YUV
b064ad6a	2022-03-08T18:14:10	Allow GL_ARB_texture_non_power_of_two environment variable to override OpenGL 2.0 check
60ddb74c	2022-02-02T12:19:37	video: rework how we prepare a texture framebuffer. Now we see if we can create an SDL_Renderer, and if that renderer reports itself as "accelerated," and added some initial heuristics to the OpenGL renderer to make better decisions about what qualifies as "accelerated." This adds some FIXMEs that might be merely hypothetical, and removes the old OpenGL checks from the video subsystem that probably weren't meaningful in modern times. This will definitely need to improve the existing list in the GL renderer, to catch things like llvmpipe, etc. Reference issue #4624.
293a0aa8	2022-02-22T10:54:21	opengl: If GL version >= 2.0, NPOT textures are supported, so favor them. Fixes #5041.
b0dd4c7d	2022-01-10T09:22:07	SDL_Render OpenGL: do batching like in the GLES2 backend (with no VBO)
90f0d2ce	2022-01-10T09:17:50	Revert OpenGL point drawing performance, do to proper batching
b82af9df	2022-01-08T14:05:50	Improved OpenGL point drawing performance (thanks @slime73!) We'll do proper call batching for the SDL 2.0.22 release
1a73c45a	2022-01-08T13:34:49	Fixed incorrect color in the OpenGL driver
18e4d9fe	2022-01-08T09:02:25	Re-enable line drawing path in render drivers This is still used for scaled line drawing in RenderDrawLinesWithRects()
9aac5531	2022-01-07T22:42:52	Remove QueueDrawLines from GL, GLES, GLES2
120c76c8	2022-01-03T09:40:00	Updated copyright for 2022
724468ae	2021-12-13T15:48:55	GL renderer uses glDrawArrays instead of glBegin/glEnd. Also change internal colors sent to GL to use unorm8 components instead of float, for improved performance.
3a5e148b	2021-12-14T11:02:07	Renderer backends use SDL_Color instead of int for geometry colors.
b786c100	2021-11-26T19:45:16	SDL_render_gl.c: GL_RunCommandQueue: always set viewport_dirty on macOS Without this, moving the window changes the viewport and causes contents to render stretched. Fixes #1504
8dd6edec	2021-11-23T09:30:42	Fixed bug #3232 - Integer overflow generates Illegal instruction under sanitizers + see bug #4995
f02ad282	2021-09-25T11:31:18	Remove FillRects from back-end, where RenderGeometry can be used
d1925154	2021-09-20T16:33:49	OpenGL: remove RenderCopy and RenderCopyEx from back-end
b360965d	2021-10-21T20:48:05	Added a hint for alternate OpenGL NV12 data format
a34fe816	2021-10-21T12:28:35	Added the ability to bind NV12 textures in the OpenGL renderer
eb3bf80f	2021-09-21T18:15:09	Fixed compiler warnings using Visual Studio 2019
ca9a3217	2021-09-19T15:47:24	render: GL/GLES now draw lines almost perfectly matching software renderer. One place known to differ in a significant way is a single line segment that starts and ends on the same point; the GL renderers will light up a single pixel here, whereas the software renderer will not. My current belief is this is a bug in the software renderer, based on the wording of the docs: "SDL_RenderDrawLine() draws the line to include both end points." You can see an example program that triggers that difference in Bug #2006. As it stands, the GL renderers might _also_ render diagonal lines differently, as the the Bresenham step might vary between implementations (one does three pixels and then two, the other does two and then three, etc). But this patch causes those lines to start and end on the correct pixel, and that's the best we can do, and all anyone really needs here. Not closing any bugs with this patch (yet!), but here are several that it appears to fix. If no other corner cases pop up, we'll call this done. Reference Bug #2006. Reference Bug #1626. Reference Bug #4001. ...and probably others...
5faea84c	2021-09-18T11:54:25	render: Mark viewport/cliprect dirty when window is resized. Fixes #4751.
4549769d	2021-03-07T15:20:45	Add `SDL_RenderSetVSync()` Currently, if an application wants to toggle VSync, they'd have to tear down the renderer and recreate it. This patch fixes that by letting applications call SDL_RenderSetVSync(). This is the same as the patch in #3673, except it applies to all renderers (including PSP, even thought it seems that the VSync flag is disabled for that renderer). Furthermore, the renderer flags also change as well, which #3673 didn't do. It is also an API instead of using hint callbacks (which could be potentially dangerous). Closes #3673.
183eb067	2021-09-01T15:46:32	Fixed bug #4711: prevent opengl SDL_renderer from crashing if GL_ARB_multitexture isn't supported
54ca1d19	2021-08-27T07:44:03	SW_RenderGeometry: add a redundant check to clear static analysis (see bug #4600)
f73c1eff	2021-03-17T09:58:49	Use normalized texture coordinates
37f78fc1	2021-03-16T15:13:15	Add OpenGL implementation
a8f89a01	2021-04-23T12:00:14	Change 'size_indice' to 'size_indices'
47db47c1	2021-04-06T21:32:02	Add SDL_HAVE_RENDER_GEOMETRY to compile or not with RenderGeometry support
cd0663e0	2021-04-01T11:47:45	Fix declaration-after-statement and remove tabs
e4812611	2021-04-01T09:49:16	Move to SDL_RenderGeometryRaw prototype with separate xy/uv/color pointer parameters
b99543b6	2021-01-11T20:40:11	opengl: More work on making line drawing match software renderer.
c0df40e0	2021-01-05T17:39:48	Add more SDL_HAVE_YUV defines
be4cfd51	2021-01-05T11:56:22	Add SDL_UpdateNVTexture() to update NV12/21 Texture (bug #5430) for renderer software, opengl, and opengles2
9130f7c3	2021-01-02T10:25:38	Updated copyright for 2021
cb361896	2020-12-09T07:16:22	Fixed bug 5235 - All internal sources should include SDL_assert.h Ryan C. Gordon We should really stick this in SDL_internal.h or something so it's always available.
754286c6	2020-12-02T13:45:24	SDL Renderer: specify the correct flag when recreating the window
0e4ce848	2020-11-08T20:57:17	opengl: Make diagonal lines match the software renderer. OpenGL leaves the final line segment open, SDL's software renderer does not, so we need a tiny bit of trigonometry here to move one more pixel in the right direction.
93a2c58c	2020-11-08T12:37:09	opengl: Use GL_LINE_STRIP instead of breaking down into seperate GL_LINES. Surely GL drivers have improved in the last seven years. I hope...?
c33f8083	2020-10-20T11:12:49	render: Restoring line rendering fixes that were previously put on hold. (Backed out hg changeset 7a4240daba46)
b6afbe63	2020-04-07T09:38:57	Added SDL_log.h to SDL_internal.h so logging is available everywhere
19a5f4ab	2020-03-22T14:32:47	opengl: Don't enable/disable texturing except when actually rendering. Otherwise our cached state goes out of sync when updating a texture. Since these state changes aren't necessary, they were removed instead of updating the cached state. Fixes Bugzilla #4998.
93b26f17	2020-02-17T16:15:04	opengl: Backed out hg changeset 94f9f40a957f This is the OpenGL line drawing fix for Bugzilla #3182, but there's some disagreement about what the renderers should do here, so I'm backing this out until after 2.0.12 ships, and then we'll reevaluate all the renderer backends to decide what's correct, and make them all work the same.
ed10d947	2020-02-10T12:53:54	opengl: Build out full GL_LINES and respect the diamond-exit rule. Likewise for the GLES1 and GLES2 renderers. This solves the missing pixel at the end of a line and removes all the heuristics for various platforms/drivers. It's possible we could still use GL_LINE_STRIP with this and save some vertex buffer space, assuming this doesn't upset some driver somewhere, but this seems to be a clean fix that makes the GL renderers match the software renderer output. Diamond-exit rule explanation: http://graphics-software-engineer.blogspot.com/2012/04/rasterization-rules.html Fixes Bugzilla #3182.
a8780c6a	2020-01-16T20:49:25	Updated copyright date for 2020
5e19e66c	2019-12-22T13:39:44	Fixed bug 4914 - Expose SDL_ScaleMode and add SDL_SetTextureScaleMode/SDL_GetTextureScaleMode Konrad This was something rather trivial to add, but asked at least several times before (I did google about it as well). It should be possible to dynamically change scaling mode of the texture. It is actually trivial task, but until now it was only possible with a hint before creating a texture. I needed it for my game as well, so I took the liberty of writing it myself. This patch adds following functions: SDL_SetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode scaleMode); SDL_GetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode *scaleMode); That way you can change texture scaling on the fly.
60d3965e	2019-10-30T15:36:17	Readability: remove redundant return, continue, enum declaration
72660a51	2019-10-13T20:52:52	Fixed bug 4825 - SDL Renderer OpenGL: Buffer overflow (SDL_RENDERCMD_DRAW_LINES)
0c263738	2019-08-26T18:49:04	gl/gles/gles2 render: fix SDL_RenderClear being affected by the clip rect in some situations.
7162649f	2019-06-18T18:58:39	opengl: Be more robust in failing cases. Load all possible symbols, not just until one fails, in case they get used during shutdown, etc. Fixes Bugzilla #4093.
2ee9b1dd	2019-05-19T11:01:36	Fixed bug 4025 - SDL_Renderer OpenGL : add support for textures ABGR, RGB, BGR Sylvain OpenGLES2 SDL renderer has support for textures ARGB, ABGR, RGB and BGR, whereas OpenGL SDL renderer only had ARGB. If you think it's worth adding it, here's a patch. I quickly tried and it worked, but there may be missing things or corner case.
b2e76d86	2019-03-19T16:52:09	Fixed Windows RT build
b28e956b	2019-03-12T07:59:53	Fixed bug 4542 - Image flipped vertically when rendering on texture Have to recompute viewport because projection/glOrtho is different wether rendering is on target texture or not
40a52cee	2019-02-04T18:55:39	render: Fix OpenGL draw state cache for various points of texture binding.
5e13087b	2019-01-04T22:01:14	Updated copyright for 2019
dc344360	2018-12-21T20:53:31	render: Fix internal state getting out of sync when destroying a texture that was just rendered and then creating a new one, in the GL and GLES2 backends. Fixes bug #4433.
9719f89d	2018-11-17T12:12:29	Back out change initializing renderer blend mode incorrectly.
29e15ce6	2018-11-17T00:58:45	The default draw blendmode is SDL_BLENDMODE_NONE
329f2eb9	2018-10-31T20:17:53	Fix crash when GL_LoadFunctions()/GLES2_LoadFunctions() fails https://bugzilla.libsdl.org/show_bug.cgi?id=4350 We can't safely call GL_DestroyRenderer() until GL_LoadFunctions() succeeds because we will be missing functions that we try to use when activating the renderer for destruction if we have an GL context.
62494a2e	2018-10-31T15:03:41	Merge SDL-ryan-batching-renderer branch to default.
b262b0eb	2018-10-22T20:50:32	Small stack allocations fall back to malloc if they're unexpectedly large.
0c2e10dc	2018-10-01T22:53:45	render: Make the GL backends cache and defer more state changes.
d04e5524	2018-09-25T19:20:31	render: OpenGL renderer now caches some state, to improve non-batching mode. (other minor bug fixes in here, too)
c01da217	2018-09-24T12:30:47	render: get rid of the predeclared functions in the GL and Metal renderers. (others to come as I continue to update render backends!)
051d1cfc	2018-09-24T02:08:34	render: Make opengl backend take advantage of new high-level features.
2241b33f	2018-09-23T23:22:56	render: Update Metal and GL backends to use new high-level features, etc. Now nothing is uploaded as dynamic data with Metal's setVertexBytes, etc; it's all in the one big vertex buffer, now.
55cb9966	2018-09-20T16:36:54	render: first shot at reworking opengl backend for new batching system.
eb14b635	2018-05-07T19:52:25	Fixed bug 4134 - Render targets lose scale quality after minimizing a fullscreen window Olli-Samuli Lehmus If one creates a window with the SDL_WINDOW_FULLSCREEN_DESKTOP flag, and creates a render target with SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear"), and afterwards sets SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "nearest"), after minimizing the window, the scale quality hint is lost on the render target. Textures however do keep their interpolation modes.
40b27fd5	2018-02-12T17:00:00	revert the recent typecast assignment changes (see bug #4079) also change the void* typedefs for the two vulkan function pointers added in vulkan_internal.h into generic function pointer typedefs.
90e72bf4	2018-01-30T18:08:34	Fixed ISO C99 compatibility SDL now builds with gcc 7.2 with the following command line options: -Wall -pedantic-errors -Wno-deprecated-declarations -Wno-overlength-strings --std=c99
e3cc5b2c	2018-01-03T10:03:25	Updated copyright for 2018
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.
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
c68d3ab7	2017-08-17T21:35:46	Watcom supports __FUNCTION__ identifier (and surely not __PRETTY_FUNCTION__) Partially fixes Bugzilla #3758.
9451cd81	2017-08-14T20:07:30	Fixed compiler warnings
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);
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.
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.
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.
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.
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.

3b191580

2022-06-27T17:19:39

Windows GDK Support (#5830) * Added GDK * Simplfied checks in SDL_config_wingdk.h * Added testgdk sample * Added GDK readme * Fixed error in merge of SDL_windows.h * Additional GDK fixes * OpenWatcom should not export _SDL_GDKGetTaskQueue * Formatting fixes * Moved initialization code into SDL_GDKRunApp

adc68758

2022-06-17T10:22:28

Added SDL_copyp to avoid size mismatch when copying values (thanks @1bsyl!) Closes https://github.com/libsdl-org/SDL/pull/5811

981e1e3c

2022-04-23T10:32:40

Fixed logical size synchronization issue on macOS https://discourse.libsdl.org/t/sdl-2-0-22-prerelease/35306/6

cb816308

2022-04-08T02:21:52

render: Update the size/scale/viewport on moves, in addition to resizes. For OpenGL this means resetting the viewport state shadowing flag too. Fixes #1504

95c0fec5

2022-03-31T12:35:17

Vita: PVROGL: fix indentation and ifdef guards

8c542a35

2022-03-29T19:08:56

Desktop OpenGL 1.X/2.X PSVita Support

3f8b450d

2022-02-05T12:22:34

extend the code hidden by SDL_HAVE_YUV

b064ad6a

2022-03-08T18:14:10

Allow GL_ARB_texture_non_power_of_two environment variable to override OpenGL 2.0 check

60ddb74c

2022-02-02T12:19:37

video: rework how we prepare a texture framebuffer. Now we see if we can create an SDL_Renderer, and if that renderer reports itself as "accelerated," and added some initial heuristics to the OpenGL renderer to make better decisions about what qualifies as "accelerated." This adds some FIXMEs that might be merely hypothetical, and removes the old OpenGL checks from the video subsystem that probably weren't meaningful in modern times. This will definitely need to improve the existing list in the GL renderer, to catch things like llvmpipe, etc. Reference issue #4624.

293a0aa8

2022-02-22T10:54:21

opengl: If GL version >= 2.0, NPOT textures are supported, so favor them. Fixes #5041.

b0dd4c7d

2022-01-10T09:22:07

SDL_Render OpenGL: do batching like in the GLES2 backend (with no VBO)

90f0d2ce

2022-01-10T09:17:50

Revert OpenGL point drawing performance, do to proper batching

b82af9df

2022-01-08T14:05:50

Improved OpenGL point drawing performance (thanks @slime73!) We'll do proper call batching for the SDL 2.0.22 release

1a73c45a

2022-01-08T13:34:49

Fixed incorrect color in the OpenGL driver

18e4d9fe

2022-01-08T09:02:25

Re-enable line drawing path in render drivers This is still used for scaled line drawing in RenderDrawLinesWithRects()

9aac5531

2022-01-07T22:42:52

Remove QueueDrawLines from GL, GLES, GLES2

120c76c8

2022-01-03T09:40:00

Updated copyright for 2022

724468ae

2021-12-13T15:48:55

GL renderer uses glDrawArrays instead of glBegin/glEnd. Also change internal colors sent to GL to use unorm8 components instead of float, for improved performance.

3a5e148b

2021-12-14T11:02:07

Renderer backends use SDL_Color instead of int for geometry colors.

b786c100

2021-11-26T19:45:16

SDL_render_gl.c: GL_RunCommandQueue: always set viewport_dirty on macOS Without this, moving the window changes the viewport and causes contents to render stretched. Fixes #1504

8dd6edec

2021-11-23T09:30:42

Fixed bug #3232 - Integer overflow generates Illegal instruction under sanitizers + see bug #4995

f02ad282

2021-09-25T11:31:18

Remove FillRects from back-end, where RenderGeometry can be used

d1925154

2021-09-20T16:33:49

OpenGL: remove RenderCopy and RenderCopyEx from back-end

b360965d

2021-10-21T20:48:05

Added a hint for alternate OpenGL NV12 data format

a34fe816

2021-10-21T12:28:35

Added the ability to bind NV12 textures in the OpenGL renderer

eb3bf80f

2021-09-21T18:15:09

Fixed compiler warnings using Visual Studio 2019

ca9a3217

2021-09-19T15:47:24

render: GL/GLES now draw lines almost perfectly matching software renderer. One place known to differ in a significant way is a single line segment that starts and ends on the same point; the GL renderers will light up a single pixel here, whereas the software renderer will not. My current belief is this is a bug in the software renderer, based on the wording of the docs: "SDL_RenderDrawLine() draws the line to include both end points." You can see an example program that triggers that difference in Bug #2006. As it stands, the GL renderers might _also_ render diagonal lines differently, as the the Bresenham step might vary between implementations (one does three pixels and then two, the other does two and then three, etc). But this patch causes those lines to start and end on the correct pixel, and that's the best we can do, and all anyone really needs here. Not closing any bugs with this patch (yet!), but here are several that it appears to fix. If no other corner cases pop up, we'll call this done. Reference Bug #2006. Reference Bug #1626. Reference Bug #4001. ...and probably others...

5faea84c

2021-09-18T11:54:25

render: Mark viewport/cliprect dirty when window is resized. Fixes #4751.

4549769d

2021-03-07T15:20:45

Add `SDL_RenderSetVSync()` Currently, if an application wants to toggle VSync, they'd have to tear down the renderer and recreate it. This patch fixes that by letting applications call SDL_RenderSetVSync(). This is the same as the patch in #3673, except it applies to all renderers (including PSP, even thought it seems that the VSync flag is disabled for that renderer). Furthermore, the renderer flags also change as well, which #3673 didn't do. It is also an API instead of using hint callbacks (which could be potentially dangerous). Closes #3673.

183eb067

2021-09-01T15:46:32

Fixed bug #4711: prevent opengl SDL_renderer from crashing if GL_ARB_multitexture isn't supported

54ca1d19

2021-08-27T07:44:03

SW_RenderGeometry: add a redundant check to clear static analysis (see bug #4600)

f73c1eff

2021-03-17T09:58:49

Use normalized texture coordinates

37f78fc1

2021-03-16T15:13:15

Add OpenGL implementation

a8f89a01

2021-04-23T12:00:14

Change 'size_indice' to 'size_indices'

47db47c1

2021-04-06T21:32:02

Add SDL_HAVE_RENDER_GEOMETRY to compile or not with RenderGeometry support

cd0663e0

2021-04-01T11:47:45

Fix declaration-after-statement and remove tabs

e4812611

2021-04-01T09:49:16

Move to SDL_RenderGeometryRaw prototype with separate xy/uv/color pointer parameters

b99543b6

2021-01-11T20:40:11

opengl: More work on making line drawing match software renderer.

c0df40e0

2021-01-05T17:39:48

Add more SDL_HAVE_YUV defines

be4cfd51

2021-01-05T11:56:22

Add SDL_UpdateNVTexture() to update NV12/21 Texture (bug #5430) for renderer software, opengl, and opengles2

9130f7c3

2021-01-02T10:25:38

Updated copyright for 2021

cb361896

2020-12-09T07:16:22

Fixed bug 5235 - All internal sources should include SDL_assert.h Ryan C. Gordon We should really stick this in SDL_internal.h or something so it's always available.

754286c6

2020-12-02T13:45:24

SDL Renderer: specify the correct flag when recreating the window

0e4ce848

2020-11-08T20:57:17

opengl: Make diagonal lines match the software renderer. OpenGL leaves the final line segment open, SDL's software renderer does not, so we need a tiny bit of trigonometry here to move one more pixel in the right direction.

93a2c58c

2020-11-08T12:37:09

opengl: Use GL_LINE_STRIP instead of breaking down into seperate GL_LINES. Surely GL drivers have improved in the last seven years. I hope...?

c33f8083

2020-10-20T11:12:49

render: Restoring line rendering fixes that were previously put on hold. (Backed out hg changeset 7a4240daba46)

b6afbe63

2020-04-07T09:38:57

Added SDL_log.h to SDL_internal.h so logging is available everywhere

19a5f4ab

2020-03-22T14:32:47

opengl: Don't enable/disable texturing except when actually rendering. Otherwise our cached state goes out of sync when updating a texture. Since these state changes aren't necessary, they were removed instead of updating the cached state. Fixes Bugzilla #4998.

93b26f17

2020-02-17T16:15:04

opengl: Backed out hg changeset 94f9f40a957f This is the OpenGL line drawing fix for Bugzilla #3182, but there's some disagreement about what the renderers should do here, so I'm backing this out until after 2.0.12 ships, and then we'll reevaluate all the renderer backends to decide what's correct, and make them all work the same.

ed10d947

2020-02-10T12:53:54

opengl: Build out full GL_LINES and respect the diamond-exit rule. Likewise for the GLES1 and GLES2 renderers. This solves the missing pixel at the end of a line and removes all the heuristics for various platforms/drivers. It's possible we could still use GL_LINE_STRIP with this and save some vertex buffer space, assuming this doesn't upset some driver somewhere, but this seems to be a clean fix that makes the GL renderers match the software renderer output. Diamond-exit rule explanation: http://graphics-software-engineer.blogspot.com/2012/04/rasterization-rules.html Fixes Bugzilla #3182.

a8780c6a

2020-01-16T20:49:25

Updated copyright date for 2020

5e19e66c

2019-12-22T13:39:44

Fixed bug 4914 - Expose SDL_ScaleMode and add SDL_SetTextureScaleMode/SDL_GetTextureScaleMode Konrad This was something rather trivial to add, but asked at least several times before (I did google about it as well). It should be possible to dynamically change scaling mode of the texture. It is actually trivial task, but until now it was only possible with a hint before creating a texture. I needed it for my game as well, so I took the liberty of writing it myself. This patch adds following functions: SDL_SetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode scaleMode); SDL_GetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode *scaleMode); That way you can change texture scaling on the fly.

60d3965e

2019-10-30T15:36:17

Readability: remove redundant return, continue, enum declaration

72660a51

2019-10-13T20:52:52

Fixed bug 4825 - SDL Renderer OpenGL: Buffer overflow (SDL_RENDERCMD_DRAW_LINES)

0c263738

2019-08-26T18:49:04

gl/gles/gles2 render: fix SDL_RenderClear being affected by the clip rect in some situations.

7162649f

2019-06-18T18:58:39

opengl: Be more robust in failing cases. Load all possible symbols, not just until one fails, in case they get used during shutdown, etc. Fixes Bugzilla #4093.

2ee9b1dd

2019-05-19T11:01:36

Fixed bug 4025 - SDL_Renderer OpenGL : add support for textures ABGR, RGB, BGR Sylvain OpenGLES2 SDL renderer has support for textures ARGB, ABGR, RGB and BGR, whereas OpenGL SDL renderer only had ARGB. If you think it's worth adding it, here's a patch. I quickly tried and it worked, but there may be missing things or corner case.

b2e76d86

2019-03-19T16:52:09

Fixed Windows RT build

b28e956b

2019-03-12T07:59:53

Fixed bug 4542 - Image flipped vertically when rendering on texture Have to recompute viewport because projection/glOrtho is different wether rendering is on target texture or not

40a52cee

2019-02-04T18:55:39

render: Fix OpenGL draw state cache for various points of texture binding.

5e13087b

2019-01-04T22:01:14

Updated copyright for 2019

dc344360

2018-12-21T20:53:31

render: Fix internal state getting out of sync when destroying a texture that was just rendered and then creating a new one, in the GL and GLES2 backends. Fixes bug #4433.

9719f89d

2018-11-17T12:12:29

Back out change initializing renderer blend mode incorrectly.

29e15ce6

2018-11-17T00:58:45

The default draw blendmode is SDL_BLENDMODE_NONE

329f2eb9

2018-10-31T20:17:53

Fix crash when GL_LoadFunctions()/GLES2_LoadFunctions() fails https://bugzilla.libsdl.org/show_bug.cgi?id=4350 We can't safely call GL_DestroyRenderer() until GL_LoadFunctions() succeeds because we will be missing functions that we try to use when activating the renderer for destruction if we have an GL context.

62494a2e

2018-10-31T15:03:41

Merge SDL-ryan-batching-renderer branch to default.

b262b0eb

2018-10-22T20:50:32

Small stack allocations fall back to malloc if they're unexpectedly large.

0c2e10dc

2018-10-01T22:53:45

render: Make the GL backends cache and defer more state changes.

d04e5524

2018-09-25T19:20:31

render: OpenGL renderer now caches some state, to improve non-batching mode. (other minor bug fixes in here, too)

c01da217

2018-09-24T12:30:47

render: get rid of the predeclared functions in the GL and Metal renderers. (others to come as I continue to update render backends!)

051d1cfc

2018-09-24T02:08:34

render: Make opengl backend take advantage of new high-level features.

2241b33f

2018-09-23T23:22:56

render: Update Metal and GL backends to use new high-level features, etc. Now nothing is uploaded as dynamic data with Metal's setVertexBytes, etc; it's all in the one big vertex buffer, now.

55cb9966

2018-09-20T16:36:54

render: first shot at reworking opengl backend for new batching system.

eb14b635

2018-05-07T19:52:25

Fixed bug 4134 - Render targets lose scale quality after minimizing a fullscreen window Olli-Samuli Lehmus If one creates a window with the SDL_WINDOW_FULLSCREEN_DESKTOP flag, and creates a render target with SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear"), and afterwards sets SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "nearest"), after minimizing the window, the scale quality hint is lost on the render target. Textures however do keep their interpolation modes.

40b27fd5

2018-02-12T17:00:00

revert the recent typecast assignment changes (see bug #4079) also change the void* typedefs for the two vulkan function pointers added in vulkan_internal.h into generic function pointer typedefs.

90e72bf4

2018-01-30T18:08:34

Fixed ISO C99 compatibility SDL now builds with gcc 7.2 with the following command line options: -Wall -pedantic-errors -Wno-deprecated-declarations -Wno-overlength-strings --std=c99

e3cc5b2c

2018-01-03T10:03:25

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.

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

c68d3ab7

2017-08-17T21:35:46

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

9451cd81

2017-08-14T20:07:30

Fixed compiler warnings

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

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.

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.

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.

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.

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.

kc3-lang/SDL/src/render/opengl/SDL_render_gl.c

src/render/opengl/SDL_render_gl.c

Log