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`.
It was initially implemented in #5871 for Godot 3.0, but never really
completed or thoroughly tested for most platforms. It then stayed in
limbo and nobody seems really keen to finish it, so it's better to
remove it in 4.0, and re-add eventually (possibly with a different API)
if there's demand and an implementation confirmed working on all
platforms.
Closes#8770.
Due to the port to Vulkan and complete redesign of the rendering backend,
the `drivers/gles3` code is no longer usable in this state and is not
planned to be ported to the new architecture.
The GLES2 backend is kept (while still disabled and non-working) as it
will eventually be ported to serve as the low-end renderer for Godot 4.0.
Some GLES3 features might be selectively ported to the updated GLES2
backend if there's a need for them, and extensions we can use for that.
So long, OpenGL driver bugs!
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.
This makes it possible to know whether the window is focused
at a given time, without having to track the focus state manually
using `NOTIFICATION_WM_FOCUS_IN` and `NOTIFICATION_WM_FOCUS_OUT`.
This partially addresses #33928.
Addresses #30068
This is a prerequisite for allowing proper support for fixed timestep interpolation, exposing the interpolation fraction to the engine, modules and gdscript.
The interpolation fraction is the fraction through the current physics tick at the time of the current frame.
Can be used via scripting as `Geometry.triangulate_delaunay_2d(points)`
The interface is the same as in `Triangulate` library, returning indices
into triangulated points.
Clipper 6.4.2 is used internally to perform polypaths clipping, as well
as inflating/deflating polypaths. The following methods were added:
```
Geometry.merge_polygons_2d(poly_a, poly_b) # union
Geometry.clip_polygons_2d(poly_a, poly_b) # difference
Geometry.intersect_polygons_2d(poly_a, poly_b) # intersection
Geometry.exclude_polygons_2d(poly_a, poly_b) # xor
Geometry.clip_polyline_with_polygon_2d(poly_a, poly_b)
Geometry.intersect_polyline_with_polygon_2d(poly_a, poly_b)
Geometry.offset_polygon_2d(polygon, delta) # inflate/deflate
Geometry.offset_polyline_2d(polyline, delta) # returns polygons
// This one helps to implement CSG-like behaviour:
Geometry.transform_points_2d(points, transform)
```
All the methods return an array of polygons/polylines. The resulting
polygons could possibly be holes which could be checked with
`Geometry.is_polygon_clockwise()` which was exposed to scripting as well.
Network peers get_var/put_var
File get_var/store_var
GDScript/Mono/VisualScript bytes2var/var2bytes
Add MultiplayerAPI.allow_object_decoding member which deprecates PacketPeer.allow_object_decoding.
Break ABI compatibaility (API compatibility for GDNative).
This allows more consistency in the manner we include core headers,
where previously there would be a mix of absolute, relative and
include path-dependent includes.
