Dev Planet

Avatar photo

RSS feed aggregator for FOSS game development.

Dev snapshot: Godot 4.7 beta 1

The 4.7 release cycle has finally reached an ever-important milestone: its very first beta snapshot! Our users have done a phenomenal job at squashing bugs nice and early once feature-freeze set in last week, and we would further encourage those who haven’t already to shift their focus to regression fixes exclusively.

For those interested in aiding us on our quest to squash any bugs that come up during this time, we once again encourage you to join our bug-hunting sprints. Anyone interested should read the Bug Triage Introduction for more information, and join the #bugsquad and #bugsquad-sprints channels on our developer RocketChat to participate.

Please consider supporting the project financially, if you are able. Godot is maintained by the efforts of volunteers and a small team of paid contributors. Your donations go towards sponsoring their work and ensuring they can dedicate their undivided attention to the needs of the project.

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, the XR 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 Idols of Ash, a horror climbing game where you delve thousands of meters into a dark and ancient place; your presence is known, and you are not welcome. You can buy the game on Steam or itch.io, and follow the developers on Bluesky, YouTube, or itch.io.

Highlights

For those who have been following our development snapshots closely, you may be familiar with a number of the highlights in this post which were already covered in previous articles (dev 1, dev 2, dev 3, dev 4, and dev 5).

Because we’re already in feature freeze, there are no new features to cover compared to dev 5. Instead, we’ll focus on a general round-up of what to expect from Godot 4.7 as a whole, as well as expanding on some additions that we didn’t have the chance to highlight in our previous snapshots.

Breaking changes

We try to minimize breaking changes, but sometimes they are necessary in order to fix high-priority issues. Where we do break compatibility, we do our best to make sure that the changes are minimal and require few changes in user projects.

You can find a list of such issues by filtering the merged PRs in the 4.7 milestone with the breaks compat label.

  • Animation: Display and allow setting name/index of BlendSpace points (GH-110369).
  • Audio: Fix Spectrum Analyzer effect returning jittered values (GH-114355).
  • Core: Change new overloads to use a tag instead of a pointer (GH-112035).
    • Should only be relevant for modules relying on unconventional initialization methods.
  • GDExtension: Bind Object::ConnectFlags as a bitfield, instead of enum (GH-109892).
  • GDScript: Improve evaluation of constant expressions with arrays/dictionaries (GH-113228).
  • GUI: Add option to scale images in RichTextLabel relative to font size (GH-112617).
  • Input: Add device IDs to keyboard and mouse input events (GH-116274).
  • Jolt Physics: Add ability for Area3D to detect/influence SoftBody3D (GH-114198).
    • Area3D will now report overlaps with SoftBody3D when using Jolt Physics, so might require re-adjusting collision layers/masks if undesireable.
  • Jolt Physics: Make SoftBody3D default mass 1 kg and fix stiffness conversion (GH-116041).
    • Fixes a number of issues, and makes things more consistent with Godot Physics, but will require re-adjusting the parameters of all SoftBody3D instances.
  • Particles: Fix angular velocity (GH-117861).
    • Bringing the functionality in-line with how it has always been documented.
  • Platforms: Android: Remove deprecated Google Play OBB support (GH-118283).
  • Shaders: Restrict condition parsing in shader preprocessor (GH-117173).

Animation

Tomasz Chabora starts our showcase with a feature we actually neglected to mention in the dev 2 blog post: AwaitTweener. Coming from GH-79712, a PR nearly three years in the making, tweeners can now await a specific signal to emit to perform their desired action:

extends RigidBody2D
func _ready() -> void:
var tween := create_tween().set_process_mode(Tween.TWEEN_PROCESS_PHYSICS)
tween.tween_property(self, ^"modulate", Color.RED, 1.0)
tween.tween_property(self, ^"freeze", false, 0)
tween.tween_await($"../Area2D".body_entered).set_unbinds(1)
tween.tween_callback(queue_free)

Malcolm Anderson gave the animation track editor some love in GH-113479, enabling users to collapse groups. This simple change should immediately resonate with users dealing with the absurd sizes animation trees can reach, though the benefits can be felt at all sizes.

And more:

  • Animation: Optimize Animation Resource, Library, Mixer, and Player (GH-116394).
  • Animation: Optimize AnimationTree, Improve internals & Editor & Node::process_thread_group safety (GH-117277).

Core and buildsystem

A collective effort has been taken towards reducing compilation times across the codebase. Spearheaded by Lukas Tenbrink in this tracker, the speed at which builds complete has dramatically improved! Special thanks to Rémi Verschelde, Thaddeus Crews, and Enzo Novoselic for not only contributing to this cause, but helping improve our tooling and detection methods. While this sort of thing is hard to showcase in a blog post, we hope that anyone who compiles the engine directly has enjoyed these benefits firsthand.

And more:

  • Buildsystem: SCons: Enable wasm64 support on web builds (GH-102378).
  • Improve thread-safety of Object signals (GH-117511).
  • PCKPacker: Add method to add files from buffer (GH-108830).
  • Use TRACY_ON_DEMAND by default for Tracy integration (GH-117583).
  • Audio: Revamp audio bus UI (GH-118266).

Editor

Gustavo Jaruga Cruz gave the 3D editor some love in the form of Path3D collider snapping with GH-102085. Now when creating and editing paths, you have the option of snapping those paths to whatever collider the mouse is hovering over, rather than simply dropping a point in space arbitrarily. As demonstrated in the below clip, this behavior is toggleable in the Path3D options menu.

Robert Yevdokimov continues the 3D editor streak with vertex snapping support in GH-117235. This allows you to snap the selection to nearby nodes’ vertices, which is useful for level design and ensuring everything is visually connected to neighboring nodes.

To use vertex snapping, hold B and move the mouse near the selection’s vertices. Once you see a yellow circle, hold the mouse button and move the mouse to the desired location (you can release B at this point). The circle becomes green once a vertex to snap to is detected near the mouse cursor. For better depth perception, the yellow/green circle appears with reduced opacity if it’s occluded by another surface.

Vertex snapping works differently depending on whether the selected node has a mesh-based representation or not. For example, MeshInstance3D and CSG nodes have a mesh-based representation, while other nodes such as Label3D and Marker3D do not. Nodes without a mesh-based representation will teleport to the highlighted vertex when holding B and clicking on another node’s vertex. Thanks to the follow-up contribution GH-117380, you can opt into this behavior for nodes that have a mesh-based representation too.

Raphaël Daubelcour’s work in GH-111469 brought a highly-requested feature for the editor to life: the ability to copy and paste data from entire sections and categories. Now instead of copying the data from individual segments of a given property and pasting them piece-by-piece, this process is now handled in a singular action.

Malcolm delivered yet another highly-requested feature in the form of monospaced code names (GH-112219). You’d be surprised by just how much the readability of the UI improves when code-like data (methods, signals, properties, etc.) is represented in a font representing their context, especially when coupled with a standard font for all other information.

Monospaced fonts in connection
Monospaced fonts in property
Monospaced fonts in connection

The previous behavior can be restored by toggling Interface > Theme > Use Monospace Font for Editor Symbols in the Editor Settings.

Jayden Sipe improved the remote scene tree view by adding class names in GH-115738. This means that, instead of anonymous-looking Object IDs, users can now view the objects directly.

Before

Object ID shown in the remote inspector, without class name indication

After

Class names shown in the remote inspector, with object ID still visible

Michael Alexsander has been hard at work bringing our asset store updated visuals and API in GH-112992. Not only will it be easier to parse the asset items themselves, but more metadata and the current rating will be readily visible.

Showcase of the polished asset item display

When accessing an asset in isolation, you’ll have immediate access to the current description and all existing changelogs. What’s more, the ability to change an asset’s version is now just one click away.

Showcase of an asset item in isolation

Michael’s work didn’t stop there, as MeshLibrary received a similar QOL update in GH-112992, in the form of an entirely new bottom editor. Items are now featured on a grid with search and zoom functionality, alongside a separate inspector enabling the customization of individual items. Full undo/redo support for all actions, as well as previews falling back to an item’s mesh if nothing is specified, makes this a complete package out-of-the-gate.

New GridMap MeshLibrary editor

For a long time, Godot has been lacking some way to easily place objects in 2D scenes. While scene tiles exist in TileMap, they come with numerous limitations, the most prominent one being no way to change properties of the placed scenes.

Dexter with GH-109360 introduced the new Scene Paint tool, which allows easily painting scenes. You can quickly paint and erase scene instances, with support for grid snapping. The instances can also be pre-configured in the inspector, so it’s easy to place rotated instances and other similarly complex configurations.

Tomasz brings this behemoth of a section to a close with two final QOL goodies. The first is a simple but obvious improvement to how arrays are displayed in the inspector with GH-118008, ensuring that whitespace isn’t wasted.

Old New
Original inspector array display Updated inspector array display

The second is an improvement to how export templates are received in the editor, as it’s been a long-standing pain point that they must be downloaded in bulk. Alex2782 discovered a clever workaround clever workaround to this by retrieving slices of the bulk package itself, which was then ported over to C++ by Tomasz in GH-117072. With this, the only downloaded export templates are what the developer explicitly requests.

And more:

  • 2D: Add a scene painter tool (GH-109360).
  • 2D: Rework TileSet editor proxy objects (GH-117574).
  • 3D: Add “Follow Selection” in the 3D editor by using Center Selection twice (GH-99499).
  • 3D: Add automatic smoothing for CSG nodes (GH-116749).
  • 3D: Add vector components to 3D ruler tool (GH-106785).
  • Add View3DController for editor 3D view manipulation (GH-115957).
  • Add 3D vertex snap base setting (Vertex/Origin) (GH-117380).
  • Add a script editor keyboard shortcut to show the documentation tooltip for the word the caret is on (GH-115767).
  • Add folding to the Visual Profiler tree (GH-118120).
  • Add type filters to create dialog (GH-111518).
  • Add vertex snap support for subgizmo points (GH-117922).
  • Depict version discrepancies in Project Manager (GH-111528).
  • Generate and display documentation for the properties generated by PropertyListHelper (GH-115253).
  • Hide renderer selector in main editor window and add editor setting (GH-117754).
  • Improve appearance of built-in help (GH-107597).
  • Improve Remote/Local SceneTreeDock buttons’ appearance (GH-118192).
  • Make right-clicking on unfocused scene tabs possible (GH-112919).
  • Optimize tree size computation and the scene tree dock filter (GH-110759).
  • Reorganize Output dock (GH-112690).
  • Revamp autoload creation (GH-91124).
  • Show custom class name in the remote inspector (GH-108208).
  • Stop autocomplete from eating words by default (GH-117464).
  • Support folding, groups, and subgroups in remote scene inspector (GH-117357).
  • Support navigating to the script in list (GH-112796).
  • Take custom type of parent scripts into account when dropping onready variables (GH-115158).

GDExtension

GDextensions can now be viewed in the editor directly. Thanks to Aaron Franke in GH-118063, users are now able to view any of their installed GDExtensions in a new project setting tab. As an added convenience, users are capable of reloading the extension directly from this window, which should even further streamline workflows.

Showcase of an installed GDExtension in the project settings

And more:

  • Add Variant::get_type_by_name to GDExtension Interface (GH-117160).

GDScript

Danil Alexeev tackled a long-time annoyance of non-exported enums reverting to integers during remote play sessions. Thanks to GH-115705, metadata is now fully retained for all declared variables, regardless of their export status.

Before After
Remote Tree Inspector enum before Remote Tree Inspector enum after

And more:

  • GDScript: LSP: Calculate simple string insertions on the server-side (GH-117710).

GUI

One of the most long-awaited features in Godot’s GUI system was to be able to translate, rotate, or scale a Control node without it affecting the rest of the container. Previously, Godot’s various Container nodes applied the position, rotation, and scale to their children, which meant losing any changes made to the children’s transform when the container is sorted again (which occurs when children are added, removed, or moved in the scene tree). The new transform offset properties implemented by Timo Schwarzer in GH-87081 aimed to address this limitation in a self-contained manner, similar to the transform property in CSS.

Render transform properties in the inspector

You can choose whether the transform offset affects mouse input. By default, the transform offset is purely visual, which means there is no risk of buttons losing their hover status after being transformed. Controls with a transform offset applied show their original bounding box with a gray dotted rectangle:

Another longstanding usability quirk was popups with dozens of options to choose from lacking any proper filtering beyond a rudamentary incremental search that lacked visual feedback. Alexander Streng added search bars to PopupMenu in GH-114236, making searching through massive lists more dicoverable, consequently improving usability. This feature is available in any PopupMenu node, which means it can also be used in projects such as non-game applications.

vaner spear-headed GH-112993 in order to improve the overall usability and intuitiveness of Tree drag-and-drop functionality. Now when performing a drag-and-drop operation, there will be an always-present vertical indicator showing the potential parental chain, leveraging a standalone CanvasItem to prevent StyleBox occlusion.

Old New
Original drag-and-drop behavior Updated drag-and-drop behavior

What’s more, this operation will now consider the x-position of the cursor while determining a to-be parent when in indent space (leftmost, empty space), whereas item space largely retains current behavior. This implementation mirrors what one would commonly find in vector design software.

Malcolm closes out this section with GH-112617, enabling RichTextLabel images, allowing width and height to specify em for their scaling. This would result in the following text…

Do you have any [img height=1em]coin.png[/img] coins?
...I said, [font_size=50]DO YOU HAVE ANY [img height=1em]coin.png[/img] COINS??[/font_size]

…displaying like this:

Showcase of the new `em` scaling for `RichTextLabel`

And more:

  • Add custom_maximum_size property to Control (GH-116640).
  • Add accessibility region role for landmark navigation (GH-114449).
  • Add conic gradient to GradientTexture2D (GH-115394).
  • Add script editor join_lines keybind (GH-111547).
  • Add triple-click paragraph selection to RichTextLabel (GH-116868).
  • Improve the table in RichTextLabel (GH-116277).
  • Support tiling AtlasTexture in TextureRect (GH-113808).

Input

One of the earliest additions to the 4.7 development cycle came from Kazox61 in GH-110933, delivering a built-in solution for handling touchscreen “joystick” inputs with VirtualJoystick.

JOYSTICK_FIXED: The joystick doesn’t move.

JOYSTICK_DYNAMIC: The joystick is moved to the initial touch position as long as it’s within the joystick’s bounds. It moves back to its original position when released.

JOYSTICK_FOLLOWING: The joystick is moved to the initial touch position as long as it’s within the joystick’s bounds. It will follow the touch input if it goes outside the joystick’s range. It moves back to its original position when released.

And more:

  • Add device orientation change signal to DisplayServer (GH-115434).
  • Add haptic feedback on long-press right-click in the editor (GH-117198).
  • Add project setting to ignore joypad events if the app is unfocused (GH-115119).
  • Add support for joypad motion sensors (GH-111679).
  • Add support for SDL3 joystick input driver for iOS (GH-114316).
  • Wayland: Implement touch support (GH-113886).

Physics

Szunami gives 2D some love with GH-104736, adding one-way collision direction for CollisionShape2D. While they’ve always technically supported one-way collisions, they’ve been hardcoded to “up”. This has now been changed to resolve across all directions, ensuring that more complex logic like rotating platforms are properly accounted for.

One-way collisions: old behavior

One-way collisions: new behavior

Platforms

Android

Thanks to the work of Fredia Huya-Kouadio in GH-114505, Godot now has the ability to run a project and move it to a small window pinned to one of the screen corners. This relies on Android’s native support for picture-in-picture (PiP) display. For example, YouTube on Android uses this functionality to show the currently played video in a corner of the screen.

Applications cannot be interacted with during picture-in-picture mode, so this feature is most useful for applications and games that have sections that don’t require real-time input (idle games, autobattlers, etc.).

Anish Kumar in GH-117109 brought the ability to switch to portrait mode while in the script editor on Android devices. This makes it easier to view code while you’re typing on a virtual keyboard. Note that distraction-free mode must be enabled for this to be possible (it can be toggled). This restriction has to be in place, since the side docks take a lot of horizontal space and the script editor in portrait mode wouldn’t be practical with the side docks visible.

Anish continues with GH-118417, bringing support to resize and reposition an embedded game window to Android. The aspect ratio is locked by default, but can be switched to “free” mode using an on-screen checkbox (demonstrated below).

And more:

  • Add support for plugins gradle platform dependencies (GH-115888).
  • Allow implementing java interfaces from GDScript (GH-115498).
  • Enable native file picker support on all devices (GH-115257).
  • Export: Add export options to customize splash screen (GH-114671).

Windows

We’re about to get into the weeds of HDR, so we need to highlight the bullet we dodged thanks to the efforts of bruvzg. To comically oversimplify: the cost of HDR output on Windows would’ve been exorbant, unless we managed to integrate support for the C++/WinRT interface. However, this integration would’ve only been feasible in C++20, whereas the Godot codebase uses C++17 at time of writing. So similar to what we’ve done for our metal renderer, bruvzg created GH-116349 to isolate the relevant Windows code to C++20, while keeping the rest of the codebase untouched. Long story short: it worked like a charm!

And more:

  • Use OneCore/WinRT emoji picker when available (GH-116351).

Rendering and shaders

Perhaps the posterchild for 4.7 overall: HDR support. This was not something highlighted in a single development snapshot; rather, of every 4.7 blog post to date, all but one have showcased incremental support for HDR! Windows support in GH-94496 by Josh Jones, Alvin Wong, and Allen Pestaluky; Apple support in GH-106814 by Stuart Carnie; and Linux and BSD support in GH-102987 by ArchercatNEO.

There’s so much to cover in fact, that it would warrant a wholly dedicated blog post. So in case you missed it, we would strongly encourage checking out yesterday’s article highlighting HDR output. The following comparison screenshots are lifted from that article directly.

These HDR images are best viewed on an HDR-compatible device and browser with brightness set to 50%. As of writing, Firefox does not support HDR images.

Standard dynamic range (SDR)

SDR screenshot of demo scene

High dynamic range (HDR)

HDR screenshot of demo scene

Antonio Caggiano laid the groundwork for raytracing with Vulkan in GH-99119. The complexity involved with bringing this to life goes well beyond the scope of this blog post (and well over my head for good measure), but users of all skill levels can see the benefits firsthand in his demo project showcasing this new functionality via GDScript.

Colin O’Rourke implemented a long-awaited DrawableTexture implementation in GH-105701. With this new class, users now have a simple API layer to abstract away all the technical noise and give users of all skill levels a convenient way to draw on a texture directly.

The above clip footage was taken from this demo project by Bastiaan Olij.

Hugo Locurcio has been refining GH-79731 over the course of nearly three years to bring one of the most anticipated integrations for our rendering system: nearest-neighbor scaling for 3D viewports. This will ensure that 3D titles with pixel-art aesthetics or lower resolution scaling will still look crisp without any compromise to performance:

Bilinear

A sample scene with bilinear filtering, results are blurry

Nearest (new behavior)

A sample scene with nearest-neighbor filtering, results are crisp

Emil Dobetsberger’s work in GH-108219 delivered rectangular area light sources. By leveraging the new AreaLight3D, it’s now possible to render real-time light from a rectangle in 3D space.

Showcase of rectangular light sources 1

Showcase of rectangular light sources 2

Showcase of rectangular light sources 3

Yuri Rubinsky rounds us off with a shader highlight with his work in GH-117726 bringing inline previews. This is a C++ implementation and improvement of Godot Shader Previewer, a popular addon written in GDScript by Cashew OldDew. Much like the addon before it, this aims to reduce the amount of guesswork when constucting text shaders, as now one can readily see the resulting effects within the text editor itself:

Showcase of the text shader inline preview on a simple selection

Showcase of the text shader inline preview on a more specialized selection –>

And more:

  • Change embedded window options to use three stacked dots and add HDR info (GH-118079).
  • Refactor raytracing pipelines (GH-118044).
  • Rendering: Clearcoat improvements and fixes (GH-111464).
  • Rendering: Give every pass its own unique environment uniform buffer (GH-115177).
  • Rendering: Metal: Refactor; fix dynamic uniforms; acyclic render graph support (GH-114484).
  • Rendering: Vulkan: Update all components to Vulkan SDK 1.4.335.0 (GH-114075).
  • Rendering: Editor additions for MipMaps and rd_textures (GH-109004).
  • Rendering: Add fast path to Polygon2D (GH-117334).
  • Rendering: Add scale 3D and rotation 3D in particle process (GH-112447).
  • Particles: Fix particles moving when timescale is 0 (GH-109911).

Changelog

309 contributors submitted 1265 fixes since the release of 4.6-stable. See our interactive changelog for the complete list of changes. You can also review changes since the 4.7-dev5 snapshot, for a more curated selection of 85 fixes from 47 contributors.

This release is built from commit 1c8cc9e7e.

Downloads

Godot is downloading…

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


Make a Donation

Close this popup

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

During the beta stage, we focus on solving both regressions (i.e. something that worked in a previous release is now broken) and significant new bugs introduced by new features. You can have a look at our current list of regressions and significant issues which we aim to address before releasing 4.7. This list is dynamic and will be updated if we discover new showstopping issues after more users start testing the beta snapshots.

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.

  • New AssetStore API fails to load if incorrect url is cached (GH-118755).
  • System an hard freeze when opening a project with Vulkan as renderer (GH-116414).
  • Android: Crash on startup when VisualShader has vertex_lighting enabled (GH-116990).

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 in 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 platform managed by Godot Foundation. There are also several alternative ways to donate which you may find more suitable.

Donate now

Dev snapshot: Godot 4.7 dev 5

As is tradition at this point: feature freeze arrived, and so too did countless last-minute pull requests from contributors. So despite the previous development snapshot releasing just one week ago, there’s no shortage of brand-new goodies ready to be experienced firsthand!

Please consider supporting the project financially, if you are able. Godot is maintained by the efforts of volunteers and a small team of paid contributors. Your donations go towards sponsoring their work and ensuring they can dedicate their undivided attention to the needs of the project.

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, the XR 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 Lost Wiki: Kozlovka, a detective game where you explore a Wikipedia-esque database to solve a small-town mystery in 90s Eastern Europe. You can buy the game on Steam, and follow the developer on Bluesky, YouTube, or itch.io.

Highlights

Assetlib: Port asset store to new API

Did you know we have an overhaul to our asset store in the works? Well… Now you do! Michael Alexsander has been hard at work bringing our current system into this new paradigm, culminating in GH-112992 fully supporting the new API. While we hope to showcase details on this new system in the future, for now we’ll simply highlight the more obvious improvements that this PR delivers.

Starting with the main selection screen, the way we display our asset items has been polished. Not only will it be easier to parse the asset items themselves, but more metadata and the current rating will be readily visible.

Showcase of the polished asset item display

When accessing an asset in isolation, you’ll have immediate access to the current description and all existing changelogs. What’s more, the ability to change an asset’s version is now just one click away.

Showcase of an asset item in isolation

Editor: Rework export template dialog to allow individual templates

A long-standing pain point for anyone that’s worked with export templates has been that they must be downloaded in bulk. This was in contrast to how our editor downloads were always isolated, causing the export templates to incur long download times for a range of platforms that aren’t necessarily relevant to a developer’s intended export targets.

This could be achieved in two main ways: overhauling our existing distribution system to make the packages available in isolation, or somehow repurposing the existing bulk distribution to only distribute a subset of options.

Despite how absurd it sounded, Tomasz Chabora managed to implement the latter! GH-117072 managed the seemingly-impossible task of hijacking the bulk package and retrieving slices of the developer’s choosing. This is all achieved within the Godot editor itself, making the process as seamless and expedient as possible for users.

GUI: Enable scaling images relative to font size in RichTextLabel

Malcolm Anderson brings new life to [img] tags in RichTextLabel with GH-112617. Now width and height can specify em for their scaling. This would result in the following text…

Do you have any [img height=1em]coin.png[/img] coins?
...I said, [font_size=50]DO YOU HAVE ANY [img height=1em]coin.png[/img] COINS??[/font_size]

…displaying like this:

Showcase of the new `em` scaling for `RichTextLabel`

Shaders: Implement inline text shader previews

A long-awaited quality-of-life addition to the text shader editor comes courtesy of Yuri Rubinsky, with his PR GH-117726 bringing inline previews. This aims to reduce the amount of guesswork when constucting text shaders, as now one can readily see the resulting effects within the text editor itself:

Showcase of the text shader inline preview on a simple selection

Showcase of the text shader inline preview on a more specialized selection

Rendering: Add rectangular area light source

Rendering has received a lot of love in these snapshots, and we’re ending things off strong with Emil Dobetsberger’s work in GH-108219 delivering rectangular area light sources. By leveraging the new AreaLight3D, it’s now possible to render real-time light from a rectangle in 3D space.

Showcase of rectangular light sources 1

Showcase of rectangular light sources 2

Showcase of rectangular light sources 3

And more!

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

  • 3D: Add vertex snap support for subgizmo points (GH-117922).
  • Audio: Revamp audio bus UI (GH-118266).
  • Editor: Allow moving and resizing the embedded game window on Android (GH-118417).
  • Editor: Improve Remote/Local SceneTreeDock buttons’ appearance (GH-118192).
  • Export: Android: Add export options to customize splash screen (GH-114671).
  • GDExtension: Add Variant::get_type_by_name to GDExtension Interface (GH-117160).
  • Input: Wayland: Implement touch support (GH-113886).
  • Platforms: Change embedded window options to use three stacked dots and add HDR info (GH-118079).
  • Rendering: Refactor raytracing pipelines (GH-118044).

Changelog

71 contributors submitted 135 fixes for this release. See our interactive changelog for the complete list of changes since 4.7-dev4. You can also review all changes included in 4.7 compared to the previous 4.6 feature release.

This release is built from commit a8643700c.

Downloads

Godot is downloading…

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


Make a Donation

Close this popup

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

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.

There are currently no known issues introduced by this release.

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 in 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 platform managed by the Godot Foundation. There are also several alternative ways to donate which you may find more suitable.

Donate now

Dev snapshot: Godot 4.7 dev 4

As we edge ever closer to feature freeze, many of our contributors have been hard at work to get their highly-anticipated features in hopes of Godot 4.7 integration. Fortunately for them, we’ve managed to accomodate several of these proposals, and are excited to showcase them today! Your testing will be crucial to ensure that everything listed stays in scope for a 4.7 release, so be sure to give this latest build a spin after the highlights

Please consider supporting the project financially, if you are able. Godot is maintained by the efforts of volunteers and a small team of paid contributors. Your donations go towards sponsoring their work and ensuring they can dedicate their undivided attention to the needs of the project.

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, the XR 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 Poke ALL Toads, a puzzle game starring mischievous fairies on a queat to poke ALL toads. You can buy the game on Steam, and follow the developer on Bluesky, YouTube, or itch.io.

Highlights

Rendering: Add nearest-neighbor scaling

We’re starting things out with one of the most anticipated integrations for our rendering system: nearest-neighbor scaling for 3D viewports. Over the course of nearly three years, Hugo Locurcio has been refining GH-79731 to ensure that 3D titles with pixel-art aesthetics or lower resolution scaling will still look crisp without any compromise to performance:

Bilinear

A sample scene with bilinear filtering, results are blurry

Nearest (new behavior)

A sample scene with nearest-neighbor filtering, results are crisp

GUI: Add custom_maximum_size property to Control

Our previous development snapshot had a large focus on GUI improvements, and that QOL continues with the new custom_maximum_size property for Control. Enzo Novoselic in GH-116640 has at last brought us the maximal equivalent to the existing custom_minimum_size, enabling the fine-tuning of GUI element sizes to their full potential.

GUI: Improve drag and drop in Tree

vaner spear-headed GH-112993 in order to improve the overall usability and intuitiveness of Tree drag-and-drop functionality. Now when performing a drag-and-drop operation, there will be an always-present vertical indicator showing the potential parental chain, leveraging a standalone CanvasItem to prevent StyleBox occlusion.

Old New
Original drag-and-drop behavior Updated drag-and-drop behavior

What’s more, this operation will now consider the x-position of the cursor while determining a to-be parent when in indent space (leftmost, empty space), whereas item space largely retains current behavior. This implementation mirrors what one would commonly find in vector design software.

Editor: Increase available space for array properties

Have you ever wondered why the inspector takes up so much negative space when working with arrays? Turns out it wasn’t done deliberately; it just so happened to be using the default offset of 0.5! Tomasz Chabora rightfully found this quite silly, and whipped up GH-118008 to rectify this oversight.

Old New
Original inspector array display Updated inspector array display

And more!

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

  • 2D: Rework TileSet editor proxy objects (GH-117574).
  • 3D: Add vector components to 3D ruler tool (GH-106785).
  • Editor: Add folding to the Visual Profiler tree (GH-118120).
  • Editor: Add type filters to create dialog (GH-111518).
  • Editor: Hide renderer selector in main editor window and add editor setting (GH-117754).
  • Editor: Make right-clicking on unfocused scene tabs possible (GH-112919).
  • GDExtension: Allow viewing GDExtensions from inside project settings (GH-118063).
  • GDScript: LSP: Calculate simple string insertions on the server-side (GH-117710).
  • Particles: Fix angular velocity (GH-117861).
    • NOTE: This is technically compatibility-breaking, but it’s bringing the functionality in-line with how its always been documented.
  • Particles: Fix particles moving when timescale is 0 (GH-109911).
  • Platforms: Android: Allow implementing java interfaces from GDScript (GH-115498).
  • Platforms: Windows: Implement OneCore TTS support using C++/WinRT (no deps) (GH-116349).
  • Platforms: Windows: Use OneCore/WinRT emoji picker when available (GH-116351).

Changelog

88 contributors submitted 188 fixes for this release. See our interactive changelog for the complete list of changes since 4.7-dev3. You can also review all changes included in 4.7 compared to the previous 4.6 feature release.

This release is built from commit 755fa449c.

Downloads

Godot is downloading…

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


Make a Donation

Close this popup

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

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.

There are currently no known issues introduced by this release.

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 platform managed by Godot Foundation. There are also several alternative ways to donate which you may find more suitable.

Donate now

Godot Showcase – Xogot: Godot for iPad & iPhone

We’re happy to showcase a project that released last year, but was long in the making. The folks at Xibbon have been working hard to port the Godot Engine to the iOS platforms. Not only did they port the editor to make it run on iOS, they successfully interfaced the editor with a custom iOS interface in order to make the engine match Apple strict UI and UX guidelines. Using their app on the iPad and iPhone feels totally native, because it is!

Xibbon has been active in our community, in terms of code contributions and events. Xibbon has been our sponsor at events, such as the first GodotCon in the US!

Today, Miguel de Icaza, known for starting the GNOME, Mono, and Xamarin projects, is sharing with us his experience developing his iOS app.


Can you tell us a little bit about your project?

Screenshot of Xogot running on an iPad.

Xogot brings the Godot Editor to the iPad and the iPhone as a native iOS application.

Xogot uses the Godot Editor and the Godot Engine, but we provide an alternative user interface and shell that is built on top of Apple’s native user interface elements. We tuned the user experience to be both touch friendly and to work with the more limited screen space on these devices.

By being a new user interface on top of the existing Godot Editor, we remain compatible with the desktop Godot and users can move seamlessly between the platforms, but we also wanted to make a product that truly belonged on the iPad, not merely running the desktop experience on the iPad.

While I am an engineer, the joy that I derive from using creative apps on the iPad is unmatched.

Interacting with the world with our fingers is one of the earliest skills that we acquire as babies – and I find the physical feedback of using touch user interfaces to be very rewarding. Not only do I spend hours playing with my iPad, I also love watching creators use their iPads for sketching, drawing, modeling, composing, editing videos, and building games.

Why did you want to build Xogot?

Xogot is very much a labor of love, the result of a perfect storm of conditions and a way of expanding our own horizons and getting out of our comfort zone.

We have worked on the mobile world for almost fourteen years, and built developer tools for helping .NET developers target mobile platforms. Mostly building IDEs and tools and supporting others on their adventures to bring software to users (among those, funding the early effort to bring .NET to Godot).

We wanted to get out of our comfort zone, and build an end-user product that followed the ethos of iOS developers that obsess over highly polished apps. Products that obsess over the details of the user experience and strive to create delightful user interfaces.

For almost sixteen years we have helped folks in the game industry adopt .NET for game development, and we supported various games, engines, and hardware vendors with their efforts to bring our compilers and tools to their systems. Just like we were inspired by the iOS community, we are inspired by the game developer community – people pouring their hearts out exploring ways of entertaining and surprising us, and we wanted to get closer to this joyful world.

Lastly, we all witnessed a major turning point in the game-engine industry when Unity’s leadership made decisions that shook developer trust across the community. We watched as the industry rushed to find alternatives – and being emotionally invested already in Godot, we were very much in the camp “How can we give the Godot community an edge?”.

What was challenging about bringing the Godot Editor to the iPad and iPhone?

Screenshot of Xogot running on an iPhone.

This is the poster child of a slippery slope, or an extreme case of Yak Shaving.

There are three buckets of challenges:

  • Multi-process
  • User experience
  • Embedding

At first, we figured “How hard could it be to get Godot on the iPad?” and it turned out that running Godot on iPad was quite simple, but comes with some strings attached. The first thing you have to deal with is that the Godot workflow uses three processes: the home screen that creates new fresh Godot Editors on demand, the Godot Editor itself, and every time you press “play”, a new and fresh instance of Godot.

The challenge is that iPadOS does not really support the above model where you get a fresh new process for each step, instead you get a single process and you get to live there. Without being able to launch a new project, Godot would have worked, but would not have been very interesting to people.

We first experimented with a proof of concept which was to reset the state of Godot to one of a fresh process. That worked, and it allowed us to edit one game, and then edit a second one. We called this the “reset state” effort. That was still not quite useful. The second stage was to make the editor run a child process, and for that what we did was to “virtualize” every single global variable in Godot, so we could run multiple instances simultaneously. That turned out to work great, but it relied on a very manual process of editing a very large chunk of Godot to remove every access to globals and static variables. We later invested in a clang-based rewriter that would take an existing Godot codebase and produce a virtualized Godot on demand. This is what we are based on now.

With the above system we could open multiple projects, but also start and stop the game under development over and over. So we were now cooking with gas. One last component was not just to launch separate instances of Godot, but having those run side-by-side, which was necessary to implement debugging over a “virtual” process that happened to be running on your same address space.

We took the limitations of the platform as a fun challenge to solve, and I am incredibly proud of the result.

That was a very satisfying technical problem to solve, but it did not lend itself to a great iPad experience. Godot is designed for a desktop computer where you have a lot of space, and you can easily aim your mouse at small user interface elements. On the iPad and iPhone, Apple recommends that elements are at least 44 points in size for users to be able to interact with them comfortably. In fact, every time I thought I could get away “just this time” with a smaller user interface, I found out the hard way that neither our users nor myself could tap it. We repeatedly learned that lesson.

44 points.

It is now hanging on a printed piece of paper next to my desk, so I do not forget.

But even if we resized the controls, the user interface did not feel good on the iPad. Godot was clearly intended to be used with a mouse and a keyboard, so we set out to solve the most problematic areas for our users. Some were mechanical, like “make this button larger” or “display this elsewhere”, but some were more philosophical. In my previous experience with the GNOME desktop, we pursued a path similar to Godot. That is, we tried to deliver a user interface, but whenever there were disagreements about the intended behavior, rather than making an editorial or design decision, we offered a choice. Or three. Or four. Or five, or as many choices as there were opinions.

Offering choices sounds great on paper, but is terrible in practice. Options can paralyze users, but each option forces you to test two codepaths – and that is if you are lucky, if you have options that interact with other options. Now you have to test combinations of those features, and so on. And then you get to document all these combinations.

We wanted an application that lived up to the ethos of great iOS applications. We felt that we had to act as editors and make design choices that surfaced the right defaults, and we opted to only surface what we felt was necessary.

Overall, I think that we did a pretty good job, but every once in a while, our users would complain and make a case for why they really needed an option. So, in those cases, we have brought back a level of configuration or re-surfaced elements that were previously not shown.

Our design process was documented in our blog, and you can see our process and some of the iterations on the concepts over time.

We initially thought we would only touch on a couple of pieces, the scene pad, the file pad – and over time we found ourselves rewriting almost all of the user interface in Godot, both because it felt so much better, but also as users struggled with different parts of the UI. This is a process that has been both extensive, but also quite enjoyable – as SwiftUI has made this a delightful exercise.

At first, we just layered a new UI on top of the Godot Editor, and we customized Godot to show fewer UI elements when running. This served us well for a while, but at some point we found ourselves needing to “host” parts of the Godot UI in SwiftUI views that we controlled, like the bottom bar panels, the plugins that render inside the inspector, as well as having a fallback for custom Godot user interface code – and for that we used a system that allows us to “rehost” parts of the Godot UI – but having this was important to fully take control of the user experience, while ensuring that everything you need to work with Godot was still there.

Adapting Godot from a desktop application into a pleasant, touch-first, iPad application was a lot of work, and we were convinced there was no more shrinking or adjusting in our future. But even during the beta period before we launched the iPad version, our testers kept asking us for an iPhone version. We were not convinced that this was necessary, but our users kept telling us all the reasons why they would want this – tuning their apps, experimenting on the go, testing an idea during small breaks, adjusting some properties of their game during their bus or train ride or during their lunch breaks.

But there is a big gap between what people tell you they want and what they are actually going to do, so we remained skeptical for a long time. The first time we reconsidered this was when we heard a presentation from Chad Stewart on using Godot on Android where he shared his real-life experiences doing his work on the go. Then the Godot foundation shared information about usage of Godot on Android, on phones and tablets – and it was then that we grasped that for some folks their phone is their sole computing device. So not only was this possible, for some folks it was a necessity.

So, delivering the full Godot Editor on iPad and iPhone has meant more than just porting a desktop app. To meet App Store requirements and match Apple users’ expectations, we rebuilt the interface to be truly native and touch-first – something that feels at home on touch devices rather than adapted for it.
Xogot has been a multi-year effort and a significant engineering investment. It’s a commercial product created by a small team deeply passionate about both Godot and Apple platforms. Xogot includes a free tier open to everyone, with the complete version provided at no cost to students and contributors to the Godot open-source project.

What are the biggest differences between the Xogot and the Godot Editor?

Xogot has two major limitations. First, it can not run third-party plugins authored in native code, or run .NET code. The reason for the former is that Apple’s security system does not allow for third-party dynamic code to be loaded into a process, so all of these plugins fail.

And the ability to run .NET code is not something we have worked on.

Considering the improvements made to adapt to the new form factor, are there any plans on bringing Xogot to other platforms?

By default, when launching the game from the Xogot Editor, the game launches in a split screen.

We want to bring Xogot to the Apple Vision Pro. Anecdotally, just before we decided to embark on bringing Godot to the iPad, we were working on building frameworks and games for the Vision Pro. We were going to our first Boston Unity meeting to learn more about Unity and Vision when the Boston Unity group disbanded in response to Unity’s license changes. It was in this turmoil that we were inspired to jump headlong into the Godot world.

The idea of building and testing immersive experiences directly inside the headset feels like a natural extension of what we have done so far – creating something with your hands, right in front of you, makes the process feel immediate and physical. But like the iPad effort, there are a number of very interesting problems to solve there before we can ship a product that would meet the expectations of users, so we are going to have to work through those.

We don’t currently have plans to bring Xogot to non-Apple platforms. Our focus right now is on delivering the best possible experience on iPhone and iPad, and continuing to refine what it means to build games natively on Apple’s devices. So you will see us iterating on the experience and incorporating user feedback until we can score ourselves one of those Apple Design Awards.

That said, Godot already runs on many platforms, and we see Xogot as part of that larger ecosystem. For now, our aim is to deliver a great experience to game developers on the Apple platforms, and to maintain a high level of compatibility with Godot so that both environments can complement each other.

Were there some improvements made in Xogot that made it upstream?

Our biggest contribution so far has been the LibGodot effort, which is a major investment we’ve been funding with the development work led by Migeran. LibGodot makes it possible to embed Godot inside modern applications, and Migeran is now in the process of getting it upstreamed so it can benefit the broader community.

We’ve also contributed a number of smaller patches and fixes, and we’re continuing to learn what it takes to shepherd contributions through the review and merge process. Looking ahead, we expect to contribute larger components as well. We already have a few ideas in mind. But as we’re still relatively new to the game development community, we want those contributions to be shaped by what we learn as Xogot and its user base continue to grow.

I would love to participate more directly in Godot’s workgroups and community discussions. Balancing that with running a company and raising three kids can be challenging, but I have enormous respect for the dedication and care of the Godot team. My hope is that over time we can contribute not just code, but also ideas and processes that help strengthen the community.

What’s next for Xogot?

We’re especially excited about Xogot Connect, our new open-source Godot add-on that lets developers on Windows, Linux, or macOS easily run and debug their projects on iPhone or iPad without the usual complexity of exporting to iOS, building in Xcode, or managing provisioning profiles.

Our goal is to keep expanding that bridge between desktop and mobile development. Xogot Connect already makes it simple to configure on-screen controls in your game by enabling the iOS Virtual Controller in Project Settings, and we have a few more ideas like this in the works that bring the mobile-specific affordances we’ve developed for Xogot directly to Godot developers on the desktop and make targeting mobile smoother and more approachable.


I would like to thank Miguel de Icaza for sharing with us the experience of his ride of adapting the Godot Editor specifically for a new platform.

You can easily find Xogot in the App Store or at its homepage.

Also, don’t forget to check out Xogot Connect in the Godot Asset Library. (Expect it to be also in the upcoming Asset Store!)