- Based on C++11's `atomic`
- Reworked `SafeRefCount` (based on the rewrite by @hpvb)
- Replaced free atomic functions by the new `SafeNumeric<T>`
- Replaced wrong cases of `volatile` by the new `SafeFlag`
- Platform-specific implementations no longer needed
Co-authored-by: Hein-Pieter van Braam-Stewart <hp@tmm.cx>
- Based on C++11's `thread` and `thread_local`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed (except for the few cases of non-portable functions)
- Simpler for `NO_THREADS`
- Thread ids are now the same across platforms (main is 1; others follow)
- Based on C++11's `mutex`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
- `BinaryMutex` added for special cases as the non-recursive version
- `MutexLock` now takes a reference. At this point the cases of null `Mutex`es are rare. If you ever need that, just don't use `MutexLock`.
- `ScopedMutexLock` is dropped and replaced by `MutexLock`, because they were pretty much the same.
This makes it possibly to run Linux binaries compiled with udev support on
Linux systems which do not provide udev (typically systemd-less distros).
If udev is missing, we fall back to parsing `/dev/input` like when compiled
without udev support (`udev=no`).
Also adding some verbose debug statements to know which method we're using
when debugging Linux joypad issues.
The libudev so wrappers were generated on Mageia 8 with libudev 246.9 using
https://github.com/hpvb/dynload-wrapper:
```
./generate-wrapper.py --include /usr/include/libudev.h --sys-include '<libudev.h>' \
--soname libudev.so.1 --init-name libudev --omit-prefix gnu_ \
--output-header libudev-so_wrap.h --output-implementation libudev-so_wrap.c
```
(cherry picked from commits a10c259c1d
and e26a1f807b)
Edit: Updated to version 0.2 of dynload-wrapper to fix symbols clobbering as
done in #46143.
There are no guarantees that joypads are in event0-event32
range. Some devices, such as laptops with detachable keyboards
and wacom can reserve events all the way up to 32.
Some udev rules with e.g. custom controller firmwares may
load the device as /dev/input/eventX, where X is greater than
32.
This patch uses POSIX dirent to enumerate the event devices, so
entries outside 0-32 range are not skipped.
(cherry picked from commit 01c030f9b7)
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
(cherry picked from commit b5334d14f7)
Some controllers (notably those made by 8bitdo) do not always emit an event to zero out a D-pad axis before flipping direction. For example, when rolling around aggressively the D-pad of an 8bitdo SN30 Pro/Pro+, the following may be observed:
```
ABS_HAT0X : -1
ABS_HAT0Y : -1
ABS_HAT0Y : 0
ABS_HAT0Y : 1
ABS_HAT0X : 1
```
Notable here is that no event for `ABS_HAT0X: 0` is emitted between the events for `ABS_HAT0X: -1` and `ABS_HAT0X: 1`. Consequently, the game engine believes that both the negative _and_ positive x-axis directions of the D-pad are activated simultaneously (i.e `is_joy_button_pressed()` returns `true` for both `JOY_BUTTON_DPAD_LEFT` and `JOY_BUTTON_DPAD_RIGHT`), which should be impossible.
This issue is _not_ reproducible on all controllers. The Xbox One controller in particular will not exhibit this problem (it always emits zeroing out events for an axis before flipping direction).
The fix is to always zero out the opposite direction on the D-pad axis in question when processing an event with a nonzero value. This unfortunately wastes a small number of CPU cycles on controllers that behave nicely.
**I have verified this issue is also reproducible in the stable 3.2 branch**
(cherry picked from commit dd021099ff)
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
The ID property for InputEvents is set by `SceneTree` when sending the event down the tree.
So there's no need for the platform specific code to set this value when it will later be overriden anyway...
I can show you the code
Pretty, with proper whitespace
Tell me, coder, now when did
You last write readable code?
I can open your eyes
Make you see your bad indent
Force you to respect the style
The core devs agreed upon
A whole new world
A new fantastic code format
A de facto standard
With some sugar
Enforced with clang-format
A whole new world
A dazzling style we all dreamed of
And when we read it through
It's crystal clear
That now we're in a whole new world of code
Now InputDefault is responsible for giving out joypad device IDs to the platform, instead of each platform handling this itself.
This makes it possible for c++ modules to add their own "custom" gamepad devices, without the risk of messing up events in case the user also has regular gamepads attached (using the OS code).
For now, it's implemented for the main desktop platforms.
Possible targets for future work: android, uwp, javascript
