Godot 4.7 erreicht RC2 – stabile Version nur noch wenige Tage entfernt
Godot 4.7 hat heute seinen zweiten Release Candidate erreicht. Die Veröffentlichung reift seit dem 24. April, als Beta 1 mit 1.265 Korrekturen von 309 Mitwirkenden gegenüber 4.6-stable erschien. RC1 folgte am 8. Juni mit nur 16 Korrekturen von 16 Mitwirkenden – eine derart ruhige Momentaufnahme bedeutet, dass die harte Arbeit erledigt ist. RC2 räumt heute noch einige späte Regressionen aus dem Weg, und das ist üblicherweise die letzte Station vor dem finalen Build.
Ein praxisnaher Überblick über die Neuerungen in Godot 4.7
Was RC2 tatsächlich behoben hat
Bei RC2 geht es um die Bereinigung von Regressionen, nicht um neue Funktionen. Das Team entdeckte einen Deadlock in WorkerThreadPool, der Multithreading-Projekte einfrieren lassen konnte, sowie einen damit zusammenhängenden Fehler, durch den die Nachrichtenwarteschlange nicht mehr vollständig abgearbeitet wurde, bevor eine MainLoop-Iteration abgeschlossen war. Beides sind unregelmäßig auftretende Hänger, die sich nur mühsam reproduzieren lassen und noch schlimmer auszuliefern wären. Der Rest der Liste betrifft den Feinschliff des Editors: Ziehvorgänge in SceneTreeEditor, die ohne Fehlermeldung scheiterten, Abstürze von AnimationTree aufgrund einer fehlenden Nullprüfung bei Stamm-Animationsknoten und ein Fehler bei der zufälligen Kachelauswahl, durch den die erste Kachel übersprungen wurde.
Nichts davon ist spektakulär. Aber all das sind Gründe, einen Release Candidate erst ausreifen zu lassen, bevor man ein Produktivprojekt darauf umstellt.
Die Funktionen, die mit 4.7 ausgeliefert werden
Wir haben die wichtigsten Funktionen bereits zum Erscheinen von Beta 1 vorgestellt, und seit dem Feature Freeze hat sich nichts geändert. Zwei davon sind für alle, die über ein Upgrade nachdenken, besonders erwähnenswert.
Die HDR-Ausgabe funktioniert jetzt auf jeder Desktopplattform. Godot rendert intern schon seit Jahren in HDR, doch in der Ausgabephase wurde im letzten Schritt alles per Tonemapping auf 8-Bit-SDR reduziert. Version 4.7 steuert HDR-Monitore unter Windows, macOS, Linux und BSD direkt an. Dadurch erscheinen Bloom, selbstleuchtende Oberflächen und Szenen mit großem Leuchtdichteumfang endlich so auf dem Bildschirm, wie es der Renderer vorgesehen hat.
Der neue Knoten AreaLight3D rendert weiches Licht von einer rechteckigen Fläche. Zuvor musste man eine Deckenleuchte oder ein Fenster simulieren, indem man Punktlichter verteilte und deren Abschwächung so lange abstimmte, bis das Ergebnis passabel aussah. Jetzt genügt ein einzelner Knoten mit Breite und Höhe sowie korrekten weichen Schatten und korrektem Lichtabfall über die Entfernung. Beleuchtungsaufbauten für Innenräume, die früher einen Nachmittag beanspruchten, sind nun in einer Minute erledigt.
Die Veröffentlichung bringt außerdem standardmäßiges Hot Reload für C#, einen Animation-Tree-Editor mit richtigem Rückgängig/Wiederholen und wasm64-Webexporte – den Teil, den wir besonders aufmerksam verfolgen.
Was das für Webspiele bedeutet
Der wasm64-Export ist der entscheidende Punkt für Browserspiele. Godots Webexport rendert über den Kompatibilitäts-Renderer weiterhin mit WebGL 2.0, und WebGPU wird noch nicht unterstützt. Daher können Forward+ und Mobile nach wie vor nicht im Browser ausgeführt werden. Was sich mit 4.7 ändert, ist die Speicherseite: wasm64-Exporte heben die alte 4-GB-Grenze auf, sodass große Projekte keine Inhalte mehr kürzen müssen, um in einen Web-Build zu passen. Die Rendering-Lücke muss weiterhin geschlossen werden, und wir haben im Januar erläutert, warum.
Für eine Plattform wie unsere, auf der Spiele ohne Installation sofort im Browser laufen, ist ein leistungsfähigeres Webziel einer Engine ein direkter Vorteil. Mehr Spielraum für Browser-Builds bedeutet mehr Spiele, die ohne Download problemlos in einem Tab laufen – und genau darauf baut Cinevva.
Solltest du upgraden?
Wenn du 4.6 verwendest und dein Projekt aktiv entwickelst, installiere RC2 jetzt in einem separaten Branch und teste es. Das Team ist von der Kompatibilität von 4.7 sehr überzeugt, auch weil das Versprechen zur API-Stabilität mit Version 4.5 verschärft und seither eingehalten wurde. Der Migrationsweg ist der übliche: Projekt in 4.7 öffnen, Warnungen zu veralteten APIs beseitigen und Testszenen ausführen.
Wenn du nach einem festen Zeitplan veröffentlichst, warte die wenigen zusätzlichen Tage auf die stabile Version. Dass RC2 so ruhig ausfällt, ist ein Zeichen dafür, dass die Wartezeit nicht lang sein wird. Der letzte Zyklus von der Beta bis zur stabilen Version verlief bei 4.6 reibungslos, und bei 4.7 sieht es nach einer Wiederholung aus.