For some reason the `-target` option on the `LINKFLAGS` was causing a weird
issue where osxcross' clang wrapper would attempt using the system `/bin/ld`
instead of the osxcross version (which is Apple's `ld64`).
The error message would be:
```
/bin/ld: unrecognized option '-dynamic'
```
Also removed from `CCFLAGS` for consistency, it seems to work fine with only
`-mmacosx-version-min`.
(cherry picked from commit dbbbb53927)
Large FVF allows batching of many custom shaders, but should not join items which have shaders that utilize BUILTINs which would change for each item, because these will not be sent individually, and all joined items would wrongly use the values from the first joined item.
image/gif is not supported in the glTF 2.0 specification,
these files are broken. But let's be lenient...
Fixes#43638.
(cherry picked from commit f70cc0a60e)
Polys that have no texture assigned contain no UVs in the poly command. These were previously not blanked, leading to random values if read from a custom shader.
This PR just blanks them.
This makes these platform behave as MacOS in that regard and also fixes the editor window appearing in some cases even when --no-window has been passed.
Export presets contains the export_path option, to specify the default
export location, but the CLI export option disregarded that, and always
required and export path to be specified.
After this commit, if the export path is not specified in the command,
the one in the preset will be used, erroring only if it's not present or
invalid.
(cherry picked from commit 032a1c5dc3)
Switching between editors now requires holding Ctrl to avoid
conflicts with the new F2 shortcut.
The asset library can now be accessed by pressing Ctrl + F4
on Windows and Linux, or Alt + 4 on macOS.
This partially addresses #38139.
(cherry picked from commit 79e4e26738)
I verified this experimentally. I added a point at roughly (1,0,0), and
dragged a handle back to the origin. The result was:
```
get_point_position: (0.991079, 0, -0.000069)
get_point_in: (0.993409, 0, 0)
get_point_out: (-0.993409, 0, 0)
```
(cherry picked from commit c6093ae612)
- Mention Lua-style syntax.
- Make the code samples self-contained.
- Mention caveat with `const` (also in Array).
- Clarify the description of `size()`.
This closes https://github.com/godotengine/godot-docs/issues/4272.
(cherry picked from commit 5325de4e6b)
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)
