The Godot API (gdnative_interface.h) allows methods to be registered on
extension classes with
`classdb_register_extension_class_method`
a `GDNativeExtensionClassMethodInfo` can be provided to this function
along with a `get_argument_info_func` which according to the comment
indicates that argument names should be definable here.
Unfortunately, setting the name field in the `GDNativePropertyInfo`
struct has no effect on the editor documentation, which continues to
display "_unnamed_arg" for each argument.
I discovered that `get_argument_info` is responsible for this as it
always overrides the `info.name`. I've added an if condition that will
only override the name when it is empty. I've tested this with my
GDExtension module and I can confirm that with this commit, the argument
name shows up in the builtin docs. eg. in Lookup Symbol.
Replace all TODO uses of `#warning` by proper TODO comments, and will open
matching bug reports to keep track of them.
We don't have a great track record fixing TODOs, but I'd wager we're even
worse for fixing these "TODO #warning" so we should prohibit this usage.
- Outright disable spammy warnings due to past or present GCC bugs:
* `-Wno-strict-overflow` for GCC 7.
* `-Wno-type-limits` for GCC before 11 (regressed in 9/10, might work in
earlier releases but at this stage we don't care).
* `-Wno-return-type` for GCC 12/13 (regression, still not fixed).
- Enable extra warnings conditionally when broken on earlier GCC:
* `-Wnoexcept` was removed due to an upstream regression in GCC 9, could
be re-enabled (but commented out for now as we actually have `-Wnoexcept`
warnings to fix.
* `-Wlogical-op` was broken on our variadic templates before GCC 11, now
seems fine.
Android was the last platform to still attempt to disable RTTI (for binary
size), but both the Android editor and now the ICU library used by templates
need RTTI.
There could still be the possibility to support this for non-ICU template
builds (i.e. without the TextServerAdvanced module), but since this isn't one
of the build configurations we test regularly it's pretty risky to keep this
option only for that specific use case. And our code is already littered with
`dynamic_cast`s which weren't guarded with `!defined(NO_SAFE_CAST)`.
A priori this doesn't appear to be an actual bug, but a known consequence of
using UBSAN. We silence this one to still have the possibility to get more
warnings raised by UBSAN, in case they are useful.
Works around and closes#66343.
"less" should be used for quantity, rather than "lesser".
Existing scripts that use `or_lesser` in `_get_property_list()`
will need to be updated to account for this change.
- Use different syntax for object printing to avoid confusion with arrays.
- Print null as `<null>` to avoid confusion with a string `"null"`.
- Display `<empty>` in editor resource pickers to avoid confusion
with array-based properties.
_has_property_default_value is a required virtual
for ScriptExtension but it was not bound, and could
therefore not be implemented
this made it impossible to implement a ScriptExtension
that runs
This was a regression from 4469144891
The callback should be called, not only be called when the refcount
reaches 0. For example, the C# callback needs to know when the
refcount reaches 1, in order to swap to a weak GC handle.
The function tried to rearrange properties but that lead to problems with duplication or deleted properties. Implemented the logic that that function did inside the get_property_list both for tool scripts and non-tool scripts.
- Add `positive_only` property hint to disallow using negative presets.
These values are clamped in several places in the editor already,
so this avoids displaying presets that don't work.
- Move the Zero preset at the end of the positive list to match
the custom property editor. It's also used less often than Linear,
Ease In and Ease Out.
- Rename presets to be consistent between the easing property editor
and custom property editor.
- Remove unused `inout` hint which was redundant since it was already
the default.
- RPC configurations are now dictionaries.
- Script.get_rpc_methods renamed to Script.get_rpc_config.
- Node.rpc[_id] and Callable.rpc now return an Error.
- Refactor MultiplayerAPI to allow extension.
- New MultiplayerAPI.rpc method with Array argument (for scripts).
- Move the default MultiplayerAPI implementation to a module.
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.
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>
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).
* 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)
* Map is unnecessary and inefficient in almost every case.
* Replaced by the new HashMap.
* Renamed Map to RBMap and Set to RBSet for cases that still make sense
(order matters) but use is discouraged.
There were very few cases where replacing by HashMap was undesired because
keeping the key order was intended.
I tried to keep those (as RBMap) as much as possible, but might have missed
some. Review appreciated!
Adds a new, cleaned up, HashMap implementation.
* Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing).
* Keeps elements in a double linked list for simpler, ordered, iteration.
* Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much
for performance vs keeping the key, but helps replace old code).
* Uses a more modern C++ iterator API, deprecates the old one.
* Supports custom allocator (in case there is a wish to use a paged one).
This class aims to unify all the associative template usage and replace it by this one:
* Map<> (whereas key order does not matter, which is 99% of cases)
* HashMap<>
* OrderedHashMap<>
* OAHashMap<>
Implemented by request of @neikeq to advance in the GDExtension version of Mono.
* If a Resource type is missing upon load, it will be remembered together with its data (Unless manually overriden).
* If a Node type is missing upon load, it will be also be remembered together with its data (unless deleted).
This feature makes working with GDExtension much easier, as it ensures that missing types no longer cause data loss.
These typedefs don't save much typing compared to the full `Ref<Resource>`
and `Ref<RefCounted>`, yet they sometimes introduce confusion among
new contributors.
Type emit_signal exposed method return type
set UndoRedo add_do_method and add_undo_method exposed return void
Set TreeItem::_call_recursive_bind returns void
Set _rpc_bind and _rpc_id_bind returns void in Node
Set _call_group and _call_group_flags method returns void in SceneTree
Set godot-cpp-test CI flag to false
* Ability to create script languages from GDExtension
* Some additions to gdnative_extension.h to make this happen
* Moved the GDExtension binder to core
This now allows creating scripting languages from GDExtension, with the same ease as if it was a module. It replaces the old PluginScript from Godot 3.x.
Warning: GodotCPP will need to be updated to support this (it may be a bit of work as ScriptInstance needs to be created over there again).
We might want to re-add something like this if/when we find a good use case
for it and do the effort to categorize all objects in the API properly.
Until then, it's better to remove that boilerplate since it's not needed.
Closes#18711.
* API kept the same (Although functions could be renamed to set_metadata/get_metadata in a later PR), so not much should change.
* Metadata now exposed as individual properties.
* Properties are editable in inspector (unless metadata name begins with _) under the metadata/ namespace.
* Added the ability to Add/Remove metadata properties to the inspector.
This is a functionality that was requested very often, that makes metadata work a bit more similar to custom properties in Blender.
