Changed CPU velocity calculation for EMISSION_SHAPE_DIRECTED_POINTS
to follow the same logic as in the GPU version:
mat2 rotm;
rotm[0] = texelFetch(emission_texture_normal, emission_tex_ofs, 0).xy;
rotm[1] = rotm[0].yx * vec2(1.0, -1.0);
VELOCITY.xy = rotm * VELOCITY.xy;
Now both CPUParticles2D & CPUParticles3D (z disabled) show the same results
as their GPU counterparts and take the initial velocity settings into account.
`ConvexPolygonShape2D` and `ConcavePolygonShape2D` are only meant to be
used directly in code and not in the editor for physics-based use cases
specifically.
Developers are advised to use `CollisionPolygon2D` instead, which does
generate those shapes under the hood, handling polygon convexivity,
proper orientation etc.
Fixes#36372 as Path2D/Path3D's `curve` property no longer uses a Curve
instance as default value, but instead it gets a (unique) default Curve
instance when created through the editor (CreateDialog).
ClassDB gets a sanity check to ensure that we don't do the same mistake
for other properties in the future, but instead use the dedicated
property usage hint.
Fixes#36372.
Fixes#36650.
Supersedes #36644 and #36656.
Co-authored-by: Thakee Nathees <thakeenathees@gmail.com>
Co-authored-by: simpuid <utkarsh.email@yahoo.com>
I couldn't find a tool that enforces it, so I went the manual route:
```
find -name "thirdparty" -prune \
-o -name "*.cpp" -o -name "*.h" -o -name "*.m" -o -name "*.mm" \
-o -name "*.glsl" > files
perl -0777 -pi -e 's/\n}\n([^#])/\n}\n\n\1/g' $(cat files)
misc/scripts/fix_style.sh -c
```
This adds a newline after all `}` on the first column, unless they
are followed by `#` (typically `#endif`). This leads to having lots
of places with two lines between function/class definitions, but
clang-format then fixes it as we enforce max one line of separation.
This doesn't fix potential occurrences of function definitions which
are indented (e.g. for a helper class defined in a .cpp), but it's
better than nothing. Also can't be made to run easily on CI/hooks so
we'll have to be careful with new code.
Part of #33027.
Which means that reduz' beloved style which we all became used to
will now be changed automatically to remove the first empty line.
This makes us lean closer to 1TBS (the one true brace style) instead
of hybridating it with some Allman-inspired spacing.
There's still the case of braces around single-statement blocks that
needs to be addressed (but clang-format can't help with that, but
clang-tidy may if we agree about it).
Part of #33027.
Using `clang-tidy`'s `modernize-use-default-member-init` check and
manual review of the changes, and some extra manual changes that
`clang-tidy` failed to do.
Also went manually through all of `core` to find occurrences that
`clang-tidy` couldn't handle, especially all initializations done
in a constructor without using initializer lists.
Part of #33027, also discussed in #29848.
Enforcing the use of brackets even on single line statements would be
preferred, but `clang-format` doesn't have this functionality yet.
Skew is x-axis only, because it must be bidirectionally convertible to a 2x3 matrix, but you can subtract it to the rotation to get the effect on y-axis
It changed name as part of the DisplayServer and input refactoring
in #37317, with the rationale that input no longer goes through the
main loop, so the previous Input singleton now only does filtering.
But the gains in consistency are quite limited in the renaming, and
it breaks compatibility for all scripts and tutorials that access
the Input singleton via the scripting language. A temporary option
was suggested to keep the scripting singleton named `Input` even if
its type is `InputFilter`, but that adds inconsistency and breaks C#.
Fixesgodotengine/godot-proposals#639.
Fixes#37319.
Fixes#37690.
Note: Only replaced 2 instances to test, Node.get_children and TileMap.get_used_cells
Note: Will do a mass replace on later PRs of whathever I can find, but probably need
a tool to grep through doc.
Warning: Mono will break, needs to be fixed (and so do TypeScript and NativeScript, need to ask respective maintainers)
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
