Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks
that can be run on threads (and then waited for). It satisfies the following use cases:
* HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads.
* Thread spawning is slow in general, so reusing threads is faster anyway.
* This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks.
After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
This PR is a continuation of #50381 (which was implemented exactly a year ago!)
* Add a visual interface to select which classes should not be built into Godot (well, they are built if something else uses them, but if not used the optimizer will remove them out).
* Add a detection system to scan the project and figure out the actual classes used.
* Added the ability for SCons to load build profiles.
Obligatory Screen:
A simple test with a couple of nodes in the scene resulted in a 25% reduction for the final binary size
TODO:
* Script languages need to implement used class detection (left for another PR).
* Options to disable servers or server functionalities (like 2D or 3D physics, navigation, etc). Are missing, that should also greatly aid in reducing binary size.
* Options to disable some modules would be desired.
* More options to disable drivers (OpenGL, Vulkan, etc) would be desired.
In general this PR is a starting point for more contributors to improve and enhance this functionality.
Read/write ops for this implementation are done through the java layer via jni, and so for good performance, it's key to avoid numerous repeated small read/write ops due the jni overhead.
The alternative is to allocate a (conversatively-sized) large buffer to reduce the number of read/write ops over the jni boundary.
MultiplayerSynchronizers can now be configured to limit their visibility
to a subset of the connected peers, if the synchronized node was spawned
by a MultiplayerSpawner (either automatically or via custom spawn) the
given node will also be despawned remotely.
The replication system doesn't have the logic to handle subspawn
directly, but it is possible to handle them appropriately by manually
updating the visibility of the parent before changing the one of the
nested spawns via the "update_visibility" function.
The visibility of each MultiplayerSynchronizer can be controlled by
adding or remove filters via "[add|remove]_visibility_filter(callable)".
To further optimize the network code, visibility filters can be configured
to be automatically updated during idle or physics frame, or set to always
require manual update (via the "update_visibility" function).
This was done by refactoring directory and file access handling for the Android platform so that any general filesystem access type go through the Android layer.
This allows us to validate whether the access is unrestricted, or whether it falls under scoped storage and thus act appropriately.
For this to work safely (user not call queue_free or something in the expression), a const call mode was added to Object and Variant (and optionally Script).
This mode ensures only const functions can be called, making it safe to use from the editor.
Co-Authored-By: reduz <reduzio@gmail.com>
When a type is shared (i.e. passed by reference) it doesn't need to be
called in a setter chain (e.g. `a.b.c = 0`) since it will be updated in
place.
This commit adds an instruction that jumps when the value is shared so
it can be used to skip those cases and avoid redundant calls of setters.
It also solves issues when assigning to sub-properties of read-only
properties.
This PR implements:
* A new hint: PROPERTY_HINT_NODE_TYPE for variant type OBJECT, which can take specific node types as hint string.
* The editor will show it as a node path, but will set it as a pointer to a node from the current scene if you select a path.
* When scene is saved, the node path is saved, then restored as a pointer.
NOTE: This is a proof of concept and this approach will most likely not work. The reason if that, if the node referenced is deleted, then when trying to edit this the node will become invalid.
Potential workarounds: Since this uses the Variant API, it should obtain the pointer from the Variant object ID. Yet, this would either only really work in GDScript or it would need to be implemented with workarounds in every language.
Alternative ways to make this work: Nodes could export an additional property with a node path (like for which_node, it could be which_node_path).
Another alternative: Path editing could happen as a hidden metadata (ignoring the pointer).
* Ensures thread safety when resources are destroyed.
* Simplified API by always forcing `ResourceCache::get_ref`, which needs less hacks and is fully thread safe.
* Removed RWLock for resources because its not possible to use for the new logic. Should not be a problem.
Supersedes #57533
* Allows running the game in "movie writer" mode.
* It ensures entirely stable framerate, so your run can be saved stable and with proper sound (which is impossible if your CPU/GPU can't sustain doing this in real-time).
* If disabling vsync, it can save movies faster than the game is run, but if you want to control the interaction it can get difficult.
* Implements a simple, default MJPEG writer.
This new features has two main use cases, which have high demand:
* Saving game videos in high quality and ensuring the frame rate is *completely* stable, always.
* Using Godot as a tool to make movies and animations (which is ideal if you want interaction, or creating them procedurally. No other software is as good for this).
**Note**: This feature **IS NOT** for capturing real-time footage. Use something like OBS, SimpleScreenRecorder or FRAPS to achieve that, as they do a much better job at intercepting the compositor than Godot can probably do using Vulkan or OpenGL natively. If your game runs near real-time when capturing, you can still use this feature but it will play no sound (sound will be saved directly).
Usage:
$ godot --write-movie movie.avi [scene_file.tscn]
Missing:
* Options for configuring video writing via GLOBAL_DEF
* UI Menu for launching with this mode from the editor.
* Add to list of command line options.
* Add a feature tag to override configurations when movie writing (fantastic for saving videos with highest quality settings).
Clean up and do fixes to hash functions and newly introduced murmur3 hashes in #61934
* Clean up usage of murmur3
* Fixed usages of binary murmur3 on floats (this is invalid)
* Changed DJB2 to use xor (which seems to be better)
This is done to prevent reducing texture quality when it doesn't save
much video memory, especially for pixel art.
The size threshold can be adjusted in the project settings.
To get the previous behavior where textures detected to be used in 3D
had their compression mode always set to VRAM, set this to the lowest value
(16).
I had an error while importing my GLB file from 32-bit precision
floating point,
I guess this was forgotten while implementing 64-bit precision floating
point.
I'm not sure if there's any other left to do though.
Initial TAA support based on the implementation in Spartan Engine.
Motion vectors are correctly generated for camera and mesh movement, but there is no support for other things like particles or skeleton deformations.
