|
c55ab963
|
2021-11-13T22:21:57
|
|
Added a hint for alternate OpenGL NV12 data format
|
|
b92056bb
|
2021-09-20T16:33:03
|
|
OpenGLES2: remove RenderCopy and RenderCopyEx from back-end
|
|
08797ada
|
2021-09-19T00:39:28
|
|
opengles2: Attempt to batch RenderCopy calls into a single glDrawArrays call.
|
|
|
502e9c3b
|
2021-10-24T17:16:49
|
|
SDL_Renderer simplifications:
- Factorize PrepQueueCmdDraw{,DrawTexture,Solid) into one single function
- Change SDL_Texture/Renderer r,g,b,a Uint8 into an SDL_Color, so that it can be passed directly to RenderGeometry
- Don't automatically queue a SET_DRAW_COLOR cmd for RenderGeometry (and update GLES2 renderer)
|
|
|
99a34643
|
2021-09-24T09:42:04
|
|
OpenGLES2: LINES and POINTS successive commands are combined into a single draw call
(using the same case for DRAW_GEOMETRY)
|
|
|
f0cdc1d0
|
2021-09-24T09:38:25
|
|
OpenGLES2: remove FillRects, since it's can be done with RenderGeometry
|
|
|
b0eef52f
|
2021-09-23T22:32:29
|
|
GLES2 batching: probably need to check for blendMode changes
|
|
|
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.
|
|
|
54ca1d19
|
2021-08-27T07:44:03
|
|
SW_RenderGeometry: add a redundant check to clear static analysis (see bug #4600)
|
|
|
154384a7
|
2021-08-18T23:59:27
|
|
Add (uintptr_t) casts
|
|
|
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
|
|
|
b9bd9da7
|
2021-04-04T22:34:17
|
|
OpenGLES2: transfert color as 4 bytes, instead of 4 floats
|
|
|
32e79101
|
2021-04-01T20:27:22
|
|
Fix warnings
|
|
|
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
|
|
|
f73c1eff
|
2021-03-17T09:58:49
|
|
Use normalized texture coordinates
|
|
|
faded41a
|
2021-03-16T15:11:13
|
|
Add OpenGLES2 implementation
|
|
|
53a2608b
|
2021-03-14T22:32:17
|
|
Renderer opengles2: turn color Uniform into Attribute.
all attributes are copied interleaved (based on rmg-nik initial patch+
+ minor clean up of data structure
+ add check for colorswap
|
|
8f38ba4d
|
2021-07-29T18:02:47
|
|
Fix casts that should be using uintptr_t
This is needed to support CHERI, and thus Arm's experimental Morello
prototype, where pointers are implemented using unforgeable capabilities
that include bounds and permissions metadata to provide fine-grained
spatial and referential memory safety, as well as revocation by sweeping
memory to provide heap temporal memory safety.
On most systems (anything with a flat memory hierarchy rather than using
segment-based addressing), size_t and uintptr_t are the same type.
However, on CHERI, size_t is just an integer offset, whereas uintptr_t
is still a capability as described above. Casting a pointer to size_t
will strip the metadata and validity tag, and casting from size_t to a
pointer will result in a null-derived capability whose validity tag is
not set, and thus cannot be dereferenced without faulting.
The audio and cursor casts were harmless as they intend to stuff an
integer into a pointer, but using uintptr_t is the idiomatic way to do
that and silences our compiler warnings (which our build tool makes
fatal by default as they often indicate real problems). The iconv and
egl casts were true positives as SDL_iconv_t and iconv_t are pointer
types, as is NativeDisplayType on most OSes, so this would have trapped
at run time when using the round-tripped pointers. The gles2 casts were
also harmless; the OpenGL API defines this argument to be a pointer type
(and uses the argument name "pointer"), but it in fact represents an
integer offset, so like audio and cursor the additional idiomatic cast
is needed to silence the warning.
|
|
2e3dd0a6
|
2020-11-02T18:14:57
|
|
Remove debug log
|
|
|
80036230
|
2020-11-02T18:10:09
|
|
Cg shaders for vita gles2
|
|
|
f40551c5
|
2021-01-25T22:17:11
|
|
GLES2 SDL_Renderer: remove old ZUNE_HD defines and simplify shader cache
|
|
|
b99543b6
|
2021-01-11T20:40:11
|
|
opengl: More work on making line drawing match software renderer.
|
|
|
958e5d5b
|
2021-01-11T10:01:24
|
|
SDL_UpdateNVTexture: fixed pitch/bpp for GLES2 (bug #5430)
|
|
|
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.
|
|
|
da49f795
|
2020-11-08T19:56:12
|
|
opengles: use glDrawArrays() correctly with GL_LINE_STRIP.
|
|
|
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)
|
|
|
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.
|
|
|
b5849daf
|
2020-02-01T09:23:04
|
|
Fixed build warnings on Android
|
|
|
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.
|
|
|
9e509e4a
|
2019-10-30T16:45:53
|
|
SDL_render_gles2: remove ineffective widening cast
warning: either cast from 'int' to 'size_t' (aka 'unsigned long') is ineffective, or there is loss of precision before the conversion [bugprone-misplaced-widening-cast]
|
|
|
60d3965e
|
2019-10-30T15:36:17
|
|
Readability: remove redundant return, continue, enum declaration
|
|
0c263738
|
2019-08-26T18:49:04
|
|
gl/gles/gles2 render: fix SDL_RenderClear being affected by the clip rect in some situations.
|
|
|
8ab698af
|
2019-03-21T10:39:49
|
|
opengles2: Fix static analysis warning.
Not clear if this could ever dereference NULL in real life, but better safe
than sorry!
|
|
|
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
|
|
|
40781dfb
|
2019-02-04T23:35:18
|
|
opengles2: patched to compile.
|
|
|
b7504f31
|
2019-02-04T23:32:28
|
|
opengles2: keep cached texturing state correct.
|
|
|
be991f3a
|
2019-01-12T13:34:03
|
|
Fixed bug 4453 - GLES / GLES2: first white renderer clear cmd is drawn as black
|
|
|
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.
|
|
|
39ec1699
|
2018-12-06T10:24:44
|
|
opengles2: fix prototype of glDeleteBuffers
|
|
|
9719f89d
|
2018-11-17T12:12:29
|
|
Back out change initializing renderer blend mode incorrectly.
|
|
|
782f1685
|
2018-11-17T14:37:51
|
|
Fixed a few compiler warnings.
|
|
|
29e15ce6
|
2018-11-17T00:58:45
|
|
The default draw blendmode is SDL_BLENDMODE_NONE
|
|
|
4659e738
|
2018-11-01T12:31:45
|
|
merge fallout: Patched to compile, fixed some compiler warnings, etc.
|
|
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.
|
|
|
eedf2c96
|
2018-10-06T17:08:04
|
|
opengles2: Fixed several incorrect things.
|
|
|
6ecd0b2c
|
2018-10-04T21:10:42
|
|
opengles2: removed useless memcpy.
|
|
|
ef3d970a
|
2018-10-04T20:22:28
|
|
opengles2: Fixed incorrect cliprect state.
|
|
|
0c2e10dc
|
2018-10-01T22:53:45
|
|
render: Make the GL backends cache and defer more state changes.
|
|
|
9870746b
|
2018-10-01T03:02:54
|
|
render: Patched to compile.
|
|
|
fdc52a65
|
2018-09-29T04:00:38
|
|
render: patched to compile on C89 compilers, other untested code fixes.
|
|
|
c20a858d
|
2018-09-28T19:47:44
|
|
render: moved opengles2 over to new interface.
|
|
|
a2f7af9a
|
2018-09-09T15:09:38
|
|
gles2: Make render command queue dynamic.
It now uses a growable linked list that keeps a pool of allocated items for
reuse, and reallocs the vertex array as necessary. Testsprite2 can scale to
20,000 (or more!) draws now without drama.
|
|
|
0d327529
|
2018-09-08T18:26:11
|
|
gles2: Major renderer optimization. Work in progress!
This moves all the rendering to a command list that is flushed to the GL as
necessary, making most common activities upload a single vertex buffer per
frame and dramatically reducing state changes. In pathological cases,
like Emscripten running on iOS's Safari, performance can go from a dozen
draw calls killing your performance to 1000 draw calls running smoothly.
This is work in progress, and not ready to ship. Among other things, it has
a hardcoded array that isn't checked for overflow. But the basic idea is
sound!
|
|
|
90a5607d
|
2018-08-29T20:23:42
|
|
Fixed compiler warning and use higher precision in angle calculation
|
|
|
92396f7d
|
2018-08-28T16:19:31
|
|
Fixed Windows build
|
|
87bc1fb5
|
2018-08-28T12:57:51
|
|
GLES2: Get sin/cos out of vertex shader
The only place angle is activated and causes effect is RenderCopyEx. All other
methods which use vertex shader, leave angle disabled and cause useless sin/cos
calculation in shader.
To get around shader's interface is changed to a vector that contains results
of sin and cos. To behave properly when disabled, cos value is set with offset
-1.0 making 0.0 default when deactivated.
As nice side effect it simplifies GLES2_UpdateVertexBuffer: All attributes are
vectors now.
Additional background:
* On RaspberryPi it gives a performace win for operations. Tested with
[1] numbers go down for 5-10% (not easy to estimate due to huge variation).
* SDL_RenderCopyEx was tested with [2]
* It works around left rotated display caused by low accuracy sin implemetation
in RaspberryPi/VC4 [3]
[1] https://github.com/schnitzeltony/sdl2box
[2] https://github.com/schnitzeltony/sdl2rendercopyex
[3] https://github.com/anholt/mesa/issues/110
Signed-off-by: Andreas M?ller <schnitzeltony@gmail.com>
|
|
|
915a7e03
|
2018-06-25T01:57:28
|
|
gles2: Whoops, overzealous copy/paste on my part. :)
|
|
|
5308a245
|
2018-06-24T12:16:58
|
|
Fixed some possible malloc(0) calls reported by static analysis.
|
|
|
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.
|
|
|
8891f591
|
2018-02-21T22:53:52
|
|
Backed out changeset 6c8521d53507
Apparently this still triggers a compiler warning, have to dig further.
|
|
|
fd8f12d2
|
2018-02-21T22:35:17
|
|
android: apparently they fixed this header at some point.
|
|
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.
|
|
|
d5f293a7
|
2018-02-09T16:31:57
|
|
Fixed compile warning
|
|
|
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
|
|
|
e8bbbb37
|
2017-12-12T12:52:17
|
|
Added support for Android video textures
|
|
|
a6a4e27a
|
2017-11-12T22:51:12
|
|
Updated SDL's YUV support, many thanks to Adrien Descamps
New functions get and set the YUV colorspace conversion mode:
SDL_SetYUVConversionMode()
SDL_GetYUVConversionMode()
SDL_GetYUVConversionModeForResolution()
SDL_ConvertPixels() converts between all supported RGB and YUV formats, with SSE acceleration for converting from planar YUV formats (YV12, NV12, etc) to common RGB/RGBA formats.
Added a new test program, testyuv, to verify correctness and speed of YUV conversion functionality.
|
|
|
9fd0d619
|
2017-10-18T08:52:04
|
|
Fixed bug 3821 - Allow SDL_CreateWindow and SDL_CreateRenderer with OpenGL ES 3.0 (GLES3) for Angle (Windows)
Carlos
Angle supports GLES3 but when using these functions (SDL_CreateWindow and SDL_CreateRenderer), defaults again to GLES2.0.
A current workaround (hack) to retrieve a GLES3.0 context with Angle is:
1) set
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
after InitSDL AND after calling SDL_CreateWindow (before SDL_CreateRenderer)
2) Comment lines 2032-2044 in SDL_render_gles2.c, funtion GLES2_CreateRenderer
window_flags = SDL_GetWindowFlags(window);
if (!(window_flags & SDL_WINDOW_OPENGL) ||
profile_mask != SDL_GL_CONTEXT_PROFILE_ES || major != RENDERER_CONTEXT_MAJOR || minor != RENDERER_CONTEXT_MINOR) {
changed_window = SDL_TRUE;
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, RENDERER_CONTEXT_MAJOR);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, RENDERER_CONTEXT_MINOR);
if (SDL_RecreateWindow(window, window_flags | SDL_WINDOW_OPENGL) < 0) {
goto error;
}
}
This retrives a GLES3 context as confirmed using glGetString(GL_VERSION). This should be fixed by modifying a few if's.
|
|
|
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
|
|
|
36ba9248
|
2017-08-14T10:04:59
|
|
Fixed setting the texture blend mode in the OpenGL ES2 renderer
|
|
|
c59d9923
|
2017-08-14T05:51:44
|
|
Implemented more flexible blending modes for accelerated renderers
This fixes bug 2594 - Propose new blend mode, SDL_BLENDMODE_BLEND_DSTA
blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA,
SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA,
SDL_BLENDOPERATION_ADD,
SDL_BLENDFACTOR_ZERO,
SDL_BLENDFACTOR_ONE,
SDL_BLENDOPERATION_ADD);
This fixes bug 2828 - Subtractive Blending
blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_SRC_ALPHA,
SDL_BLENDFACTOR_ONE,
SDL_BLENDOPERATION_SUBTRACT,
SDL_BLENDFACTOR_ZERO,
SDL_BLENDFACTOR_ONE,
SDL_BLENDOPERATION_SUBTRACT);
This goes partway to fixing bug 3684 - Add support for a pre-multiplied alpha blending mode
blendMode = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_ONE,
SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA,
SDL_BLENDOPERATION_ADD,
SDL_BLENDFACTOR_ONE,
SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA,
SDL_BLENDOPERATION_ADD);
|
|
63b3e06f
|
2017-06-03T23:00:15
|
|
Corrected names of header file guards.
|
|
|
266816b4
|
2017-03-26T21:00:19
|
|
Removed newlines from error messages.
|
|
|
45b774e3
|
2017-01-01T18:33:28
|
|
Updated copyright for 2017
|
|
|
e93e91f0
|
2016-11-23T21:52:48
|
|
Pacify some GCC strict-aliasing compiler warnings.
|
|
|
40c2a6fb
|
2016-11-23T11:49:26
|
|
Fixed more compiler warnings.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|