Godot 4
ShalokShalom opened this issue · 48 comments
Since Godot 4 offers a completely revamped API for language bindings, all already developed bindings are completely useless.
I introduce a tag "Godot 4" and announce this thread as a visible reminder and eventually as a coordination platform to integrate the new bindings.
So, do we create a new section at the top of the current README for the new bindings, once they come in?
Or a completely new repository?
Also guides, blog articles and similar stuff to help with the development might help.
Thanks for contributing.
I'd recommend against creating an entirely separate repo as well as creating a dedicated branch or git tag for representing the difference. When people come to the default/home Markdown page for this repo, I feel like they should expect to see a proper summarization of all known bindings, and then the condition of the bindings are just added as details with the icons and whatnot. We don't want pieces of information hidden away on some specific drop-down menu in a corner of the page.
And it isn't like the implementations of the bindings should significantly change all that much either (in most cases anyway). You just integrate the language in a slightly different manner based on the interface exposed by GDExtensions.
If anything, I would use some special icon to annotate which language bindings support which Godot versions, and then ensure that links are provided for each version-specific implementation.
The implementors of the Nim, Haskell and Kotlin extensions mean its a significant change and they either attempt to rewrite it all from scratch, or dont do it at all.
I like the idea with an icon in theory, it just destroys the order completely.
How to rank a binding, that has a very good support for Godot 3 and a very limited one for 4?
How to differanciate between the versions and their respective quality?
The implementors of the Nim, Haskell and Kotlin extensions mean its a significant change and they either attempt to rewrite it all from scratch, or dont do it at all.
Wow. Honestly wouldn't have expected that it was that complicated. But then again, I haven't done a serious comparison of the old and new C APIs.
How to rank a binding, that has a very good support for Godot 3 and a very limited one for 4? How to differanciate between the versions and their respective quality?
We'd probably have to take a more decoupled and segregated approach. Use HTML to put a summarization table at the top of the page with each of the rankings and criteria items (editor support, maintainer, methods) as individual columns, each language as a row (with a hyperlink to a more in-depth description of its language/Godot version implementation specifics and condition), and then within each cell, have a divisor or discriminator of some sort to distinguish between values for different versions of Godot.
Then, you can index the various categories to improve discoverability by having dedicated lists of hyperlinks specific to each language implementation (for a Godot version) that match a certain column value. So, e.g. the summarization table would have everything in one place, but then further below it you could have a dedicated shorthand list of all of the "full support" languages, the "module" languages, the "editor support" languages, etc. And then all of these various tables' hyperlinks would just go to in-depth breakdowns further down the page where you go language by language, and then within them implementation by implementation with all of the rankings/categories/etc. re-iterated beside the language, as we do now.
This way, you more or less keep what we have already, but version-specific implementations beside one another for locality. Hmmmmm...the more I'm thinking through this, the more you'd probably want it to be more like something built with a static-site generator rather than a simple Markdown file. XD Otherwise, you'd make an update to the data for the languages and have to modify over a dozen different locations. Would be simpler to just write up some Javascript logic for generating all the various tables and hyperlinks, and then be able to store all the language info in a single place, run a script, and have it re-build the whole "site" instantly.
We can collect static website themes, to decide between them.
As an example, docusaurus has a lot, is build by Facebook and quite neat, IMHO:
There is one instance build by Redis.
I like how they list all the different languages with their respective symbol, we can do that too.
We could simply adopt that, what do you think?
https://github.com/redis-developer/redis-developer.github.io
Here are a lot of other themes listed:
Sounds like it might be the right way to handle this moving forward.
Thanks
Ah, a full refactor of the site might be really cool as well! Segregating language support into several documents may make things more streamlined if we know a lot about specific binding projects.
That said it might just be extra work since we'll essentially maintain a duplicate to the authors' own doc page, barring just adding specific news or updates about bindings, which we can author ourselves, as a community. It does stand to reason though that we should at the very least provide a pseudo-CHANGELOG per binding project, per major version of Godot starting from 3 (at the time of writing, 3 and 4).
We have been playing around with the idea of a static website for quite some time, and it does seem to be a cool way to go forward in terms of its sheer expressivity (through improved UX) and power to organise our data. We may not need those weird emoji to be put in manually, instead creating an internal tag system that can be labelled with the necessary emoji -- essentially, we can convert the doc's implicit organising conventions into code. It will also revive this project as I see low traffic here these days. 😢
We can surely simply source the readme of the individual projects :)
We can surely simply source the readme of the individual projects :)
Guess we could always just mirror the content!
@ShalokShalom Please contact the devs to provide a suitable entry!
It seems currently on hold
But yeah, I will
When would be a good time to convene on a discussion for creating a static website?
I guess once production ready language bindings are ready.
I have setup an instance of Docusaurus, to which I can give you access, if you want to play.
The URL would change, obviously:
So.. we're moving from here to Docusaurus?
D https://github.com/godot-dlang/godot-dlang
gd4 support is there but there's still some bugs
I would leave this instance here for Godot 3 and start a new one for Godot 4.
Potentially with Docusaurus.
Thanks for the D link.
Then I guess this repo needs some clarification that it's for gd3
Renaming it would break existing links, so perhaps a change in readme then
Yes. f99e419
Let me find some time in the weekend to approach this!
I am reposting this here from the Discord server:
"Little teaser of a gdextension I got in the works: https://github.com/dazKind/hxgodot-cpp
It leverages Godot4's gdextension system and Haxe's cpp target code generation to allow for a full integration of Haxe into Godot. Nodes are written in Haxe instead of CPP and behave like any other Godot-Node(attach scripts etc). It uses Haxe's macro generation to create a full set of bindings so one can interact with all classes/built-ins exposed in Godot.
In the future I want to add Haxe CPPIA based scripting(https://code.haxe.org/category/other/working-with-cppia/index.html), to allow script instances using the extension to be built & hot-reloaded in the running editor.
Rating the relative runtime performance (depending on what you are doing), it should look like this:
CPP < Haxe(cpp) < C# < GDScript
My current plan is to transform it into a simple haxelib release + sample game and then release the first alpha in Q1 23."
From the author of the lib
Which languages support GDExtension now?
I contacted the devs of the Python and Swift extension, to see which API they are using.
I am sure the Python extension used to be build on the previous Script API, so it is probably currently rewritten.
The languages I checked, and that claim to use the GDExtension API:
Cpp, Lua (Sandbox), Go, Rust.
And then languages that do not use the GDExtension API, but do support Godot 4 otherwise:
Haxe, Lua, Swift, C#, (eventually F#, I dont follow the development in the F# Discord anymore), D and Nim is on its way.
For Swift, also see this repo, from the same author:
https://github.com/migueldeicaza/SwiftGodotKit
D maintainer here, it's basically ready to use, aside from some minor hurdles and it can do anything that C++ can
D maintainer here, it's basically ready to use, aside from some minor hurdles and it can do anything that C++ can
Superb, thanks.
Do you feel motivated, to a) Create a Godot 4 section (above the current one) and
b) put at least D, and ideally all the other languages in, with c) the appropriate emoijs?
Thanks
@willnationsdev Do you have any information on the progress of the F# implementation?
I do not visit Discord anymore, and the development had happened at the F# Discord Server.
(They have their own topic about it, in one of the threaded discussions)
I would like to add it to the list, so its interesting to know, how far they are.
You can point them to this repo, maybe they wanna fill it out themselves.
Thanks a lot
I've got zero info on F# related anything, let alone Godot chatter since I've been neck deep in web/dotnet (C#) stuff for the last year basically. Sorry!
D maintainer here, it's basically ready to use, aside from some minor hurdles and it can do anything that C++ can
Superb, thanks.
Do you feel motivated, to a) Create a Godot 4 section (above the current one) and
b) put at least D, and ideally all the other languages in, with c) the appropriate emoijs?Thanks
Where and how what who..?
D maintainer here, it's basically ready to use, aside from some minor hurdles and it can do anything that C++ can
Superb, thanks.
Do you feel motivated, to a) Create a Godot 4 section (above the current one) and
b) put at least D, and ideally all the other languages in, with c) the appropriate emoijs?
ThanksWhere and how what who..?
Our README, on this repo.
Update on Swift: migueldeicaza/SwiftGodot#285 (comment)
The languages I checked, and that claim to use the GDExtension API: Cpp, Lua (Sandbox), Go, Rust.
And then languages that do not use the GDExtension API, but do support Godot 4 otherwise: Haxe, Lua, Swift, C#, (eventually F#, I dont follow the development in the F# Discord anymore), D and Nim is on its way.
Little correction when it comes to Haxe:
- https://hxgodot.github.io supports Haxe via the Godot 4's GDExtension API.
- https://github.com/HaxeGodot uses the Haxe C#-target for Godot 3.4.5
The languages I checked, and that claim to use the GDExtension API: Cpp, Lua (Sandbox), Go, Rust.
And then languages that do not use the GDExtension API, but do support Godot 4 otherwise: Haxe, Lua, Swift, C#, (eventually F#, I dont follow the development in the F# Discord anymore), D and Nim is on its way.Little correction when it comes to Haxe:
- https://hxgodot.github.io supports Haxe via the Godot 4's GDExtension API.
- https://github.com/HaxeGodot uses the Haxe C#-target for Godot 3.4.5
I only remember HxGodot compiling to C++, good to know that works over GDExtension.
I am a bit confused, since C++ over GDExtension was not ready, when I read about HxGodot.
Did you implement hxcpp in GDExtension?
The languages I checked, and that claim to use the GDExtension API
D bindings (godot-dlang) do use gdextension tho, gotta read readme better (which noone does)
Did you implement hxcpp in GDExtension?
Yeah. HxGodot generates the necessary glue between hxcpp and gdextension/godot. Important: I'm not using godot-cpp, instead I use the C extension-interface directly.
The languages I checked, and that claim to use the GDExtension API
D bindings (godot-dlang) do use gdextension tho, gotta read readme better (which noone does)
True. I reminded the D extension to exist for Godot 3, so I assumed it would be a module.
I did not expect someone actually porting the whole thing from GDNative and should have looked.
New zig project for Godot 4
https://github.com/godot-zig/godot-zig
https://www.juliawiki.com/wiki/Godot_Engine
Julia for statistics
The first link is full with disinformation.
Godot is not written in Julia ^^
Thanks for the link, Julia is my most favorite language 👍🏻
I wonder what prevent GDExtension written for R?
I wonder what prevent GDExtension written for R?
Unsure, likely because nobody has envisioned bindings for statistical programming?