For example, if sR is 0 and dR is 255, we will get -255*sA casted to an unsigned value. Basically results are quite large numbers instead of the expected 0-255 range.
Fixed a case where partial trigger pull could be bound to another button
There is a fundamental problem not resolved by this commit:
Some controllers have axes (triggers, pedals, etc.) that don't start at zero, but we're guaranteed that if we get a value that it's correct. For these controllers, the current code works, where we take the first value we get and use that as the zero point and generate axis motion starting from that point on.
Other controllers have digital axes (D-pad) that assume a zero starting point, and the first value we get is the min or max axis value when the D-pad is moved. For these controllers, the current code thinks that the zero point is the axis value after the D-pad motion and this doesn't work.
My hypothesis is that the first class of devices is more common and that we should solve for that, and add an exception to SDL_JoystickAxesCenteredAtZero() as needed for the second class of devices.
Ryan C. Gordon
Kristian says you can't do it with Wayland, and that going forward, it'll just handle whatever you throw at it anyhow.
https://twitter.com/hoegsberg/status/816148272402165761
So I say we mark it SDL_PIXELFORMAT_RGB888, which is what my X11 display currently reports, and leave it at that.
kaisyu
In case of OpenGLES, the sequences of loading and unloading driver library should be like that:
SDL_Init
...
SDL_GL_LoadLibrary
SDL_EGL_LoadLibrary
...
SDL_Quit
...
SDL_GL_UnloadLibrary
SDL_EGL_UnloadLibrary
...
However, according to my test results, the varible '_this->gl_config.driver_loaded' does not allow 'SDL_GL_UnloadLibrary' to call 'SDL_EGL_UnloadLibrary'.
Coriiander
This notice is about a misplaced comment.
Often times when we use an #if #endif sequence, the #endif is followed by a comment to indicate what #if statement it belonged to. The SDL_xaudio2.c file contains a misplaced comment, as follows (I stripped the other comments):
#ifdef __GNUC__
# define SDL_XAUDIO2_HAS_SDK 1
#elif defined(__WINRT__)
# define SDL_XAUDIO2_HAS_SDK
#include "SDL_xaudio2.h"
#else
#if 0
#include <dxsdkver.h>
#if (!defined(_DXSDK_BUILD_MAJOR) || (_DXSDK_BUILD_MAJOR < 1284))
# pragma message("Your DirectX SDK is too old. Disabling XAudio2 support.")
#else
# define SDL_XAUDIO2_HAS_SDK 1
#endif
#endif
#endif /* 0 */
That final /* 0 */ should be moved one line up. Like this (I tabbed it out for you to make it more clear):
Tristan
The internal SDL_vsnprintf implementation accesses memory outside buffer. The bug existed also inside the format (%) processing, which was fixed with Bug 3441.
But there is still an invalid access, if we do not have any format inside the source string and the destination string is shorter than the format string. You can use any string for this test, as long it is longer than the buffer.
Example:
va_list argList;
char buffer[4];
SDL_vsnprintf(buffer, sizeof(buffer), "Testing", argList);
The bug is located on the 'else' branch of the format char test:
while (*fmt) {
if (*fmt == '%') {
...
} else {
if (left > 1) {
*text = *fmt;
--left;
}
++fmt;
++text;
}
}
if (left > 0) {
*text = '\0';
}
As you can see that text is always incremented, even when left is already one. When then on the last lines, *text is assigned the NULL char, the pointer is located outside bounds.
Intellectual Kitty
In SDL_video.c, on line #1756, in SDL_SetWindowPosition (from today's distribution, 12-31-2016, https://hg.libsdl.org/SDL/shortlog/bf19e0c84483):
if (displayIndex > _this->num_displays) {
should be:
if (displayIndex >= _this->num_displays) {
felix
Compiling even a simple SDL2 'hello world' program with gcc -Wstrict-prototypes (GCC 6.2.1) results in warnings like:
/usr/include/SDL2/SDL_gamecontroller.h:143:1: attention : function declaration isn't a prototype [-Wstrict-prototypes]
extern DECLSPEC int SDLCALL SDL_GameControllerNumMappings();
^~~~~~
It seems there is a missing 'void' between the parentheses.
This was a leftover of simplifying the resamplers down from autogenerated
code; I forgot to make something that the generator hardcoded into something
variable.
Fixes Bugzilla #3507.
Ozkan Sezer
http://hg.libsdl.org/SDL/rev/464a2676d8ab seems to have
forgotten removing the return from SDL_dynapi_procs.h, and this patch
does that. Without it, MSVC warns:
c:\sdl2\src\dynapi\SDL_dynapi_procs.h(598) : warning C4098:
'SDL_GL_SwapWindow_DEFAULT' : 'void' function returning a value
c:\sdl2\src\dynapi\SDL_dynapi_procs.h(598) : warning C4098:
'SDL_GL_SwapWindow' : 'void' function returning a value
Ozkan Sezer
This adds the name 'ad' to two unnamed unions in edid.h
and adjusts edid-parse.c for it. Nameless unions are not supported in
ancient gcc, which I happened to use on one of my ancient setups.
These fixes are lumped into two categories:
1. add new file, SDL_dataqueue.c, to UWP/WinRT build-inputs (via MSVC project
files)
2. implement a temporary, hack-fix for a build error in SDL_xinputjoystick.c.
Win32's Raw Input APIs are, unfortunately, not available for use in UWP/WinRT
APIs. There does appear to be a replacement API, available in the
Windows.Devices.HumanInterfaceDevice namespace.
This fix should be sufficient to get SDL compiling again, without affecting
Win32 builds, however using the UWP/WinRT API (in UWP/WinRT builds) would
almost certainly be better (for UWP/WinRT builds).
TODO: research Windows.Devices.HumanInterfaceDevice, and use that if and as
appropriate.
This currently doesn't affect absolute motion, which would need to be implemented on each windowing system so the cursor matches the reported mouse coordinates.
Diego
I was previously unaware that rotating the device to a different orientation when the keyboard is shown causes a keyboardWillHide followed by a keyboardWillShow notification. The previous patch would then mistakenly StopTextInput when rotating. This patch fixes that by checking if the device is rotating before stopping text input.
Ozkan Sezer
With rev. 10651, i.e. http://hg.libsdl.org/SDL/rev/747a6a795b21 ,
SDL2 - OS X builds fail to run on 10.6 (my setup: i686 / 10.6.8)
because the symbol _IOPMAssertionCreateWithDescription is missing.
The SDK listing it for 10.7+ does seem correct. Reverting r10651
and rebuilding makes it to function again.
Simon Hug
The SDL_BlitScaled function runs into an access violation for specific blit coordinates and surface sizes. The attached testcase blits a 800x600 surface to a 1280x720 surface at the coordinates -640,-345 scaled to 1280x720. The blit function that moves the data then runs over and reads after the pixel data from the src surface causing an access violation.
I can't say where exactly it goes wrong, but I think it could have something to do with the rounding in SDL_UpperBlitScaled. final_src.y is 288 and final_src.h is 313. Together that's 601, which I believe is one too much, but I just don't know the code enough to make sure that's the problem.
Sylvain
I think this patch fix the issue, but maybe it's worth re-writing "SDL_UpperBlitScaled" using SDL_FRect.
The non-deprecated approach (IOPMAssertion) already exists in SDL, and is
available in Mac OS X 10.6 and later (although it was incorrectly listed as
10.7 and later in SDL). Since SDL now requires 10.6 or later, this is no
longer conditionally used.
realitix
SDL2 allows to create widow and to get information through SDL_SysWMinfo.
But it misses something, with Vulkan, you need the HWND and HINSTANCE of the window for Win32 system.
Sadly, SDL2 provides only HWND but not HINSTANCE.
In some context, it can be difficult to get the HINSTANCE, indeed, I'm using pySDL2 (Python) and I can only access properties that SDL2 gives me.
I have to use a dirty trick like that to get the HINSTANCE: (https://raw.githubusercontent.com/bglgwyng/pyVulkan/master/examples/win32misc.py)
felix
Building SDL 2.0.5, or even the Mercurial snapshot (r10608) with GCC 6.2.1 and --enable-video-directfb generates a number of compiler diagnostics and fails.
Simon Hug
The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.)
Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient.
The following blend modes have issues when drawn at an angle.
NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode.
MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations.
BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is.
This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function.
There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers.
The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode...
It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster?
As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode.
I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
Vitaly Novichkov
Okay, when I researched code and algorithm, I tried to replace condition "while(dst >= target)" with "while(dst > target)" and crashes are gone.
Seems on some moments it tries to write into the place before memory block begin, therefore phantom crashes appearing after some moments.
Sylvain 2016-11-07 08:49:34 UTC
when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey.
if you set a dummy colorkey, it will remove the line ...
if you set a some alpha mod, the +90/-90 get transparent but not the 0/180 ...
x414e54
It is a bit of a pain to update the library or rely on whatever version the user has on their computer for default mappings.
So providing an easily updatable text file via SDL_GameControllerAddMappingsFromFile is still currently the most viable way. However using this replaces all mappings provided by the SDL_HINT_GAMECONTROLLERCONFIG environment variable which may have come from the user's custom Steam mapping.
There should be an easy way for games to supply extra game controller mappings to fill in the differences between SDL versions without it clobbering the SDL_HINT_GAMECONTROLLERCONFIG environment variable.
Internally the mappings could use a priority system and if the priority is lower then it will not overwrite the mappings.
For now it just assumes SDL_HINT_GAMECONTROLLERCONFIG is the highest priority, the default hardcoded are the lowest and anything set via the API is medium.
Mark Pizzolato
On Windows with Visual Studio, when building SDL as a static library using the x86 (32bit) mode, several intrinsic operations are implemented in code in SDL_stdlib.c.
One of these, _allshr() is not properly implemented and fails for some input. As a result, some operations on 64bit data elements (long long) don't always work.
I classified this bug as a blocker since things absolutely don't work when the affected code is invoked. The affected code is only invoked when SDL is compiled in x86 mode on Visual Studio when building a SDL as a static library. This build environment isn't common, and hence the bug hasn't been noticed previously.
I reopened#2537 and mentioned this problem and provided a fix. That fix is provided again here along with test code which could be added to some of the SDL test code. This test code verifies that the x86 intrinsic routines produce the same results as the native x64 instructions which these routines emulate under the Microsoft compiler. The point of the tests is to make sure that Visual Studio x86 code produces the same results as Visual Studio x64 code. Some of the arguments (or boundary conditions) may produce different results on other compiler environments, so the tests really shouldn't be run on all compilers. The test driver only actually exercised code when the compiler defines _MSC_VER, so the driver can generically be invoked without issue.
Ozkan Sezer
On systems with old glibc, such mine with glibc-2.8, the following warning
is issued and is fixed easily by defining _GNU_SOURCE:
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c: In function 'CalculateXRandRRefreshRate':
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: implicit declaration of function 'round'
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: incompatible implicit declaration of built-in function 'round'
x414e54
I have implemented Drag and Drop and Clipboard support for Wayland.
Drag and dropping files from nautilus to the testdropfile application seems to work and also copy and paste.
