Engine
There are 1,666 posts filed in Engine (this is page 5 of 167).
jMonkeyEngine: jMonkeyEngine 3.8.1-stable
Dev snapshot: Godot 4.5 dev 4
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, editNode.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_v1and 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
Godot is downloading…
Godot exists thanks to donations from people like you. Help us continue our work:
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
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.
libGDX 1.13.5
Live from GodotCon Boston: Web .NET prototype
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:
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!
Fheroes2: version 1.1.8
Godot Showcase – Somar
Today we present a showcase that is a little different. We interviewed Frederic Plourde and Daniel Castellanos who used Godot to create an educational XR experience for SOMAR, a non-profit association focusing on the conservation of marine life in the Algarve.
Frederic Plourde is the XR Lead at Collabora where he drives AR/VR strategy, business development, and open-source innovation, leading a team of talented engineers working on XR customer projects and Monado, the cross-platform open-source OpenXR runtime. He is also Vice Outreach Officer at the Khronos Group where he promotes the OpenXR standard, fosters industry collaboration, and advocates for open and interoperable XR solutions. In the SOMAR project, Frederic took on a technical leadership role, overviewing the development of an immersive XR experience and leading Collabora’s efforts toward developing a Cardboard driver for Monado.
Daniel Castellanos is the owner of Decacis Studio, and was contracted by Collabora to work mainly as a programmer/developer on the SOMAR project.
Can you tell us a little more about the non-profit organisation behind the SOMAR project, who they are and what their mission is?
Fred: SOMAR is a non-profit organization that focuses on protecting dolphins, whales, and marine life in the Algarve. Their mission is to raise awareness about the impact of human activities—like underwater noise pollution—on marine ecosystems. By combining scientific research, education, and innovative technology, SOMAR promotes sustainable practices and works to preserve the region’s ocean biodiversity for future generations.
Can you tell us a bit about the XR experience you have created, and what you set out to achieve?
Fred: The XR experience developed for the SOMAR project was designed to provide an immersive, educational tool to raise awareness about the impact of underwater noise pollution on marine life. By immersing users in realistic coastal and offshore environments of the Algarve, the experience showcases the effects of noise from tourist boats, particularly whale and dolphin-watching activities. Users can witness firsthand how these essential marine mammals are disrupted in their communication and hunting activities, gaining a deeper understanding of the challenges they face. Through this interactive experience, we aimed to engage users emotionally and inform them about the urgent need for conservation efforts to protect these creatures and their habitats.
I understand the project is focused on being deployed in museums and in classrooms in Portugal. Can you tell us more about how this works?
Fred: The SOMAR project was designed with flexibility in mind and offers content in both English and Portuguese through Godot’s built-in localization functionality. Built on OpenXR, the project benefits from a standardized framework that simplifies deployment across multiple devices, allowing us to target both museums and classrooms across Portugal. In museums and institutional venues, the Meta Quest version of the XR experience offers a high-fidelity, immersive experience with detailed visuals, allowing visitors to explore the application in a captivating, educational environment. Meanwhile, the PhoneXR version, optimized for accessibility, is intended for use in classrooms, where students can experience the same core content through low-cost Google Cardboard-type phone holders. By running the open-source cross-platform OpenXR runtime Monado on those phones, this version is designed to be more accessible and straightforward, making it possible for kids to dive into XR for the first time, all while learning about conservation in an interactive way. This dual deployment strategy ensures that the SOMAR project can reach diverse audiences, from the general public to younger generations, fostering environmental awareness across different settings.
Will the experience be available to play by the general public and if so, where can they find it?
Fred: Yes — the SOMAR experience is now available for everyone to explore! 🐬 Dive into our open-source XR project and discover the impact of underwater noise pollution on marine life. You can download and try it out for free on SOMAR’s official itch.io page.
What were your main considerations in choosing Godot as the XR platform to create this experience?
Fred: One of the main considerations for selecting Godot as the game engine for this project was finding an open-source engine that could provide flexibility, scalability, and a strong support community. Godot stood out for its robust 3D capabilities, ease of use, and ability to run on multiple platforms. Godot’s open-source nature felt like a perfect match for the Monado-driven experience and our collaboration with a non-profit as part of Collabora’s 1% for the Planet initiative, reinforcing our commitment to both innovation and social impact. Additionally, Godot’s growing reputation within the XR and gaming communities, coupled with its ongoing OpenXR development via a Khronos-funded project, gave us confidence in its future-proof capabilities, ensuring that the SOMAR project could evolve and expand over time.
What was the most enjoyable part of using Godot?
Daniel: I’ve been using Godot for a few years now, and the most enjoyable part of it for me is being able to iterate quickly. Throughout its development, the project experienced numerous revisions, but implementing these changes was generally straightforward and quick.
What was the most difficult issue to overcome?
Daniel: Having a balance between creating the most realistic or immersive experience possible while having to keep the experience performant on mobile devices apart from the Quest.
Did you use any existing toolkits/plugins in developing this experience and what was the motivation behind choosing these or building your own solution?
Daniel: Not really! The project doesn’t feature movement, and user input is limited, so building a custom solution was not a problem. Furthermore, keeping the project as simple as possible was one of my goals, both to prevent bugs and keep the code clean and easy to understand.
What would you like to see evolve within Godot’s XR support that would have made building this project easier?
Daniel: There was a single bug or unexpected behavior that I found during development, but nothing that couldn’t be worked around. For this project, I believe Godot was the right choice and made things as easy as they could be.
I understand the project currently targets the Meta Quest headsets. What motivated this choice?
Fred: The Meta Quest headset was chosen for the SOMAR project due to its strong popularity, excellent performance, and ease of use. As a standalone device, the Quest 3 delivers high-quality visuals and immersive experiences without needing a PC or external sensors, making it ideal for both museum venues and broader accessibility. Its widespread presence in the XR market ensures compatibility with future updates, allowing us to reach a wide audience while providing a seamless and engaging experience.
How was the experience of using Godot with the Meta Quest?
Daniel: Awesome! I used Meta Quest Link for most of the development to quickly test things, but every once in a while I deployed the project directly into the Meta Quest to measure performance. Fun fact: the project uses the Khronos OpenXR runtime, and it worked flawlessly first time.
I also understand the project is also capable of using the Monado OpenXR runtime. Can you tell me a bit more about the motivation and goals of this port?
Fred: The motivation behind also targeting the Monado OpenXR runtime was to ensure broader accessibility and compatibility across different platforms, particularly for low-cost, phone-based VR systems. Monado’s open-source nature aligns with our goal of creating a flexible, cost-effective solution that’s not reliant on proprietary ecosystems. For this project, Collabora dedicated engineering resources to develop a new Monado Cardboard driver, which enables the experience to run on Android phones with Cardboard VR headsets, making the immersive content accessible to a wider audience, including kids and students. This port reinforces our commitment to open standards, allowing for future enhancements and maintaining the project’s long-term sustainability.
You can find the code for that driver on the [freedesktop.org GitLab]
(https://gitlab.freedesktop.org/bl4ckb0ne/monado/-/tree/cardboard-sdk). It will be upstreamed soon.
Fred, specifically for you, can you give us a synopsis of what Monado is and your perspective on the combination of using Godot with Monado?
Fred: Monado is an open-source, cross-platform OpenXR runtime designed to provide the fundamental building blocks for XR device vendors and developers. By offering compatibility with major platforms like Linux, Windows, and Android, Monado serves as a versatile foundation for creating and deploying XR applications. Combining Monado with Godot, an open-source game engine, creates a powerful synergy. Godot’s flexibility, combined with Monado’s OpenXR support, enables both the simplicity of Godot’s development environment and the vast compatibility of Monado’s runtime.
Are there any plans to bring this project to other VR headsets?
Fred: Yep, we’re currently testing the SOMAR application on other platforms and devices. Since Monado is built on OpenXR, it’s designed to be highly adaptable and should be able to run on many other platforms and devices with minimal effort. However, as an open-source project, the real strength lies in the community. While we continue to extend support for more headsets, we encourage developers and enthusiasts to contribute to the project and help expand its reach even further. The open-source nature of Monado makes it easy for anyone to pitch in and bring support to new platforms, creating a collaborative and growing ecosystem.
What’s next for you, anything interesting on the horizon?
Daniel: Sure. I’m currently working on my next game: Stellar Checkpoint, which will be available in both VR and desktop/flat modes. It should come out later this year, so stay tuned!
Finally, is there any advice you’d like to share especially to someone considering using Godot for their next XR project?
Fred: Absolutely! One of the most exciting things about using Godot for XR projects is the incredible community that surrounds it. Godot has such a passionate and supportive group of developers, artists, and creators, and it’s all accessible through platforms like the Godot Discord. If you’re just getting started with XR in Godot, I highly recommend joining the Discord first.
Daniel: Just try it. Read the official documentation, place a couple of cubes as hands and experience how easy it is to get started! And if you get stuck, there is always someone from the community willing to help. Godot scales really well, and it works for both simple and complex projects, and best of all, being open-source means you can extend it to fit your needs.
Some extra information about the organisations involved
Collabora is a global consultancy specializing in delivering the benefits of open-source software to the commercial world. Whether it’s the Linux kernel, graphics, multimedia, machine learning or XR, Collabora’s expertise spans across all key areas of open-source software development. By harnessing the potential of community-driven open-source projects, and re-using existing components, Collabora helps its clients reduce time to market and focus on creating product differentiation. To learn more, please visit collabora.com.
Decasis studio is an independent development studio run by Daniel Castellanos.
SOMAR is a non-profit association founded in 2020, dedicated to the conservation of the Algarve’s dolphins, whales, and broader marine life. With a focus on protecting the oceans, SOMAR operates through a variety of initiatives aimed at safeguarding the region’s rich biodiversity. The organization is driven by its commitment to raise awareness about the negative impacts of human activities, such as underwater noise pollution, on marine fauna. By combining scientific research, environmental education, and innovative technologies, SOMAR seeks to promote sustainable practices and inspire collective action to preserve the natural marine ecosystems of the Algarve for future generations.
