Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

The team behind Godot Engine continue to push what an open source game engine can do, with a recent big release now behind them work continues towards another with some impressive changes.

It's going through a big code refactoring process right now, as written up in a blog post by Lead Developer Juan Linietsky. They said that while a lot of "core code changes" happened for the 3.0 release two years ago, they now have the chance to do even more for the massive Godot 4.0 release which will have Vulkan API support.

One major change is a "design flaw in Godot 3.0", that meant you couldn't always tell if an object instance was freed or not which created bugs that Linietsky said couldn't be fixed. Not a problem in the 4.x code branch, which can improve "performance considerably" and they may backport it to the 3.x releases.

Multiple other big changes were done, many of which will help improve performance. Including a removal of "PoolArrays (PoolVector in C++), replaced by PackedArrays" which was done for 32bit, since they no longer need it the replacement "improves performance in all operations related to large memory allocations".

Another big one is threaded resource loading, using a new API that's simpler and it can take advantage of many cores resulting in "4x to 6x performance increases, and in considerably improves the usability for background loading".

As for what comes next, during March they will continue the code refactoring and back to Vulkan API work in April. One of their upcoming goals is to "perform the separation of OS class into OS and DisplayServer", to allow them to support multiple windows, Wayland and Linux+EGL plus more API cleanups.

It really does sound like Godot Engine 4.0 due late this year is going to be an absolutely massive improvement for this cross-platform free and open source game engine.

See more about the FOSS game engine Godot Engine of the official site.

Article taken from GamingOnLinux.com.
17 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
6 comments

Kimyrielle Mar 2, 2020
One thing they really should address while at it is dynamically loading resources at runtime. Which largely is a PITA in Godot. Since the engine dumps every resource into the .import folder (for whatever reason I don't understand), loading resources via file system calls is not working in the exported game. It works just fine in the editor though, leading developers into the mistaken belief that the approach works, when it doesn't.
It's bad. Not only because I don't understand why they would create a huge junkyard folder for everything when they could just leave resources in the folders where they got placed at development time and put just the -reference- in the .import folder, Which would allow loading resources dynamically just fine and still allow the engine to locate the resources easily. But also because an exported game should never ever work differently from running it in the editor. That's just asking for trouble.

Other than that I really love Godot. That's one of the few things that really makes want to me pull out my hair.
Shmerl Mar 2, 2020
Wayland + Vulkan: 🚀

I suppose it's going to be using WSI, rather than EGL in that case?


Last edited by Shmerl on 2 March 2020 at 7:29 pm UTC
Natedawg Mar 3, 2020
Quoting: KimyrielleSince the engine dumps every resource into the .import folder (for whatever reason I don't understand)

This is because Godot changes the model, texture, audio, etc files into a format the engine, graphics card, etc understands and is optimized for. It's the difference between a released game taking 10 minutes to load and 10 seconds to load. It also allows you the developer to try different import settings on individual assets quickly and non-destructively. The reason they're in the import folder is so that you can easily ignore it in your version control system.

Were you using "res://path/to/file" when trying to load a resource during runtime or something else? I can't remember, but I think "/home/username/path/to/file" might work in editor but not in a released game.

Hope that helps!


Last edited by Natedawg on 3 March 2020 at 2:44 am UTC
Kimyrielle Mar 3, 2020
Quoting: NatedawgWere you using "res://path/to/file" when trying to load a resource during runtime or something else? I can't remember, but I think "/home/username/path/to/file" might work in editor but not in a released game.

File system calls using "res://path/to/file" don't work in the released version either, as the engine moves files to .import upon export and renames them, so the design-time path is no longer valid. That's the gist of the problem. The only halfway clean way to resolve it I am aware of is to write an installer putting resources that are to be loaded dynamically into the "user://" path and load them from there. Which comes with the trade-off of these resources being easily accessible from outside the game, which might or might not be desireable.


Last edited by Kimyrielle on 3 March 2020 at 6:23 am UTC
TheRiddick Mar 3, 2020
I might be tempted to diddle around with this once the vulkan release comes out. I wonder if they intend to compete with Unity3d and Unreal3d engines at some point.

Think I've actually got a few developer resource libraries laying around, might be time to check them out.


Last edited by TheRiddick on 3 March 2020 at 9:24 am UTC
rkfg Mar 3, 2020
Quoting: TheRiddickI might be tempted to diddle around with this once the vulkan release comes out. I wonder if they intend to compete with Unity3d and Unreal3d engines at some point.

Think I've actually got a few developer resource libraries laying around, might be time to check them out.
You might be interested in this short thread where Juan explains the Godot and UE4/Unity relationship: https://twitter.com/reduzio/status/1224409252023894016
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.