Godot is only the best open source engine because Bevy is not ready for production, Lumberyard/O3DE is hard to set up and everything else is ancient or 2D only. one eyed man among the blind type shit
> Godot is only the best open source engine because Bevy is not ready for production
I would argue that even if Bevy was ready for production it would not really compete with Godot.
Godot's performance is plenty for the vast majority of small to medium games. Plus they're starting to work on features like texture streaming for bigger games. It also has an editor which is a big plus for most teams.
Bevy would be objectively better for expensive CPU simulation stuff but realistically what percentage of games need that? Maybe 1%?
For Bevy to catch up on the indie game scene it needs an editor plus a scripting language and/or something like Unreal Blueprints. If it only wants to target the hardcore Rust dev that does everything by code it will never go mainstream.
No. If you try Bevy, it feels different from ECS and ordinary OOP. So it's hard to get used to. But Godot, although GDScript has performance issues, if you use GDScript it's easy to port to mobile and web games, and the syntax itself is OOP, so it's easy to adapt to.
A lot of people complain about OOP, but it's a paradigm very well suited for rapid development.
Godot is the best open source engine because it is dead simple to use, comes bundled with its own IDE and documentation, the editor runs on any platform that Godot runs (including the web) and the performance benefits for something like Bevy only apply to a handful of games that really need it.
Godot gives GDScript simplicity for the vast majority of use cases which is that iteration boon, provides C# for games that need the additional guardrails. For performance critical game scripts you can just jump to C++, Rust, Swift, etc.
But most game scripts are not performance critical. Clair Obscur: Expedition 33 swept the game awards last year as an Unreal Engine game made using almost entirely visual scripting (blueprints).
It still bothers me that game engines come with their own bespoke languages like GDScript. Godot is a bit better than others for having C# support and forks in other languages but really no other language will ever be as integrated with the framework as GDScript, And GDScript is never going to be a general purpose programming language, and that necessarily creates lock-in.
I'm currently messing with some old projects written in Game Maker 5 and let me tell you it would be so much easier if I didn't have to do internet archaeology just to figure out how GML worked 20 years ago.
Because it is much easier to have a custom language, than try to subsetting an existing mainstream language, while having to deal with all the mess of people trying to use random stuff on the engine, that naturally isn't supported.
Example, see all the bad rep .NET and C# get from devs that only know them from Unity, full of legacy stuff and restrictions, instead of using the real product.
That seems like more of a feature than a bug to me. Using C# in Godot means you have all of the Nuget libraries at your disposal, whereas no one is writing libraries in GDScript, because no one is using it outside of Godot.
Meanwhile to extend Godot usefully you have to use C++ and a plugin API that's arguably no less complicated than adapting an existing language as the scripting language would have been.
But that is the thing, you don't have access to all the NuGet libraries, or even CLR/MSIL abilities, it is a hit and miss depending on what platforms are being targeted.
Sure if you only want to target desktop/laptop computers, you're safe.
I always do not understand why defold is never put into the fold [sic!] of those sentiments/discussions.
You can learn a clean & fun language (lua) and its JIT is maybe/probably running laps around something like GDScript, which in itself is proprietary and has no other uses for you than, ehh, Godot??
You can integrate C/C++ extensions natively, neatly exposing them through lua APIs.
Its mobile and web target footprint is unbeatably (?) small, desktop at least 10x smaller than Godot or Unity.
It is Open Source.
Maybe it's the "ancient" part, because more recent is always better ;)
Starting with absolutely nothing but a compiler is always going to be a worse experience (and less likely to result in anything released) than a GUI-driven and aided solution. If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance. As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space. As most people know, the vast majority of games are net-losses, so engines live and die by the ease of adoption by newcomers.
I don't understand what you mean by this -- Defold has a graphical editor?
> If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance.
What do you mean by libraries in this context? It has a robust plugin system with a reasonably active ecosystem, if that's the sort of thing you're talking about: https://defold.com/assets/
And it covers all the systems one would expect in a 2D game engine natively -- tilemaps, physics etc.
> As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space.
I definitely disagree with this -- it's certainly not abandoned, and though it does have a slightly steeper learning curve than Godot or other popular engines, that's also how it gets such impressive performance and slim builds; feature, not a bug.
Good news, they've been working on adding C# support for a year or two now. I think it's still experimental, but from what I understand they already had a robust extension system that supported C/C++/Java/etc., so fitting C# in wasn't much of a stretch.
(it is only extension support -- not scripting -- but the extension system is such that it can be used for any game logic AFAIK)
What motivated you to use c++ rather than C#?
Especially when you mention the usage of c++ being tedious, when I would argue using C# is equally straight forward as gdscript is.
C# is a "first class" language in Godot and doesn't need a GDExtension, but it's not compatible with web builds yet. There is a draft PR that includes C# support but it adds about +50 MB to a web export and is also missing a few features.
Console support is accomplished using "Middleware ports" for the Nintendo Switch, Xbox Series X/S, and PlayStation 5. https://godotengine.org/consoles/
I know the process, the question was how far .NET tooling support is there, because if they just rewrite everything into C++, there isn't much there to talk about.
A combination of two factors that are rather specific to myself. One being that even tho its quite some time ago i have a bit of c++ experience, while i never tried to code C#. So when i got the idea to try to run the heavy simulation in an "extension" it was just a language i was a bit familiar with. Maybe C# would have been the "smarter" choice, i just never digged into it yet.
The other reason is that in my well closer circle i got quite some people that code c++ on a daily basis and i don't know (at least i think so) anyone doin C# actively, so i thought if i would get stuck i have people i can easily ask about my c++ problems.
So it wasn't a "i think c++ is better than c#" decision rather a what do i know and what resources i have available easily.
Yeah there are some gamedev treasures in C#, owning to the fact that Microsoft created the Xbox Live Indie Games program back in the X360 era, which meant you could ship games to customers with generally little oversight and meddling - this was WAY before Steam did something similar, and even before the iPhone app store.
The catch was that you had to use C# and XNA (which was a wrapper for gaming related APIs like DirectX, XAudio and XInput, generally considered to be very good). This meant there were a lot of hardcore libs made for C# gamedev (BEPU physics is from that era, and there were things like very good UI frameworks).
Tons of games were made with XNA, and its open source ofshoots, MonoGame and FNA power some of the greatest indie hits (Stardew Valley, Celeste, Bastion and other Supergiant titles, Terraria come to mind).
Imo this is one of the main reasons Unity went with C# in the first place.
C# being closer to C++, and .NET having direct support for C++ helped quite a bit regarding adoption among game studios.
Unity started on Mac, and they only adopted .NET when doing the cross platform rewrite.
I also don't remember if there wasn't some Mono advocacy at the time, as they became customers in the process.
Ironically Mono/Xamarin is almost gone from official .NET, all these years after the acquisition, with every modern .NET release, another bit falls off.
We are already on the phase that CoreCLR might take the remaining bits.
Not sure how relevant this is for this simulation use case but IIRC C# has a bigger overhead when communicating with the core engine compared to GDScript or C++.
Godot comes with a lot of tools in addition to the runtime. Maybe they are using the IDE to do layouts for the menu dialogues, for example.
Also, I am not sure about how easy it is to build binaries using SFML for various platforms (such as WASM), but with Godot you just have to download the right template.
Again combination of multiple points but for some part this is correct.
One side is that i started developing it with godot, and the game has well alot of menu stuff going on (without wanting to go to much into detail but you are to a certain degree able to configure units outside of a match into "blueprint" like system). This whole editor / management etc stuff got quite big and works really well.
Means, when i hit the gdscript limits, i did not want to port all of the existing stuff that already works perfectly fine with godot.
And ye since the c++ only runs math simulations but i still use the godot renderer (which so far seems to work out perfectly fine) i was okay with that mixed solution (for now).
It's not like i didn't consider that step :D but as mentioned in another response the game contains some rather complex configurator etc systems that i already completely baked with the godot system, also a simple map editor that works fine - so im not to motivated to also rewrite them all. Apart from that its a hobby project (one of many) so well maybe i reach that point and go full c++ but for now i dont think i will.
If you know rust, the Godot rust bindings for GDExtension are also really good and let you use any Rust library in Godot (including tokio and async rust if you really want)
https://godot-rust.github.io/
Just don't forget the versioning script needed on at least Linux. It's either that or build with the same older distro Godot uses, so you have a matching libstdc++ version. You can link with a newer stdlibc++ but you will need a linker versioning script that hides your impl from the dynamic linker so you don't get random ghosts in your machine.
Hi! Yes, you are right, thanks for pointing this out. It's something to keep in mind when distributing an extension for Linux. I have just updated the post with a note about it.
So, what profiling support is available to find the critical parts of your GDscript or C# code. Before needlessly jumping into c++ hassle for performance reasons? Tfa addresses functional reasons, which is ok.
I don't follow it that much, but I think there are no plans to improve GDscript performance other than maybe the interpreter itself, nothing with JIT or AOT in mind.
Also .NET integration has the issue it doesn't work in all target platforms, that is why Capcom and Unity have their own compilers to native code. Even when Unity finally adopts modern .NET, Native AOT naturally doesn't cover game consoles.
It's not up to .NET AOT, it's up to Xbox and Sony.
.NET can generate the code, but your game won't pass certification if it runs machine code generated by something other than the officially provided C/C++ tool chain.
I know. That's why it's too bad! It would probably (almost) just work if only it used the console's toolchain, which requires signing NDAs to even look at.
Coming from Instruments (Apple) and Chrome Dev Tools, I found the Godot profiler to be hilariously hard to get useful results out of because of its simplistic presentation of information that you can't drill down into.
Is Godot (or something else,say, Bevy) the right tool for building a complex, data intensive GUI app (like a DAW)?
I tried dear imgui for this before but I felt it was very low level and had to build a lot of systems (not it's intended use as a GUI app framework, tbf)
Hi! I don't think the boundary itself is the issue, although I'm not an expert on that part of Godot. My understanding is that the copy in this example comes from converting data from flecs into the layout MultiMesh expects. A different layout might reduce that work, but I haven't explored if fully zero-copy is possible.
I am building something similar, with c++26 reflection. So any language can use c++ libs with only a few lines of boilerplate in a lifetime and memory safe way where possible. And where it’s not possible to infer the safe lifetime of an object i got a small .toml file which tells the lib how to safely use those functions.
> Engine modules are compiled into the engine itself. They have full access to the internals, but you need to build and ship your own copy of Godot, including the editor and export templates for every platform.
I’m not familiar with distributing godot games. If I build a game to distribute on steam (for example) would this be an option? Or is a GDExtension (runtime loaded .so) the standard way to go?
It depends on what your use case is. GDExtension is the standard way to go, unless its API is too limited and you have to access/modify engine internals not otherwise exposed.
That being said, this has no impact on distribution either way as far as I know.
GDExtension is the standard way. But building a custom version of Godot is common and won't be a problem for distributing the game on steam or any platform.
It's necessary to build your own godot version and export templates to produce an encrypted build not too easily hackable for example.
If the API is c++ based you have to statically link it to the engine since the chosen c++ runtime is statically linked to the engine binaries.
You cannot ship as a shared c++ runtime since it would conflict with a possible version installed on the user distro (version of the gcc libstdc++, version of the clang runtime, intel?, or none see below).
To avoid c++ ABI issues, distros may statically link their c++ runtimes (clang[c++ and compiler versions]/gcc[c++ and compiler and versions]/intel[c++ and compiler versions]/etc)... if they need any (and the new c++ to C transpiler may have some significant impact in the near future).
(BTW, is the c++ intel compiler still shipping??)
If the API is "C" based (aka core platform ABI), no issue, just statically load only the common glibc libs (ELF DT_NEED entries) and dynamically load (libdl/dlopen/dlsym/dlclose) everything else (private libs, or system interface shared libs), and you are good to ship. A word though: wayland code with its libxkbcommon are statically linked, do not reproduce the same mistakes than with x11).
This is required for broad distro support [and long term support].
Basically, game binaries should be "-static-libgcc -static-libstdc++ --enable-new-dtags" everywhere, statically load _ONLY_ common glibc libs (and with "old" symbol versions, see binutils ld documentation, the 2nd part of the VERSION documentation page), and dynamically load everything else.
I have been inspecting many recent godot4 games on steam: all had "correct" binaries to maximize broad distro loading support on the long run.
The current issues: some games are written in microsoft rust which toolchain is still unable to statically link libgcc (see tinyglade game). Or some unity versions which "forgot" the '-static-libgcc' compiling/linking options, and even forgot to statically link their libz Oo.
If valve could do just that with the binaries of their client and their games... They can keep their 'runtimes' for old broken games but should have 'correct' binaries for everything else on their side (and valve still has to port the final 32bits reaper command to 64bits for clean 64bits support, hopefully I did not miss other 32bits binaries). Forcing distros to compile that user namespace in their linux kernel is quite "inappropriate", better keep that optional for those broken games only.
If your API is c++ based, you ship a static lib. If the game engine is "closed" source, you also a have static lib (or a set of) for the game engine too, and "exporting" is actually linking (basically a binutils ld invokation). Ofc, you better use the same c++ compiler _VERSION_ than the game engine devs did use, or you are good for c++ hell.
If your API is C based (or core platform ABI), and you should design such API for interop with any framework anyway, you can ship a shared lib (but it has to statically load only the common glibc libs, and that with "old" symbol versions, and the other things too, see my previous post).
Was playing arround recently building an RTS with godot until i just hit the ceilling of what i could handle with gdscript performance wise.
Than started to move alot of heavy logic to c++ simulation : tedious indeed but the results speak for themself.
Basically allows me to use godot for things like menus dialogues and similar stuff while running the true heavy work in a c++ simulation.
gdscript is incredibly slow, worst than something like lua, maybe only good for handling the UI events
the hierarchy and physics api isn’t great either, it’s easy to hit heap allocs even from a gdextension
a lot of things wrong with this generic engine, but at least it’s lightweight
Lots of things right too, thankfully
Godot is only the best open source engine because Bevy is not ready for production, Lumberyard/O3DE is hard to set up and everything else is ancient or 2D only. one eyed man among the blind type shit
I miss Torque
> Godot is only the best open source engine because Bevy is not ready for production
I would argue that even if Bevy was ready for production it would not really compete with Godot.
Godot's performance is plenty for the vast majority of small to medium games. Plus they're starting to work on features like texture streaming for bigger games. It also has an editor which is a big plus for most teams.
Bevy would be objectively better for expensive CPU simulation stuff but realistically what percentage of games need that? Maybe 1%?
For Bevy to catch up on the indie game scene it needs an editor plus a scripting language and/or something like Unreal Blueprints. If it only wants to target the hardcore Rust dev that does everything by code it will never go mainstream.
No. If you try Bevy, it feels different from ECS and ordinary OOP. So it's hard to get used to. But Godot, although GDScript has performance issues, if you use GDScript it's easy to port to mobile and web games, and the syntax itself is OOP, so it's easy to adapt to.
A lot of people complain about OOP, but it's a paradigm very well suited for rapid development.
Lots of people complain, yet nothing else has won over in GUI development tooling.
Godot is the best open source engine because it is dead simple to use, comes bundled with its own IDE and documentation, the editor runs on any platform that Godot runs (including the web) and the performance benefits for something like Bevy only apply to a handful of games that really need it.
Godot gives GDScript simplicity for the vast majority of use cases which is that iteration boon, provides C# for games that need the additional guardrails. For performance critical game scripts you can just jump to C++, Rust, Swift, etc.
But most game scripts are not performance critical. Clair Obscur: Expedition 33 swept the game awards last year as an Unreal Engine game made using almost entirely visual scripting (blueprints).
Also Unreal C++ has a GC, exactly to have easy interoperability between engine code and C++ components exposed to Blueprints.
It still bothers me that game engines come with their own bespoke languages like GDScript. Godot is a bit better than others for having C# support and forks in other languages but really no other language will ever be as integrated with the framework as GDScript, And GDScript is never going to be a general purpose programming language, and that necessarily creates lock-in.
I'm currently messing with some old projects written in Game Maker 5 and let me tell you it would be so much easier if I didn't have to do internet archaeology just to figure out how GML worked 20 years ago.
Because it is much easier to have a custom language, than try to subsetting an existing mainstream language, while having to deal with all the mess of people trying to use random stuff on the engine, that naturally isn't supported.
Example, see all the bad rep .NET and C# get from devs that only know them from Unity, full of legacy stuff and restrictions, instead of using the real product.
That seems like more of a feature than a bug to me. Using C# in Godot means you have all of the Nuget libraries at your disposal, whereas no one is writing libraries in GDScript, because no one is using it outside of Godot.
Meanwhile to extend Godot usefully you have to use C++ and a plugin API that's arguably no less complicated than adapting an existing language as the scripting language would have been.
But that is the thing, you don't have access to all the NuGet libraries, or even CLR/MSIL abilities, it is a hit and miss depending on what platforms are being targeted.
Sure if you only want to target desktop/laptop computers, you're safe.
I always do not understand why defold is never put into the fold [sic!] of those sentiments/discussions. You can learn a clean & fun language (lua) and its JIT is maybe/probably running laps around something like GDScript, which in itself is proprietary and has no other uses for you than, ehh, Godot?? You can integrate C/C++ extensions natively, neatly exposing them through lua APIs. Its mobile and web target footprint is unbeatably (?) small, desktop at least 10x smaller than Godot or Unity. It is Open Source.
Maybe it's the "ancient" part, because more recent is always better ;)
defold is really cool, the only downside is its really weird build system for native extensions
> I always do not understand why defold
Starting with absolutely nothing but a compiler is always going to be a worse experience (and less likely to result in anything released) than a GUI-driven and aided solution. If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance. As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space. As most people know, the vast majority of games are net-losses, so engines live and die by the ease of adoption by newcomers.
> Starting with absolutely nothing but a compiler
I don't understand what you mean by this -- Defold has a graphical editor?
> If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance.
What do you mean by libraries in this context? It has a robust plugin system with a reasonably active ecosystem, if that's the sort of thing you're talking about: https://defold.com/assets/
And it covers all the systems one would expect in a 2D game engine natively -- tilemaps, physics etc.
> As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space.
I definitely disagree with this -- it's certainly not abandoned, and though it does have a slightly steeper learning curve than Godot or other popular engines, that's also how it gets such impressive performance and slim builds; feature, not a bug.
Unfortunately, I'm really not a fan of using Lua for anything beyond simple scripting.
Good news, they've been working on adding C# support for a year or two now. I think it's still experimental, but from what I understand they already had a robust extension system that supported C/C++/Java/etc., so fitting C# in wasn't much of a stretch.
(it is only extension support -- not scripting -- but the extension system is such that it can be used for any game logic AFAIK)
What motivated you to use c++ rather than C#? Especially when you mention the usage of c++ being tedious, when I would argue using C# is equally straight forward as gdscript is.
C# is a "first class" language in Godot and doesn't need a GDExtension, but it's not compatible with web builds yet. There is a draft PR that includes C# support but it adds about +50 MB to a web export and is also missing a few features.
I did not know that. Thanks for the info. I always use C# with Godot, but never had a use-case where i needed a web build.
And even that doesn't add consoles support, is W4 that far?
Console support is accomplished using "Middleware ports" for the Nintendo Switch, Xbox Series X/S, and PlayStation 5. https://godotengine.org/consoles/
I know the process, the question was how far .NET tooling support is there, because if they just rewrite everything into C++, there isn't much there to talk about.
A combination of two factors that are rather specific to myself. One being that even tho its quite some time ago i have a bit of c++ experience, while i never tried to code C#. So when i got the idea to try to run the heavy simulation in an "extension" it was just a language i was a bit familiar with. Maybe C# would have been the "smarter" choice, i just never digged into it yet.
The other reason is that in my well closer circle i got quite some people that code c++ on a daily basis and i don't know (at least i think so) anyone doin C# actively, so i thought if i would get stuck i have people i can easily ask about my c++ problems.
So it wasn't a "i think c++ is better than c#" decision rather a what do i know and what resources i have available easily.
C# is mostly in the Unity community. I agree that GDScript performance isn't good.
Godot, Unity, Stride, Flax and even jank niche engines like NeoAxis generally have pretty good C# integration!
If you look more at Stride, you’ll see that even their physics engine is C# which is insane in the best possible way: https://doc.stride3d.net/4.3/en/Manual/physics/index.html and https://github.com/bepu/bepuphysics2
Very cool language and as much of a mainstay in gamedev like something like Lua.
It surprises me that Java never got similarly big despite their GC improvements, though jMonkeyEngine was a nice project last I looked.
Yeah there are some gamedev treasures in C#, owning to the fact that Microsoft created the Xbox Live Indie Games program back in the X360 era, which meant you could ship games to customers with generally little oversight and meddling - this was WAY before Steam did something similar, and even before the iPhone app store.
The catch was that you had to use C# and XNA (which was a wrapper for gaming related APIs like DirectX, XAudio and XInput, generally considered to be very good). This meant there were a lot of hardcore libs made for C# gamedev (BEPU physics is from that era, and there were things like very good UI frameworks).
Tons of games were made with XNA, and its open source ofshoots, MonoGame and FNA power some of the greatest indie hits (Stardew Valley, Celeste, Bastion and other Supergiant titles, Terraria come to mind).
Imo this is one of the main reasons Unity went with C# in the first place.
Historical note that Arena Wars, released in the .NET 1.0 days, with thin bindings to OpenGL, was the very first .NET game, years before XNA.
https://en.wikipedia.org/wiki/Arena_Wars
C# being closer to C++, and .NET having direct support for C++ helped quite a bit regarding adoption among game studios.
Unity started on Mac, and they only adopted .NET when doing the cross platform rewrite.
I also don't remember if there wasn't some Mono advocacy at the time, as they became customers in the process.
Ironically Mono/Xamarin is almost gone from official .NET, all these years after the acquisition, with every modern .NET release, another bit falls off.
We are already on the phase that CoreCLR might take the remaining bits.
Not sure how relevant this is for this simulation use case but IIRC C# has a bigger overhead when communicating with the core engine compared to GDScript or C++.
Assuming it's a 2D game, why not just use something like SFML to build your own simple RTS engine at that point?
Seems like carrying a lot of Godot baggage around for nothing.
Godot comes with a lot of tools in addition to the runtime. Maybe they are using the IDE to do layouts for the menu dialogues, for example.
Also, I am not sure about how easy it is to build binaries using SFML for various platforms (such as WASM), but with Godot you just have to download the right template.
Again combination of multiple points but for some part this is correct.
One side is that i started developing it with godot, and the game has well alot of menu stuff going on (without wanting to go to much into detail but you are to a certain degree able to configure units outside of a match into "blueprint" like system). This whole editor / management etc stuff got quite big and works really well.
Means, when i hit the gdscript limits, i did not want to port all of the existing stuff that already works perfectly fine with godot.
And ye since the c++ only runs math simulations but i still use the godot renderer (which so far seems to work out perfectly fine) i was okay with that mixed solution (for now).
At which point do you just switch to a cpp UI library and forget about the engine?
It's not like i didn't consider that step :D but as mentioned in another response the game contains some rather complex configurator etc systems that i already completely baked with the godot system, also a simple map editor that works fine - so im not to motivated to also rewrite them all. Apart from that its a hobby project (one of many) so well maybe i reach that point and go full c++ but for now i dont think i will.
If you know rust, the Godot rust bindings for GDExtension are also really good and let you use any Rust library in Godot (including tokio and async rust if you really want) https://godot-rust.github.io/
Came here to mention this. As an example there's godot-iroh which uses iroh for peer to peer networking:
https://github.com/tipragot/godot-iroh
I'm a big fan of the godot rust bindings as well
Just don't forget the versioning script needed on at least Linux. It's either that or build with the same older distro Godot uses, so you have a matching libstdc++ version. You can link with a newer stdlibc++ but you will need a linker versioning script that hides your impl from the dynamic linker so you don't get random ghosts in your machine.
Hi! Yes, you are right, thanks for pointing this out. It's something to keep in mind when distributing an extension for Linux. I have just updated the post with a note about it.
So, what profiling support is available to find the critical parts of your GDscript or C# code. Before needlessly jumping into c++ hassle for performance reasons? Tfa addresses functional reasons, which is ok.
For C# there’s basically nothing in engine, so you’d use Rider or Superluminal. Which is fine, Godot can have a bit too much nih imo
I don't follow it that much, but I think there are no plans to improve GDscript performance other than maybe the interpreter itself, nothing with JIT or AOT in mind.
Also .NET integration has the issue it doesn't work in all target platforms, that is why Capcom and Unity have their own compilers to native code. Even when Unity finally adopts modern .NET, Native AOT naturally doesn't cover game consoles.
It's too bad .NET AOT wouldn't support consoles. They use x86 and ARM processors that it already supports.
There is more to it than just a CPU ISA.
It's not up to .NET AOT, it's up to Xbox and Sony.
.NET can generate the code, but your game won't pass certification if it runs machine code generated by something other than the officially provided C/C++ tool chain.
Devil May Cry on PlayStation 5 uses .NET, as do many other games from Capcom.
They have their own in-house fork of modern .NET, integrated into RE:Engine.
I know. That's why it's too bad! It would probably (almost) just work if only it used the console's toolchain, which requires signing NDAs to even look at.
Coming from Instruments (Apple) and Chrome Dev Tools, I found the Godot profiler to be hilariously hard to get useful results out of because of its simplistic presentation of information that you can't drill down into.
Is Godot (or something else,say, Bevy) the right tool for building a complex, data intensive GUI app (like a DAW)?
I tried dear imgui for this before but I felt it was very low level and had to build a lot of systems (not it's intended use as a GUI app framework, tbf)
Maybe?
I think it depends on what GUI tools it provides. Game engines aren't designed to be general purpose application frameworks either.
It's probably doable in Godot but you'll probably be building a lot of systems there as well, and probably writing a lot of plugins.
But people do it. I've seen plenty of applications in Unity.
So it requires writing a CMake script, some python, and some weird C++ code.
A bit tedious but that's how it goes.
The point is that it's compatible, not that it's the recommended way of doing things.
> // Copy the position of every entity into the MultiMesh buffer
So, is a zero-copy impossible due to world (C++ vs Godot) boundaries?
Hi! I don't think the boundary itself is the issue, although I'm not an expert on that part of Godot. My understanding is that the copy in this example comes from converting data from flecs into the layout MultiMesh expects. A different layout might reduce that work, but I haven't explored if fully zero-copy is possible.
I am building something similar, with c++26 reflection. So any language can use c++ libs with only a few lines of boilerplate in a lifetime and memory safe way where possible. And where it’s not possible to infer the safe lifetime of an object i got a small .toml file which tells the lib how to safely use those functions.
> Engine modules are compiled into the engine itself. They have full access to the internals, but you need to build and ship your own copy of Godot, including the editor and export templates for every platform.
I’m not familiar with distributing godot games. If I build a game to distribute on steam (for example) would this be an option? Or is a GDExtension (runtime loaded .so) the standard way to go?
It depends on what your use case is. GDExtension is the standard way to go, unless its API is too limited and you have to access/modify engine internals not otherwise exposed.
That being said, this has no impact on distribution either way as far as I know.
GDExtension is the standard way. But building a custom version of Godot is common and won't be a problem for distributing the game on steam or any platform. It's necessary to build your own godot version and export templates to produce an encrypted build not too easily hackable for example.
Static linking libstdc++ with -fvisibility=hidden saved me on Linux, though it bit me the day I needed exceptions to cross the boundary.
I’m using CPP with Godot for runtime procedural mesh generation. Works like a charm. It’s nice to have this option when you need it.
c++ is sorta private to the application.
If the API is c++ based you have to statically link it to the engine since the chosen c++ runtime is statically linked to the engine binaries.
You cannot ship as a shared c++ runtime since it would conflict with a possible version installed on the user distro (version of the gcc libstdc++, version of the clang runtime, intel?, or none see below).
To avoid c++ ABI issues, distros may statically link their c++ runtimes (clang[c++ and compiler versions]/gcc[c++ and compiler and versions]/intel[c++ and compiler versions]/etc)... if they need any (and the new c++ to C transpiler may have some significant impact in the near future).
(BTW, is the c++ intel compiler still shipping??)
If the API is "C" based (aka core platform ABI), no issue, just statically load only the common glibc libs (ELF DT_NEED entries) and dynamically load (libdl/dlopen/dlsym/dlclose) everything else (private libs, or system interface shared libs), and you are good to ship. A word though: wayland code with its libxkbcommon are statically linked, do not reproduce the same mistakes than with x11).
This is required for broad distro support [and long term support].
Basically, game binaries should be "-static-libgcc -static-libstdc++ --enable-new-dtags" everywhere, statically load _ONLY_ common glibc libs (and with "old" symbol versions, see binutils ld documentation, the 2nd part of the VERSION documentation page), and dynamically load everything else.
I have been inspecting many recent godot4 games on steam: all had "correct" binaries to maximize broad distro loading support on the long run.
The current issues: some games are written in microsoft rust which toolchain is still unable to statically link libgcc (see tinyglade game). Or some unity versions which "forgot" the '-static-libgcc' compiling/linking options, and even forgot to statically link their libz Oo.
If valve could do just that with the binaries of their client and their games... They can keep their 'runtimes' for old broken games but should have 'correct' binaries for everything else on their side (and valve still has to port the final 32bits reaper command to 64bits for clean 64bits support, hopefully I did not miss other 32bits binaries). Forcing distros to compile that user namespace in their linux kernel is quite "inappropriate", better keep that optional for those broken games only.
A big issue. If you can't ship a library its basically useless.
If your API is c++ based, you ship a static lib. If the game engine is "closed" source, you also a have static lib (or a set of) for the game engine too, and "exporting" is actually linking (basically a binutils ld invokation). Ofc, you better use the same c++ compiler _VERSION_ than the game engine devs did use, or you are good for c++ hell.
If your API is C based (or core platform ABI), and you should design such API for interop with any framework anyway, you can ship a shared lib (but it has to statically load only the common glibc libs, and that with "old" symbol versions, and the other things too, see my previous post).