The new color for screen drawing was chosen to be easier to distinguish
from the 2D viewport limits.
This also makes lines less opaque when the Camera2D has the Current
property enabled. The increased line width is enough to spot the
camera easily, and the increased opacity on top of that felt obnoxious.
(cherry picked from commit 8e2a7fff1d)
Decide whether half offset should be added based on the value used for calculating the return value of this method.
(cherry picked from commit f1420c7cbf)
We've been using standard C library functions `memcpy`/`memset` for these since
2016 with 67f65f6639.
There was still the possibility for third-party platform ports to override the
definitions with a custom header, but this doesn't seem useful anymore.
Backport of #48239.
When AnimatedSprite2D::play() was called before SpriteFrames has been initialized, a crach occurred (issue #46013).
Modification : An error message on null check test has been added to prevent crash.
Fix#46013.
(cherry picked from commit 324ab63844)
The logic for internal process and internal physics process in Camera2D was very buggy and convoluted for historical reasons.
This is a cleanup to make the logic simpler and easier to follow.
More work is needed to make sure that those options actually solve users' issues, so we prefer to remove the options for 3.2.4 and revisit for a future release.
If true, collision shapes are shown in the editor and at run-time.
Requires Visible Collision Shapes to be enabled in the Debug menu,
for collision shapes to be visible at run-time.
When one of the bodies exited the tree, the corresponding node path was
reset instead of just resetting the joint from the physics server. That
was causing the node path to be reset on scene switch when one of the
bodies is under the joint in the scene tree.
The rendering/quality/2d section of project settings is becoming considerably expanded in 3.2.4, and arguably was not the correct place for settings that were not really to do with quality.
3.2.4 is the last sensible opportunity we will have to move these settings, as the only existing one likely to break compatibility in a small way is `pixel_snap`, and given that the whole snapping area is being overhauled we can draw attention to the fact it has changed in the release notes.
Class reference is also updated and slightly improved.
`pixel_snap` is renamed to `gpu_pixel_snap` in the project settings and code to help differentiate from CPU side transform snapping.
Two common problems have emerged as a result of transform snapping:
1) Camera jitter with a camera following a snapped object
2) Pixel gaps between e.g. a platform and a player, where a platform rounds down and a player rounds up
Using round seems to greatly reduce problems due to camera jitter. It also may prove better for pixel gaps because pixel art is often designed on a grid, so whole numbers are too expected, which are unstable with floor().
Having white or strongly desaturated debug collision shape color
setting would make it harder to visualize enabled / disabled state.
This change makes it easier to visualize enabled / disabled state
by reducing the alpha color by half when disabled.
(cherry picked from commit 0c4594f6c9)
- 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 `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 change does two things:
1. Properly update the internal shape data using _update_in_shape_owner
when updating a shape (in 2D it was resetting one way collision)
2. Avoid unnecessary updates when calling set_shape with the same shape,
which happens each time a shape property is modified
(e.g shape.extents.x = ...)
Fixes#45090
(cherry picked from commit 4b43cd17c5)
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)
Body transforms from physics are used to setup the joint and they are
only updated before the physics step by default.
Without forcing the transform update, joints could use a previous
position if the body's position was set after it was added to the scene.
3D physics is not affected by this issue.
(cherry picked from commit 11bee25de4)
Partially revert change allowing sprite get_rect snapping to be controlled by `pixel_snap` again rather than `transform_snap` (to prevent breaking compatibility). Adds a final `use_camera_snap` project setting to allow snapping viewports as in reduz original PR.
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.
(cherry picked from commit 1c231cacb3)
`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.
(cherry picked from commit dc446203be)
This reverts commit 7f61710183.
See #38868, in its current implementation a small skew value might end up
serialized to scene files due to floating point precision errors, which is
detrimental to VCS.
This can be cherry-picked anew once a fix for #38868 has been found.
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.
(cherry picked from commit cd4e46ee65)
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
(cherry picked from commit efb1f7d76b)
Calls to set_amount can increase the size of the particle array, but do not zero the memory, they only set the active flag to false. This uninitialized memory can be sent to the GPU, possibly as NaNs.
The code above for horizontal movement uses the right margin (_positive_ x direction) when the offset is negative, but vertical movement uses the top margin (_negative_ y direction) when the offset is negative.
The resulting problem is easily seen in the editor — set the drag margins to be asymmetrical, turn on drawing the drag margins, and slide the offsets from -1 to 1 and back. The horizontal offset moves the camera's center between the left and right margins, but the vertical offset gets them backwards and will move the camera outside the margins entirely.
(cherry picked from commit 40816574ac)
- Add some missing descriptions.
- Add links to tutorials for ARVR and AnimationTree.
- Style fixes.
- Engine changes:
* Make `AnimationNodeTransition.input_<number>` properties internal
so that they don't appear in the docs. They still appear in the
inspector based on the actual number of inputs requested.
* Drop unimplemented `CPUParticles.flatness`. It's only used for 3D
particles in `ParticlesMaterial`, and thus only relevant for
`CPUParticles3D`.
When there is no collision with a floor the get_floor_normal() function
should return the zero vector to be consistent with get_floor_velocity().
Renames floor_normal to up_direction in all bindings.
Updates the documentation of get_floor_normal() and get_floor_velocity()
to make it clear when the values are valid. Updates the documentation for
move_and_slide() and move_and_slide_with_snap() to use the new up_direction
parameter name.
