We're targeting .NET 5 for now to make development easier while
.NET 6 is not yet released.
TEMPORARY REGRESSIONS
---------------------
Assembly unloading is not implemented yet. As such, many Godot
resources are leaked at exit. This will be re-implemented later
together with assembly hot-reloading.
The main focus here was to remove the majority of code that relied on
Mono's embedding APIs, specially the reflection APIs. The embedding
APIs we still use are the bare minimum we need for things to work.
A lot of code was moved to C#. We no longer deal with any managed
objects (`MonoObject*`, and such) in native code, and all marshaling
is done in C#.
The reason for restructuring the code and move away from embedding APIs
is that once we move to .NET Core, we will be limited by the much more
minimal .NET hosting.
PERFORMANCE REGRESSIONS
-----------------------
Some parts of the code were written with little to no concern about
performance. This includes code that calls into script methods and
accesses script fields, properties and events.
The reason for this is that all of that will be moved to source
generators, so any work prior to that would be a waste of time.
DISABLED FEATURES
-----------------
Some code was removed as it no longer makes sense (or won't make sense
in the future).
Other parts were commented out with `#if 0`s and TODO warnings because
it doesn't make much sense to work on them yet as those parts will
change heavily when we switch to .NET Core but also when we start
introducing source generators.
As such, the following features were disabled temporarily:
- Assembly-reloading (will be done with ALCs in .NET Core).
- Properties/fields exports and script method listing (will be
handled by source generators in the future).
- Exception logging in the editor and stack info for errors.
- Exporting games.
- Building of C# projects. We no longer copy the Godot API assemblies
to the project directory, so MSBuild won't be able to find them. The
idea is to turn them into NuGet packages in the future, which could
also be obtained from local NuGet sources during development.
We are moving in the direction of no dynamic code generation,
so this is no longer desired.
The feature can still be easily implemented by any project that
still want it.
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.
With this commit the macro `memnew_placement` uses the standard memory
placement syntax: `new (mem) TheClass()`, and removes the outdated and
not used syntax:
```
_ALWAYS_INLINE_ void *operator new(size_t p_size, void *p_pointer, size_t check, const char *p_description) {
```
Thanks to this change, the function `memnew_placement` call is compatible with
any class, and can also initialize classes with non-empty constructor:
```
// This is valid, like before.
memnew_placement(mem, Variant);
// This works too:
memnew_placement(mem, Variant(123));
```
- Back to 1-based layer names to make it clearer in editor UI
- Layer bit accessors are renamed to layer value and 1-based too
- Uniform errors and documentation in render and physics
- Fix a few remaining collision_layer used in place of collision_mask
This PR and commit adds the functionality to arrange nodes in VisualScript/VisualShader editor. The layout generated by this
feature is compact, with minimum crossings between connections
& uniform horizontal & vertical gaps between the nodes.
This work has been sponsored by GSoC '21.
Full list of additions/changes:
• Added arrange_nodes() method in GraphEdit module.
• This method computes new positions for all the selected
nodes by forming blocks and compressing them.
The nodes are moved to these new positions.
• Adding this method to GraphEdit makes it available for
use in VisualScript/VisualShaders editors and its other
subclasses.
• Button with an icon has been added to call arrange_nodes() in GraphEdit.
• This button is inherited by VisualScript/VisualShaders editors
to invoke the method.
• Undo/redo is functional with this method.
• By using signals in arrange_nodes(), position changes are registered
in undo/redo stack of the subclass that is using the method.
• Metadata of the method has been updated in ClassDB
• Method description has been added to class reference of GraphEdit
Same thing that was already done in 2D, applies moving platform motion
by using a call to move_and_collide that excludes the platform itself,
instead of making it part of the body motion.
Helps with handling walls and slopes correctly when the character walks
on the moving platform.
Also made some minor adjustments to the 2D version and documentation.
Co-authored-by: fabriceci <fabricecipolla@gmail.com>
When synchronizing CharacterBody motion with moving the platform using
direct body state, only the linear velocity was taken into account.
This change exposes velocity at local point in direct body state and
uses it in move_and_slide to get the proper velocity that includes
rotations.
