|
a720d1a2
|
2020-08-09T00:55:39
|
|
render: fixes to how we convert touch events for logical scaling.
We now handle HiDPI correctly, and touches are clamped to the viewport. So
if you are rendering to a logical 640x480 in a 720p window, and touch the
letterboxing at point (640,700), it will report the touch at (0.5,1.0) instead
of outside the documented range.
|
|
39690a04
|
2020-05-15T21:33:47
|
|
Fix static analysis warning in SDL_render.c
|
|
a96d8a43
|
2020-04-13T22:05:36
|
|
render: Fixed compiler warning about implicit cast.
|
|
aa188048
|
2020-04-10T12:23:08
|
|
render: Scale relative mouse motion better for logical sizing
From hmk:
"When scaling is enabled (e.g. via SDL_RenderSetLogicalSize, size not equal
to window size), mouse motion events are also scaled. Small motions are
rounded up (SDL_max() when the value after scaling is less than 1), while
larger motions are truncated by the floating point -> integer conversion.
https://hg.libsdl.org/SDL/file/b18197f9bf9d/src/render/SDL_render.c#l658
The end result feels something like mouse reverse mouse acceleration + angle
snapping at low speeds, but less consistent (amount of truncation & rounding
depends on how fast the mouse is moved) and potentially much worse if the
scaling factor is large. This pretty much makes it useless for anything
where you need precise mouse aiming (think of games). I suspect this is why
aiming gets so terrible in some games that let you use scaling to reduce the
render resolution (e.g. Ion Fury).
With 4x4 scaling, I can reproduce a situation where it takes three fast flicks
of the mouse across the pad to undo one slow sweep across the pad. In other
words, extreme reverse acceleration. This does not happen when scaling is
disabled.
Furthermore, any game that uses relative mouse motion events for 3D camera
rotation probably wants the raw mouse deltas and not a value that depends on
scaling and resolution and rounding and truncation. Ideal camera rotation
just takes mouse input, multiplies it by sensitivity, and adds it to the
angle-in-radians or whatever measure is used for yaw & pitch. Pixels and
screen resolution or window dimensions should not be a part of the equation
at all, even if it could be implemented without rounding errors.
[...]
This [patch] completely eliminates angle snapping for me, and makes
sensitivity consistent. In other words, it's completely usable for, say,
aiming in a first person shooter."
Partially fixes Bugzilla #4811.
|
|
b6afbe63
|
2020-04-07T09:38:57
|
|
Added SDL_log.h to SDL_internal.h so logging is available everywhere
|
|
e6189f40
|
2020-03-17T15:47:30
|
|
Fix warnining implicit declaration of SDL_DetectPalette (Thanks meyraud705)
|
|
838bbf1f
|
2020-03-17T09:35:42
|
|
Fixed bug 5037 - Regression 2.0.12 Alpha value of 0 on palette may become opaque
(see also bug 3827)
|
|
9a7c2b22
|
2020-02-23T09:59:52
|
|
Fixed bug 4999 - Palette surface always promoted to alpha (Thanks Cameron Gutman!)
MSVC Static analysis: Incorrect alpha_value check in SDL_render.c
(see also bug 4425)
|
|
b5e3d264
|
2020-01-23T01:00:52
|
|
Added a single SDL_LEAN_AND_MEAN define to turn on minimal SDL builds
Protected more code with #ifdefs to reduce the size of minimal shared library builds
|
|
7df22cf2
|
2020-01-21T21:33:40
|
|
A few #defines to reduce SDL2 footprint.
Only applied when library is statically linked
|
|
a8780c6a
|
2020-01-16T20:49:25
|
|
Updated copyright date for 2020
|
|
981e0d36
|
2020-01-16T08:52:59
|
|
Fixed bug 4903 - Lack of color multiply with alpha (SDL_BLENDMODE_MOD + SDL_BLENDMODE_BLEND) blending mode for all renderers
Konrad
This kind of blending is rather quite useful and in my opinion should be available for all renderers. I do need it myself, but since I didn't want to use a custom blending mode which is supported only by certain renderers (e.g. not in software which is quite important for me) I did write implementation of SDL_BLENDMODE_MUL for all renderers altogether.
SDL_BLENDMODE_MUL implements following equation:
dstRGB = (srcRGB * dstRGB) + (dstRGB * (1-srcA))
dstA = (srcA * dstA) + (dstA * (1-srcA))
Background:
https://i.imgur.com/UsYhydP.png
Blended texture:
https://i.imgur.com/0juXQcV.png
Result for SDL_BLENDMODE_MOD:
https://i.imgur.com/wgNSgUl.png
Result for SDL_BLENDMODE_MUL:
https://i.imgur.com/Veokzim.png
I think I did cover all possibilities within included patch, but I didn't write any tests for SDL_BLENDMODE_MUL, so it would be lovely if someone could do it.
|
|
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.
|
|
fe20c35b
|
2019-10-14T16:40:46
|
|
Fixed race condition when scaling Touch events, and changing the renderer
target.
Always read the output size of the main renderer.
(similar to bug 2107)
|
|
7d47f526
|
2019-10-01T09:26:30
|
|
SDL_LockTextureToSurface: robustness of locked region compared to texture size
|
|
0918903f
|
2019-09-30T22:54:16
|
|
render: add a hint for toggling relative scaling
Fixes Bugzilla #4811.
|
|
1ae61f10
|
2019-09-30T20:58:44
|
|
Added a helper function SDL_LockTextureToSurface()
Similar to SDL_LockTexture(), except the locked area is exposed as a SDL surface.
|
|
ff7888e6
|
2019-08-18T09:35:11
|
|
render: fix colors not being set properly after the previous change
|
|
1be03b40
|
2019-08-17T22:26:33
|
|
render: avoid a couple redundant memcmp calls in all drawing functions. Improves performance slightly.
|
|
69c6924c
|
2019-08-17T00:43:44
|
|
render: simplify vertex and uniform data allocation. Improves performance of various SDL_Render functions (bug #4764).
|
|
22a2decf
|
2019-06-28T16:38:42
|
|
Android: concurrency issues, make sure Activity is in running State when calling
functions like SDL_CreateWindow, SDL_CreateRenderer, Android_GLES_CreateContext
Bugs 4694, 4681, 4142
|
|
cfed0b77
|
2019-06-28T16:14:50
|
|
Add an "error" label in SDL_CreateRenderer (no op)
|
|
b5e9ebba
|
2019-06-08T19:12:05
|
|
Fixed compiler warning
warning C4018: '<' : signed/unsigned mismatch
|
|
41c718db
|
2019-05-19T12:04:06
|
|
Fixed bug 4469 - make SDL_CreateTextureFromSurface pick a more appropriate format
Sylvain
Currently SDL_CreateTextureFromSurface picks first valid format, and do a conversion.
format = renderer->info.texture_formats[0];
for (i = 0; i < renderer->info.num_texture_formats; ++i) {
if (!SDL_ISPIXELFORMAT_FOURCC(renderer->info.texture_formats[i]) &&
SDL_ISPIXELFORMAT_ALPHA(renderer->info.texture_formats[i]) == needAlpha) {
format = renderer->info.texture_formats[i];
break;
It could try to find a better format, for instance :
if SDL_Surface has no Amask, but a colorkey :
if surface fmt is RGB888, try to pick ARGB8888 renderer fmt
if surface fmt is BGR888, try to pick ABGR8888 renderer fmt
else
try to pick the same renderer format as surface fmt
if no format has been picked, use the fallback.
I think it goes with bug 4290 fastpath BlitNtoN
when you expand a surface with pixel format of size 24 to 32, there is a fast path possible.
So with this issue:
- if you have a surface with colorkey (RGB or BGR, not palette), it takes a renderer format where the conversion is faster.
(it avoids, if possible, RGB -> ABGR which means switching RGB to BGR)
- if you have a surface ABGR format, it try to take the ABGR from the renderer.
(it avoids, if possible, ABGR -> ARGB, which means switch RGB to BGR)
|
|
b2e76d86
|
2019-03-19T16:52:09
|
|
Fixed Windows RT build
|
|
07548602
|
2019-01-19T16:47:43
|
|
Fixed bug 3657 - Color-key doesn't work when an alpha channel is present
When surface format is the same as renderer format, it still needs an
intermediate conversion to transform colorkey to alpha.
|
|
5e13087b
|
2019-01-04T22:01:14
|
|
Updated copyright for 2019
|
|
0a705901
|
2018-12-19T18:10:02
|
|
render: Prefer the Metal renderer over OpenGL.
This is the best option for macOS and iOS, the only platforms with Metal.
Pre-Metal versions of these platforms will fall back to OpenGL (ES), as
appropriate.
Huge thanks to Alexander Szpakowski, who worked incredibly hard to get the
Metal renderer to such a high-quality state!
|
|
e5476c65
|
2018-12-15T14:50:12
|
|
Fixed bug 4425 - promote to alpha format, palette surface with alpha values.
SDL_CreateTextureFromSurface() forgets to choose a texture format with alpha for
surfaces that have palettes with alpha values.
|
|
252dc85e
|
2018-12-06T09:22:00
|
|
Fix warnings detected on Android build
|
|
939bf1c4
|
2018-12-03T02:06:17
|
|
render: fix some static analysis warnings.
|
|
0d79a8a1
|
2018-11-01T20:04:24
|
|
fix build using Watcom :
./src/render/SDL_render.c(2168): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2168): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2175): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2175): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2322): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2322): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2322): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2322): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2329): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2329): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2329): Error! E1054: Expression must be constant
./src/render/SDL_render.c(2329): Error! E1054: Expression must be constant
./src/render/software/SDL_render_sw.c(602): Error! E1054: Expression must be constant
./src/render/software/SDL_render_sw.c(602): Error! E1054: Expression must be constant
./src/render/software/SDL_render_sw.c(602): Error! E1054: Expression must be constant
./src/render/software/SDL_render_sw.c(602): Error! E1054: Expression must be constant
|
|
4659e738
|
2018-11-01T12:31:45
|
|
merge fallout: Patched to compile, fixed some compiler warnings, etc.
|
|
62494a2e
|
2018-10-31T15:03:41
|
|
Merge SDL-ryan-batching-renderer branch to default.
|
|
8340b0f0
|
2018-10-23T01:34:03
|
|
render: Add floating point versions of various draw APIs.
|
|
b262b0eb
|
2018-10-22T20:50:32
|
|
Small stack allocations fall back to malloc if they're unexpectedly large.
|
|
1ecf4dfc
|
2018-10-04T16:34:44
|
|
render: Added SDL_RenderFlush().
|
|
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.
|
|
7df0f4fd
|
2018-09-27T14:56:29
|
|
Fixed bug 4277 - warnings patch
Sylvain
Patch a few warnings when using:
-Wmissing-prototypes -Wdocumentation -Wdocumentation-unknown-command
They are automatically enabled with -Wall
|
|
60afec79
|
2018-09-25T19:53:16
|
|
Removed redundant SDL_GetColorKey() call. (thanks Sylvain!)
|
|
06461bba
|
2018-09-25T17:04:47
|
|
render: Move non-batching flushes to different place.
This lets us batch up a few commands that are all related to the same API
call.
|
|
ef347048
|
2018-09-24T16:41:55
|
|
Fixed bug 4264 - SDL_CreateTextureFromSurface generates error message but returns ok
Anthony @ POW Games
SDL_CreateTextureFromSurface makes an internal call to SDL_GetColorKey which can return an error and spams the error log with "Surface doesn't have a colorkey" even though the original function didn't return an error.
|
|
8ac5c00a
|
2018-09-24T02:07:35
|
|
render: Add command queue debug logging.
|
|
cc56de44
|
2018-09-23T23:20:40
|
|
render: A bunch of high-level improvements.
- high-level filters out duplicate render commands from the queue so
backends don't have to.
- Setting draw color is now a render command, so backends can put color
information into the vertex buffer to upload with everything else instead
of setting it with slower dynamic data later.
- backends can request that they always batch, even for legacy programs,
since the lowlevel API can deal with it (Metal, and eventually Vulkan
and such...)
- high-level makes sure the queue has at least one setdrawcolor and
setviewport command before any draw calls, so the backends don't ever have
to manage cases where this hasn't been explicitly set yet.
- backends allocating vertex buffer space can specify alignment, and the
high-level will keep track of gaps in the buffer between the last used
positions and the aligned data that can be used for later allocations
(Metal and such need to specify some constant data on 256 byte boundaries,
but we don't want to waste all that space we had to skip to meet alignment
requirements).
|
|
5fb67f9f
|
2018-09-20T15:46:02
|
|
render: Move to a batching system for rendering (work in progress).
|
|
74ec7cab
|
2018-06-18T13:13:56
|
|
Fixed race condition where Android touch events could get scaled by a render target's viewport
|
|
fe032ff4
|
2018-05-10T08:25:23
|
|
do the direct3d tap dance for overscan hint only if SDL_VIDEO_RENDER_D3D == 1
|
|
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.
|
|
e3cc5b2c
|
2018-01-03T10:03:25
|
|
Updated copyright for 2018
|
|
87894224
|
2017-12-12T16:34:16
|
|
Fixed bug 3981 - Inverted logic bug in SDL_renderer "overscan" feature
Eric wing
There is a tiny bug in the new overscan code for the SDL_renderer.
In SDL_renderer.c, line 1265, the if check for SDL_strcasecmp with "direct3d" needs to be inverted.
Instead of:
if(SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) {
It should be:
if(0 == SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) {
This bug causes the "overscan" mode to pretty much be completely ignored in all cases and all things remain letterboxed (as before the feature).
|
|
cf3d4503
|
2017-12-08T14:30:10
|
|
Added SDL_RenderGetMetalLayer() and SDL_RenderGetMetalCommandEncoder()
|
|
a7c79c5e
|
2017-10-12T08:37:55
|
|
Normalize touch events to the render viewport (thanks Sylvain!)
|
|
04e76499
|
2017-08-14T20:37:07
|
|
Fixed build warning
|
|
9451cd81
|
2017-08-14T20:07:30
|
|
Fixed compiler warnings
|
|
aebe17d3
|
2017-08-14T16:34:54
|
|
Fixed bug 2344 - CHECK_WINDOW_MAGIC should include __FILE__ and __LINE__
Martin Gerhardy
just for easier debugging issues in the own code...
SDL_CreateRenderer should maybe also use this macro
Ryan C. Gordon
I'll go one better: it should have an SDL_assert().
|
|
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);
|
|
ca5c3048
|
2017-08-13T21:06:52
|
|
Fixed bug 3744 - missing SDLCALL in several functions
Ozkan Sezer
The attached patch adds missing SDLCALL to several functions, so that
they properly match the headers as intended.
|
|
af9ec8f6
|
2017-08-13T20:13:11
|
|
Fixed copy-paste error, thanks Alen!
|
|
8aa147fa
|
2017-08-04T23:00:30
|
|
Fixed compiler warnings about type conversions.
Found by buildbot.
|
|
9dbe5a96
|
2017-08-02T13:38:46
|
|
Fixed bug 3311 - Broken touch positions with SDL_RenderSetLogicalSize & HIGHDPI on iOS
Eric wing
Hi, I think I found a bug when using SDL_WINDOW_ALLOW_HIGHDPI with SDL_RenderSetLogicalSize on iOS. I use SDL_RenderSetLogicalSize for all my stuff. I just tried turning on SDL_WINDOW_ALLOW_HIGHDPI on iOS and suddenly all my touch/mouse positions are really broken/far-off-the-mark.
I actually don't have a real retina device (still) so I'm seeing this using the iOS simulator with a 6plus template.
Attached is a simple test program that can reproduce the problem. It uses RenderSetLogicalSize and draws some moving happy faces (to show the boundaries/space of the LogicalSize and that it is working correctly for that part).
When you click/touch, it will draw one more happy face where your button point is.
If you comment out SDL_WINDOW_ALLOW_HIGHDPI, everything works as expected. But if you compile with it in, the mouse coordinates seem really far off the mark. (Face appears far up and to the left.)
Alex Szpakowski on the mailing list suggests the problem is
"I believe this is a bug in SDL_Render?s platform-agnostic mouse coordinate scaling code. It assumes the units of the mouse coordinates are always in pixels, which isn?t the case where high-DPI is involved (regardless of whether iOS is used) ? they?re actually in ?DPI independent? coordinates (which matches the window size, but not the renderer output size)."
Additionally, if this is correct, the Mac under Retina is also probably affected too and "as well as any other platform SDL adds high-dpi support for in the future".
|
|
92889836
|
2017-06-06T14:06:40
|
|
Merged Eric Wing's overscan patch.
Fixes Bugzilla #2799.
|
|
ca0bf151
|
2017-03-03T16:38:17
|
|
Fix some more compiler warnings on armcc.
|
|
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.
|
|
8e2634eb
|
2016-10-14T00:51:57
|
|
Fixed divide by zero if setting integer scale without setting logical width and height
|
|
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.
|
|
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).
|
|
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.
|
|
2a2c8d42
|
2016-04-21T03:16:44
|
|
Initial shot at a renderer target for Apple's Metal API.
This isn't complete, but is enough to run testsprite2. It's currently
Mac-only; with a little work to figure out how to properly glue in a Metal
layer to a UIView, this will likely work on iOS, too.
This is only wired up to the configure script right now, and disabled by
default. CMake and Xcode still need their bits filled in as appropriate.
|
|
bb3cb4f4
|
2016-04-04T19:25:24
|
|
overscan (feature for SDL_RenderSetLogicalSize): Fix to ignore overscan hint when using the Direct3D 9 backend.
D39 does not support negative viewport values which the current implementation relies on.
D3D11 does support negative viewport values so that will continue working.
Refer to Bug 2799.
|
|
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
|
|
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!
|
|
0856a7ef
|
2015-08-21T23:50:37
|
|
Changed an error return value from 0 to NULL for consistency.
|
|
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().
|
|
d77a5573
|
2015-06-21T04:04:14
|
|
merged SDL 2.0.4 rc2
|
|
b7ede6cc
|
2015-06-19T23:20:43
|
|
Fixed bug 1550 - SDL_RenderCopy/CopyEx in software should optionally render 8bit alpha
Adam M.
There are three problems in the code that I see.
1. SW_RenderCopyEx enables a color key on surface_scaled even if the source surface didn't have a color key.
2. SW_RenderCopyEx doesn't copy blend mode, color mod, or alpha mod from src to surface_scaled.
3. When SDL_BlitScaled(src, srcrect, surface_scaled, &tmp_rect) is called, it blends the src pixels into surface_scaled instead of overwriting them (if src has blending, etc. enabled).
I've attached a patch that 1) fixes the three problems that I mentioned, 2) adds the requested performance improvement of using the regular blit function if no rotation or flipping is needed, 3) avoids cloning the source surface if no stretching is required, and simplifies the rotation code slightly.
|
|
27fab8f4
|
2015-06-17T20:03:08
|
|
merged SDL 2.0.4rc1+
|
|
6a3ad8a9
|
2015-05-28T12:18:05
|
|
Fixed bug 2367 - Bad mouse motion coordinates with two windows where one has changed logical size
Andreas Ragnerstam
I have two windows where one has a renderer where the logical size has been changed with SDL_RenderSetLogicalSize. When I get SDL_MOUSEMOTION events belonging to the non-scaled window these will have been scaled with the factor of the scaled window, which is not expected.
Adding some printf debugging to SDL_RendererEventWatch of SDL_render.c, where (event->type == SDL_MOUSEMOTION), I found that for every mouse motion SDL_RendererEventWatch is called twice and the event->motion.x and event.motion.y are set twice for the event, once for each renderer where only the last one set will be saved to the event struct. This will work fine if both renderers have the same scale, but otherwise the motion coordinates will be scaled for the renderer belonging to another window than the mouse was moved in.
I guess one solution would be to check that window == renderer->window for SDL_MOUSEMOTION events, similar to what is done for when SDL_WINDOWEVENT events.
I get the same error on both X11 and Windows.
The same problem also exists for SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events.
|
|
d5a57853
|
2015-05-26T16:42:36
|
|
Drop out of SDL_UpdateTexture() early if the rectangle is zero pixels.
Hopefully makes static analysis happy about a zero-byte malloc elsewhere.
|
|
2c4a6ea0
|
2015-05-26T06:27:46
|
|
Updated the copyright year to 2015
|
|
b72938c8
|
2015-04-20T12:22:44
|
|
Windows: Always set the system timer resolution to 1ms by default.
An existing hint lets apps that don't need the timer resolution changed avoid
this, to save battery, etc, but this fixes several problems in timing, audio
callbacks not firing fast enough, etc.
Fixes Bugzilla #2944.
|
|
fe6c797c
|
2015-04-10T23:30:31
|
|
Fixed an iOS view orientation issue when SDL_GL_CreateContext or SDL_CreateRenderer is called.
|
|
b88ca1b4
|
2015-02-10T16:28:56
|
|
the last parameter of XChangeProperty is the number of elements.. and when the element format is 32.. the element is "long" so we have 5 long elements here.
Yes this seems confusing as on mac+linux Long is either 32 or 64bits depending on the architecture, but this is how the X11 protocol is defined. Thus 5 is the correct value for the nelts here. Not 5 or 10 depending on the architecture.
More info on the confusion https://bugs.freedesktop.org/show_bug.cgi?id=16802
|
|
b48e54aa
|
2015-01-26T22:00:29
|
|
Fixed bug 2802 - [patch] Fix android build compiling in wrong filesystem implementation
Jonas Kulla
The configure script didn't differentiate between Linux and Android, unconditionally compiling in the unix implementation of SDL_sysfilesystem.c.
I'm probably one of the very few people building SDL for android using classic configure + standalone toolchain, so this has gone undetected all along.
|
|
70438be2
|
2014-12-03T10:55:23
|
|
WinRT: fixed bug whereby SDL would override an app's default orientation
WinRT apps can set a default, preferred orientation via a .appxmanifest file.
SDL was overriding this on app startup, and making the app use all possible
orientations (landscape and portrait).
Thanks to Eric Wing for the heads up on this!
|
|
31388117
|
2014-12-03T04:41:26
|
|
Adds support to control the scaling policy/mode of SDL_RenderSetLogicalSize for both letterbox (current behavior) and a new overscan mode (expand to fill the entire screen, even if some parts draw off the screen).
The expected use case is for games that are designed with multiple aspect ratios already in mind and leave optional margins on the edges of the game which won't hurt if they are cut off.
An example use case is a game is designed for wide-screen/16:9, but then wants to deploy on an iPad which is 4:3. Normally, SDL will letterbox, which will shrink things and result in wasted space. But the designer already thought about 4:3 and designed the edges of the game so they could be cut off without any functional loss. So rather than wasting space with letterboxing, "overscan" mode will zoom the rendering to fill up the entire screen. Parts on the edges will be drawn offscreen, but since the game was already designed with this in mind, it is fine. The end result is the iPad (4:3) experience is much better since it feels like a game designed for that screen aspect ratio.
This patch introduces a new SDL_hint: SDL_HINT_RENDER_LOGICAL_SIZE_MODE.
Valid values are "letterbox" or "0" for letterboxing and "overscan" or "1" for overscan.
The default mode is letterbox to preserve existing behavior.
// Example usage:
SDL_SetHint(SDL_HINT_RENDER_LOGICAL_SIZE_MODE, "overscan");
SDL_RenderSetLogicalSize(renderer, SCREEN_WIDTH, SCREEN_HEIGHT);
|
|
9c398852
|
2014-11-22T22:20:40
|
|
Corrected header file documentation comment.
|
|
24c86b55
|
2014-09-11T19:24:42
|
|
[X11] Reconcile logical keyboard state with physical state on FocusIn
since the window system doesn't do it for us like other platforms.
This prevents sticky keys and missed keys when going in and out
of focus, for example Alt would appear to stick if switching away
from an SDL app with Alt-Tab and had to be pressed again.
CR: Sam
|
|
2e3c778e
|
2014-08-17T14:34:41
|
|
Fixed bug where the render target is updated instead of the default output when the window is resized.
|
|
529ed53b
|
2014-08-16T23:30:44
|
|
Fixed bug 2681 - dereference a NULL pointer dst_fmt in SDL_CreateTextureFromSurface function
Nitz
In SDL_CreateTextureFromSurface:
SDL_PixelFormat *dst_fmt;
/* Set up a destination surface for the texture update */
dst_fmt = SDL_AllocFormat(format);
temp = SDL_ConvertSurface(surface, dst_fmt, 0);
Here is need of NULL check for dst_fmt because there are chances of NULL return from SDL_AllocFormat(format);
|
|
defd90b6
|
2014-04-19T13:15:41
|
|
Render: Allow empty cliprect.
This fixes an issue where an empty cliprect is treated the same as a NULL
cliprect, causing the render backends to disable clipping.
Also adds a new API, SDL_RenderIsClipEnabled(render) that allows you to
differentiate between:
- SDL_RenderSetClipRect(render, NULL)
- SDL_Rect r = {0,0,0,0}; SDL_RenderSetClipRect(render, &r);
Fixes https://bugzilla.libsdl.org/show_bug.cgi?id=2504
|
|
3dcb451f
|
2014-04-09T21:29:19
|
|
Added a README file regarding WinRT support
To note, this file is currently formatted with CRLF line endings, rather than
LF, to allow the file to be viewed with Notepad.
|
|
93ba5bd8
|
2014-03-20T16:23:18
|
|
Static analysis fix: uninitialized value.
(A false positive: clang doesn't know SDL_SetError() always returns -1.)
|