Lisandro Lorea: Godot releases used to take a while but nowadays we get feature-packed updates every couple months. How do you work with contributors to decide what gets merged and when?
Rémi Verschelde: Godot releases used to take a bit longer until Godot 4, and Godot 4 took forever, but I always wanted us to go towards a faster release cycle so we get things out faster, get feedback, and iterate on that.
When we released Godot 4.0, we decided to try a release cycle of four months - three months for feature development (what we call the “dev phase”, “dev snapshots”) and then one month of beta, release candidate, and stable release.
We had 4.4 in early March, and 4.5 should be in early August. So it's kind of like five months if I count correctly. We're not too far from the goal. That's the idea - frequent releases.
We are doing feature freeze for 4.5 today, which was supposed to be two days ago, but there are more and more things we keep wanting to add. Just in the last four or five days, every contributor is updating their pull requests, reviewing each other's pull requests, trying to get the last features merged.
Lisandro Lorea: “Get on the train before it leaves”, right?
Rémi Verschelde: Exactly. So there's still a bit of that, but it was even worse before with big releases where it's like, okay, if you miss that train, then you have to wait a year to have the feature. So the idea with more frequent cycles is that there's not too much pressure and we don't incentivize crunch too much.
Abstract classes and its unexpected community hype.
Lisandro Lorea: Moving on to 4.5, one feature that didn't get a highlight in the release notes but caught my attention is the ability to create named editor scripts and automatically have them available in the command palette. Seems like a little change resulting in a nice QoL improvement.
Rémi Verschelde: Definitely. There are a few things we didn't highlight because there were too many, but sometimes we see the community's reaction to some stuff that we didn't even anticipate, and it's like "okay people have really been craving this without us knowing", like abstract classes in GDScript. This is a PR that was made two years ago or something and nobody seemed to care, but then we got this feature merged finally because we were like "sure we have this feature in C++, it can make sense to expose it" and then everyone just goes crazy.
From a solo dev perspective it’s like "I'm not going to mess with my own stuff" or “don’t instantiate this class if you don’t want to”, but some are more on the bigger team perspective and they want to put safeguards in place.
Lisandro Lorea: It also affects how they are presented in the editor, right?
If you make a class abstract it doesn't show up in the add new node dialogue, and I think just this tiny bit of UX also matters a lot. If you use resources - like you export something that's of a resource type and you use the abstract class as the type - then it will list the named classes that derive that type but not the base one. So it's mostly a usability feature, but that's usually the thing that we realize people are most excited about.
Script Backtraces
Lisandro Lorea: Any new feature you are personally excited about?
Script back traces. I think that's super cool. That's also a W4 contribution made by Juan Linietsky and finalized by Mikael Hermansson. That's super useful and that's something a lot of people have been asking for.
Lisandro Lorea: You could already see backtraces in the debugger when you got an error in GDScript. What changes with this new feature?
Rémi Verschelde: This feature you have in the debugger now you also have it at runtime, you can print the back traces yourself. It's very important for people who want to do proper handling of bugs and have in their logs enough information. Players can send them logs or they get automated log reports and then they can possibly fix the bug without ever having to reproduce it themselves.
Lisandro Lorea: Does that work on release builds as well? That's amazing!
Rémi Verschelde: There might be a compile time option to enable it or maybe we just have it all the time. There was a bit of concern that it adds a bit of overhead to have this, but I think in the end we might just have it always enabled.
Embedded Game Window Lands on macOS
Rémi Verschelde: Another one I'm really happy we have because there's been so much demand is the macOS embedded window. 4.4 included the embedded game system that we kickstarted with Michael Alexsander, and then he and Hilderin made the embedded part but not for macOS because that was much harder.
Stuart Carnie made the macOS embedding, so now we finally have parity between all the desktop platforms.
Lisandro Lorea: I remember reading that the approach used for macOS was more solid and could be used for all platforms. Is that correct?
Rémi Verschelde: Now there's basically a full communication protocol to replicate things between the game and the editor. Embedding is one part, but the other part is making it so that the events you pass to the editor window actually get propagated to the game, and this all goes through the debugger. A lot of work was done there and that could be extended to the other platforms.
In-editor Translation Preview
Rémi Verschelde: And finally two other features I'm excited about. One is the ability to live preview translations in the editor. Before you had to run the project with each language to see the translations, but now you can see everything in the editor, you just have a dropdown and can change the language and see if it's properly translated or if the UI breaks
Optimizations to the Engine Core, a focus of Godot 4.5
Rémi Verschelde: This release there's been a focus on optimization of core components and to some extent some of the editor. A lot of small things that have been properly profiled, not just theoretical optimization. It's hard to say what the full performance impact is going to be, but for example, the editor should just feel like it could just start much faster than it did before. And there's a lot of small enhancements also in the node system, in GDScript...I think there should be some nice gains.
SIMD on WASM and legacy hardware support
Lisandro Lorea: And talking about performance, some more explicit features for the users are the shader baker and the SIMD support on WASM. Anything to say about that?
Rémi Verschelde: SIMD for WASM, that's really cool. It's just a simple flag that we added that enables a lot of optimizations that are available on all modern browsers. That's also something we're starting to use more also on native builds. Godot 4.5 now requires hardware that supports SSE 4.2 to run. If you have very old hardware like a Pentium 3 it's going to crash even though Godot could work in theory, but on the other hand it means it gets faster for everyone else. We're considering going further to higher levels of instruction sets that further limits the hardware and gives more performance, but we're being conservative with it.
We try to be accessible and cater to as many users as possible but if we are too conservative we prevent ourselves from getting free performance improvements.
Lisandro Lorea: and Godot 3 is still a viable option for those target legacy hardware, right?
Rémi Verschelde: Totally. If the developer has the goal to support older hardware I’d recommend to use Godot 3 from the start, which is still maintained. We have Lawnjelly still adding new features for Godot 3.7.
Shader Baker
Rémi Verschelde: The shader baker is a big W4 contribution. It was initially made by Pedro Estébanez for our console support (we support shader baking for consoles since 4.3) but we've also done the work to upstream this, which required a significant rework of that system by Dario Banini and got finally ready and merged for 4.5
That really helps with reducing shader compilation stutters and reducing the startup time of games, especially for Metal and Direct3D 12
Between this and the Uber shader that we included in Godot 4.4, I think now we've finally solved the difficulty most users have with making 3D games (also in other engines) of having stutters, having long loading times.
Personally, the first time I saw both the shader baker and the Uber shader on the Godot third person shooter, seeing that it would just start fast and not have any stutter, I was like "this is not Godot." It was really amazing.
AccessKit, bringing screen reader support to Godot
Lisandro Lorea: You mentioned being accessible and catering to as many people as possible and this reminds me that Godot 4.5 includes support for AccessKit. Can you talk a bit about that?
Rémi Verschelde: Right. This is huge. I don't think we can claim yet that Godot is accessible but we have the AccessKit API included. You can use a screen reader with Godot and we have a bunch of accessibility descriptions everywhere. My understanding - I haven't tested it - is that you can navigate the editor with a screen reader and you can make games using this API that are accessible.
The features are there, what's lacking is documentation and a lot more work on the editor to make it really accessible, and get it tested with blind and visually impaired users so that they actually tell us "yes this is working for me" or "we need to adapt this or that part of the editor so that it's more screen reader friendly".
Currently I would say the base framework for making games accessible for blind and visually impaired users - both developers and players - is there. The whole AccessKit framework has been implemented, but if you're just a regular Godot user and you're like "how do I make my Balatro clone accessible," there's a huge gap of knowledge that needs to be filled with tutorials and then content creators covering it and maybe plugins to make it easier.
But I'm super happy this is finally merged because this was honestly a sore point. Godot has its own UI toolkit and it runs everywhere but there was no accessibility support, while if you use native frameworks like Qt, SwiftUI, etc. you get all this for free. It’s great that we finally have that and we're also lucky there's a framework like AccessKit that enables applications like us to have access to all these features.