Remove now unnecessary bindings of signal callbacks in the public API.
There might be some false positives that need rebinding if they were
meant to be public.
No regular expressions were harmed in the making of this commit.
(Nah, just kidding.)
Main:
- It's now implemented thanks to `<mutex>`. No more platform-specific implementations.
- `BinaryMutex` (non-recursive) is added, as an alternative for special cases.
- Doesn't need allocation/deallocation anymore. It can live in the stack and be part of other classes.
- Because of that, it's methods are now `const` and the inner mutex is `mutable` so it can be easily used in `const` contexts.
- A no-op implementation is provided if `NO_THREADS` is defined. No more need to add `#ifdef NO_THREADS` just for this.
- `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`.
- Thread-safe utilities are therefore simpler now.
Misc.:
- `ScopedMutexLock` is dropped and replaced by `MutexLock`, because they were pretty much the same.
- Every case of lock, do-something, unlock is replaced by `MutexLock` (complex cases where it's not straightfoward are kept as as explicit lock and unlock).
- `ShaderRD` contained an `std::mutex`, which has been replaced by `Mutex`.
Although destructor call was missing, it still doesn't heal #36537 memory leaks. Further description how that might be overcome - on GitHub
Partialy covers #36537
- Renames PackedIntArray to PackedInt32Array.
- Renames PackedFloatArray to PackedFloat32Array.
- Adds PackedInt64Array and PackedFloat64Array.
- Renames Variant::REAL to Variant::FLOAT for consistency.
Packed arrays are for storing large amount of data and creating stuff like
meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of
memory. That said, many users requested the ability to have 64 bits packed
arrays for their games, so this is just an optional added type.
For Variant, the float datatype is always 64 bits, and exposed as `float`.
We still have `real_t` which is the datatype that can change from 32 to 64
bits depending on a compile flag (not entirely working right now, but that's
the idea). It affects math related datatypes and code only.
Neither Variant nor PackedArray make use of real_t, which is only intended
for math precision, so the term is removed from there to keep only float.
-Texture renamed to Texture2D
-TextureLayered as base now inherits 2Darray, cubemap and cubemap array
-Removed all references to flags in textures (they will go in the shader)
-Texture3D gone for now (will come back later done properly)
-Create base rasterizer for RenderDevice, RasterizerRD
Self-modulation was forcefully used for the curve drawing which
can interfere with scripted drawing. The curve color is specified by
the `draw_line()` method instead.
- 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.
Some cases were not handled properly for Polygon2D after making changes in common code to fix Line2D antialiasing. Added an option for drawing polygons to differentiate the two use cases.
Fixes#34568
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.
In the 3D version:
- Partially revert #20908 that was reverted in the 2D version as part
of #21653. This ensures that the Vector returned is always perpendicular
to the surface collided with; and not the floor_normal Vector passed to
the function when on a floor.
- Include an update of the floor velocity before multiplying by the time
delta, which was added to the 2D version as part of commit 13a8014.
In the 2D version:
- Use the Vector2.slide() function instead of Vector2.tangent() to adjust
the amount of motion the stop_on_slope undoes to ensure that it is in the
right direction. This is a implementation of the 3D approach from #30588.
- Combine the !found_collision and motion == Vector2() checks for break.
- Other minor formating changes to make the functions look identical.
Also renamed some variables to align with their use.
Polygon2D:
The property wasn't used anymore after switching from canvas_item_add_polygon() to canvas_item_add_triangle_array() for drawing.
Line2D:
Added the same property as for Polygon2D & fixed smooth line drawing to use indices correctly.
Fixes#26823
Particles were processed only on the next frame after the emission started, causing a one frame delay in rendering. Now the first process cycle is started during the same frame, which makes them consistent with Particles & Particles2D.
Fixes#32890
Now using joint_disable_collisions_between_bodies() to reset the exception, because body_remove_collision_exception() was doing only a part of the work.
Fixes#32733
When playing an animation in reverse, the animation initially starts on frame 0. If it loops, it'll play normally by going to the last frame of the animation, but if it does not... it prematurely stops, since it is already on the last frame (for reversed animation) by starting on frame 0.
OpenGL uses the diamond exit rule to rasterize lines. If we don't shift
the points down and to the right by 0.5, the line can sometimes miss a
pixel when it shouldn't. The final fragment of a line isn't drawn. By
drawing the lines clockwise, we can avoid a missing pixel in the rectangle.
See section 3.4.1 in the OpenGL 1.5 specification.
Fixes#32279
Modified Sprite to use "changed" signal instead of _changed_callback to make it work when tool is disabled (change receptors are editor only).
Fixes#32349
The CanvasItem property setters `set_modulate`, `set_self_modulate`
and `set_light_mask` have some side effects that don't need to be run
if the value hasn't changed.
This closes#31777.
When moving KinematicBody2D from one scene to another and not freeing
the old scene, the first call to move_and_slide() in the new scene will
generate an error because KinematicBody2D keeps internaly a
RID on_floor_body of a body resource in the old scene which no more has
a space assigned.
To fix this, on_floor_body is set to empty RID in response to
NOTIFICATION_ENTER_TREE notification of KinematicBody2D and
KinematicBody. Also all other data related to move_and_slide() is reset:
floor, ceiling, wall flags, colliders vector, floor_velocity.
This fixes#31416.
- Add new handle icons for path/polygon editors
- Add smooth path point icons and curve tangent icons
- Use a gray color for tangent lines in the Path2D and Path editors
- Use antialiasing for Path2D lines
This was a regression in 3.1 and later from the new inspector, where
PROPERTY_HINT_SPRITE_FRAME was not fully re-implemented. It's meant to
be a normal PROPERTY_HINT_RANGE which also automatically increments its
value when keyed in the animation player.
To avoid code duplication, I made the frames properties use the actual
PROPERTY_HINT_RANGE and introduced a PROPERTY_USAGE_KEYING_INCREMENTS
usage flag instead.
- Make RayCast2D gray when it's disabled
- Make the one-way collision arrow use the inverted shape debugging
color (will result in an orange color by default)
- This makes it easier to distinguish it from RayCast2D arrows
- Make lines slightly thinner
- Make the RayCast2D arrow tip larger
- Use anti-aliasing for the RayCast2D and one-way collision lines
- Refer to properties explicitly when possible
- When multiple warnings are returned, always separate them by one
blank line to make them easier to distinguish
- Improve grammar and formatting
For clarity, assign-to-release idiom for PoolVector::Read/Write
replaced with a function call.
Existing uses replaced (or removed if already handled by scope)
This commit fix#22989#15249#28206. Main problem is that tilemap displace textures in different tile origins in a strange way and doesn´t respect coincidence between texture and shapes in not uniform tiles. This issue is present in godot 3.0 and godot 3.1. To maintain compatibility are added a compatibility mode and a center texture option. Other related issues and pull request: #28896#29487#29519#29961. Idications of #30204 are added
Those signals receive either a PhysicsBody2D or a TileMap object,
and what the emitting method checks internally is only that the
object is a Node. In theory any Node could go through these signals
if they talk directly to the PhysicsServer2D.
Also updated docs.
Fixes#27076.
Might need further (compat breaking) improvement as this API is a
bit confusing, cf. #24739.
Warnings raised by Emscripten 1.38.0 and MinGW64 5.0.4 / GCC 8.3.0.
JS can now build with `werror=yes warnings=extra`.
MinGW64 still has a few warnings to resolve with `warnings=extra`,
and only one with `warnings=all`.
Part of #29033 and #29801.
The original shader code uses a phase (ratio from 0 to 1 for the particle
lifetime) for the randomness ratio computations, and this code was ported
over but converted to time computations.
The seeding/cycle logic was thus invalid, so we're going back to phase
for these computations, thus fixing the previous non-working time/emission
randomness property.
Part of #29692. Follow-up to #26859.
The tangential acceleration for both CPUParticles2D and CPUParticles had been
badly converted from their GPU counterpart (ParticlesMaterial).
This fixes it and ensures that both GPU and CPU particles behave the same with
regard to tangential acceleration.
It's not necessary, but the vast majority of calls of error macros
do have an ending semicolon, so it's best to be consistent.
Most WARN_DEPRECATED calls did *not* have a semicolon, but there's
no reason for them to be treated differently.
