pj5085
It occurred to me that my simple patch that comments out a few lines of code does not correctly remove the dead zone since the calculation presumably assumes the dead zone has been cut out of the range. Then, while looking into how to make it output the correct range of values, I realized SDL wasn't returning the correct range of values to begin with.
This line of code was already present:
printf("Values = { %d, %d, %d, %d, %d }\n", absinfo.value, absinfo.minimum, absinfo.maximum, absinfo.fuzz, absinfo.flat);
For my joystick this yeilds:
Values = { 0, -127, 127, 0, 15 }
Then this code calculates the coefficients:
In SDL1:
joystick->hwdata->abs_correct[i].coef[0] = (absinfo.maximum + absinfo.minimum) / 2 - absinfo.flat;
joystick->hwdata->abs_correct[i].coef[1] = (absinfo.maximum + absinfo.minimum) / 2 + absinfo.flat;
t = ((absinfo.maximum - absinfo.minimum) / 2 - 2 * absinfo.flat);
if ( t != 0 ) {
joystick->hwdata->abs_correct[i].coef[2] = (1 << 29) / t;
} else {
joystick->hwdata->abs_correct[i].coef[2] = 0;
}
In SDL2:
joystick->hwdata->abs_correct[i].coef[0] = (absinfo.maximum + absinfo.minimum) - 2 * absinfo.flat;
joystick->hwdata->abs_correct[i].coef[1] = (absinfo.maximum + absinfo.minimum) + 2 * absinfo.flat;
t = ((absinfo.maximum - absinfo.minimum) - 4 * absinfo.flat);
if (t != 0) {
joystick->hwdata->abs_correct[i].coef[2] = (1 << 28) / t;
} else {
joystick->hwdata->abs_correct[i].coef[2] = 0;
}
Neither calculates the correct coefficients for the code in the AxisCorrect function.
In SDL1:
if ( value > correct->coef[0] ) {
if ( value < correct->coef[1] ) {
return 0;
}
value -= correct->coef[1];
} else {
value -= correct->coef[0];
}
value *= correct->coef[2];
value >>= 14;
In SDL2:
value *= 2;
if (value > correct->coef[0]) {
if (value < correct->coef[1]) {
return 0;
}
value -= correct->coef[1];
} else {
value -= correct->coef[0];
}
In SDL1, the calculated coefficients are coef[0]=15, coef[1]=-15 and coef[2]=5534751. So with a full-scale input of 127, it calculates an output value of 37835, which is considerably out of range.
In SDL2, the calculated coefficients are coef[0]=30, coef[1]=-30, and coef[2]=1383687. So with a full-scale input of 127, it calculates the same output value of 37835.
I tested it with the 3 joysticks I have, and it produces out-of-range values for all of them.
Anyway, since dead zones are garbage, I just deleted all of that junk and wrote some code that takes the absinfo.minimum and absinfo.maximum values and uses them to scale the axis range to -32767 through +32767.
I also made it detect when a range doesn't have an integer center point, e.g. the center of -128 to + 127 is -0.5. In such cases, if either value to the side of the center is provided, it zeros it, but it otherwise doesn't implement any kind of dead zone. This seemed important with my gamepad which provides only the values of 0, 127, and 255, since without this hack it would never be centered.
Also, the previous minimum output value was -32768, but as that creates an output range that has no true center, I changed the minimum value to -32767.
I tested it with the 3 joystick devices I have and it seems to create correct values for all of them.
Added a hint to control whether a separate thread should be used for joystick events.
This is off by default because dispatching messages in other threads appears to cause problems on some versions of Windows.
- SDL_video.c (SDL_ShowMessageBox): replace messageboxdata, set title
or message field to "" if either of them is NULL.
- SDL_video.c (SDL_ShowSimpleMessageBox): set title or message to ""
if either of them is NULL for EMSCRIPTEN builds.
- SDL_bmessagebox.cc: add empty string check along with NULL check for
title and message fields.
- SDL_windowsmessagebox.c (AddDialogString): remove NULL string check
- SDL_windowsmessagebox.c (AddDialogControl): add empty string check
along with the NULL check.
- SDL_x11messagebox.c: revert commit 677c4cd68069
- SDL_os2messagebox.c: revert commit 2c2a489d76e7
- test/testmessage.c: Add NULL title and NULL message tests.
Joel Linn
TLDR; https://godbolt.org/z/43fd8G
Let's deduce this from C++ reference code:
https://docs.microsoft.com/en-us/cpp/cppcx/wrl/how-to-activate-and-use-a-windows-runtime-component-using-wrl?view=msvc-160
At the bottom of the page there is this snippet:
```
int wmain()
{
/* ... more code ... */
// Get the domain part of the URI.
HString domainName;
hr = uri->get_Domain(domainName.GetAddressOf());
if (FAILED(hr))
{
return PrintError(__LINE__, hr);
}
// Print the domain name and return.
wprintf_s(L"Domain name: %s\n", domainName.GetRawBuffer(nullptr));
// All smart pointers and RAII objects go out of scope here.
}
```
`HString` is defined in `corewrappers.h` and the call chain for the destructor is:
`~HString() -> Release() -> ::WindowsDeleteString()`
QED
Sven-Hendrik Haase
In CMake I currently have trouble activating hidapi support as libusb-1.0 isn't ever correctly detected as it's searched for by the wrong name.
configure.ac correctly does this:
PKG_CHECK_MODULES([LIBUSB], [libusb-1.0], have_libusb=yes, have_libusb=no)
However, sdlchecks.cmake does this:
pkg_check_modules(LIBUSB libusb)
but it needs to be:
pkg_check_modules(LIBUSB libusb-1.0)
Vincent Hamm
Xcode11 and ios13 added support for metal simulator.
Here is a quick and dirty patch to enable it. Pretty early and only tested on a few samples for now. Required mostly to enable metal support on correct version of ios, generate simulator compatible shaders and enforce buffer alignments on simulator (same as osx).
Sebastian Vargas Vargas
Running CMake configure from a Windows Subsystem for Linux using Visual Studio Code Remote doesn't generate the header file with the current source revision, it throws "/home/sebva/SDL/build-scripts/updaterev.sh: 13: cannot create /mnt/c/Users/sebva/.vscode/extensions/ms-vscode-remote.remote-wsl-0.44.4/include/SDL_revision.h.new: Directory nonexistent".
If we fail to connect to the the pa server, we have an assigned context
and mainloop that isn't connected. So, when PULSEAUDIO_pa_context_disconnect
is called, pa asserts and crashes the application.
Assertion 'pa_atomic_load(&(c)->_ref) >= 1' failed at pulse/context.c:1055, function pa_context_disconnect(). Aborting.
Joel Linn
Eliminate additional heap allocation for short-lived HSTRINGs.
Uses `WindowsCreateStringReference()` to disable reference counting and memory management by the Window Runtime.
Tom Seddon
2nd time lucky, perhaps. patch 2 applies to current HEAD at time of writing - 4eb049c9bb1ca94efe3c40b57beda3169984d0cb from https://github.com/SDL-mirror/SDL.
This basically goes back to what was there originally, but now manually adding "-x objective-c" to the clang command line rather than "-ObjC". clang is then invoked without the "-x c" that was causing the problem, the snippet builds, and Metal is detected. (I had a quick trawl through the cmake code, but I couldn't see where this is handled.)
I was moved to try this after finding SDL's own CHECK_OBJC_SOURCE_COMPILES macro, and noting what it does: 4eb049c9bb/cmake/macros.cmake (L67)
An alternative fix of course would be to use CHECK_OBJC_SOURCE_COMPILES instead of cmake's check_objc_source_compiles - but that had the same problem of getting confused by "return 0;". (Maybe that's because it's a macro? I'll defer to a cmake expert on this one.)
I decided in the end to err on the side of leaving things looking basically the same as they were before my first patch.
Ivan Mogilko
With SDL 2.0.12 under MS Windows, if the window is partially offscreen calling SDL_SetWindowGrab(w, SDL_TRUE) works, but subsequent call to SDL_SetWindowGrab(w, SDL_FALSE) does not work.
I tested this in both real program, and a small test app, where unlocking cursor worked perfectly while window is fully in desktop bounds, but did not work if it was at least few pixels outside.
For the reference, following code is enough to reproduce the issue:
#include <windows.h>
#include <SDL.h>
int WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nShowCmd)
{
SDL_Init(SDL_INIT_VIDEO);
SDL_Window* w = SDL_CreateWindow("", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 640, 400, 0);
bool grabbed = false;
bool want_quit = false;
while (!want_quit)
{
SDL_Event event;
while (SDL_PollEvent(&event))
{
switch (event.type)
{
case SDL_QUIT: want_quit = true; break;
case SDL_KEYDOWN:
if (event.key.keysym.scancode == SDL_SCANCODE_SPACE)
{
SDL_SetWindowGrab(w, static_cast<SDL_bool>(!grabbed));
grabbed = !grabbed;
}
}
}
}
SDL_DestroyWindow(w);
SDL_Quit();
return 0;
}
Mathieu Eyraud
SDL dynamically loads libusb but does not check the return value of 'SDL_LoadFunction'.
Also libusb is loaded and initialized several time because 'SDL_hidapi_wasinit' is never set to true.
I made a patch if you want to test:
- check that 'hid_init' is called once and only once,
- check return value of 'hid_init',
- check return value of 'SDL_LoadFunction',
- check return value of 'SDL_malloc',
- add some debug logging.
On older mac, where METAL Renderer METAL fails to create, it allows to switch back to OpenGL SDL_Renderer
by re-creating the window (METAL flags was previously persistent).
This can happen if the application has not yet processed SDL_JOYDEVICEADD when
the same joystick is removed. It may also happen if two joysticks are added
and the second joystick is removed before the first joystick's SDL_JOYDEVICEADD
has been processed by the application.
Dominik Reichardt
Trying to integrate the latest SDL2 changes into our iOS project of Exult I've stumbled over the fact that when I added the static iOS library the public header files were copied to the archive of our project when you let Xcode build the archive.
This makes the archive invalid for upload to the AppStore Connect.
To fix this you need to delete the public headers from the build phase:
Open the xcode project, select the target "Static Library-ios", got to build phases, and in "headers" delete all the headers in the "public" group. This is safe to do as this actually just copies the public headers for some odd counterintuitive reason.
I think this needs to be done for all the library build targets but likely not for the framework targets.
Tom Seddon
This is as of commit 50d804ea729accf9e3a9ce83238d0a2976a17545 from https://github.com/SDL-mirror/SDL, which is HEAD as I write (apologies, not confident with Mercurial)
# Config
macOS: 10.14.6 (18G6042)
cmake --version: cmake version 3.16.20200101-g23e782c
clang --version: Apple clang version 11.0.0 (clang-1100.0.33.17)
Xcode version: Version 11.3.1 (11C504)
# Repro steps
Run the following commands in the shell.
cd /tmp/
git clone https://github.com/SDL-mirror/SDL
mkdir build.SDL
cd build.SDL
cmake -G ../SDL/
Examine cmake output.
# Expected result
Metal is detected.
# Actual result
It appears that Metal is not detected! Note this line in the summary:
-- RENDER_METAL (Wanted: 0): OFF
# Fix
Change check_c_source_compiles to check_objc_source_compiles. The cmake script tries to add -ObjC to the clang command line, but, for whatever reason, this doesn't seem to work.
Change the test source to have an empty main. The "return 0;" line seems to confuse cmake somehow, causing it to crap out with an error about HAVE_FRAMEWORK_METAL being an unknown argument. (Maybe I'm just dense, but it's not obvious to me what the problem is here.)
With these two changes:
-- RENDER_METAL (Wanted: ON): ON
Patch attached.
Dominik Reichardt
When you unified the Xcode project file you forgot to add the iOS file (/src/misc/ios/SDL_sysurl.m) to the project file, so the dummy in that folder takes over and the call does not work.
Relevant commits:
http://hg.libsdl.org/SDL/rev/c86bbf75f55e (SDL_OpenUrl enabled for macOS/iOS)
http://hg.libsdl.org/SDL/rev/282c3dc1cf65 (and following: unified Xcode project files)
Adding an ios group in the misc group of the project file and then adding /src/misc/ios/SDL_sysurl.m to it fixes the problem.
Sam Lantinga
Ozkan Sezer
Alistair Leslie-Hughes
Alice Rowan
Mikhail Paulyshka
Sylvain Becker
Cameron Gutman