Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

Godot Engine to get improved Linux support in the upcoming Godot 4 release

By - | Views: 12,506

While the free and open source game engine Godot Engine already has Linux support, for both exported games and the full editor, it's set to get even better in Godot 4.0.

In a blog post written by Camille Mohr-Daurat, they mentioned how they've been hired by the Godot team to work as a contractor on fixes and improvements for the Linux port of Godot. Camille Mohr-Daurat is an indie developer who actually uses Godot too at Nekomatata, where they created the unique ping-pong battler Punch Pong. So this is a real fun example of open source in action.

Godot 4.0 will be coming with a new windowing system, so that you can separate parts of the Godot Engine editor from the main window. A lot of their work is focused on ensuring that works great on Linux with X11, which seems like there's a lot of work involved, because there's places where X11 doesn't have APIs to handle things where it does on other platforms like Windows and macOS - with drag and drop between windows being one mentioned example they've had to solve directly.

Multi-windows could be seriously useful in a multi-monitor setup.

Another possible change they're discussing for after they fix up the current issues in on modernizing their implementation using XCB which is a replacement for Xlib. They also confirmed Wayland support is planned at some point, as a separate Display Server implementation.

Since Godot Engine is open source, it's always thoroughly interesting to be able to see what really goes on behind the scenes on these huge complicated projects. Their dedication to Linux and cross-platform in general is great too, showing others how it can be done.

Full blog post on it here.

Article taken from GamingOnLinux.com.
26 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
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.
See more from me
11 comments
Page: 1/2»
  Go to:

fagnerln 20 Oct
It's already pretty good, godot is fantastic. I hope that they don't change the structure as 3.0 changed from 2.0, a lot of good 2.0 tutorial don't work.
TheSHEEEP 20 Oct
View PC info
  • Supporter Plus
In the category "Headlines you won't see about Unreal Engine".
Dunc 20 Oct
QuoteMulti-windows could be seriously useful in a multi-monitor setup.
I know I'm in the minority here, but the current layout can be very cramped on a 5:4 display. Being able to offload some less-used windows to a second screen will be a huge help.
Shmerl 20 Oct
Hm, why are they working directly with X instead of using something like SDL?
setzer22 20 Oct
This is the kind of things that made me switch from Unity to Godot. They *do* care about Linux, and it shows . Also, being able to pop out windows from the main editor looks neat!


Quoting: fagnerlnIt's already pretty good, godot is fantastic. I hope that they don't change the structure as 3.0 changed from 2.0, a lot of good 2.0 tutorial don't work.

Sadly, there's quite a bit of that already planned :/ Pointless renames like Node -> Node3D will break most existing scripts/tooling. They promised some sort of limited support to automate the conversion, but YMMV. These renames *may* make things clearer, but the cost of an API break just for this is too high IMO.

This is the one thing I'll never understand about godot (and Blender has the exact same problem). Why do they have so little care for backwards compatibility?


Last edited by setzer22 on 20 October 2020 at 4:04 pm UTC
TheSHEEEP 21 Oct
View PC info
  • Supporter Plus
Quoting: setzer22This is the one thing I'll never understand about godot (and Blender has the exact same problem). Why do they have so little care for backwards compatibility?
Because backwards compatibility drags every project down with additional maintenance cost.
Windows STILL has to carry legacy code and support around that is by now ~20 years old.

Godot is in the position that they don't have to do that - and so they don't.
They already limit themselves to changes for major versions (and even backport improvements where possible) - that's more than reasonable.

If you think that doing a global find/replace for Node -> Node3D is a real problem, then I don't know what to tell you.
Though 4.0 will break a lot more than that. Porting a larger 3.2 project to 4.0 will probably take the better part of a week with API changes that go beyond renaming stuff.
I do hope they'll provide an extensive porting guide.

And that's still better than carrying legacy code around because it means Godot will actually be able to shed or replace old code instead of having to maintain it, making a much better use of their limited resources.
Phlebiac 21 Oct
I don't know the complexities involved, but it seems to me that GIMP handled multiple windows for the last 25 years or so?
Quoting: TheSHEEEP
Quoting: setzer22This is the one thing I'll never understand about godot (and Blender has the exact same problem). Why do they have so little care for backwards compatibility?
Because backwards compatibility drags every project down with additional maintenance cost.
Windows STILL has to carry legacy code and support around that is by now ~20 years old.

Godot is in the position that they don't have to do that - and so they don't.
They already limit themselves to changes for major versions (and even backport improvements where possible) - that's more than reasonable.

If you think that doing a global find/replace for Node -> Node3D is a real problem, then I don't know what to tell you.
Though 4.0 will break a lot more than that. Porting a larger 3.2 project to 4.0 will probably take the better part of a week with API changes that go beyond renaming stuff.
I do hope they'll provide an extensive porting guide.

And that's still better than carrying legacy code around because it means Godot will actually be able to shed or replace old code instead of having to maintain it, making a much better use of their limited resources.
I think the pros and cons depend to some extent on the life cycle of the software. When software is young, many major features have yet to arrive, and use is growing but there isn't a huge installed base, you don't want to sweat backwards compatibility. You'd hamper your ability to add those important features, and all you'd gain is a bit of convenience for early adopters who can handle a bit of fiddling and are also waiting impatiently for those features.
When software is mature and already dominates the industry, or maybe doesn't but has a fairly static, loyal user base, then you want to think seriously about whether a bit more ease adding new bling which probably doesn't represent any kind of core feature ('cause you did those already) is worth pissing off all the users who are doing production work with your stuff.

Godot is still towards the early end of that, so it would be foolish of them to stress backwards compatibility.


Last edited by Purple Library Guy on 21 October 2020 at 9:07 am UTC
Dunc 21 Oct
Quoting: PhlebiacI don't know the complexities involved, but it seems to me that GIMP handled multiple windows for the last 25 years or so?
There is a certain irony in the fact that a single-window mode was celebrated as a great advance for the GIMP, and now a multi-window mode is being presented as an advance for Godot.

In fairness, I didn't mind the old GIMP interface, but find myself using single-window mode all the time now, and as I said, multiple windows will definitely come in useful in Godot.
setzer22 22 Oct
Quoting: TheSHEEEP
Quoting: setzer22This is the one thing I'll never understand about godot (and Blender has the exact same problem). Why do they have so little care for backwards compatibility?
Because backwards compatibility drags every project down with additional maintenance cost.
Windows STILL has to carry legacy code and support around that is by now ~20 years old.

Godot is in the position that they don't have to do that - and so they don't.
They already limit themselves to changes for major versions (and even backport improvements where possible) - that's more than reasonable.

If you think that doing a global find/replace for Node -> Node3D is a real problem, then I don't know what to tell you.
Though 4.0 will break a lot more than that. Porting a larger 3.2 project to 4.0 will probably take the better part of a week with API changes that go beyond renaming stuff.
I do hope they'll provide an extensive porting guide.

And that's still better than carrying legacy code around because it means Godot will actually be able to shed or replace old code instead of having to maintain it, making a much better use of their limited resources.

I'm sorry if my comment came off as harsh criticism on Godot. I still love the engine and think they're doing a great job (heck, I use it myself almost daily!)

I'm all in for useful API changes and removing cruft from older versions. But you should always aim for backwards compatibility whithin reason. Minor API changes is also what caused the great divide between Python 2 and 3, and we're paying the price for some of those decisions still today. When you have thousands of users, you should consider every API break carefully.

I was mentioning the Node->Node3D switch not because it's difficult to upgrade (I, too, know how to do global search and replace ), but because it is an API breaking change that has very little point. But even for such an easy change, my point stands: There's hundreds of tutorials out there that will become outdated. How many of them will be fixed by their original developers? Because otherwise, they're as good as gone.

Take this amazing Godot plugin for example: https://github.com/Stoeoeoe/godot_data_editor It's unfortunately built for Godot 2. After half an hour attempting to port it to 3.X, I decided to stop and just roll my own thing, which I'll probably never release to the public. A great piece of software was lost just because someone decided their API was not "clean enough", that's what happened.

This may be quite a bit off-topic for this forum, but the kind of philosophy shown in this talk is precisely what I'm talking about: https://www.youtube.com/watch?v=oyLBGkS5ICk And let me tell you this guy is no charlatan, he's the main designer of a programming language used by thousands of developers, and he managed to do so for 10+ years while never breaking an API :)
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just 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!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.

Livestreams & Videos
Community Livestreams
Latest Forum Posts