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.
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.
- Add support for explicit values in properties using `PROPERTY_HINT_FLAGS`
that works the same way it does for enums.
- Fix enums and flags in VisualScriptEditor (it wasn't considering the
explicit value).
- Use `PROPERTY_HINT_FLAGS` for C# enums with the FlagsAttribute instead
of `PROPERTY_HINT_ENUM`.
* 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<>
`DirAccess *` needs to be deleted manually, and this is often forgotten
especially when doing early returns with `ERR_FAIL_COND`.
`DirAccessRef` is deleted automatically when it goes out of scope.
Co-authored-by: bruvzg <7645683+bruvzg@users.noreply.github.com>
We prefer to prevent using chained assignment (`T a = b = c = T();`) as this
can lead to confusing code and subtle bugs.
According to https://en.wikipedia.org/wiki/Assignment_operator_(C%2B%2B), C++
allows any arbitrary return type, so this is standard compliant.
This could be re-assessed if/when we have an actual need for a behavior more
akin to that of the C++ STL, for now this PR simply changes a handful of
cases which were inconsistent with the rest of the codebase (`void` return
type was already the most common case prior to this commit).
Settings that aren't within a subsection are difficult to reach when
other settings do have a subsection.
This also adds documentation for the project setting.
Sets `AlignOperands` to `DontAlign`.
`clang-format` developers seem to mostly care about space-based indentation and
every other version of clang-format breaks the bad mismatch of tabs and spaces
that it seems to use for operand alignment. So it's better without, so that it
respects our two-tabs `ContinuationIndentWidth`.
This commit completely removes the RPC_MODE_MASTER ("master" keyword),
and renames the RPC_MODE_PUPPET to RPC_MODE_AUTHORITY ("auth" keyword).
This commit also renames the "Node.[get|set]_network_master" methods to
"Node.[get|set]_network_authority".
This commit also renames the RPC_MODE_REMOTE constant to RPC_MODE_ANY.
RPC_MODE_MASTER in Godot 3.x meant that a given RPC would be callable by
any puppet peer on the master, while RPC_MODE_PUPPET meant that it would
be callable by the master on any puppet.
Beside proving to be very confusing to the user (referring to where it
could be called instead of who can call it) the RPC_MODE_MASTER is quite
useless. It is almost the same as RPC_MODE_REMOTE (anyone can call) with
the exception that the network master cannot. While this could be useful
to check in some case, in such a function you would anyway need to check
in code who is the caller via get_rpc_sender_id(), so adding the check
there for those rare cases does not warrants a dedicated mode.
- Move the "sync" property for RPCs to RPCConfig.
- Unify GDScript annotations into a single one:
- `@rpc(master)` # default
- `@rpc(puppet)`
- `@rpc(any)` # former `@remote`
- Implement three additional `@rpc` options:
- The second parameter is the "sync" option (which also calls the
function locally when RPCing). One of "sync", "nosync".
- The third parameter is the transfer mode (reliable, unreliable,
ordered).
- The third parameter is the channel (unused for now).
* The harcoded 8 slots are no more and impose limits in the new extension system.
* New system is limitless, although it will impose small performance hit with a mutex.
* Use a token to request the instance binding.
**Warning**: Mono will most likely break as a result of this, will need to be modified to use the new system.
- Fix C++ compile errors about pending variable renames after the `Reference` to `RefCount` change.
- Fix C# compile errors due to the recent rename of `EnablePlugin()` and `Build()`, which are now underscore-prefixed in bindings.
- Additional rename: `godot_icall_Reference_Dtor` to `godot_icall_RefCounted_Dtor`.
