godot-lang-support
godot-lang-support copied to clipboard
Vivraan
Godot 4
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:
https://docusaurus.io/
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://developer.redis.com/
https://github.com/redis-developer/redis-developer.github.io
Here are a lot of other themes listed:
https://docusaurus.io/showcase?tags=opensource
Sounds like it might be the right way to handle this moving forward.
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 :)
Guess we could always just mirror the content!
FSharp https://blog.bencope.land/godot-4-and-f/
Rust https://github.com/godot-rust/godot-rust/issues/824
When would be a good time to convene on a discussion for creating a static website?
I have setup an instance of Docusaurus, to which I can give you access, if you want to play.
The URL would change, obviously:
https://fsharp.online
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. https://github.com/Vivraan/godot-lang-support/pull/49/commits/f99e419c129b61fe9ee46a0beace9cbfe79cb889
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
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.