-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardize Object ptrcall encoding on Object **
#77410
Standardize Object ptrcall encoding on Object **
#77410
Conversation
e08af61
to
2cc0490
Compare
I've done some more testing with this, and GDScript still appears to be working fine. (I did realize that I forgot to update I built the C# version of Godot and can confirm that these changes totally break C# - it crashes immediately. :-) I spent a little time looking at the C# code, and I think it's using @godotengine/dotnet: Is it possible to change C# so that it makes ptrcalls with objects encoded as |
2cc0490
to
30713ac
Compare
Actually, I seem to have gotten C# working, at least in my super simplistic testing :-) I'm going to take this out of draft, since it does at least appear to be working, and to try and get some more feedback! |
Object **
Object **
Cool to see some consistency improvements in this regard! 🙂 Maybe worth noting that a similar problem is present for variant-to-object conversions, as mentioned by @saki7 in the godot-cpp thread: #61967 Also, general question regarding these fixes: would it be possible to incorporate them during the 4.0 -> 4.1 GDExtension API change? That would allow an extension to use the old ("inconsistent") convention when compiled against a Godot 4.0.x version. |
30713ac
to
d8dbe0f
Compare
d8dbe0f
to
77733fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the best approach IMO, as I've mentioned in other discussions.
I tested this with GDScript ptrcall and it works fine. I can't say about the C# side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach is the best choice in light of the discussion in godotengine/godot-cpp#1119. I think this would remove the "inconsistency" on encodings, thus we can hopefully avoid regressions like those we had been repeatedly experiencing in past few months.
I haven't tested extensively, but this approach works on my game's codebase which is utilizing a limited subset of GDExtension. (My application is based on 100% godot-cpp, no GDScript is involved.)
That said, even if this commit would fail on unexpected corner cases, I believe we should stick on this Object**
protocol.
@akien-mga Could you endorse this PR for merging into 4.1? If there are any objections, we need to process the discussion as soon as possible as this PR will define a stable ABI which affects all GDExtension bindings. |
Yes, we discussed this in #gdextension and agreed to merge this for 4.1, but after the imminent 4.1 beta 1 release, so we have enough time to do downstream changes and potential bugfixes before beta 2. |
Thanks everyone! Great work :) |
This is an attempt to implement "possible solution nr 2" from godotengine/godot-cpp#1119
That issue is about problems in godot-cpp due to Godot using a different encoding of Object in two different situations:
Object *
Object **
This PR attempts to standardize on
Object **
per @vnen's suggestion:It appears to work in very limited testing? And, when paired with PR godotengine/godot-cpp#1123, it seems to fix the godot-cpp issues (both the original issues and the regressions).
However, I suspect this breaks some things I'm not aware of and/or didn't try -
in particular, this probably has an impact on C#, which I didn't test at all.My limited testing of GDScript seems to work, but it's possible I'm just not testing in a way that would trigger issues.UPDATE: I have now tested C# a little, and it seems to work in limited testing with the small change to C# bindings generator.
In any case, please let me know what you think :-)
Fixes #61967