Closed wp2000x closed 1 year ago
I think this will be extremely useful, so I would very much look forward to Godot 4 support :D
With some patches and hacks, I was finally able to see at least such a graph upd:
@DmitriySalnikov I wanted to try out the CI build but get this error, any ideas why?(https://github.com/DmitriySalnikov/godot_debug_draw_3d/actions/runs/3688845973)
@wp2000x As I mentioned in the comment to this commit 7133097220b78d931d405a5db56ca4e071e6c7bf, you need a newer version of Godot. Beta 8 doesn't include this change yet. Use for example this version: https://github.com/godotengine/godot/actions/runs/3714553342 But don't expect this addon to work correctly. It's currently has problems with centering boxes, clearing memory when closing, clearing geometry when switching scenes, and many other problems.
I will try to fix them as soon as I solve the problem with a completely broken and reinstalled Windows...
Everything looks fine now. But there are still a lot of problems left:
Callable
does not have a bind
method (https://github.com/godotengine/godot-cpp/issues/802). (fixed in 1e5ba73d598aee5a3b06f4a4852cf9c0fd4daaef by using bindv
)And most likely I missed something else.
Plus, for a successful build, you need to apply 2 patches (the corresponding Pull Requests have already been created for them https://github.com/godotengine/godot-cpp/pull/950 https://github.com/godotengine/godot-cpp/pull/956).
Examples and libraries updated in the master branch (requires beta9).
I think the C# interface needs also a bit of work, because it does not run anymore out of the box on Godot 4? (DebugDrawCS.cs)
Edit: In the meantime, i tried to do a hacky fix up for DebugDrawCS.cs and creating a instance of the GD Extenstion via ClassDB with ClassDB.Instantiate("DebugDraw");
but it is not working, is this a Godot bug?
ClassExists
and CanInstantiate
are both returning true.
Or is there a different way to access the lib in C#?
I haven't started working on the C# wrapper yet. I just decided not to delete this .cs
file, even though it was generated by a script that no longer exists.
I'll see what I can do about it later. I need to check how C# code generators work and whether they can generate code from GDExtension
. If not, then I will now be able to generate the .cs
API file from ClassDB
without any problems 🙂 (except that I do not know how to add documentation there).
One more issue:
I haven't started working on the C# wrapper yet. I just decided not to delete this
.cs
file, even though it was generated by a script that no longer exists.I'll see what I can do about it later. I need to check how C# code generators work and whether they can generate code from
GDExtension
. If not, then I will now be able to generate the.cs
API file fromClassDB
without any problems 🙂 (except that I do not know how to add documentation there).
Great! Im waiting eagerly, so that i can re-intergrate it into my GD4 C# project. Any ETA? 😄 I didn't saw any C# code generation in Godot for custom engine extenstions, so ClassDB came into my mind how to connect it. But that is also not really working.
I didn't saw any C# code generation in Godot for custom engine extenstions
I found that it is possible to do so https://www.reddit.com/r/godot/comments/zlglpk/comment/j081fkm/?utm_source=share&utm_medium=web2x&context=3 But it doesn't work correctly.. Maybe I can find out from there how to make a good binding generator.
At the moment I want to add a small optimization of instances data transfer to Godot. After that, I will either try to fix memory leaks when closing the engine, or add a C# wrapper.
And it would also be interesting how difficult and whether it is even possible to add support for other C++ libraries (use debug_draw_3d
from another GDExtension
library).
Ah, good to know, that the mono glue generator also tries to generate it for extenstions. I also found this: https://github.com/antonWetzel/GDExtensionCSharp maybe it will help you as a base for a binding generator.
If I understand correctly, this is not what I need. Here the developer makes an alternative to godot-cpp
but in C#. But I may still study this repository if I encounter some problems. Thanks.
--generate-mono-glue
can't even generate mono glue for me
C:\My\Godot\godot_v4.0\beta15\Godot_v4.0-beta15_mono_win64.exe --project "C:\My\Projects\GE\DebugDraw3D 4.0\project.godot" --generate-mono-glue .
$ Godot Engine v4.0.beta15.mono.official.4fa6edc88 - https://godotengine.org
Vulkan API 1.3.224 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 970
Ignoring type 'AnimationNodeEndState' because it's not exposed
Ignoring type 'AnimationNodeStartState' because it's not exposed
Ignoring type 'CreateDialog' because it's not exposed
ERROR: FATAL: Condition "r_iarg.type.cname != name_cache.type_String" is true.
at: _arg_default_value_from_variant (modules/mono/editor/bindings_generator.cpp:3272)
Now I need to understand where I use NodePath
at all... and why is the name of this class not equal to String
Aah, this all applies to String
, StringName
and NodePath
.
I got something 🤷♂️
I got a dll with bindings for debug_draw_3d
. It remains to connect them correctly to the project.
🎉🎉🎉 (in this project, only one script has code, all other files are commented out)
"path to the godot's exe" --headless --project "path to the project with .gdextension\project.godot" --generate-mono-glue "path to cloned repository\modules\mono\glue"
dotnet nuget add source "absolute path to the local nuget source" --name MyLocalGodotSource
cd "path to cloned repository"
then "modules/mono/build_scripts/build_assemblies.py" --godot-output-dir=./bin --godot-platform=windows --push-nupkgs-local "absolute path to the local nuget source"
.godot/mono
inside the project%appdata%\Godot\mono\GodotNuGetFallbackFolder
I hope I didn't miss anything. But I don't like this solution. Maybe if you have a lot of .gdextension
s and if you have worked with the godot builds, then this will be the easiest and most convenient way to add the C# API, but do it only for the sake of one extension.....
Nice! Will test it out. Would it maybe make sense to ship a pre-generated nuget for every DebugDraw version release on nuget.org for this approach?
Edit: Ah i see now the problem, its one big glue package.
I build the Nugets successfuly, and verified that debugdraw is in there, but the project refuses to use those nugets. The local nuget source is there but the DebugDraw interface classes are not recognized. Deleting .godot/mono
and %appdata%\Godot\mono\GodotNuGetFallbackFolder
does not help.
Would it maybe be possible to separate the DebugDraw assembly part from the glue and make it as a standalone dll/nuget?
The local nuget source is there but the DebugDraw interface classes are not recognized. Deleting .godot/mono and %appdata%\Godot\mono\GodotNuGetFallbackFolder does not help.
I also faced this and struggled with it for a while. Clearing all caches and recreating the C# project helped me (maybe I did something else).
I have already asked a question in godot's RocketChat about generating an API for GDExtension, but there has been no answer yet. Most likely I will have to write a proposal. My plan for now is to make my own C# API generator (or copy it from Godot) until the official one appears.
But unfortunately I can't develop the project yet. My PC's PSU failed and I'm without a PC until at least February 3rd.
But if you manage to use local nuget packages, then you can safely use them, because I will try to make the generator as close as possible to the Godot generator. And most likely it will be just a .cs file inside your project again.
I tried further, but still the same. Guess i will wait for your API generator. Good idea with the proposal, something like this would be very nice when implemented out of the box. Good luck with your PSU 😄
I found one annoying problem. The entire C# API consists of unsafe code.
This means that users of this extension will need to enable this checkbox if I generate a .cs
file with API inside project.
Otherwise, you will need to add a precompiled library... Which also forces you to edit the project settings.
I tried several options with changing the original generator to support GDExtension
API generation, but nothing worked. Even if you get direct access to all the internal
methods and classes of GodotSharp.dll
(InternalsVisibleToAttribute), there will still be problems with the Godot's SourceGenerator.
I will have to make my own generator from scratch and without maximum performance of GodotSharp.dll
, or I'll just postpone C# support for now.
I want to release a GDScript-only version first. And if no one has created a proposal yet, then I need to write it as well.
I think the porting is complete. I have collected the remaining issues into a separate topic. #9
@DmitriySalnikov
This could be a possible way to deal with GDExtensiong binding for c# based on ideas from LibGodotSharp
@GeorgeS2019 I noticed only a copy paste of my solution there, the rest will not help me in any way. But if I understood everything correctly, then you have confused GlobalClass
with bindings for GDExtension
.
As @j20001970 said:
it is about allowing C# classes to be registered as global classes (similar to Autoload in GDScript), not using GDExtension classes in C#
I would say that GlobalClass
is an analog of class_name
from GDScript
.
And I agree with him that at the moment it is better to wait until the official support for GDExtension
in C#
appears. Or you can help Godot with the implementation of this feature.
Do you mean compiling the entire C# interop code only with my bindings (GodotSharp.dll
and all tools libs)? Or only GodotSharp.dll
with only my classes?
In the first case, it seemed to me that Godot.exe
can only load specific predefined DLLs. And I am not sure that I will be able to load and use a full-fledged separate C# interop.
And in the second case with generation only GodotSharp.dll
, I have already tried and faced a bunch of problems and errors. I tried to duplicate the C# interop generator from the Godot module, cutting out all unnecessary and replacing some names with my own so that there would be no conflicts.
Do you already have a ready-made prototype with the implementation of your ideas? I would be interested to see it.
@DmitriySalnikov I believe this is the current status for GDExtension for c# https://github.com/godotengine/godot/pull/77410#issuecomment-1561883694
Isn't this a "standard" fix for casting Objects from an internal Godot type to an external GDExtension or C#? (they just tried to fix it several times already)
Also here is the binding generator
which was mentioned in the comments there.
@DmitriySalnikov
https://github.com/antonWetzel/GDExtensionCSharp/issues/1#issuecomment-1576276659
namespace GDMP {
class SomeCoolObject {
private GD.Object data;
public SomeCoolObject() { this.data = GD.Instantiate("GDMPSomeCoolObject"); }
public SomeType SomeFunction() {
return (SomeType)this.data.call("some_function");
}
}
}
GDExtensionCSharp
is also not a GDExtension
binding generator for C#
.. This is an implementation of C#
support via GDExtension
.
If you are interested, then this is how it was implemented for a long time in my GDNative
version for Godot 3: https://github.com/DmitriySalnikov/godot_debug_draw_3d/blob/godot_3/addons/debug_draw_3d/DebugDrawCS.cs.
This can also be implemented now, but this is a very bad way of calling methods, because every time there is a comparison of strings with method names, type conversions to variant and back. Whereas official bindings use lower-level method calls.
Now I am not sure that it is even possible to make such bindings now.
too much off topic
After a lot of confusion, I was able to build a library for godot 4.
But I haven't even tried to display anything yet. At the moment I can't even register any function with pointers.
Some of these functions can be ignored, but the problem still remains.
Callable::bind()
is still unavailable, but it can also be avoided.I also need to rethink how to initialize the displaying of everything. Previously, a node was simply created, now I want to use a singleton that is not added to the scene...
upd. At the moment I can't even set the value of a boolean variable.. Perhaps I'll wait until GDExtension works more stably.