2018-09-04 05:40:41 +02:00
|
|
|
using System;
|
2021-09-12 20:21:15 +02:00
|
|
|
using System.Linq;
|
|
|
|
using System.Reflection;
|
2018-09-04 05:40:41 +02:00
|
|
|
using System.Runtime.CompilerServices;
|
2021-09-12 19:50:13 +02:00
|
|
|
using Godot.NativeInterop;
|
2018-09-04 05:40:41 +02:00
|
|
|
|
|
|
|
namespace Godot
|
|
|
|
{
|
|
|
|
public partial class Object : IDisposable
|
|
|
|
{
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
private bool _disposed = false;
|
2021-09-12 20:21:15 +02:00
|
|
|
private Type _cachedType = typeof(Object);
|
2018-09-04 05:40:41 +02:00
|
|
|
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
internal IntPtr NativePtr;
|
|
|
|
internal bool MemoryOwn;
|
2018-09-04 05:40:41 +02:00
|
|
|
|
|
|
|
public Object() : this(false)
|
|
|
|
{
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
if (NativePtr == IntPtr.Zero)
|
|
|
|
{
|
|
|
|
unsafe
|
|
|
|
{
|
2021-09-12 20:21:15 +02:00
|
|
|
NativePtr = NativeCtor();
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
}
|
2021-09-12 20:23:05 +02:00
|
|
|
|
2021-09-12 20:21:15 +02:00
|
|
|
InteropUtils.TieManagedToUnmanaged(this, NativePtr,
|
|
|
|
NativeName, refCounted: false, GetType(), _cachedType);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
InteropUtils.TieManagedToUnmanagedWithPreSetup(this, NativePtr);
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
}
|
|
|
|
|
2020-10-26 06:59:08 +01:00
|
|
|
_InitializeGodotScriptInstanceInternals();
|
|
|
|
}
|
|
|
|
|
|
|
|
internal void _InitializeGodotScriptInstanceInternals()
|
|
|
|
{
|
2021-09-12 20:21:15 +02:00
|
|
|
// Performance is not critical here as this will be replaced with source generators.
|
|
|
|
Type top = GetType();
|
|
|
|
Type native = InternalGetClassNativeBase(top);
|
|
|
|
|
|
|
|
while (top != null && top != native)
|
|
|
|
{
|
|
|
|
foreach (var eventSignal in top.GetEvents(
|
|
|
|
BindingFlags.DeclaredOnly | BindingFlags.Instance |
|
|
|
|
BindingFlags.NonPublic | BindingFlags.Public)
|
|
|
|
.Where(ev => ev.GetCustomAttributes().OfType<SignalAttribute>().Any()))
|
|
|
|
{
|
|
|
|
unsafe
|
|
|
|
{
|
|
|
|
using var eventSignalName = new StringName(eventSignal.Name);
|
|
|
|
godot_string_name eventSignalNameAux = eventSignalName.NativeValue;
|
2021-09-12 20:23:05 +02:00
|
|
|
NativeFuncs.godotsharp_internal_object_connect_event_signal(NativePtr, &eventSignalNameAux);
|
2021-09-12 20:21:15 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
top = top.BaseType;
|
|
|
|
}
|
2018-09-04 05:40:41 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
internal Object(bool memoryOwn)
|
|
|
|
{
|
2021-09-12 20:21:15 +02:00
|
|
|
MemoryOwn = memoryOwn;
|
2018-09-04 05:40:41 +02:00
|
|
|
}
|
|
|
|
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
public IntPtr NativeInstance => NativePtr;
|
2018-09-04 05:40:41 +02:00
|
|
|
|
|
|
|
internal static IntPtr GetPtr(Object instance)
|
|
|
|
{
|
2019-02-19 00:37:10 +01:00
|
|
|
if (instance == null)
|
|
|
|
return IntPtr.Zero;
|
|
|
|
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
if (instance._disposed)
|
2019-02-19 00:37:10 +01:00
|
|
|
throw new ObjectDisposedException(instance.GetType().FullName);
|
|
|
|
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
return instance.NativePtr;
|
2018-09-04 05:40:41 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
~Object()
|
|
|
|
{
|
|
|
|
Dispose(false);
|
|
|
|
}
|
|
|
|
|
|
|
|
public void Dispose()
|
|
|
|
{
|
|
|
|
Dispose(true);
|
|
|
|
GC.SuppressFinalize(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected virtual void Dispose(bool disposing)
|
|
|
|
{
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
if (_disposed)
|
2018-09-04 05:40:41 +02:00
|
|
|
return;
|
|
|
|
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
if (NativePtr != IntPtr.Zero)
|
2018-09-04 05:40:41 +02:00
|
|
|
{
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
if (MemoryOwn)
|
2018-09-04 05:40:41 +02:00
|
|
|
{
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
MemoryOwn = false;
|
2021-09-12 20:23:05 +02:00
|
|
|
NativeFuncs.godotsharp_internal_refcounted_disposed(NativePtr, (!disposing).ToGodotBool());
|
2018-09-12 02:41:54 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-09-12 20:23:05 +02:00
|
|
|
NativeFuncs.godotsharp_internal_object_disposed(NativePtr);
|
2018-09-04 05:40:41 +02:00
|
|
|
}
|
|
|
|
|
2021-09-12 20:23:05 +02:00
|
|
|
NativePtr = IntPtr.Zero;
|
2018-09-04 05:40:41 +02:00
|
|
|
}
|
|
|
|
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
_disposed = true;
|
2018-09-04 05:40:41 +02:00
|
|
|
}
|
|
|
|
|
2021-09-12 19:50:13 +02:00
|
|
|
public override unsafe string ToString()
|
2019-04-18 14:48:10 +02:00
|
|
|
{
|
2021-09-12 19:50:13 +02:00
|
|
|
using godot_string str = default;
|
|
|
|
NativeFuncs.godotsharp_object_to_string(GetPtr(this), &str);
|
2021-09-12 20:21:15 +02:00
|
|
|
return Marshaling.mono_string_from_godot(str);
|
2019-04-18 14:48:10 +02:00
|
|
|
}
|
|
|
|
|
2019-03-28 20:01:54 +01:00
|
|
|
/// <summary>
|
|
|
|
/// Returns a new <see cref="Godot.SignalAwaiter"/> awaiter configured to complete when the instance
|
|
|
|
/// <paramref name="source"/> emits the signal specified by the <paramref name="signal"/> parameter.
|
|
|
|
/// </summary>
|
|
|
|
/// <param name="source">
|
|
|
|
/// The instance the awaiter will be listening to.
|
|
|
|
/// </param>
|
|
|
|
/// <param name="signal">
|
|
|
|
/// The signal the awaiter will be waiting for.
|
|
|
|
/// </param>
|
|
|
|
/// <example>
|
|
|
|
/// This sample prints a message once every frame up to 100 times.
|
|
|
|
/// <code>
|
|
|
|
/// public override void _Ready()
|
|
|
|
/// {
|
2019-04-18 14:48:10 +02:00
|
|
|
/// for (int i = 0; i < 100; i++)
|
2019-03-28 20:01:54 +01:00
|
|
|
/// {
|
|
|
|
/// await ToSignal(GetTree(), "idle_frame");
|
|
|
|
/// GD.Print($"Frame {i}");
|
|
|
|
/// }
|
|
|
|
/// }
|
|
|
|
/// </code>
|
|
|
|
/// </example>
|
2020-03-14 19:20:17 +01:00
|
|
|
public SignalAwaiter ToSignal(Object source, StringName signal)
|
2018-09-04 05:40:41 +02:00
|
|
|
{
|
|
|
|
return new SignalAwaiter(source, signal, this);
|
|
|
|
}
|
|
|
|
|
2021-09-12 20:21:15 +02:00
|
|
|
internal static Type InternalGetClassNativeBase(Type t)
|
|
|
|
{
|
|
|
|
do
|
|
|
|
{
|
|
|
|
var assemblyName = t.Assembly.GetName();
|
|
|
|
|
|
|
|
if (assemblyName.Name == "GodotSharp")
|
|
|
|
return t;
|
|
|
|
|
|
|
|
if (assemblyName.Name == "GodotSharpEditor")
|
|
|
|
return t;
|
|
|
|
} while ((t = t.BaseType) != null);
|
|
|
|
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
internal static bool InternalIsClassNativeBase(Type t)
|
|
|
|
{
|
|
|
|
var assemblyName = t.Assembly.GetName();
|
|
|
|
return assemblyName.Name == "GodotSharp" || assemblyName.Name == "GodotSharpEditor";
|
|
|
|
}
|
|
|
|
|
|
|
|
internal unsafe bool InternalGodotScriptCallViaReflection(string method, godot_variant** args, int argCount,
|
|
|
|
out godot_variant ret)
|
|
|
|
{
|
|
|
|
// Performance is not critical here as this will be replaced with source generators.
|
|
|
|
Type top = GetType();
|
|
|
|
Type native = InternalGetClassNativeBase(top);
|
|
|
|
|
|
|
|
while (top != null && top != native)
|
|
|
|
{
|
|
|
|
var methodInfo = top.GetMethod(method,
|
|
|
|
BindingFlags.DeclaredOnly | BindingFlags.Instance |
|
|
|
|
BindingFlags.NonPublic | BindingFlags.Public);
|
|
|
|
|
|
|
|
if (methodInfo != null)
|
|
|
|
{
|
|
|
|
var parameters = methodInfo.GetParameters();
|
|
|
|
int paramCount = parameters.Length;
|
|
|
|
|
|
|
|
if (argCount == paramCount)
|
|
|
|
{
|
|
|
|
object[] invokeParams = new object[paramCount];
|
|
|
|
|
|
|
|
for (int i = 0; i < paramCount; i++)
|
|
|
|
{
|
|
|
|
invokeParams[i] = Marshaling.variant_to_mono_object_of_type(
|
|
|
|
args[i], parameters[i].ParameterType);
|
|
|
|
}
|
|
|
|
|
|
|
|
object retObj = methodInfo.Invoke(this, invokeParams);
|
|
|
|
|
|
|
|
ret = Marshaling.mono_object_to_variant(retObj);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
top = top.BaseType;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = default;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
internal unsafe bool InternalGodotScriptSetFieldOrPropViaReflection(string name, godot_variant* value)
|
|
|
|
{
|
|
|
|
// Performance is not critical here as this will be replaced with source generators.
|
|
|
|
Type top = GetType();
|
|
|
|
Type native = InternalGetClassNativeBase(top);
|
|
|
|
|
|
|
|
while (top != null && top != native)
|
|
|
|
{
|
|
|
|
var fieldInfo = top.GetField(name,
|
|
|
|
BindingFlags.DeclaredOnly | BindingFlags.Instance |
|
|
|
|
BindingFlags.NonPublic | BindingFlags.Public);
|
|
|
|
|
|
|
|
if (fieldInfo != null)
|
|
|
|
{
|
|
|
|
object valueManaged = Marshaling.variant_to_mono_object_of_type(value, fieldInfo.FieldType);
|
|
|
|
fieldInfo.SetValue(this, valueManaged);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
var propertyInfo = top.GetProperty(name,
|
|
|
|
BindingFlags.DeclaredOnly | BindingFlags.Instance |
|
|
|
|
BindingFlags.NonPublic | BindingFlags.Public);
|
|
|
|
|
|
|
|
if (propertyInfo != null)
|
|
|
|
{
|
|
|
|
object valueManaged = Marshaling.variant_to_mono_object_of_type(value, propertyInfo.PropertyType);
|
|
|
|
propertyInfo.SetValue(this, valueManaged);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
top = top.BaseType;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
internal bool InternalGodotScriptGetFieldOrPropViaReflection(string name, out godot_variant value)
|
|
|
|
{
|
|
|
|
// Performance is not critical here as this will be replaced with source generators.
|
|
|
|
Type top = GetType();
|
|
|
|
Type native = InternalGetClassNativeBase(top);
|
|
|
|
|
|
|
|
while (top != null && top != native)
|
|
|
|
{
|
|
|
|
var fieldInfo = top.GetField(name,
|
|
|
|
BindingFlags.DeclaredOnly | BindingFlags.Instance |
|
|
|
|
BindingFlags.NonPublic | BindingFlags.Public);
|
|
|
|
|
|
|
|
if (fieldInfo != null)
|
|
|
|
{
|
|
|
|
object valueManaged = fieldInfo.GetValue(this);
|
|
|
|
value = Marshaling.mono_object_to_variant(valueManaged);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
var propertyInfo = top.GetProperty(name,
|
|
|
|
BindingFlags.DeclaredOnly | BindingFlags.Instance |
|
|
|
|
BindingFlags.NonPublic | BindingFlags.Public);
|
|
|
|
|
|
|
|
if (propertyInfo != null)
|
|
|
|
{
|
|
|
|
object valueManaged = propertyInfo.GetValue(this);
|
|
|
|
value = Marshaling.mono_object_to_variant(valueManaged);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
top = top.BaseType;
|
|
|
|
}
|
|
|
|
|
|
|
|
value = default;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
internal unsafe void InternalRaiseEventSignal(godot_string_name* eventSignalName, godot_variant** args,
|
|
|
|
int argc)
|
|
|
|
{
|
|
|
|
// Performance is not critical here as this will be replaced with source generators.
|
|
|
|
|
|
|
|
using var stringName = StringName.CreateTakingOwnershipOfDisposableValue(
|
|
|
|
NativeFuncs.godotsharp_string_name_new_copy(eventSignalName));
|
|
|
|
string eventSignalNameStr = stringName.ToString();
|
|
|
|
|
|
|
|
Type top = GetType();
|
|
|
|
Type native = InternalGetClassNativeBase(top);
|
|
|
|
|
|
|
|
while (top != null && top != native)
|
|
|
|
{
|
|
|
|
var foundEventSignals = top.GetEvents(
|
|
|
|
BindingFlags.DeclaredOnly | BindingFlags.Instance |
|
|
|
|
BindingFlags.NonPublic | BindingFlags.Public)
|
|
|
|
.Where(ev => ev.GetCustomAttributes().OfType<SignalAttribute>().Any())
|
|
|
|
.Select(ev => ev.Name);
|
|
|
|
|
|
|
|
var fields = top.GetFields(
|
|
|
|
BindingFlags.DeclaredOnly | BindingFlags.Instance |
|
|
|
|
BindingFlags.NonPublic | BindingFlags.Public);
|
|
|
|
|
|
|
|
var eventSignalField = fields
|
|
|
|
.Where(f => typeof(Delegate).IsAssignableFrom(f.FieldType))
|
|
|
|
.Where(f => foundEventSignals.Contains(f.Name))
|
|
|
|
.FirstOrDefault(f => f.Name == eventSignalNameStr);
|
|
|
|
|
|
|
|
if (eventSignalField != null)
|
|
|
|
{
|
|
|
|
var @delegate = (Delegate)eventSignalField.GetValue(this);
|
|
|
|
|
|
|
|
if (@delegate == null)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
var delegateType = eventSignalField.FieldType;
|
|
|
|
|
|
|
|
var invokeMethod = delegateType.GetMethod("Invoke");
|
|
|
|
|
|
|
|
if (invokeMethod == null)
|
|
|
|
throw new MissingMethodException(delegateType.FullName, "Invoke");
|
|
|
|
|
|
|
|
var parameterInfos = invokeMethod.GetParameters();
|
|
|
|
var paramsLength = parameterInfos.Length;
|
|
|
|
|
|
|
|
if (argc != paramsLength)
|
|
|
|
{
|
|
|
|
throw new InvalidOperationException(
|
|
|
|
$"The event delegate expects {paramsLength} arguments, but received {argc}.");
|
|
|
|
}
|
|
|
|
|
|
|
|
var managedArgs = new object[argc];
|
|
|
|
|
|
|
|
for (uint i = 0; i < argc; i++)
|
|
|
|
{
|
|
|
|
managedArgs[i] = Marshaling.variant_to_mono_object_of_type(
|
|
|
|
args[i], parameterInfos[i].ParameterType);
|
|
|
|
}
|
|
|
|
|
|
|
|
invokeMethod.Invoke(@delegate, managedArgs);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
top = top.BaseType;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
internal static unsafe IntPtr ClassDB_get_method(StringName type, string method)
|
|
|
|
{
|
|
|
|
IntPtr methodBind;
|
|
|
|
fixed (char* methodChars = method)
|
|
|
|
{
|
2021-09-12 20:21:15 +02:00
|
|
|
methodBind = NativeFuncs.godotsharp_method_bind_get_method(ref type.NativeValue, methodChars);
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (methodBind == IntPtr.Zero)
|
|
|
|
throw new NativeMethodBindNotFoundException(type + "." + method);
|
|
|
|
|
|
|
|
return methodBind;
|
|
|
|
}
|
|
|
|
|
2021-09-12 20:21:15 +02:00
|
|
|
internal static unsafe delegate* unmanaged<IntPtr> ClassDB_get_constructor(StringName type)
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
{
|
|
|
|
// for some reason the '??' operator doesn't support 'delegate*'
|
2021-09-12 20:21:15 +02:00
|
|
|
var nativeConstructor = NativeFuncs.godotsharp_get_class_constructor(ref type.NativeValue);
|
C#: Move marshaling logic and generated glue to C#
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.
2021-05-03 15:21:06 +02:00
|
|
|
|
|
|
|
if (nativeConstructor == null)
|
|
|
|
throw new NativeConstructorNotFoundException(type);
|
|
|
|
|
|
|
|
return nativeConstructor;
|
|
|
|
}
|
2018-09-04 05:40:41 +02:00
|
|
|
}
|
|
|
|
}
|