Continue reading ➤

To everyone who ended up going to GodotCon this past week, we hope you had a safe journey home! For those of you that missed the fun, we’ve logged some of the highlights on the blog already—such as the long-awaited web support for .NET—with more to come later in the week. As always, we’ve recorded all of our GodotCon talks, and those shall be uploaded to our YouTube channel in a few weeks. With that now behind us, we can go full-steam ahead on our next development snapshot: 4.5 dev 4. Plenty of new features this time around, so feedback and bug reports from testing are once again strongly recommended.

Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.

The cover illustration is from Ambidextro, a precision-platformer where you must control two characters simultaneously, one with each hand. It is developed by Majorariatto. You can get the game on Steam and follow the developer on Twitter.

Highlights

In case you missed them, see the 4.5 dev 1, 4.5 dev 2, and 4.5 dev 3 release notes for an overview of some key features which were already in those snapshots, and are therefore still available for testing in dev 4.

macOS: Embedded window support

After Windows and Linux users got to experience the benefits of embedding their windows in the editor, macOS users have understandably been expressing interest in the same coming to their platform. Easier said than done, as this feature is OS-specific and very low-level, so implementation requires someone both extremely knowledgeable in a niche area and actually owning the platform in question for proper testing. Thankfully, both of these qualifications were met by Stuart Carnie, who was up to the task of integrating this behemoth in GH-105884. The results should speak for themselves:

The macOS implementation works differently from the Windows and Linux implementations. Since macOS does not allow the kind of window manipulation that Windows and Linux use for game window embedding, macOS uses an inter-process communication approach where the framebuffer is sent from the game process (which performs off-screen rendering) to the editor window. Input events are also sent from the editor window to the game process. This approach is more complex, but is also more robust as it doesn’t rely on window management tricks that can fall apart in certain edge cases. This approach may be ported later to Windows/Linux in a future release, as it would help improve the reliability of game window embedding.

Move 3D physics interpolation to SceneTree

The old design of the 3D interpolation system was fundamentally flawed, as it operated under the assumption that the scene side wouldn’t require access to interpolated transforms. This isn’t something that could’ve just been “patched in” either, thanks to the multithreaded design, command queue, and stalling. Lacking any sort of workaround, lawnjelly has taken a break from being the person responsible for 90% of 3.x code nowadays and forward-ported a solution via GH-104269. This addresses the problem by porting all logic to the SceneTree, while completely retaining the existing API!

No changes are needed to existing projects to benefit from the new 3D physics interpolation architecture.

Export variables as Variant

Despite both arrays and dictionaries technically supporting Variant values, this functionality was never actually exposed in isolation. That is: it was impossible to export a variable of type Variant directly. Tomasz Chabora found this limitation quite silly, so took to addressing this grave injustice with GH-89324. Now users are granted extra flexibility with their exports, as the option is now available to change not only the variable, but the type itself.

Stackable outlines on Label

Have you ever been in the situation where you want to add fancy outline or shadow effects to your text, only to realize that you’re stuck with only one of each? Sure, you can double-up the amount of text objects directly atop one-another, but that’s cumbersome and doesn’t account for outlines affecting other outlines. There must be a better way! Well, thanks to the efforts of Delsin-Yu, users no longer have to struggle with this moral conundrum. Instead, they can simply take advantage of GH-104731 adding support for stacked layers of effects; no cumbersome workarounds required.

Specular occlusion from ambient light

Our renderer currently lacks a cheap option for specular occlusion, causing certain metallic/reflective materials to still receive reflections when they should be darkened/occluded. Lander rectified this limitation in GH-106145, where specular occlusion is added based on ambient light. As users might prefer the old visuals, this is now handled through a toggle in the project settings. The differences can be observed here:

Disabled	Enabled

And more!

There are too many exciting changes to list them all here, but here’s a curated selection:

• Core: Add Node.get_orphan_node_ids, edit Node.print_orphan_nodes (GH-83757).
• Core: Add compression level support to Zip module (GH-103283).
• Core: Fix for debugging typed dictionaries (GH-106170).
• Core: Print script backtrace in the crash handler (GH-105741).
• Editor: Add editor setting to collapse main menu into a MenuButton (GH-105944).
• Editor: Enable Auto Reload Scripts on External Change by default in the editor settings (GH-97148).
• GUI: Add drag zoom feature with CTRL+MiddleMouseButton (GH-105625).
• GUI: Add property to control showing the virtual keyboard on focus events (GH-106114).
• Import: Use libjpeg-turbo for improved jpg compatibility and speed (GH-104347).
• Network: mbedTLS: Fix concurrency issues with TLS (GH-106167).
• Particles: Overhaul the cull mask internals for Lights, Decals, and Particle Colliders (GH-102399).
• Porting: Android: Annual versions bump for the Android platform (GH-106152).
• Porting: Android: Bump the minimum supported SDK version to 24 (GH-106148).
• Porting: Wayland: Handle fifo_v1 and clean up suspension logic (GH-101454).
• Rendering: Add Meshes to the Video RAM Profiler (GH-103238).
• Rendering: Allow moving meshes without motion vectors (GH-105437).
• Rendering: Forward+: Replace the current BRDF approximation with a DFG LUT and add multiscattering energy compensation (GH-103934).
• Rendering: FTI – Add custom interpolation for wheels (GH-105915).
• Shaders: Expose built-in region information (GH-90436).

Changelog

105 contributors submitted 261 fixes for this release. See our interactive changelog for the complete list of changes since the previous 4.5-dev3 snapshot.

This release is built from commit 209a446e3.

Downloads

Download Godot 4.5 dev4

Linux

Standard

.NET

macOS

Standard

.NET

Windows

Standard

.NET

Export templates and other downloads


Make a Donation

Godot is downloading…

Godot exists thanks to donations from people like you. Help us continue our work:

Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

Known issues

There are currently no known issues introduced by this release.

With every release, we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.

Bug reports

As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.

In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).

Support

Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part and full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!

If you’d like to support the project financially and help us secure our future hires, you can do so using the Godot Development Fund.

Donate now

Hi there! I’m Adam Scott (@adamscott on GitHub), the Godot Engine Web team lead, live from the GodotCon Boston 2025!

On May 6, during my State of Godot and the Web talk, I revealed a world premiere to the GodotCon attendees. It was something some thought impossible, and others were resigned to not seeing during their lifetime.

Please note that the VOD isn’t available yet. The link to the recording will be added to the article once available. Meanwhile, you can access the slides of the presentation.

The .NET team lead, Raul Santos (@raulsntos on GitHub), managed to create a prototype running C# on the Web.

Wasn’t it impossible?

We tried dotnet.js. It didn’t work.

We tried NativeAOT-LLVM. It didn’t work.

We (initially) tried statically linking Mono. It didn’t work.

Well, Raul gave it another shot recently and managed to make it work. Here’s how he explains his accomplishment.

As mentioned in my last update, the option of statically linking Mono seemed the most promising so we went ahead with that.

I have opened a draft PR with the latest changes, but keep in mind it’s still a work in progress:

• [.NET] Add web export support #106125

As a reminder, this approach still seems very brittle to me and has some limitations. The C# project must match the WASM features supported by the Godot template (this includes things like the threading model, exception handling, SIMD support, etc.). The TargetFramework version of the C# project must also match the one that was used to build the template.

Additionally, since we currently don’t load any globalization data, we only support invariant mode. This is not a big problem because most users will likely rely on Godot’s localization features, so it’s not a blocker.

On the last update the issue we run into was retrieving function pointers. We were able to workaround that by declaring stub C# methods on the project we use to retrieve the Mono runtime. When building the Godot templates, this ensures these methods are included in the generated table which seems to be enough to let us retrieve the function pointer at runtime.

In a regular C# application built for the web platform you’d use dotnet.js which acts as a loader for the WASM file and other required assets. In Godot we have our own way of doing this, and as a result we’re currently missing a key part of the process.

The Mono runtime exports some JavaScript functions but at the time of building the templates these are stubs. The dotnet.js loader takes care of replacing these stubs with their real implementation in dotnet.runtime.js. We’re currently missing this step so they remain stubs.

This means some .NET APIs that rely on these exported JavaScript functions will not work, resulting in unexpected behavior. This includes things that must be implemented using browser APIs such as cryptography.

Nonetheless, I think this is significant progress and has allowed us to build a demo running on the browser.

What’s next for C#/.NET on the Web

Raul has published his pull request as a draft so far. It means that there’s a lot of work and testing to do.

We’re working as fast as we can to enable you to export C#/.NET to the Web, but we cannot commit to a specific timeline yet. If everything works great, it should be available in the next Godot release.

What about file size? My .pck size has exploded!

Currently, we do have to include some .dll files in your main .pck file in order to be able to run a C# project. For the simple prototype, the .pck file size is at an astounding 72 MiB. Fortunately, when Brotli-compressed, the file can be reduced to 23.8 MiB.

It’s not perfect, as we often suggest targeting the smallest size when deploying to the Web. But the following announcement should help at least somewhat concerning this issue.

Introducing built-in (pre)compression

I also revealed my upcoming built-in (pre)compression PR to the public.

It will do the following:

• add an option to compress template files when compiling the engine
• add export options to compress exported files
• if the target server doesn’t support serving pre-compiled files, the preloading script will take over as a fallback, ensuring to download compressed files instead of non-compressed ones in order to save bandwidth.

The future is bright

C#/.NET support on the Web and file compression are two important features that will come to the platform. These features will push the limits of what can be done by Godot users on the Web. I do hope that you are as excited as we are!