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.
Kimyrielle Mar 2, 2020
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.
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
Since 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
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.
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
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
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.You might be interested in this short thread where Juan explains the Godot and UE4/Unity relationship: https://twitter.com/reduzio/status/1224409252023894016
Think I've actually got a few developer resource libraries laying around, might be time to check them out.
Patreon
PayPal
See more from me