Input accumulation was implemented and enabled by default in 3.1, and
I don't recall major complaints around it (or bugs were fixed).
In 3.4, #42220 added input buffering and apparently toggled input
accumulation off by mistake.
This led to multiple bug reports about degraded performance on Windows,
or simply unexpected behavior change (see linked issues in #55037).
Fixes#55037.
As _buttons and _axes have both valid string and nullptr.
When iterating over them, if given key exists it will work correctly.
But if given key does not exist, it will end up with
String::operator=(nullptr). As String constructor from nullptr exists, I
use it.
There is no filtering on the Nintendo Switch Pro controller thumbstick, so there will frequently be events with very slight change. These are turned into "not pressed" events, which cancel "pressed" events from keys and buttons.
This change filters out up to 5% jitter, but it might be worth revisiting whether "not pressed" events should cancel "pressed" events.
Sets `AlignOperands` to `DontAlign`.
`clang-format` developers seem to mostly care about space-based indentation and
every other version of clang-format breaks the bad mismatch of tabs and spaces
that it seems to use for operand alignment. So it's better without, so that it
respects our two-tabs `ContinuationIndentWidth`.
Input buffering is implicitly used by event accumulation, but this commit makes it more generic so it can be enabled for other uses.
For desktop OSs it's currently not feasible given main and UI threads are the same).
- API has been simplified: all events now go through `parse_input_event()`. Whether they are accumulated or not depends on the `use_accumulated_input` flag.
- Event accumulation is now thread-safe (it was not needed so far, but it prepares the ground for the following changes).
- Touch drag events now support accumulation.
Added additional param to action related methods to test for exactness.
If "p_exact_match" is true, then the action will only be "matched" if the provided input event *exactly* matches with the action event.
Before:
* Action Event = KEY_S
* Input Event = KEY_CONTROL + KEY_S
* Is Action Pressed = True
Now:
You can still do the above, however you can optionally check that the input is exactly what the action event is:
* Action Event = KEY_S
* Input Event = KEY_CONTROL + KEY_S
* p_exact_match = True
* Is Action Pressed = False
* If the Input Event was only KEY_S, then the result would be true.
Usage:
```gdscript
Input.is_action_pressed(action_name: String, exact_match: bool)
Input.is_action_pressed("my_action", true)
InputMap.event_is_action(p_event, "my_action", true)
func _input(event: InputEvent):
event.is_action_pressed("my_action", false, true) # false = "allow_echo", true = "exact_match"
event.is_action("my_action", true)
```
Co-authored-by: Eric M <itsjusteza@gmail.com>
Thow errors if requesting an unexisting InputMap action.
Makes `Input.is_action_*` methods consistents with `Event.is_action_*` which already throw errors.
fixes#33303
(cherry picked from commit 2aee71d52d)
In the core input handling code we have checks to make sure that if axis
rapidly change sign we inject mid-points to release any pending inputmap
action.
The function though, did not correctly insert the mid-point causing
dpads mapped to an axis that behaves like tri-state buttons (-1,0,1) to
not be released correctly.
This commit fixes that by including in the check the case where the axis
swtiches from abs(1) to 0.
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)
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.
