| Age | Commit message (Collapse) | Author |
|---|
|
We will be progressively moving most code to C#.
The plan is to only use Mono's embedding APIs to set things at launch.
This will make it much easier to later support CoreCLR too which
doesn't have rich embedding APIs.
Additionally the code in C# is more maintainable and makes it easier
to implement new features, e.g.: runtime codegen which we could use to
avoid using reflection for marshaling everytime a field, property or
method is accessed.
SOME NOTES ON INTEROP
We make the same assumptions as GDNative about the size of the Godot
structures we use. We take it a bit further by also assuming the layout
of fields in some cases, which is riskier but let's us squeeze out some
performance by avoiding unnecessary managed to native calls.
Code that deals with native structs is less safe than before as there's
no RAII and copy constructors in C#. It's like using the GDNative C API
directly. One has to take special care to free values they own.
Perhaps we could use roslyn analyzers to check this, but I don't know
any that uses attributes to determine what's owned or borrowed.
As to why we maily use pointers for native structs instead of ref/out:
- AFAIK (and confirmed with a benchmark) ref/out are pinned
during P/Invoke calls and that has a cost.
- Native struct fields can't be ref/out in the first place.
- A `using` local can't be passed as ref/out, only `in`. Calling a
method or property on an `in` value makes a silent copy, so we want
to avoid `in`.
REGARDING THE BUILD SYSTEM
There's no longer a `mono_glue=yes/no` SCons options. We no longer
need to build with `mono_glue=no`, generate the glue and then build
again with `mono_glue=yes`. We build only once and generate the glue
(which is in C# now).
However, SCons no longer builds the C# projects for us. Instead one
must run `build_assemblies.py`, e.g.:
```sh
%godot_src_root%/modules/mono/build_scripts/build_assemblies.py \
--godot-output-dir=%godot_src_root%/bin \
--godot-target=release_debug`
```
We could turn this into a custom build target, but I don't know how
to do that with SCons (it's possible with Meson).
OTHER NOTES
Most of the moved code doesn't follow the C# naming convention and
still has the word Mono in the names despite no longer dealing with
Mono's embedding APIs. This is just temporary while transitioning,
to make it easier to understand what was moved where.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add Text Server related options to the build profiles editor.
|
|
`shader_uniform` is now consistenly used across both per-shader
and per-instance shader uniform methods. This makes methods easier
to find in the class reference when looking for them.
|
|
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.
|
|
|
|
Adds SCons options to disable Brotli and Graphite.
Adds option categories to the build profiles editor.
Adds options default state to the build profiles editor.
Adds Text Server related options to the build profiles editor.
Fix misplaced OpenGL/Vulkan SCons options.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add `editor_paths.h` include missing in mono module
|
|
|
|
|
|
The `Callable::call` and `Callable::call_deferred` methods have been
renamed to `Callable::callp` and `Callable::call_deferredp`.
|
|
|
|
|
|
|
|
bluenote10/feature/rename_translated_to_translated_local
|
|
- 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.
|
|
Adds `header_guards.sh` bash script, used in CI to validate future
changes. Can be run locally to fix invalid header guards.
|
|
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.
|
|
|
|
|
|
|
|
|
|
The / operator was wrongly documented as a multiplication.
|
|
|
|
|
|
|
|
|
|
filenames) and some non-standard UTF-8 variants, makes Unicode parse errors more verbose.
|
|
C#: Add `BezierInterpolate` method
|
|
Replace old RPC attributes with a new single `RPCAttribute` which works
like the GDScript `@rpc` annotation.
|
|
|
|
Adds a `BezierInterpolate` method for floats in `Mathf` and for vectors
in `Vector2` and `Vector3`.
|
|
|
|
|
|
|
|
Allows to specify the binder that an enum must be treated as a bitfield.
|
|
|
|
|
|
|