godotengine
/
godot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
godot/modules/mono/signal_awaiter_utils.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

103 lines
4.6 KiB
C++
Raw Normal View History

Added mono module
2017-10-02 21:24:00 +00:00
/**************************************************************************/
/* signal_awaiter_utils.h */
/**************************************************************************/
/* This file is part of: */
/* GODOT ENGINE */
/* https://godotengine.org */
/**************************************************************************/
/* Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md). */
/* Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur. */
/* */
/* Permission is hereby granted, free of charge, to any person obtaining */
/* a copy of this software and associated documentation files (the */
/* "Software"), to deal in the Software without restriction, including */
/* without limitation the rights to use, copy, modify, merge, publish, */
/* distribute, sublicense, and/or sell copies of the Software, and to */
/* permit persons to whom the Software is furnished to do so, subject to */
/* the following conditions: */
/* */
/* The above copyright notice and this permission notice shall be */
/* included in all copies or substantial portions of the Software. */
/* */
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. */
/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
/**************************************************************************/
Add missing copyright headers and fix formatting Using `misc/scripts/fix_headers.py` on all Godot files. Some missing header guards were added, and the header inclusion order was fixed in the Bullet module.
2018-01-04 23:50:27 +00:00
Added mono module
2017-10-02 21:24:00 +00:00
#ifndef SIGNAL_AWAITER_UTILS_H
#define SIGNAL_AWAITER_UTILS_H
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
#include "csharp_script.h"
Added mono module
2017-10-02 21:24:00 +00:00
#include "mono_gc_handle.h"
Style: Harmonize header includes in modules This applies our existing style guide, and adds a new rule to that style guide for modular components such as platform ports and modules: Includes from the platform port or module ("local" includes) should be listed first in their own block using relative paths, before Godot's "core" includes which use "absolute" (project folder relative) paths, and finally thirdparty includes. Includes in `#ifdef`s come after their relevant section, i.e. the overall structure is: - Local includes * Conditional local includes - Core includes * Conditional core includes - Thirdparty includes * Conditional thirdparty includes
2023-06-13 14:56:21 +00:00
#include "core/object/ref_counted.h"
C#: Restructure code prior move to .NET Core 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.
2021-09-12 18:21:15 +00:00
Error gd_mono_connect_signal_awaiter(Object *p_source, const StringName &p_signal, Object *p_target, GCHandleIntPtr p_awaiter_handle_ptr);
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00: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 13:21:06 +00:00
class BaseSignalCallable : public CallableCustom {
public:
virtual StringName get_signal() const = 0;
};
class SignalAwaiterCallable : public BaseSignalCallable {
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
ObjectID target_id;
Mono/C#: Optimize the way we store GC handles for scripts Don't store GC handles for C# script instances and instance bindings as 'Ref<MonoGCHandle>'; store the raw data instead. Initially this was not possible as we needed to store a Variant, but this had not been the case for a looong time yet the stored type was never updated.
2019-12-11 16:08:40 +00:00
MonoGCHandleData awaiter_handle;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
StringName signal;
public:
static bool compare_equal(const CallableCustom *p_a, const CallableCustom *p_b);
static bool compare_less(const CallableCustom *p_a, const CallableCustom *p_b);
Added mono module
2017-10-02 21:24:00 +00:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
static constexpr CompareEqualFunc compare_equal_func_ptr = &SignalAwaiterCallable::compare_equal;
static constexpr CompareEqualFunc compare_less_func_ptr = &SignalAwaiterCallable::compare_less;
Added mono module
2017-10-02 21:24:00 +00:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
uint32_t hash() const override;
Added mono module
2017-10-02 21:24:00 +00:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
String get_as_text() const override;
Re-write SignalAwaiter implementation Old implementation had issues where you could only await on the same signal of the same source once.
2017-10-16 01:54:23 +00:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
CompareEqualFunc get_compare_equal_func() const override;
CompareLessFunc get_compare_less_func() const override;
Added mono module
2017-10-02 21:24:00 +00:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
ObjectID get_object() const override;
Re-write SignalAwaiter implementation Old implementation had issues where you could only await on the same signal of the same source once.
2017-10-16 01:54:23 +00: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 13:21:06 +00:00
StringName get_signal() const override;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
void call(const Variant **p_arguments, int p_argcount, Variant &r_return_value, Callable::CallError &r_call_error) const override;
C#: Restructure code prior move to .NET Core 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.
2021-09-12 18:21:15 +00:00
SignalAwaiterCallable(Object *p_target, MonoGCHandleData p_awaiter_handle, const StringName &p_signal);
Mono/C#: Optimize the way we store GC handles for scripts Don't store GC handles for C# script instances and instance bindings as 'Ref<MonoGCHandle>'; store the raw data instead. Initially this was not possible as we needed to store a Variant, but this had not been the case for a looong time yet the stored type was never updated.
2019-12-11 16:08:40 +00:00
~SignalAwaiterCallable();
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
};
Re-write SignalAwaiter implementation Old implementation had issues where you could only await on the same signal of the same source once.
2017-10-16 01:54:23 +00: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 13:21:06 +00:00
class EventSignalCallable : public BaseSignalCallable {
Zero initialize all pointer class and struct members This prevents the pitfall of UB when checking if they have been assigned something valid by comparing to nullptr.
2022-04-04 13:06:57 +00:00
Object *owner = nullptr;
C#: Restructure code prior move to .NET Core 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.
2021-09-12 18:21:15 +00:00
StringName event_signal_name;
Re-write SignalAwaiter implementation Old implementation had issues where you could only await on the same signal of the same source once.
2017-10-16 01:54:23 +00:00
Added mono module
2017-10-02 21:24:00 +00:00
public:
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
static bool compare_equal(const CallableCustom *p_a, const CallableCustom *p_b);
static bool compare_less(const CallableCustom *p_a, const CallableCustom *p_b);
static constexpr CompareEqualFunc compare_equal_func_ptr = &EventSignalCallable::compare_equal;
static constexpr CompareEqualFunc compare_less_func_ptr = &EventSignalCallable::compare_less;
uint32_t hash() const override;
String get_as_text() const override;
CompareEqualFunc get_compare_equal_func() const override;
CompareLessFunc get_compare_less_func() const override;
ObjectID get_object() const override;
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 13:21:06 +00:00
StringName get_signal() const override;
Added mono module
2017-10-02 21:24:00 +00:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 18:20:17 +00:00
void call(const Variant **p_arguments, int p_argcount, Variant &r_return_value, Callable::CallError &r_call_error) const override;
Re-write SignalAwaiter implementation Old implementation had issues where you could only await on the same signal of the same source once.
2017-10-16 01:54:23 +00:00
C#: Restructure code prior move to .NET Core 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.
2021-09-12 18:21:15 +00:00
EventSignalCallable(Object *p_owner, const StringName &p_event_signal_name);
Added mono module
2017-10-02 21:24:00 +00:00
};
#endif // SIGNAL_AWAITER_UTILS_H