This check was there since the first commit in 2014, but a later feature added in 2018
with #17717 did not properly update the code while adding non animation-related code
in `perform_node_renames`.
Fixes#40532.
Resolvesgodotengine/godot-proposals#1246.
It is difficult to tell the difference between the handles for adjusting
curves and the points themselves when looking at a Path gizmo.
This re-uses the icons used for Path2D.
Unlike Path2D, this does not use a different icon for smooth vs sharp
points, as using a potentially different material for each point would
prevent batching the points in add_handles (and adding them out-of-order
messes up other logic based on handle indices).
This includes a public API change to allow specifying a texture for a
handle material. This allows spatial gizmo plugins to customize the way
a handle is rendered, if desired, but does not break existing behavior
(as providing no texture uses the default).
The path handle icons were resized as well. 16x16 is the standard icon
size. These icons were 10x10 rather than 16x16, and appeared rather
small in the editor.
To resize, I:
- Opened the original in Inkscape
- Resized the document to 16x16
- Opened the transform dialog
- Scaled by 160% proportionally
- Used Align/Distribute to center on the page
- Saved the document
- Cleaned with `svgcleaner --multipass`
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**
* Using C-style function pointers now, InternalMethod is gone.
* This ensures much better performance in typed code.
* Renamed builtin_funcs to utility_funcs, to avoid naming confusion
-Moved Expression to use this, removed its own.
-Eventually GDScript/VisualScript/GDNative need to be moved to this.
-Given the JSON functions were hacked-in, removed them and created a new JSONParser class
-Made sure these functions appear properly in documentation, since they will be removed from GDScript
Rewrote AudioDriverJavaScript to support multiple processor nodes.
The old (and deprecated) ScriptProcessorNode when threads are not
available, and the new AudioWorklet API when threads are enabled.
The new implementation uses two ring buffers and a shared state to
communicated with the AudioWorklet thread.
The audio.worklet.js JavaScript file is always added to the export
template, but only really used (and downloaded) in the thread build.
- Escape the method names as e.g. `operator <` is invalid XML.
- Add a hack to merge all String % operator definitions for each Variant type
as a single one with `Variant` argument type.
- Add support for the new qualifiers in makerst.py.
- Drop unused `doc_merge.py`, seems to date back to when we had all the
documentation in a single `classes.xml`.
