This article is from December 2022, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
The year 2022 was very special for us. We reached a lot of milestones within Godot and also in the community. This blog post will offer a small retrospective of the year.
Godot 4.0
The work of Godot 4.0 begun in 2019 when I forked it after 3.1 was released with the hopes of rewriting the rendering architecture using Vulkan as a target API. I worked on it alone for a while, while it was just a graphics fork.
But then things happen, in the years in between the community (both users and contributors) grew massively and so did our funding thanks to many generous large donations.
With more users come more demands and, suddendly, the will to use Godot for larger and more serious projects required that large parts of the core were modernized. Godot 3.x core architecture is still that of an engine of the late 2000s, when computers were single core and the difference in speed between CPU and memory was not as significant as it is today.
As a result, and with many contributors interested in improving and modernizing Godot, the goal for 4.0 became much bigger and more ambitious, and a huge amount of the engine core was rewritten, as well as GDScript.
As far as 2021, the status of the 4.0 was a mess. A lot of work was done, but almost nothing worked and so many features were unfinished. As a result, 2022 became a year of focus on stabilizing and finishing all major remaining issues.
Early in the year, we released Godot 4.0 Alpha. After it, 17 alphas followed in total. Things improved a lot, but eventually it was time to do feature freeze and focus on bug fixing. In September, the first betas rolled out and, since then, the stability of the master branch has improved enormously thanks to contributors changing their mindset to fixing bugs.
We will not end the year with a stable release, but we are very close. We are still aiming to release the first stable version of Godot 4.0 during the first months of 2023.
It is important to note, though, that as with any X.0 release, there will still be significant stability, usability and performance related issues. All these will improve significantly in the upcoming point releases (just like it happened after Godot 3.0).
First Godot Sprint after Covid
In June this year, we held our first Godot Sprint since the pandemic started (previous one being in Brussels, January 2020).
It was an excellent way to get back in touch with everyone. As much as Godot is developed very efficiently online, the main developers meeting personally is a great way to move forward with a lot of issues that are difficult to discuss online.
Even if we do online calls often, we are all very tired after an hour or two, but meeting in person is a blast where we can have fun all day discussing Godot topics.
Godot Foundation
The success of Godot is largely due to the support provided by the Software Freedom Conservancy. Thanks to them, we could receive donations, and hire contributors who work full or part time to improve the project.
As Godot continued to grow, we realized that we needed the autonomy, control, and flexibility of an organization specifically dedicated to Godot.
Because of this, the Godot Foundation was launched last month. It’s still not fully operational, as there is still some bureaucracy remaining, but the plan is to do a gradual move from the Conservancy to it during all of next year.
The 2022 showreels were published
We published our 2022 showreels, and they looks amazing! The quality and quantity of games published using Godot keep growing significantly every year. This year, we also added the tools category! Thanks to its powerful UI system and architecture, Godot is becoming a go-to platform to create applications and tools that are graphically intensive.
Social media explosion
Godot also kept growing strongly on social media, surpassing 100k subscribers on Reddit, 50k stars on GitHub and 60k followers on Twitter. Our Discord has also grown significantly.
Godot games on Steam keep growing exponentially
This year, there were several hit games published with Godot, such as Dome Keeper, Brotato or The Case of the Golden Idol. It makes us very happy that studios are starting to choose Godot more and more for developing their games.
Closing and personal note
On a personal level, this year was a turning point for me. As a Godot creator and having pushed countless hours majorly churning code for the project since its inception, this is the year where I finally stopped working on large features and moved on to helping other contributors and a more administrative role.
I worked hard towards this happening, increasingly delegating engine areas to trusted and talented contributors over the years. Nowadays, pretty much all the major areas have dedicated maintainers who understand the code better than I do.
Of course, I still help them out with feedback and code reviews and will still contribute new features from time to time but, as time passes, it is (and always was) my intention that Godot is a project that can stand on its own and thrive.
We create Godot out of love and a belief that game development should be freely accessible to everyone. By using Godot, you can have full ownership and control over the technology powering your game. If you believe in our mission and want to support us, you can become a Patreon or send a donation.
It has been a productive year, and we are grateful to have been able to share it with all of you. We look forward to seeing what the next year brings. Thank you!
And with that, the 2024 season comes to an end. What a year it has been, with the number of Godot submissions in game jams rising to new heights, more people working for the Godot Foundation than ever before, and most industry award shows featuring one if not more games made with Godot.
A busy year inside the project as well. Too much to compile into a single article, unless you want to read pages of meeting notes and technical documentation. So instead, we chose to celebrate the past by looking back at one cherry-pick per month, something you might have missed during the scuffle but is worth learning about even now.
This could be an event the team attended, a major project milestone being reached, or a fun moment online the Godot community gathered around. Likewise, we looked at the release dates of notable Godot games on Steam and decided to introduce you to some favorites alongside our own organizational news. The separate tech highlight section might even introduce you to a feature or two you missed out on so far.
But before we get started, let us sneak in an announcement: this blog post is part of our newsletter project, premiering this January. Subscribe to “The Nodeletter” to get a regular digest of Godot Engine news directly in your email inbox!
Tech Highlights
To be frank: there is no good way to summarize the work of hundreds of contributors across the span of an entire year without leaving out something important. The closest we can feasibly get are the Godot 4.3 release page, and the newly published Godot 4.4 beta 1 release notes.
For the purpose of this retrospective, we approached the engine maintainers directly, asking them to point us at one particularly compelling change they witnessed in their area of expertise. How many of these have you not heard about yet?
Nostalgia became the theme of January, as we compiled a small game showcase leading up to Godot’s 10-year-anniversary (counting from the moment the engine was first open sourced). For every year from 2014 to 2024 we shared two gems found on Steam and itch.io with the community, celebrating an ever growing list of Godot releases since the beginnings of the project.
Desktop pets have risen to new popularity in 2024. KinitoPET combines this trend with the evergreen horror genre to bring you a unique experience about virtual assistants.
February
As part of our social media expansion, we also created an official Godot Engine account on the streaming platform Twitch.
Using it to check on Godot game development streamers resulted in this funny compilation — both the content creators and their viewers expressed happiness that the communities they had built were being recognized by us.
Logically, the next step was to hand over the reins of the channel to some of these talented developers directly. You can find the takeover recordings on our YouTube.
Another twist on “gaming directly on a desktop” came in the form of the action roguelike Windowkill. The twin-stick shooter requires you to keep track of and fight the ever-closing game windows while evading enemies.
March
In March, the Godot Foundation team assembled in San Francisco to meet community members at our biggest event booth yet, in the expo hall of the annual Game Developer Conference (GDC). We shared the space with our sponsor W4 Games and an amazing lineup of Godot-powered games that we had the pleasure of inviting.
We had a great time, both on the event grounds and at our own gatherings, and made sure to recount our full experience in a retrospective blog post — see you this year?
Backpack Battles decided to make inventory management the main game mechanic. The PvP auto-battler with a medieval fantasy theme has quickly gained popularity with content creators!
Build your own settlements in Of Life and Land and experience different maps, scenarios, and rich simulations. Strategize with animals and nature in mind!
May
Did you know that we still update Godot 3? Not everyone upgraded their projects when the big codebase refresh happened last year, so by offering two versions alongside each other we aim to accommodate these existing games as well as the lower-end systems used by some developers.
The feature freeze for 3.6 happened in May, leading up to the most recent release in September.
This game about cooking eggs in a cold climate found great reception on the internet. There is just something about the frustratingly fun mechanics of Arctic Eggs that captured quite an audience — who are we to judge your taste?
June
Our annual community poll rolled around in June. We want to know who our users are, so we can learn about common needs and offer the best support possible.
This year’s poll had more responses than ever before, once again proving the incredible growth the Godot community is experiencing.
This article is from May 2017, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Learn to create your own 2d game inspired by Zelda!
GDquest is on Kickstarter again, and we’re doing this in collaboration with the Godot developers. We want to bring you the first professional course for our favourite Free and Open Source Game Engine!
For the next 30 days, get one free tutorial daily on YouTube!
Update: the Kickstarter was funded in 12 hours! There are plenty of stretch goals to unlock, including direct contributions to the Godot 3.0 documentation.
All the money will go to make the course: the higher the funding, the bigger your reward.
Back the project now and get at least 50% off the course’s price:
Previous
diff --git a/article/80-funded-celebrating-patreon-rewards-upgrade/index.html b/article/80-funded-celebrating-patreon-rewards-upgrade/index.html
index 88bdca4f03..22d0408f58 100644
--- a/article/80-funded-celebrating-patreon-rewards-upgrade/index.html
+++ b/article/80-funded-celebrating-patreon-rewards-upgrade/index.html
@@ -1,8 +1,9 @@
80% funded! Celebrating with a Patreon rewards upgrade – Godot Engine
This article is from August 2017, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Astounding and invigorating
I have to admit, the financial support that we got over the last two weeks has been astounding and reached far beyond my expectations for the launch of our Patreon campaign.
diff --git a/article/abandoning-gles3-vulkan-and-gles2/index.html b/article/abandoning-gles3-vulkan-and-gles2/index.html
index 0139e0faf8..4ba7379c6c 100644
--- a/article/abandoning-gles3-vulkan-and-gles2/index.html
+++ b/article/abandoning-gles3-vulkan-and-gles2/index.html
@@ -1,8 +1,9 @@
Moving to Vulkan (and ES 2.0) instead of OpenGL ES 3.0 – Godot Engine
This article is from February 2018, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Edit: Changed post title for clarity (previously Abandoning OpenGL ES 3.0 for Vulkan (and ES 2.0)). We are not abandoning the current OpenGL ES 3.0 backend right now: as outlined in the post, we will start working on a Vulkan backend, which will eventually coexist with the OpenGL ES 2.0 and 3.0 backends - and eventually we might deprecate the OpenGL ES 3.0 backend if Vulkan cuts it.
Edit 2:This article is now outdated. See About Godot 4, Vulkan, GLES3 and GLES2 for up-to-date information about the planned rendering backends transition.
The rationale behind OpenGL ES 3.0
The rationale for the OpenGL ES 3 renderer was having a single codebase for targeting all platforms:
Desktop Linux, Windows, macOS
Android, iOS
WebGL 2.0
This sounds really good in theory and we could say it almost works. Single codebase for everything is like a dream come true for writing an engine. OpenGL ES 3 provided sufficient functionality to implement most modern rendering features and have something that looks really good (as you can see in all the images and videos we posted).
Yet, in reality, many things did not go as expected.
Poor mobile support
OpenGL ES 3.0 works, nowadays, in all versions of iOS. On Android, it is supported in most of the mobile devices in the market. Still, there seems to be a large chunk of them (36% at the time of this writing) that only support OpenGL ES 2.0. This segment is not decreasing fast enough and it seems it will be many years until all devices are fully 3.0 compliant.
Added to that is the terrible driver support for OpenGL ES 3.0 on Android. Most drivers are outright full of bugs, which translates directly to crashes that don’t make any sense. Save for Tegra, all other platforms (Adreno, Mali and PowerVR) are buggy and this prevented implementing many potential optimizations for the sake of stability.
This led us to the conclusion that we will need to ship an OpenGL ES 2.0 driver that works in the same way as Godot 2.x (though, including PBR support) in order to achieve maximum compatibility.
This means we have lost a third of the reasons to use OpenGL ES 3.0. Fortunately, Godot 3.1 will come with a new OpenGL ES 2.0 backend that will make Godot work great on mobile again.
Poor WebGL 2.0 adoption and performance
While WebGL 2 works on Firefox and Chrome (and even runs great on Android mobile), it still does not on the other platforms.
Added to that, Godot 3.0 uses quite complex shaders which, while they work fine on WebGL 2, take a long time to compile on Windows due to the Angle GLSL validation and compilation to HLSL.
It seems that for nicer performance and compatibility, we will be forced to use WebGL 1.0 for the time being (based on the upcoming OpenGL ES 2.0 backend).
Corner cases on NVidia and AMD
While the Godot 3.0 renderer works great for the most part on NVidia and AMD, there are some corner cases (which are pretty difficult to come by) where the OpenGL 3.3 drivers are not optimized as we would like.
These cases are easy to workaround if they ever happen, as they have been the same sort of limitations OpenGL always had (state validation before drawing can take some time).
Still many new users may not be aware of this and do things in less efficient ways, yet expect them to work.. as they do in engines that use Direct3D 12. Again, this is easy to workaround using batching or instancing and does not happen often, but it’s one more step.
Performance on Intel GPUs
Intel GPUs on Windows and macOS have pretty unoptimized OpenGL drivers. The same hardware running Linux has considerably better performance. While the performance hit is not really that bad (you can’t expect much from this type of hardware), it’s enough that compared to other engines (which may use Direct3D and Metal) Godot may seem a bit slower (e.g. 45 FPS where you would expect 60 if you have an Intel HD 5000).
Vulkan as an alternative
While none of the problems on the desktop side are serious (users have so far mostly reported performance problems on old Intel IGPs, or extreme corner cases), Vulkan was always a tempting alternative to solve them and to ensure we are much safer from driver bugs (after all, this is what the API was intended for). Still, the lack of support on macOS made it unappealing. Having to write a Metal backend to support this OS is a lot of effort for a platform not used very much.
Khronos announced many months ago the Vulkan Portability Initiative, which we found really interesting but was far from being functional. As we mentioned many times in online discussions, moving to it eventually would be ideal.
MoltenVK goes open source
However, today, in a completely unexpected turn of events, it seems Valve has found an arrangement with the developers of MoltenVK (the commercial and proprietary Vulkan over Metal wrapper), ported Dota 2 to it, and got it open sourced.
It seems to be a mostly complete Vulkan implementation that runs on macOS and iOS. This pretty much lifts the only barrier we had for moving Godot to it.
Roadmap changes
As it seems clear that we will be moving to Vulkan on desktop and OpenGL ES 2.0 on mobile and web, further work on the current OpenGL ES 3.0 rendering backend is pointless as it will be rewritten.
For now, we will keep focus on releasing Godot 3.1 with the following main features:
OpenGL ES 2.0 support
Proper Mono export support
Support for 2D meshes, 2D skeletons, and deformable polygons
New animation tree, with state machine and root motion support
Blender to Godot exporter that keeps Cycles/Eevee materials (tentatively)
Features voted in Patreon that do not involve changing 3D rendering
Then afterwards, the rewrite of the rendering backend to use Vulkan will begin. It should not take too long (estimating a couple of months, since there’s nothing really new to design), and a new version will be released with this backend (among other features that contributors will keep working on).
For a while, we will then offer three backends to choose from: OpenGL ES 2.0, OpenGL ES 3.0, and Vulkan (the default, when ready). Once the Vulkan backend is well tested and proven to fulfill everything we need it to, the OpenGL ES 3.0 backend might be deprecated and replaced.
This will delay a bit the implementation of new features on the 3D side, but we believe it will be very worth it on the long term. Thanks for the patience!
It is important to note that for games being currently developed with Godot 3.0, there will not be any compatibility breakage when moving to Vulkan. This is an internal renderer change, and the exposed APIs and formats will remain the same.
Previous
diff --git a/article/about-godot4-vulkan-gles3-and-gles2/index.html b/article/about-godot4-vulkan-gles3-and-gles2/index.html
index 997d847fc0..e99bf424d0 100644
--- a/article/about-godot4-vulkan-gles3-and-gles2/index.html
+++ b/article/about-godot4-vulkan-gles3-and-gles2/index.html
@@ -1,8 +1,9 @@
About Godot 4, Vulkan, GLES3 and GLES2 – Godot Engine
This article is from July 2021, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Hello fellow developers!
As the alpha of Godot 4.0 comes closer and closer, we wanted to spend some words to clarify the direction that Godot 4 has taken in regard of rendering back-ends.
Will Godot 4.0 support OpenGL/OpenGL ES?
OpenGL will most likely not be supported at the time Godot 4.0 is out. The renderer design and all resulting code had to be re-implemented entirely from scratch in order to support Vulkan and modern rendering techniques. This took an enormous amount of work (more than two years, close to three at the time of release).
OpenGL support will definitely be implemented by the time 4.1 is out, hopefully some months later. One of our main goals for the 4.x releases it to provide them in a timely manner, so you will not have to wait a whole year for it. That said, given 4.0 has so much new code (the engine was rewritten significantly), it will also require a large amount of time dedicated to bug-fixing and stabilization even after stable.
What version of OpenGL will Godot support?
In the beginning, we wanted to support Vulkan alongside GLES2, which is why in the project manager you can see a disabled option for GLES2.
As more work was poured into the Vulkan back-end, it became clearer and clearer that supporting GLES2 is not an option anymore. There are several reasons for this:
On Desktop, hardware that does not support GLES3 (or GLES3 via Angle, which is what Chrome uses to display WebGL) is extremely old. Mid 2000s. This hardware does not posses enough video memory to run a modern game engine, anyway.
On Mobile, the story is different but, as mobile phones keep coming out and old ones no longer work due to dead batteries/slowness/etc, GLES2-only devices are becoming very scarce (Only 10% at the time of this writing and less by the time Godot 4.0 launches).
On Web, GLES3 (WebGL2) suport is not present on Safari at this time (and support for it was uncertain for a long time), but it’s now finally in Technology Preview stage, which means it will be out and supported soon.
In other words, when work begun on Vulkan for Godot, GLES3 support was not widespread or certain, but that is no longer the case.
Because of this, Godot 4.x will focus on both Vulkan and OpenGL ES 3.0.
Wait, but isn’t GLES3 too demanding? GLES2 is faster in Godot 3.x
OpenGL ES 3.0 is a superset of 2.0. This means that the same things are supported and more features are added in. Many of these added features allow for better optimization so, in practice, performance in itself should be better.
The reason this is not the case in Godot 3.x is because performance per se is not a linear metric. On the surface it should be obvious that, the more features and toggles you add, this has a performance cost. This is not the only factor, though.
Reality is that performance is better measured in base cost and ability to scale. The GLES2 renderer in Godot 3.x has a much lower base cost than the GLES3 one. If you use only a few lights and reflection probes, it will be much faster. It’s also designed to run efficiently on old hardware. If you start adding lights, reflection probes, etc. at some point it will become slower than the GLES3 back-end. It also lacks support for the more advanced features such as Global Illumination.
To put it simply: In Godot 3.x the GLES2 renderer is designed for older hardware and it will perform better than the GLES3 renderer for relatively simple scenes, but it just does not scale for more complex/high end scenes.
The GLES3 implementation in Godot 4.1 will be a hybrid. It will have a design more similar to the GLES2 renderer in Godot 3.x (so it will achieve better performance in old devices), but it will still take advantage of the added features to scale better for more complex scenes. Some more advanced features such as decals or Real-Time GI, present on the Vulkan renderer, will not be supported, though.
Still, if you are making a high-end mobile game, keep in mind that we will support a mobile optimized version of the Vulkan renderer. Vulkan runs on all high end phones that were shipped in the past several years.
What if I can’t run GLES3 or Vulkan?
Technically, for the editor, all hardware from the past decade supports either GLES3 and Vulkan. The main problem is that some of it (older Intel IGP) does not support OpenGL 3.x on Windows (though it does on Linux). Because of this, we are considering shipping the Windows version of Godot editor running on top of ANGLE (the same wrapper Google uses to run WebGL on Chrome). So, if you can run WebGL2 in your browser, you will be able to run Godot.
On MacOS, as OpenGL is being deprecated, we will also supply builds based on ANGLE (over Metal this time) so the editor and exported games using GLES3 continues to run.
So, GLES2 support is effectively dead in Godot?
Not necessarily. It will be kept alive in two ways:
Godot 3.x will be maintained for a long time so, if you require GLES2 you can use this version.
Godot 4.x may support GLES2, but not necessarily out of the box. Some contributors want to work on it, so we may still add limited support for those who need it (may be switched off by default, though to save binary space). Keep in mind this will most likely be focused on 2D and may only support rather simple 3D.
Being a part of Godot 4
Once again, Godot could not be where it is without all the wonderful people that participate to the development of Godot by financially supporting the engine, by dedicating time to fixing bugs and implementing features, by creating awesome demos, by opening issues, by contributing to the documentation and by participating in the Godot communities.
To all of you, thank you from the bottom of our hearts. You are the fuel of this project and there aren’t words to express how much that means to Godot.
If you want to help Godot 4 shine, you can join the contributor chat platform, where a number of people are working to make visually impressive demos for Godot 4.
Another important way to support Godot 4, other than donating, is to try out the alpha builds as soon as they are out and report all the issues that you encounter.
diff --git a/article/about-official-console-ports/index.html b/article/about-official-console-ports/index.html
index 9bec4c0bce..69dc58ebcd 100644
--- a/article/about-official-console-ports/index.html
+++ b/article/about-official-console-ports/index.html
@@ -1,8 +1,9 @@
This article is from August 2021, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Since it’s not very usual I post here, let me remind you who I am. I’m Pedro, a.k.a. RandomShaper in the Godot community. I’ve been contributing to the engine since 2016, when I discovered it –version 2.1 was the newest– and decided to use it to create my game Hellrule. Precisely while testing this project on different models of Android phones, I found the need to make the improvements I’m explaining in this post.
Old behavior in Godot 3.3.x and before
In a game engine, the engine loop is the sequence of steps that is happening again and again to let the game run. This includes rendering, physics, input processing, and more. Optimizing this loop to run with as little CPU time as possible is important to have smooth gameplay on high-end and low-end hardware alike.
Godot’s engine loop used to look like this (this is heavily simplified to just show what we are talking about here):
The key element of this is the possibility of multiple physics steps being processed per cycle of the engine loop. Consider a game that wants its gameplay logic and physics to run at 60 FPS. To achieve this, the engine needs to poll for the player’s inputs from various sources, such as a mouse, keyboard, gamepad or touchscreen. Ideally, the engine would read the player’s inputs once per each of those gameplay-physics steps so it reacts as quickly as possible to player actions. Also, rendering would happen at that very same pace, so everything stays in sync.
However, depending on the demands of the game and the hardware it’s running on at a given time, that may not be possible. If the device running the game is not powerful enough to keep everything at 60 FPS, the engine will run at a lower effective FPS rate. Rendering and idle processing will then occur less than 60 times per second, but the engine will do its best to have the gameplay-physics running at the target rate, by executing more than one of those physics steps per visible frame.
If you look again at the game loop above, you’ll understand that a consequence of the engine looping at a lower frequency is that, user input is also pumped and handled less frequently, which leads to having a lower responsiveness in addition to a less smooth update of the display.
New behavior in Godot 3.4 beta and later
In order to avoid that, Godot needed to somehow uncouple input from render so the engine main loop looked more like this:
To make that happen, I’ve added the concept of input buffering, which allows that one thread –usually the one consuming events from the OS– stores the input events from the player in a buffer as they are received while the main thread of the engine flushes them at key points of the cycle. This new approach improves the responsiveness of the game in situations of lower-than-ideal FPS.
Remarks
This enhancement is implemented in two pieces. One belongs to the core of the engine, whereas the other must be implemented on each platform. At this point, only Android has the platform-specific part implemented. (To be honest, that’s most likely the platform where agile input flushing is needed the most, due to the huge range of hardware capabilities found across devices.)
However, the doors are open wide for it to be implemented for other platform given the base is already done.
Both Godot 3.4 and 4.0 will enjoy agile input, exposed as the input_devices/buffering/agile_event_flushing project setting.
The project setting mentioned above is disabled by default. The rationale is that not every project may want to have batches of input events coming multiple times per frame. Also, until this feature is implemented universally, enabling it causes differences of behavior across platforms. Nonetheless, elaborating on the latter, my game has been in the wild for months with agile input flushing on Android and without it on iOS with no issues. As long as you make your game physics-centric, whether agile input is enabled or not won’t have any side effects. The game will just be more responsive when it’s enabled and available, but it will keep working without agile input.
Previous
diff --git a/article/android_godot_editor_play_store_beta_release/index.html b/article/android_godot_editor_play_store_beta_release/index.html
index 1022f365bc..8fb3c60077 100644
--- a/article/android_godot_editor_play_store_beta_release/index.html
+++ b/article/android_godot_editor_play_store_beta_release/index.html
@@ -1,8 +1,9 @@
Godot Editor (Beta) arrives to the Play Store – Godot Engine
You’ve probably heard it before, that Godot’s own editor is “built with the Godot Engine”, and in a certain way it is true. Another fact is that Godot supports the Android platform, and many developers have been using it to create amazing mobile games in the last few years. The natural conclusion of these two factoids is a question: “Can I run the Godot Editor on my Android device to make games and app on the go?”.
Yes, you can! Since our announcement last year, we have been hard at work demonstrating this capability and have been making significant progress developing, refining, and polishing the port of the Godot Editor on Android devices.
Note that the same tenets apply to other platforms supported by the Godot Engine, like iOS; the implementation is left as an exercise to the reader :).
Our porting efforts culminate with a beta release of the Godot Editor for Android on the Google Play Store! And you can try not one, but two upcoming Godot Engine releases on your device:
The focus, at this stage, has been to replicate on the Android platform as much of the functionality offered by the Godot Editor on desktop platforms as we can. We want to provide Godot users with an experience, environment, and capabilities they are already familiar with.
With this release we hope to enable both existing and new members of the Godot community, as well as other Android users interested in game development, to develop and test their projects on accessible, flexible, and portable mobile devices. To that end, we’ve tried to optimize the workflow and the user interface to work better on smaller screens and with touch input.
Supported form factors
For the best experience, we strongly recommend to use a large form factor Android device (e.g., an Android tablet or an Android-powered netbook). The Godot Editor for Android can also be downloaded and installed on regular Android phones, though the experience may vary and be suboptimal. We are looking forward to your feedback to address key pain points in future releases.
Keyboard and mouse support
While we have made some adjustments to allow for easier navigation and control with the touch input, an external keyboard and mouse connected to the Android device would still give you a better experience. This setup brings you close the development experience on desktop platforms, which has received numerous refinement and polish over the years.
Touchscreen and multi-touch support
The Godot Editor for Android has been updated with touchscreen and multi-touch support to allow using it without a connected keyboard or mouse. This support is going to receive refinement and additional features based on your feedback.
Viewport navigation
Double-tap & zoom. Double-tap and drag to zoom in or out inside of the viewport.
This article is from November 2021, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
One of the last areas pending for redesign in upcoming Godot 4.0 has now been completed, resulting in much improved usability when dealing animation data.
Animation data
While there are upcoming improvements on the general animation system, one key aspect that required a strong redesign and subsequent rework in Godot is the way that animation data is stored.
Animation data is the information that comes from scenes that have been exported from Blender, Maya, 3DS Max, etc. In those applications, animation is edited as Bezier curves and many times happens naturally as a result of modifiers such as IK (Inverse Kinematics).
In game engines (or even when exported from the 3D modelling application), animation data is baked to a simpler representation because, for games, processing beziers and IKs is way too expensive for real-time. Games need to process dozens or hundreds of models in real-time, so data must be available in a format that can be more efficiently decoded.
Just decoding the animation, however, is not enough. Games will often have several requirements that must be satisfied regarding the imported animations, such as:
Ability to attach and remove different meshes to be deformed by the same skeleton. This is key to having character customization or equippable items.
Ability to reuse the same animation across different character models, even if the models are slightly different (taller, shorter, etc).
Ability to play very long animations, which is common in cut-scenes. Animations can be so long that they may need to be streamed from disk.
Ability to play back individual channels (position, rotation, scale) to allow controlling the others procedurally (common for IK, character customization, etc).
Work with as many files as you can find on the internet. Not everybody can create their own animators or has the budget to hire 3D animators.
Many of those items were not working correctly in Godot for several years. Workarounds were designed but they were all ultimately hacks. After the latest meetings with animation contributors, it was clear that the animation data subsystem had to be redone almost from scratch.
As a result, several steps and improvements were made:
Removed the transform tracks
Godot would originally import animation tracks by combining Position/Rotation/Scale into a single transform keyframe. Because animations were just matrices relative to the skeleton rest, this allowed limited sharing between different models but failed in more complex cases. Additionally, it proved to be a problem when animations contained non-uniform scaling in tracks because the animations (relative to the bone rests) would create skewing, which could not be represented properly in keyframes.
To fix this, the transform tracks were entirely removed. In their place, individual Position, Rotation and Scale tracks are now created and imported. This allows for importing only what animations require.
Additionally, a special Blend Shape trackwas added, which allows processing blend shape animations more efficiently.
Removed the animation dependency on bone rests
Thanks to the previous step (individual tracks), it was now possible to change how animations fundamentally work in Godot. By entirely removing the dependency on bone rests for animation, skeletons now contain a final pose for each bone and that’s it. Likewise, bone poses are now Pos/Rot/Scale and can be animated manually. A transform matrix is no longer used.
Removing this has the following immediate effects:
Massive improvement in compatibility with 3D applications and models. As Maya and 3DS Max don’t have the concept of “rests” (unlike Blender which does), many models exported from those softwares would just not work in Godot. They now do.
Improvement in compatibility with non-uniform scaling. By removing the rest dependency, all animations using non-uniform scaling will now work.
Improvement in ease of animation reuse. By simply importing a rotation track, animations can be re-used across different models with similar skeletons. Even with different bone sizes.
Generating procedural animation is now much easier, as every track can be generated independently.
Implemented animation compression
A common problem of dealing with animations in Godot is that animations are stored uncompressed. This means that animation data can take a large amount of memory and disk, specially animation that comes from mocap or animation used for cinematics.
Several approaches were investigated including curve-fitting techniques but, in the end, a bitwidth and page based approach was implemented. This creates animations 5 to 10 times smaller and stores them in a format that is very friendly for streaming (a feature that may be implemented in future versions of the engine).
Improved how rotations are exposed to the user for animation
For animators, creating animations directly in Godot was always relatively limiting. While the animation system is powerful, the 3D part of it lacked several basic features that standard animation packages offer.
The more important one is the ability to choose the rotation order for Euler rotations. Godot uses YXZ Euler rotation order, but changing this was never possible.
With this change, it will now be possible to specify rotation order, as well as doing quaternion rotation interpolation to avoid Gimbal Lock.
Expression based transitions for Animation State Machines
For AnimationTree the only way to advance states in the AnimationStateMachine was by setting a boolean property. Users have asked for a long time for the possibility to use some more advanced form of conditions for this, to control the states.
To allow this, expressionswere introduced as an optional way to trigger the transitions. They require a base node to work with and a valid logic that uses the properties exposed by that node.
Future
This was a last minute unexpected change because it required large compatibility breaking, and I want to hugely thank the animation contributors: Fire, Tokage, Lyuma and Saracen. Godot 4.0 alpha is around the corner now (we have been pushing pre-alpha builds recently), so looking forward to a release soon! There will be many new and exciting changes in animation after 4.0 is out, but for now the priority is to stabilize the engine.
This article is from November 2022, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
This post will talk about animation retargeting, a new feature coming in Godot 4.0. It has already been merged, so anything you read in this post can be done in the current beta version (beta 3).
Recently, a lot of attention has been paid to the 3D features of Godot 4 that have been improved such as rendering, physics, etc. To make those improvements widely known, we should make it easier to create 3D games with Godot so that more people will be able to use them.
My background
Hi, my name is Silc ‘Tokage’ Renew (TokageItLab). I am so honored to write this blog post as a member of Godot’s animation team.
The showreel for 2020 is up! As every year, more and more quality submissions fall in our hands, making the selection job very difficult. This year was not the exception, as we had had a record submission amount (over 200) so, this time, several core contributors had to take the work of ranking and voting them to decide which would make up the final reel.
Desktop / Console showreel
Mobile showreel
Thanks
Thanks to everyone for submitting videos, Hugo Locurcio for editing, and thanks to Christian Perucchi and Hubert Lamontagne for providing their music!
Previous
diff --git a/article/announcing-2021-godot-games-showreel/index.html b/article/announcing-2021-godot-games-showreel/index.html
index 5abb3c571a..b7e24bfa6e 100644
--- a/article/announcing-2021-godot-games-showreel/index.html
+++ b/article/announcing-2021-godot-games-showreel/index.html
@@ -1,8 +1,9 @@
Announcing the 2021 Godot games showreel! – Godot Engine
By:
diff --git a/article/announcing-android-xr-support/index.html b/article/announcing-android-xr-support/index.html
index 97363be3c7..fd2e0f265f 100644
--- a/article/announcing-android-xr-support/index.html
+++ b/article/announcing-android-xr-support/index.html
@@ -1,8 +1,9 @@
Godot and W4 Games support Android XR from day One – Godot Engine
With the recent public release of Samsung Galaxy XR, the first headset using the new Android XR operating system, we are pleased to announce that Godot already supports this new ecosystem.
As a game engine that puts OpenXR front and center, Godot is uniquely positioned to excel on this platform.
With the release of the Godot OpenXR vendor plugin v4.2.0, a new option for Android XR has been added that allows developers using Godot 4.5 and newer to effortlessly export their existing projects to this new platform.
The Godot XR Editor has also been updated with Android XR support and runs beautifully on this new device. Users can download the Godot XR Editor from Google Play.
W4 Games has announced their support of the platform including implementing various vendor specific extensions that expose functionality unique to Android XR.
As part of this initiative, W4 Games will be making a donation to the Godot Foundation to ensure supporting Android XR long term and continue their work on enhancing Godot’s OpenXR support.
We bring you three brand-new videos showcasing what the Godot Engine can do. As always we have separate videos for games targeting desktop/console and games targeting mobile devices. This year we are proud to introduce a new category called “Apps & Tools” to highlight non-game creations made with Godot. This is a field that has been growing a lot, so we wanted to shine a light on the great projects released or under development.
Many of our core contributors and maintainers voted to make the final list in each category, and this year was particularly hard. There were way too many good projects, and we couldn’t include them all to keep the videos at a reasonable length and pace – but don’t be discouraged if your entry didn’t make it, we’ll have more opportunities to showcase great projects, including next year’s showreels.
This article is from November 2021, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
GoGodotJam is a month-long festival ending with a game jam. During the event, you can expect tutorials and interviews with Godot creators on a daily basis.
diff --git a/article/announcing-gogodotjam-3/index.html b/article/announcing-gogodotjam-3/index.html
index ee48879c2b..342740f86b 100644
--- a/article/announcing-gogodotjam-3/index.html
+++ b/article/announcing-gogodotjam-3/index.html
@@ -1,8 +1,9 @@
This article is from May 2022, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
GoGodotJam is a Festival that celebrates Godot’s Awesome Community. Join them in live events with tutorials, workshops, interviews and more - all culminating with a Game Jam.
In this edition there will be not one, but two Game Jams:
GoGodotJam CLASSIC - for people that want to participate casually, with a timespan of 2 weekends and one week using the same recipe as the last 2 editions
GoGodotJam ULTRA - for people that want a challenge, like high-risk high-reward situations and, of course, big prizes: $240+ and counting
This article is from May 2021, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Meet Adrian, a game developer from Stockholm, Sweden. He co-organises Go Godot Jam, a one-month long community festival with a game jam included. Adrian answered a few questions.
Who are you, Adrian?
I am a game developer based in Stockholm, Sweden. While I am passionate about creating games, I also want to help the gamedev community grow. I have created a few gamedev teams, a club, and more recently, the Redefine Gamedev YouTube channel. Here I want to grow together with other game developers by sharing quality content.
How did you find out about Godot?
At work, I have developed games and other software by using proprietary engines only. But in my free time, I have always sought a breath of fresh air. That led me to experiment with free game engines: from Irrlicht to Esenthel to Godot.
Upon closer inspection, I have found out that Godot is the perfect place for me to grow. So I began exploring it further, creating content for it, and helping others discover it as well.
What do you see in Godot?
Godot is a great game engine that unlocks possibilities for game developers. It is a free, open-source 2D and 3D engine that provides many features so that you can focus on your game.
Yet most people start developing games with proprietary engines such as Unity or Unreal. They are solid engines with a proven track record and a vibrant ecosystem. One advantage having experience with more than one engine can enable people to create better games. In the end, it’s up to each individual to pick the one that they’ll be most comfortable with to fulfil their creative vision.
I know that Godot has a lot to offer to new developers, with a distinctive approach to game development which enables more people to express their creativity. It’s open, focused on user-friendliness, easy to learn, yet feature-packed and a great fit for many types of games. As such, I want to increase awareness of the engine so that more users decide to try it out and add it to their toolset.
How can we supercharge Godot?
We, the community, are the fuel that can supercharge Godot. We can spread awareness, clarify misunderstandings, and in the end, show it to the world. At the same time, we can also carve a path for new people to get started on their gamedev journeys.
One way to achieve this is to organise a Godot event that will ripple in the gamedev community, offering a lot of content for both existing Godot developer and new people that want to approach the engine but just don’t know how to.
What is Go Godot Jam?
With Go Godot Jam, we want to try a new format which complements existing Godot events.
diff --git a/article/announcing-monthly-live-q/index.html b/article/announcing-monthly-live-q/index.html
index 610cdbfdbe..3562ba85f4 100644
--- a/article/announcing-monthly-live-q/index.html
+++ b/article/announcing-monthly-live-q/index.html
@@ -1,8 +1,9 @@
By:
diff --git a/article/announcing-new-community-map-user-groups/index.html b/article/announcing-new-community-map-user-groups/index.html
index 13d884a418..92fb727ba6 100644
--- a/article/announcing-new-community-map-user-groups/index.html
+++ b/article/announcing-new-community-map-user-groups/index.html
@@ -1,8 +1,9 @@
Announcing the new community map for user groups – Godot Engine
This article is from January 2021, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Starting from today, there is a new User groups page on the Godot Engine website! This page replaces the old User groups page by featuring a community map that can be freely navigated and contributed to.
What is the community map?
The community map on the User groups page allows you to see where physical and online communities are located around the world.
diff --git a/article/announcing-new-hire-gilles-roudiere/index.html b/article/announcing-new-hire-gilles-roudiere/index.html
index 2324590c2f..52b4df4a45 100644
--- a/article/announcing-new-hire-gilles-roudiere/index.html
+++ b/article/announcing-new-hire-gilles-roudiere/index.html
@@ -1,8 +1,9 @@
Announcing a new hire! (Gilles Roudière) – Godot Engine
This article is from August 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
In the past month, the excess donations accumulated so we are finally able to offer enough financial security to do an extra hire. Beginning November, Gilles Roudière (Groud) will be working full-time for the project, dedicated to 2D and general editor usability!
Background
Gilles is responsible for the 2D editor in Godot, as well as some other areas such as the current filesystem dock and several improvements to Godot UI nodes. He has done an outstanding job, producing top quality contributions.
His main responsibility from now on will be to become the general editor maintainer. He will work on improving usability, adding features, and making sure that the experience with the built-in tools is the best as it can be.
Immediate priorities include improvements to the tilemap editor, animation editor, skeleton animation editors, and general 2D editor experience. Further ahead, more general improvements for the editor overall, based on your proposals.
Future
We have more hires planned, but we need to increase our donations level for this. If you are not, please consider becoming our patron and help make this happen!
Previous
diff --git a/article/as-oss-godot-is-more-than-a-game-engine/index.html b/article/as-oss-godot-is-more-than-a-game-engine/index.html
index 59a1874dd3..63473b1f28 100644
--- a/article/as-oss-godot-is-more-than-a-game-engine/index.html
+++ b/article/as-oss-godot-is-more-than-a-game-engine/index.html
@@ -1,8 +1,9 @@
As an Open Source project, Godot is more than a game engine – Godot Engine
This article is from October 2017, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Introduction
Godot is a community developed game engine. The development process is becoming tighter and more efficient every day. As the amount of contributors keep growing exponentially, it’s a big challenge for us to keep this process efficient and yet improve it.
In fact, our development process and code quality are, already, arguably in many senses better than commercial game engine counterparts. Proof of this is the large amount of features added on each release, and the ever high stability of the codebase, even on alpha state.
Before explaining this further, It’s important to understand what is, according to the point of view in this article, considered to be a game engine, and where Godot stands.
What is, then, a game engine? Let’s try to agree on a common point of view.
A renderer + OS obstraction functions
For a lot of developers, just a renderer plus abstraction on some OS functions (such as input handling, filesystem, etc), is enough to label something a “game engine”.
Truth is, I don’t think this is fair. In Godot, the renderer is only, at much, 1% of the codebase, and OS abstraction does not even amount to that.
If Rendering and OS abstraction is only, at much, 2%. What is the rest needed for?
Adding tools to the mix
At some point, a lot of functions are needed for a more modern workflow. Asset importing, exporting, level editors, serialization, etc.
One could then argue, that a game engine is an OS abstraction, a renderer, and tools that help to make a game.
It would be easy to agree that this definition fit the bill a decade ago, but engines from back then definitely are not the same as the more modern ones from today.
Back then, tools were generally separate applications or processes to deal with different aspects of a game. Nowadays, game engines don’t look like this (save for maybe in-house engines that large companies still use).
A Coherent experience
During this past decade, game engines morphed into all-in one tools with an unified interface. The focus was put mainly on usability and a coherent experience.
This made engines migrate from being specialized tools for experts to accessible applications than anyone can use.
Nowadays, it would be difficult to argue that a modern game engine does not include this aspects in it’s definition.
There is also something else, though..
Extensibility and Community
Game engines are meant to be tools that save work on the most common tasks of developing a game but, as game development is a creative process, it’s not uncommon to find situations where new features need to be added in order to achieve game design goals.
Due to this, extensibility is a very important aspect of modern game engines.
Building a community around this model is vital for developers to save time on their respective projects. This way, common extensions and features can be shared without having to be reimplemented.
As such, we can agree that extensibility and a user community also fit the definition of a modern game engine.
For some engines, this is even part of their business model. This way, if something is missing, the community can create and sell the missing functionality.
But then comes Godot
Godot adds something entirely different to the mix. Something both new and old. It’s a fully open source and community driven game engine.
It may not make sense what’s special about this at first, but once you start using it and taking part of the community, it becomes obvious.
The Open Source Difference
The open source development process is something beautiful. Once you get it, it becomes clear why. Once a project is set in motion and starts getting traction, it becomes unstoppable.
It may not make sense to most developers how a bunch of guys working in their free time and without getting paid can create quality software that, very often, matches or surpasses it’s commercial counterparts.
Projects such as Linux, gcc, LLVM, Python, Videolan, Blender, git, etc. are proof of this.
The Open Source development model
Many confuse Open Source with Shared Source, or making the source available.
When you read about Open Source somewhere, it’s always about the OSI definition of it.
It means that a special license is used so everyone collaborating will benefit equally, making the development truly open.
When companies make the source available, they will often do it together with a license where they clearly state that they benefit more from it than anyone that contributes. Alternative, some companies make part of their code open while keeping the rest as closed or under a more restrictive license.
This is what makes Godot different to engines such as Unreal, Xenko, Cocos2D, Lumberyard, etc. Anyone who contributes to Godot, benefits equally from other’s contributions.
Godot is a true Developer Community
This key difference is what makes us stronger in the end. Godot is not just a game engine, it’s a true developer community. It encourages everyone to contribute and benefit on equal terms.
We have dozens of core developers and more than 400 contributors working on Godot, and this number keeps growing exponentially month by month.
But this is not all, Godot development is a true meritocracy. Code is only merged when deemed worthy by the other developers. Every change is discussed for pros and cons.
This process is led by our large user community, who usually sets our priorities via issues (or just random rants on our community sites :P). This same community helps with the testing and works directly with developers implementing each feature to ensure it works as best as possible. Our process is truly community-driven from begining to end.
This development process, which involves several thousands individuals, is extremely efficient and ensured that, in a bit less than 3 years, Godot went from being completely unknown to appear on the map on the most important developer communities. No other game related technology has grown so quickly!
To add to that, Godot gives you the safety that we are just individuals working towards making the best game engine possible.
Godot does not need to survive by selling you new features constantly that you probably don’t need and just bloat the engine because they are implemented in a hurry. The small 20mb download size is a testament to this.
Godot does not need to sell you assets or extra services to keep the development going, and does not ask you for a % of your income.
Godot does not need to pay high salary to talented developers in order to exist, talent forms around it due to the oppenness of our process.
Godot does not need to convince companies or users that it has a solid cashflow and it won’t go away anytime soon. Like every successful open source project, we are a talent pool that constantly self replenishes.
Because of all this, Godot is a lot more than a game engine. It’s a lot of talented individuals and the best community we could ever wish for, working together with the hopes of creating the best game development tool that ever exists.
Following this process is very exciting, so stay with us and help us keep making Godot better and better!
Previous
diff --git a/article/asset-library-web-frontend-reaches-beta/index.html b/article/asset-library-web-frontend-reaches-beta/index.html
index a4cc4c8aa6..c6f0067227 100644
--- a/article/asset-library-web-frontend-reaches-beta/index.html
+++ b/article/asset-library-web-frontend-reaches-beta/index.html
@@ -1,8 +1,9 @@
The Asset Library web frontend reaches beta – Godot Engine
This article is from October 2016, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
After several months of waiting (obligatory joke) and more importantly of development, the web frontend to Godot’s Asset Library finally reached the beta status!
What does it mean? That the Asset Lib frontend is now officially public and that the community can start using it extensively. It is still in development, but we have a pretty solid base that should allow you to create your account, submit and update your assets - as well of course as seeing the existing assets in the library.
Many thanks to Bojidar Marinov for the huge work he did on the Asset Lib so far! Others have started to contribute too, don’t hesitate to join in if you like (or at least know) PHP :)
If you missed the inline links, here they are in clear:
Asset Library - browse anonymously or register and login to submit new assets
Issue tracker - to report any issues you may encounter (also usability wise, it’s still a work in progress)
How does it work?
The Asset Library is composed of three parts:
The engine frontend in Godot itself (since 2.1 stable), that you can access via the project manager (to install templates and demos) or via the AssetLib tab in your opened project (for all other types of assets).
The web backend, which is queried by the engine frontend to retrieve the list of assets and related metadata.
The web frontend, which allows you to see the contents of the library in your browser (see this asset for example), and most importantly to submit new assets and edit existing ones registered to your account.
What assets can be submitted?
The exact policy for the Asset Lib still needs to be formally written down, but here are the general rules that apply so far:
All assets should be licensed under a free and open source license (e.g. MIT, BSD, GPL, CC0, etc.). When picking a license for your assets, you should of course ensure that you have the appropriate rights (i.e. you can’t relicense assets from someone else to submit them to the Asset Lib).
All assets should be hosted in a Git repository, and accessible through a web frontend. The supported frontends so far are GitHub, GitLab (both gitlab.com and self hosted), Bitbucket, gogs and cgit (those two are also typically self hosted).
Each asset should be hosted in its own Git repository, i.e. one asset = one repo.
Why do we request this? We are not a company, and we want to give the priority to open source contributions that will benefit all users without having to care for the legal burden of running a commercial asset store. It does not mean that Godot’s engine frontend will not support paid assets in the future, but it is not our focus right now for the godotengine.org platform. People who want to run commercial stores are free to extend on our (obviously open source) web frontend and backend code and to host their own platform that can talk to Godot.
We also enforce the usage of Git and code hosting platforms such as GitHub or GitLab for security reasons: it allows moderators to review the code included in each asset before accepting them. The specific commit or git tag provided as the version to download in the Asset Lib can be used to generate an archive with a unique cryptographic hash – moderators have to enter this hash when they accept new assets or edits, and Godot users will only be able to download files with a valid hash from within the engine – this ensures that what users download is what moderators approved.
How to submit/edit assets
Once logged in, click “Submit Asset” in the navigation bar. You will then see a form asking for various details about your git repository and the asset you want to package:
Asset name
Category: 2D Tools, 3D Tools, Shaders, Materials, Tools, Scripts, Misc, Templates, Projects, Demos (subject to change as we gather community feedback)
Frontend type: GitHub, GitLab, Bitbucket, gogs or cgit
Repository URL
Download commit or tag: this identifies the version you want to submit to the Asset Lib. It will not be automatically updated for the security reasons mentioned above, so please edit your asset to update this hash or tag when needed.
Icon URL
License
Description
Optionally image and video previews
Once you submit your asset, you will have to wait for an Asset Lib maintainer to review it and accept it (it can take several hours, though we’re usually quite fast).
How to setup assets in your git repositories
We will provide more information about this in the docs in the coming weeks, but in the meantime, please check existing assets and their git repositories to see how it was done.
Keep in mind that assets are unzipped directly at the root of your project’s folder. Therefore, for plugins, you should use a addons/yourassetname/ folder in your git repository.
If you are in doubt, don’t hesitate to ask for guidance on one of the many community channels!
Future developments
As you will probably notice, the frontend is not finished yet. For example, rating assets is not implemented in the beta. You can check the existing list of issues as well as the milestone to the 1.0 release to see what is in the works. If you have issues to report or suggestions to make, please use the issue tracker.
For now, enjoy the existing assets and the web frontend, and give us your feedback!
Previous
diff --git a/article/atlas-support-returns-godot-3-2/index.html b/article/atlas-support-returns-godot-3-2/index.html
index 7117f798e2..cbe088a5bf 100644
--- a/article/atlas-support-returns-godot-3-2/index.html
+++ b/article/atlas-support-returns-godot-3-2/index.html
@@ -1,8 +1,9 @@
Atlas support returns to Godot 3.2 – Godot Engine
This article is from April 2019, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
With the import system rewrite in Godot 3.0, the ability to import atlases was lost. Using atlases is not as common nowadays, given the processing power of desktop and devices has increased a lot, but there are many use cases where this may be worth it. Godot 3.2 will bring back support for it.
What is an Atlas?
Importing images into an atlas is a process that will take all of the images, and pack them into a single larger image (called an “Atlas”). Then, when the original image needs to be drawn, it actually draws the piece of the larger atlas.
Character is (c) Square Enix.
This is also only useful for 2D (Godot does not support 3D atlases).
So, why would one use an atlas instead of individual images? In most cases, it doesn’t make sense, but for some situations it may provide some improvement in memory usage or performance. Here are such cases:
Batching
In cases where a lot of objects need to be drawn, having them all share the same texture (or material) may reduce draw calls or state changes. When working on tile-sets, it’s normal to have everything already drawn to a single texture but if the level uses a lot of separate images, then using an atlas may make sense to improve performance.
Optimizing Memory
When doing character animations, specially characters with hundreds of thousands of animation frames (like Cuphead), using an atlas will not give any increase in performance (as only one frame is drawn at the same time).
However, to ensure animation remains fluid and easy to integrate, animators will use a relatively large image size that remains constant, then animate a smaller character inside. This produces a lot of wasted memory, as these empty places in the animation frames take up a lot of video memory and make loading slow.
Using atlases ensures that, before placing all the animation frames in a single image, the frames are cropped (and the offset to the crop remembered). The packer will then, ensure everything is fit in the atlas image as compactly as possible. This makes it easy to optimize for memory, as only the places in the images that contain information are saved.
How to use atlases in Godot
Using atlases in Godot is extremely easy. Just select all the files that you want to pack together in the Filesystem Dock, then change the import type to “Texture Atlas”.
When the new file type is selected, change the “atlas file” setting to the image you will want to create, then push the “Re-Import” button. All your assets will be re-imported and added to an atlas. (The editor will restart afterwards, as the images may be in use, to ensure everything is re-opened in a clean state).
Here is a visual explanation:
Packing is also deterministic, which means that the same image should always be generated (this ensures it works for generating normal map atlases separatedly, as an example).
Import modes
As you may have noticed, atlas files have an Import Mode, settings. There are two possible ones:
Region
This packs the used part of the image in a square region in the atlas, then this is referenced in an AtlasTexture.
diff --git a/article/basic-cryptography-ssl-improvements/index.html b/article/basic-cryptography-ssl-improvements/index.html
index 72f3b650ba..c9610e2e1d 100644
--- a/article/basic-cryptography-ssl-improvements/index.html
+++ b/article/basic-cryptography-ssl-improvements/index.html
@@ -1,8 +1,9 @@
This article is from September 2019, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
As part of the MOSS project sponsored by Mozilla, during July I worked on some new features regarding cryptography and SSL to improve the quality and security of Godot networking.
Certificates and keys as resources
SSL certificates (in the form of *.crt files) and private keys (in the form of *.key files) are now treated as resources in Godot. This means they will be exported automatically and they can be loaded via the GDScript load() function.
Crypto class
A new Crypto class was introduced that allows to access some basic cryptographic functions.
You can generate cryptographically secure random bytes via the generate_random_bytes() function. The bytes are returned in a PoolByteArray.
You can generate RSA keys that can be used by StreamPeerSSL to act as a server.
You can generate SSL self-signed certificates that again, can be used by StreamPeerSSL to act as a server.
Hashing Context
A new HashingContext class now provides an interface for computing cryptographic hashes (MD5, SHA-1, SHA-256) over multiple iterations.
This is useful for example when computing hashes of big files (so you don’t have to load them all in memory), network streams, and data streams in general (so you don’t have to hold buffers). Here is an example of how it works:
const CHUNK_SIZE = 1024
diff --git a/article/become-godot-contributor-hacktoberfest-2018/index.html b/article/become-godot-contributor-hacktoberfest-2018/index.html
index 5eb9c32882..9684b75892 100644
--- a/article/become-godot-contributor-hacktoberfest-2018/index.html
+++ b/article/become-godot-contributor-hacktoberfest-2018/index.html
@@ -1,8 +1,9 @@
Become a Godot contributor for Hacktoberfest 2018 – Godot Engine
This article is from October 2018, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
October arrived, and with it one of the great community events of the FOSS year, the Hacktoberfest!
This event co-organized by Digital Ocean and GitHub has simple rules: contribute 5 pull requests to open source projects on GitHub, and you will get a cool T-shirt (plus eternal recognition from project maintainers and internal fame in many communities, or something close to that ;)).
And of course, Godot being one of the GitHub-hosted projects, you can work on your Hacktoberfest milestones by contributing directly to Godot’s source code or documentation.
Getting started
First of all head to the Hacktoberfest 2018 website and register with your GitHub account (if you haven’t one, you’ll have to register there too). The Hacktoberfest website has plenty of resources to get you started, and tips on how to find projects that you could be interested in, so make sure to check it in depth.
For Godot specifically, here are relevant links and tips:
Engine contributions
If you want to contribute to the game engine itself by fixing bugs or implementing enhancements (note that new features would be put on hold as we are in feature freeze - you can still make them but you wouldn’t get much feedback for now), head to the godotengine/godot repository. Most of the code is C++, with some bits in Objective-C (iOS/macOS), Java (Android) and JavaScript (HTML5).
This is also the place to work on the class reference, the documentation of all nodes available in Godot and their properties and methods.
Here’s how to get started:
The Hacktoberfest label on the source code repository lists some “newcomer-friendly” issues that you can have a look at. Note that you are not limited to those issues, you can work on anything you want - this selection is just a shortlist.
Similarly, the Hero wanted! label also has a selection of issues ready to be worked on, where project maintainers or users have done enough initial debugging to point you in the right direction (see our recent blog post about the “Hero wanted!” campaign).
You can also browse all other issues of the code repository which are in the 3.1 milestone (our main focus currently), and especially the ones labelled as bug.
Join the #godotengine-devel IRC channel on Freenode (also bridged on Matrix) to discuss with fellow engine contributors.
If you want to work on the class reference, have a look at the dedicated page.
Documentation contributions
To contribute to the online documentation and tutorials, the main repository is godotengine/godot-docs. Note that as mentioned above, contributions to the class reference should instead be done directly in the engine repository (as the class reference is also included offline in the editor).
Here’s how to get started:
Check the list of issues and see if there’s anything you’d like to work on.
Join the #documentation channel on Godot’s Discord server (most active place to discuss with fellow documentation contributors), or if you prefer the #godotengine-doc IRC channel on Freenode (but it’s less active).
That’s it! It’s a lot of links and documentation, but you of course don’t need to review everything in depth, look in priority at the contributor’s documentation and then pick something you’d like to work on.
Enjoy your Hacktoberfest and have fun contributing to your very own engine!
Previous
diff --git a/article/ben-tristem-gamedevtv-are-kickstarting-godot-course/index.html b/article/ben-tristem-gamedevtv-are-kickstarting-godot-course/index.html
index f727ae5d3f..e12aaf2076 100644
--- a/article/ben-tristem-gamedevtv-are-kickstarting-godot-course/index.html
+++ b/article/ben-tristem-gamedevtv-are-kickstarting-godot-course/index.html
@@ -1,8 +1,9 @@
Ben Tristem & GameDev.tv are kickstarting a Godot course – Godot Engine
This article is from May 2018, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
If you are into game development, chances are that you’ve heard of Ben Tristem and his GameDev.tv team, as they are making some of the best-rated online courses on Udemy for game engines like Unity3D and Unreal Engine 4, as well as art making tools like Blender and The GIMP.
New professional Godot course on Kickstarter
Last week, Ben and his team started a new Kickstarter campaign for a Godot Engine course!
In the Godot team, we are delighted to see them giving Godot the spotlight it deserves by making a top-quality professional course for the hundreds of thousands of Udemy users that learn with their material.
Their formula was tested and proven on other game engines, and we can’t wait to see how they will approach Godot – we are confident that they will make a great course, as they plan to involve the backers and the greater Godot community to help them shape the final curriculum.
Make sure to check it out and to support the campaign if you can, as this course should be a great learning resource as well as a visibility boost for your favourite no-marketing-budget game engine :)
diff --git a/article/beta-release-python-support/index.html b/article/beta-release-python-support/index.html
index e03e0a6965..56dce5c5e5 100644
--- a/article/beta-release-python-support/index.html
+++ b/article/beta-release-python-support/index.html
@@ -1,8 +1,9 @@
This article is from July 2017, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
This is a guest post by Emmanuel Leblond (touilleMan), a Godot contributor and Python lover who develops a GDNative interface to use Python 3 as alternative scripting language in Godot. To answer the obligatory question: yes, the plan is still to ship Godot 3.0 with GDScript, VisualScript and C# support. Python support should also be ready by then and usable plug ‘n play thanks to GDNative; its main advantage compared to the Python-like GDScript will be the access to the whole Python ecosystem.
Who said Godot’s only about waiting? Today we are releasing the first beta version of Python for Godot, the GDNative interface that enables you to use the full-blown Python 3 as a scripting language for Godot games. Now we need you to try it and give your feedback, so that it can be made as good as possible for the upcoming 3.0 release!
All core features of Godot are expected to work fine:
Builtins (e.g. Vector2)
Object classes (e.g. Node)
Signals
Variable export
RPC synchronization
On top of that, mixing GDScript and Python code inside a project should work fine, have a look at the Pong example to see how you can convert one by one your existing GDScript code to Python fairly easily.
This release ships a recent build of Godot 3.0-alpha (yes, it’s a beta based on an alpha…) and CPython 3.6.1 with the standard library and pip, ready to work with the Python ecosystem in its full glory (can’t wait to see people experimenting game AI with Pytorch!).
The project is Linux-only so far, however you should be able to compile it from the sources if you are on macOS (let us know if you do so).
diff --git a/article/betsy-gpu-texture-compressor/index.html b/article/betsy-gpu-texture-compressor/index.html
index 445523e524..7bbe96f1ae 100644
--- a/article/betsy-gpu-texture-compressor/index.html
+++ b/article/betsy-gpu-texture-compressor/index.html
@@ -1,8 +1,9 @@
Introducing the Betsy GPU texture compressor – Godot Engine
This article is from November 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
This work was commissioned by Godot Engine through the Software Freedom Conservancy to solve a major complaint: importing textures is excruciantly slow and takes many minutes.
Certain compression algorithms such as BC1-5 are quite simple and there are already fast high quality compression algorithms.
However algorithms such as BC6, ETC1, ETC2 and EAC are currently taking the majority of time and thus considerably attention were given to these.
Nonetheless Betsy implemented compute-shader versions for BC1,3,4,5,6, ETC1,2 and EAC algorithms.
Betsy works as a standard Command Line tool which means it can be used like any other exe tool outside of Godot.
More importantly, Betsy was developed with integration to Godot in mind, which is why its code has been isolated and abstracted from API details, written in GLSL shaders since Godot uses Vulkan.
Godot can make further performance improvements a standard CLI tool can’t, because Godot doesn’t have to initialize the graphics API every time it is invoked to compress a texture; and Godot can upload a texture just once and then encode into multiple formats (e.g. compress into BC1 and ETC1, or EAC and BC4 at the same time); rather than re-upload the texture again for every format we need to compress into.
Theoretically the CLI tool could accept to encode many textures in a single invocation (e.g. encode A.png into A.etc1.ktx A.etc2.ktx A.bc1.ktx and B.etc1.ktx B.etc2.ktx B.bc1.ktx) but we were worried that could complicate the code and make its integration with Godot harder. Additionally it’s hard to write a generic tool interface that would take advantage of such command line syntax.
What is texture compression and why you care
GPUs have precious limited available RAM. Too many big textures and you can see yourself running out of RAM.
When that happens, the GPU driver may fallback to streaming from regular system RAM over the PCI-E bus.
When this works, a significant performance degradation can happen.
diff --git a/article/beyond-100000-you-re-breathtaking/index.html b/article/beyond-100000-you-re-breathtaking/index.html
index 9c51cd0f66..c034e465ad 100644
--- a/article/beyond-100000-you-re-breathtaking/index.html
+++ b/article/beyond-100000-you-re-breathtaking/index.html
@@ -1,8 +1,9 @@
"You're breathtaking!"Sketch of Keanu Reeves at the 2019 #XboxE3 event
Beyond #100000: You're breathtaking!
By:
diff --git a/article/bugs-lets-catch-em-all-saturday/index.html b/article/bugs-lets-catch-em-all-saturday/index.html
index 86fb919a39..521da73c4e 100644
--- a/article/bugs-lets-catch-em-all-saturday/index.html
+++ b/article/bugs-lets-catch-em-all-saturday/index.html
@@ -3,8 +3,9 @@ We propose to have a special bug hunting day on Saturday, 9 December, to focus o
We propose to have a special bug hunting day on Saturday, 9 December, to focus on fixing the bugs reported for the 3.0 milestone. Testers are also encouraged to use this opportunity to file new bug reports, after checking existing issues for potential duplicates.">Bugs: Let's catch 'em all this Saturday 9 December – Godot Engine
This article is from December 2017, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Both testers and developers are doing a great job, but we need to go ever faster to get Godot 3.0 out as soon as possible - especially now that the master branch is in feature freeze, meaning that new features will have to wait for Godot 3.1 to be merged.
Bug hunting day on Saturday 9 December
We propose to have a special bug hunting day tomorrow (Saturday 9 December), to focus on fixing the bugs reported for the 3.0 milestone. Testers are also encouraged to use this opportunity to file new bug reports, after checking existing issues for potential duplicates.
How does it work?
Join us on the developers’ IRC channel (#godotengine-devel on Freenode, also accessible from Matrix) to discuss issues and potential fixes live, and pick any bug in the 3.0 milestone to try to fix it. To avoid potential conflicts/duplicated work, add a comment in the relevant issue to state that you are working on it.
If you don’t know which issue to start with, check the Hero Wanted! selection which lists bugs with useful debugging information and/or some hints about how to fix them.
The event will start as soon as someone is awake in the channel on Saturday (our contributors from Asia and Australia will get to start :)), and will continue for the whole day over the globe’s timezones.
You’re free to join for one hour or for the whole day, the important is that we fix issues and get to know each other at the same time. There should always be plenty of experienced devs around to help you get started if you are not very familiar with Godot’s source code.
This article is from December 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
2021 is quickly approaching and in the Godot community we are starting to prepare for next year’s GodotCon!
As you might know, each year we attend FOSDEM, the major Free and Open Source event in Europe, and we use the opportunity to organise our own small conference as a fringe event: GodotCon! A meetup for contributors, users and interested people to socialize, collaborate and share knowledge.
Sadly, given the uncertainty regarding international travel and the possibility to host big gatherings, FOSDEM has decided to go online-only for next year’s edition and we are taking the same decision for our own GodotCon.
It’s not all bad news because as much as we’ll miss meeting each other in person, we must see it as an opportunity for everyone to participate, no matter where they are located.
So, what’s the plan?
Online GodotCon 2021 will happen on the 23rd of January (the weekend before the Global Game Jam ;)) and will consist of a video stream with pre-recorded talks and a community platform to host chat and Q&A.
We decided to go for pre-recorded event as this will be our first fully online event and we would like to simplify its technical complexity so everyone has the best experience. This will also make it more comfortable for users to present if GodotCon is happening at an impractical time for their timezone.
We are preparing a way for users to submit questions for the presenter to answer, we will share more info on this topic closer to the event.
As usual for Godot events, Online GodotCon 2021 will be free of charge, and the video streams will be available to replay after the event. More precise details on the streaming and chat platforms, as well as start and end time, will be announced in coming weeks.
Call for participation
Over the coming weeks, we encourage anyone interested to send us proposals for talks, workshops or any other idea you would like to host. GodotCon is an event made by Godot users, so we need you to propose content that will make it a great event for all attendees.
We are interested in any Godot-related topic. It can be a talk about your own Godot project, the tricks you’re using in your workflow, a specific feature or plugin that you developed in the engine, etc. We’d like to have diverse speakers and topics, so if you’re using Godot for non-gaming topics (education, research, non-game apps, etc.), you’re also very welcome to share this with the community. Basically, feel free to propose anything that you think could be worth sharing with fellow Godot users and/or contributors.
As an indication, we propose a duration of 20 minutes (+ 5-10 min Q&A) for talks, though you can tell us if you’d prefer a different format. A 5 min presentation of your game would be welcome, and a 40 min talk is fine too if the topic is worth it :)
Please send your proposals to godotcon at godotengine · org with the following information:
Type (talk, tutorial, live demo… anything you think would be fun to see)
Title
Abstract (short description of what it will be about)
Preferred communication method (for us to contact you)
Don’t overthink the above too much, we’d prefer to know ASAP who may give a talk, and we can fill in more details later on.
For inspiration, feel free to review the schedules of past events for a glimpse at the kind of activities that we usually have (Brussels 2019, Poznań 2019, Brussels 2020).
We will schedule the event as soon as possible and get back to you if we accept your presentation so you can start working on it. Please, try to send your proposals before the 31st of December so there is plenty of time to schedule and prepare it.
More questions?
For any other questions, please, don’t hesitate to write to that same mail (godotcon at godotengine · org) and the GodotCon team (Aina, Ilaria, Julian, and Wojciech) will try to solve your doubts.
Thanks everyone and we hope to see you at our first Online GodotCon 2021!
Previous
diff --git a/article/call-participation-godotcon-2019/index.html b/article/call-participation-godotcon-2019/index.html
index bb47cd6b25..e994440c00 100644
--- a/article/call-participation-godotcon-2019/index.html
+++ b/article/call-participation-godotcon-2019/index.html
@@ -1,8 +1,9 @@
Call for participation for GodotCon 2019 – Godot Engine
This article is from December 2018, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Last month we announced the GodotCon 2019 in Brussels (4-5 Feb 2019), as well as a contributors-focused Godot Sprint (31 Jan & 1 Feb 2019) and our stand at the FOSDEM 2019 (2-3 Feb 2019).
We have a few updates since then:
We found a venue for GodotCon and the Godot Sprint: it will be at the Ludus Académie, like last year (Quai du Commerce, 48, 1000 Brussels). Thanks a ton to the Ludus staff and students for generously hosting us another year :)
Our stand at FOSDEM was confirmed! We’re still waiting on an answer to Juan’s talk proposal.
Update: Juan’s main track at FOSDEM was just confirmed! Stay tuned for details.
If you haven’t done so yet, we encourage you to book accommodation in the vicinity of the Ludus Académie (OpenStreetMap). Note that Brussels public transportation network works quite well, so it’s fine if you’re staying a bit further away.
You can still register! We currently have more than 50 persons registered for GodotCon, and expect more to register until the event, as well as 25 contributors signed up for the Godot Sprint. Both events are going to be a lot of fun :)
The next step is to define our line-up of speakers for GodotCon, who will be giving talks, workshops or other activities. That’s where we need you to step up!
We’re interested in any Godot-related topic. It can be a technical presentation of upcoming engine features, a talk about your own Godot project, the tricks you’re using in your workflow, a workshop about a lesser known feature of the engine, etc. Basically, feel free to propose anything that you think could be worth sharing with fellow Godot users.
As an indication, we propose a duration of 20 minutes (+ 5-10 min Q&A) for talks, though you can tell us if you’d prefer less or more time. A 5 min presentation of your game would be welcome, and a 30 min talk or workshop is fine too if the topic is worth it :) Even longer workshops could be imagined (e.g. 1h or 1h30) – we’ll have several rooms so we could run a long workshop in one room while shorter talks happen in another one.
Please send your proposals to remi at godotengine · org, with the following information:
Type (talk, workshop, round table, live demo, live tutorial… feel free to think outside the box)
Title
Abstract (short description of what it will be about)
Expected duration
Don’t overthink the above too much, I’d prefer to know ASAP who may give a talk, and we can fill in more details later on.
Note for Godot Sprint attendees: don’t hesitate to also propose talks, workshops, dev discussions, etc. for the Sprint. We’ll have two days to focus on contribution work (engine, documentation, tutorials), and it’s up to all of us to make it a great knowledge-sharing event.
Previous
diff --git a/article/call-volunteers-organizing-regional-communities/index.html b/article/call-volunteers-organizing-regional-communities/index.html
index 8927caeba8..3022bfda75 100644
--- a/article/call-volunteers-organizing-regional-communities/index.html
+++ b/article/call-volunteers-organizing-regional-communities/index.html
@@ -1,8 +1,9 @@
Call for volunteers for organizing regional communities – Godot Engine
This article is from February 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Godot communities keep growing steadily around the world. As a result, in the past years, many local groups related to Godot usage and development have started to appear in different continents, countries and cities.
Each of them usually has their own model and activities, but often suffer of visibility problems, as it is difficult for Godot users in those regions to know such groups exist and what they do.
Connecting the communities
After much discussion, we decided it could be useful for them if we could keep track of what they do and publicize their existence and activities in our official channels. This way, nearby users can find about those groups and engage in their activities, or use other groups as models to create their own if none exists.
Additionally, having a better idea of where Godot communities are can make sure the project can help them in a more “official” way, from encouraging and helping them to participate in local gamedev events, to creating materials they can use for workshops and talks.
Regional Communities team
Unfortunately, Godot as a project does not currently have enough experience or resources to be able to do this task, and the project management is too busy coordinating the engine development itself. Because of this, we came up with the idea to do a call for volunteers, hoping some experienced organizers may be willing to take on this task.
The plan is to form a Regional Communities team that can work together on these tasks. There are no rules on how this team will assign responsibilities to its members. As most things in Godot development, it will be up to the volunteers to discuss, agree and organize.
The Regional Communities team would be composed of organizers of regional communities, and any other contributor interested in helping with the meta-organization of all Godot communities.
To clarify, we’d like all existing regional communities organizers to join the Regional Communities team, if only to share information about your own community. And then we’d want some of the team members to help with any infrastructure, web development and communication work needed to make regional communities visible and efficient.
Tasks
Our initial idea for tasks in the Regional Communities team would be:
Reach out to all Godot communities around the world.
Work with the admins to create a more centralized flow of information of what is going on. If activities happen in those communities, use our social networks to promote them.
Work on a local map of communities and representatives, similar to this one, that we can put in our community page.
Make the user groups page a more fancy portal, and help fill missing content.
Investigate video game development events around the world, large or small. Some may require asking people from different regions. Contact the event organizers to propose them Godot talks, then see who from our community would be willing to speak at each event.
Help local communities organize Godot events, game jams, workshops, etc.
Help communities share materials they created for use by other communities.
Volunteer profile
The project expects to find volunteers matching the following profile as best as possible:
Always being nice, able to listen and able to express your views politely.
Significant experience communicating with others, good social interaction skills and being a polite person.
Having a significant understanding of the game development communities in general.
Having some experience assisting game development events.
Joining the team
To get the team started, we created a #godotengine-regional IRC channel on Freenode, where we invite everyone interested in this new Regional Communities team.
For those not already familiar with IRC, we suggest using the open source Matrix communication platform (and its Riot.im cross-platform client app) which is bridged with Freenode IRC, and lets you have persistent logs even when you’re offline. Once connected on Matrix, you can join the bridged channel which is named #freenode_#godotengine-regional:matrix.org.
Eventually some motivated members of the Regional Communities team could look into ways to also bridge this channel with the official Discord server, to lower the entry barrier for all community managers.
From there, we can brainstorm together on additional tools that might be relevant to efficiently handle the team’s tasks.
See you around in the Regional Communities channel!
Previous
diff --git a/article/camille-mohr-daurat-hired-work-physics/index.html b/article/camille-mohr-daurat-hired-work-physics/index.html
index cfdf9dfeeb..2c08b8595e 100644
--- a/article/camille-mohr-daurat-hired-work-physics/index.html
+++ b/article/camille-mohr-daurat-hired-work-physics/index.html
@@ -1,8 +1,9 @@
Camille Mohr-Daurat was hired to work on physics – Godot Engine
This article is from December 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Thanks to a generous donation, I was brought onto the team to work part-time on improving the 2D and 3D physics engines for the next 6 months.
The main goal is to modernize Godot Physics 2D and Godot Physics 3D, the custom physics backends Godot uses internally for physics simulation.
For 3D physics: Bullet is currently the default physics engine, but this will change. Godot Physics will become the new default after improvements and no loss in functionality is verified. The reason being Godot Physics is lighter, simpler and easier to maintain. That will make 3D physics easier to use and more reliable for most use-cases out of the box.
Will it be still possible to use Bullet Physics in Godot?
Yes, Bullet will still be available as an official plugin for the cases where you need specific features.
And not just that, but Godot 4 improvements around GDNative will allow different physics engines to be easily integrated as plugins. This opens the possibility for Nvidia PhysX to be supported in the future.
For 2D physics: Godot already uses a custom engine so there will be no major change, although it will also be improved and optimized.
Plan in details
Though most changes will be done for Godot 4, some fixes and improvements that can easily be backported will be included in 3.2 updates.
Here is my general roadmap:
1. Add physics test framework
The first step is to add a series of physics tests for Godot that will help with physics engine maintenance.
Functional tests will be added to check for regressions and compare behavior between physics engines.
Performance tests will be added to evaluate and compare performance between physics engines.
These tests will be part of the official Godot demos. You can already check the progress for 3D and 2D.
2. Review and fix physics issues
With the help of other physics contributors, I will audit existing issues with Godot Physics 2D and 3D, review existing pull requests, and implement fixes in order to make the custom physics backends as stable as possible.
New cases will be added to the physics test framework based on these issues to keep it up-to-date.
3. Implement features for Godot Physics 2D/3D
The next step is to implement all needed features for the custom physics engines in order to match Bullet Physics (for 3D) and consider them feature complete for Godot 4.0.
The current list of features is:
Soft bodies (3D only)
Cylinder shapes (3D only)
Heightmap shapes (3D only)
Buoyancy (new feature for 2D/3D to allow objects to float in Areas)
4. Optimize Godot Physics
Godot Physics 2D and 3D will be improved in order to have good enough performance in the most common scenarios.
Optimizations include:
Broadphase improvements (using dynamic BVH tree)
Solver improvements (using jacobians)
SAT collision improvements
Adding multithreading whenever possible
The optimization task list might change depending on performance investigations on the physics engines.
5. Review of extra physics topics
Finally, depending on the remaining time I have, I will help move along extra features and improvements for Godot 4, based on some Godot Proposals.
You will be able to get development progress updates on this blog or by following me on Twitter.
Credits illustration: Robot Head model by James Redmond (fracteed) 2018
diff --git a/article/cfp-game-development-room-fosdem-2020/index.html b/article/cfp-game-development-room-fosdem-2020/index.html
index 671ea84488..5794ec1f3b 100644
--- a/article/cfp-game-development-room-fosdem-2020/index.html
+++ b/article/cfp-game-development-room-fosdem-2020/index.html
@@ -1,8 +1,9 @@
CFP: Game Development room at FOSDEM 2020 – Godot Engine
This article is from October 2019, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
We are happy to announce that we will be organizing a Game Development devroom at FOSDEM 2020! The event will take place on 1st and 2nd of February at the usual venue in Brussels, Belgium. The devroom will last for a full day (most likely Saturday, but not set in stone yet).
Note: While this CFP is published on Godot’s blog, we want to outline that this FOSDEM devroom will be about Free and Open Source Game Development at large, and not focused on Godot Engine. We will assess all proposals independently of the engine or framework used, as long as it is free and open source.
About the Game Development devroom
Open source is often neglected in the game industry—and the reverse is also true: game development is often neglected in open source. We want to present that it is possible to combine the two. In particular, Godot being an open source game engine is a proof of that.
We want to present open source tools to make games. That not only include engines but also asset-making tools. There are many industry-grade open source tools which are growing in use in the gamedev world. Software as Blender, Krita, GIMP, Ardour, LMMS, etc. can be applied to any kind of game.
More importantly, we want to present games made with those tools. We want to hear the benefits, the insights, the hurdles, the challenges, the sleepless nights and everything. Real examples are always a great inspiration for other game developers, even (or maybe especially) when things don’t go perfectly. Talking about changing tools is welcome too (either from proprietary to open source, or between FOSS solutions), as we can hear a perspective about the differences between them.
Also, we want to hear about open source games. What are the issues with those and the benefits, and whether it can be a viable business model.
Call for participation
This is the point where we ask you to participate. Even though we from Godot are organizing the room, we want to hear from people using other engines and tools as well. There’s no discrimination, we want to hear experiences from everybody (even if are you moving out of Godot for some reason).
We ask you to submit the proposals through FOSDEM’s pentabarf system at https://penta.fosdem.org/submission/FOSDEM20. If you already have an account, please use the same as they show speakers’ participation across the editions. We’ll be using that system to organize the schedule. Please take your time to fill up the fields, especially the descriptions, as that will be shown on FOSDEM website and booklets.
The topic can be anything related to open source together with game development, be it tools or games.
The time slot for presentations is 25 min including questions (if you think your topic would fit better in a longer time slot, feel free to contact us to discuss it – see email below).
diff --git a/article/change-image/index.html b/article/change-image/index.html
index db555b14aa..fb519b8e5f 100644
--- a/article/change-image/index.html
+++ b/article/change-image/index.html
@@ -1,8 +1,9 @@
This article is from September 2016, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Image
Godot has many built-in types. Built-in types are used for non-pointer API arguments, where you need to pass around information fast and you don’t really care much about keeping a reference.
One of the early built-in types in Godot is Image, which is like a Vector, but with a little more information related to image data (such as width, height, format and whether or not it has mipmaps).
Origins
I tried to track down an early version of Image class and could find this from 2006.
You can see an old Macro from when we used Tolua++ to interface! Back then Godot (or what little was of it) ran on the Nintendo DS and Sony PSP, so indexed texture compression was the most common! Other than that, and save for many helpers for dealing with image processing, this class has not changed much in years.
Present
With the excuse of compatibility, new formats piled up over a decade to end in their current state.
Some stuff we added was:
YUV textures, so we could send them to a video buffer and do conversion in GPU. This was, however, pretty hacky to do in the end and did not improve performance that much over an SSE conversor.
BC texture compression, which is the most common on PC and consoles.
PVRTC texture compression, which is common on Apple devices.
ETC texture compression, used by Android devices.
Also ATC, used by Qualcomm, which is kind of the same as S3TC with different ramp values to work around patents.
Ability to send custom data to a texture. We used this when working in PSP and PS3 games, so we could load texture data swizzled (old GPUs expected you to load texture data in a special format friendlier to cache, nowadays GPUs can rewire memory to work around this limitation or use texture formats which are already swizzled).
Two decades ago, everyone wanted to make their own graphics API and protect it with patents, so texture compression algorithms were all patented and barely no one wanted to bet on open APIs. To say the truth, only NVidia kept OpenGL kicking, as Intel and AMD support for it were a mess. As a result, there are plenty of competing texture compression formats (out of which only PVRTC is truly innovative IMO, but also patented). PC and consoles generally supported S3TC, but on mobile no GPU manufacturer wanted to lose money to S3 patents so each used their own compression format (or no compression at all, like ARM MALI).
For Apple devices PVRTC is somehow standard, but on Android this is a mess. Google tried to improve the situation by making ETC the standard in all Android devices, but this compression only covers opaque textures.
Future
As Godot 3.0 will remove a lot of compatibility in exchange for many improvements, and given we already started work on a new renderer, this became a great opportunity to clean up this class.
Many formats and naming conventions are now obsolete, and new formats became common. As such, Image is going through a clean-up:
The following changes happened:
Renamed all formats to a more standard convention including formant, components and bit depth.
Dropped YUV (may come back, but we are slowly moving to use native APIs for video playback, or built-in libraries for playing into a texture).
Added floating point types (float and half float).
Renamed BC to have a less-Microsoft naming (I know DXT is also a Microsoft name, but it’s the one used by the OpenGL extension).
Added ETC2 format, which is now standard in OpenGL 4.3, OpenGL ES 3.0 and Vulkan.
Removed custom format, as its use case is no longer relevant.
When OpenGL ES 2.0 and non-Vulkan based devices and GPUs become obsolete enough, we’ll probably have to rewrite this API again to remove all the extra unnecessary formats, but this won’t happen for some years. Feedback welcome!
Previous
diff --git a/article/code-of-conduct-godot-community/index.html b/article/code-of-conduct-godot-community/index.html
index 20651f1a1c..e47b075130 100644
--- a/article/code-of-conduct-godot-community/index.html
+++ b/article/code-of-conduct-godot-community/index.html
@@ -1,8 +1,9 @@
Code of Conduct for the Godot community – Godot Engine
This article is from November 2019, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
The Godot community now has a Code of Conduct, which applies to all users and contributors on all Godot community platforms, both online and at Godot-related events.
It defines common sense guidelines to ensure that our community platforms are a safe and welcoming environment for all Godot users. By interacting with other participants in the Godot community, you agree to respect the terms of the Code of Conduct.
During the past five years of free and open source, collaborative development, we’ve been blessed with one of the best-behaved online communities that I have been in contact with. The vast majority of users on all our community platforms dearly care both for the Godot project itself, but also for all their fellow participants.
Yet there are occasional outliers, and to properly moderate an ever growing community (more than doubling in size each year) we need a written statement for the de facto guidelines that our moderation teams have applied until now. This will give users a clear overview of our expectations for positive and respectful behavior. Community moderators, who are also participants donating their free time to ensure a safe environment for all users, will therefore be able to back their decisions with common guidelines.
While we agreed many months ago with core contributors to introduce a Code of Conduct to that effect, it took us a while to finally write it down and ensure that it fully describes our values and expectations. As existing documents used by other projects did not fully satisfy our requirements, we finally decided to write our own.
Visit the Code of Conduct page of this website to read the full guidelines.
The page also includes the contact details for the Code of Conduct team and its members, who are in charge of reviewing and acting upon any reports of participants breaching the Code of Conduct.
The document was written by the Godot Project Leadership Committee with help and reviews from various other core contributors and platform moderators.
Previous
diff --git a/article/collaboration-with-google-forge-2023/index.html b/article/collaboration-with-google-forge-2023/index.html
index f875f9fec0..15d34a6158 100644
--- a/article/collaboration-with-google-forge-2023/index.html
+++ b/article/collaboration-with-google-forge-2023/index.html
@@ -1,8 +1,9 @@
Announcing a collaboration with Google and The Forge – Godot Engine
This article is from December 2023, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
We are excited to announce that we have partnered with Google and The Forge to bring some helpful performance optimizations to our Vulkan mobile backend. This will primarily benefit users targeting Vulkan-capable mobile devices.
Google is committed to enhancing the Android gaming ecosystem by ensuring that Vulkan is well supported across many games, game engines, and devices. Lucky for us, this means that they have decided to help us ensure that our Vulkan mobile renderer is as efficient as possible.
The Forge is one of the premier developers in the world specializing in building custom game engines and rendering solutions as well as optimizing existing game engines.
The Forge will spend the next several months working on Godot and bringing their expertise to our engine. They will be assisted by experts at Google and, of course, Godot contributors.
We are excited to welcome The Forge into the Godot pool of contributors and we are very thankful to Google for their assistance as well!
The end goal for all of us is to create an amazing ecosystem for games on Android. We are happy to already participate in that ecosystem and look forward to allowing game developers to push their ideas even further with Vulkan.
Previous
diff --git a/article/communications-update-2023/index.html b/article/communications-update-2023/index.html
index 5f02fbd36c..6d17e4caf4 100644
--- a/article/communications-update-2023/index.html
+++ b/article/communications-update-2023/index.html
@@ -1,8 +1,9 @@
Prepare to hear a lot more from us! – Godot Engine
This article is from December 2023, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
As a non-profit organization in charge of an open-source project, transparency is important to us at the Godot Foundation. The project wouldn’t function without its incredibly dedicated community, and we want to listen to your requests asking for clearer communication and avoid giving anyone the feeling of being left out as we grow. This will happen not only in the form of the upcoming Financial Report, but include the smaller things too: introducing the people behind their screen names and sharing insights into the daily life of the someone working for the Foundation, for instance.
One way to implement these wishes: an increasing and louder social media presence! And since the programmers themselves are quite busy coding, the Foundation is welcoming Nathalie Galla, who will henceforth be in charge of Community & Communications at Godot. Together with Executive Director Emilio Coppola, she will build the basis for a growing communications team. This includes but is not limited to: shaping the new social media presence of the Foundation, handling public relation matters like press releases and influencer outreach, and aiding in the organization of community events.
Which leads us to another often encountered ask: more interaction with users of the Godot Engine, especially those not working on contributions themselves. The game developers that trust Godot’s continuous progress and ambitions, who decide to make their games and projects with us. Therefore, we are already working on ways to more efficiently gather feedback and better handle proposals. To get started, please fill out this Google Form so that we can compare expectations before setting a course.
Lastly, even though we only require funding to sustain our efforts and are never looking to turn a profit, we of course cannot neglect marketing efforts completely. The reasons stretch from wanting to welcome more diverse voices into the community, people who simply have not encountered Godot before, to hoping that our reach can be used to amplify community projects. Please follow us on the journey ahead!
Previous
diff --git a/article/community-forum-back/index.html b/article/community-forum-back/index.html
index 5d2aac4626..72fa6f5804 100644
--- a/article/community-forum-back/index.html
+++ b/article/community-forum-back/index.html
@@ -1,8 +1,9 @@
The community forum is back! – Godot Engine
This article is from April 2016, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Godot Developers forum
The community asked for it, and the community made it! The new Godot Developers forum is live and ready for you to use it!
Godot used to have an official forum alongside the other community channels, but when designing our new website, it was decided to publish it even though we did not have the time and infrastructure to setup a new forum (and most importantly to migrate the old posts into the new database).
Still, many members of the community expressed their wish for a traditional forum to use for general discussion about Godot, advanced support requests and to showcase projects. Some community members thus decided to setup a forum themselves, on their own hosting and using SMF. With the blessing of the core Godot developers, they did an impressive work to migrate the old database and design cool features and branding for their forum.
A heartfelt thank to Timo (toger5) and Kiori for their dedication, and we hope that you will all have a good experience on this new community forum. Make sure to read the various announcements about the forum rules and how to use its specific features!
YouTube channel and games showcase
To celebrate this new forum and the recent 2.0 release, we also published a video showcase of some of the nice games being developed with Godot. Thanks a lot to Andrew Conrad and Freeman for editing the video and composing the soundtrack respectively.
We also have an official YouTube channel to post such videos; we hope to do some more of these showcase videos in the future, and also trailers to show the features of new Godot releases.
This article is from October 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Introduction
Hello! bruvzg here, I got hired by the Godot team to work on the complex text layouts and BiDi aware UI implementation. This is the first part that focuses on TextServer API implementation.
Currently, text display in Godot Engine is extremely limited, text is drawn character-by-character, left-to-right without kerning and support for any other font features.
Godot is incapable of correctly displaying text in the languages that are written right-to-left (e.g. Arabic, Hebrew), have context-sensitive characters (e.g. Arabic positional shape-forms) and ligatures or character reordering (e.g. Devanagari consonant placement).
How does this work?
Since Godot is game engine and CTL support is slower than simple text display and can (depending on the set of supported features) substantially increase the size of the exported project, and is not required for every game, CTL support is implemented as standalone TextServer module, that can be disabled, or easily moved to the GDNative library in the future.
Here’s TextServer API in the current state (API is not final and is subject to minor changes during further development): https://bruvzg.github.io/textserver-api-overview.html
Preparation work
wchar_t type that was previously used by Godot to store Unicode string, is inconsistent and have different size on different platforms. Due to lack of UTF-16 surrogate pair support Godot was incapable to store and display character outside the basic multilingual plane (characters with the codes above 0xFFFF, e.g. emojis) on Windows, where wchar_t is 16-bit.
For the ease of TextServer and GDNative interface development, Godot strings were changed to always use C++11 char32_t type and store string in UTF-32 encoding.
diff --git a/article/complex-text-layouts-progress-report-2/index.html b/article/complex-text-layouts-progress-report-2/index.html
index 624091a06a..372e432317 100644
--- a/article/complex-text-layouts-progress-report-2/index.html
+++ b/article/complex-text-layouts-progress-report-2/index.html
@@ -1,8 +1,9 @@
Complex text layouts progress report #2 – Godot Engine
This article is from November 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Introduction
This is the second part of my work on Complex Text Layouts for Godot 4.0, focusing on Fonts and UI mirroring.
Since font handling was moved to TextServer, some substantial changes were made to the Godot Font and related classes:
BitmapFont, DynamicFont and DynamicFontData were removed and replaced with universal Font and FontData resources which are backed by TextServer. This provides cleaner font fallback/substitution and possibility for custom text servers to expose different types of fonts without interface changes, for example direct access to the system fonts.
The new Font class provides new functions to draw and measure multiline text, and apply alignment.
Font and outline size, that were properties of the Font instance, are moved to the arguments of the draw functions and theme constants. This allows changing font size for individual draw calls, controls, or spans of text in the RichTextLabel control without creating new Font instances.
Functions for loading font data from the memory buffer are exposed to GDScript and GDNative.
Font substitution system for scripts and languages
A new, smarter font substitution system is added:
Each FontData has an associated list of supported scripts (writing systems) and languages. For a TrueType/OpenType fonts, a script list is populated automatically from the OS2 table, but it’s not always precise.
Script and language support can be overridden by the user.
For each run of text with a specific script and language, TextServer will try to use fonts in the following order:
Fonts with both script and language supported.
Fonts with script supported.
Rest of the fonts.
Here’re a few cases of manual override:
Many Latin fonts have a limited set of Greek characters for use in scientific texts (and such fonts usually have Greek script support flag set in the OS2 table), but it’s not always enough to display Greek text. Adding a separate font with full Greek support, and disabling Greek support in the main font will prevent TextServer from mixing characters form different fonts.
TrueType/OpenType font tables do not have flags for rare/ancient scripts (e.g. Egyptian hieroglyphs), enabling script support manually will speed up font substitution.
Some languages use the same script, but different font styles (e.g. Kufic, Naskh and Nastaʼlīq writing styles preferred for writing different Arabic languages; or the use of traditional Chinese characters in different regions and CJK variants - Traditional Chinese, Simplified Chinese, Japanese, and Korean). Setting language overrides allows to seamlessly use the same font stack for the text in different languages and get the desired style.
Incorrect font used for “μ”:
diff --git a/article/complex-text-layouts-progress-report-3/index.html b/article/complex-text-layouts-progress-report-3/index.html
index c03126d25b..92a2f8ad2b 100644
--- a/article/complex-text-layouts-progress-report-3/index.html
+++ b/article/complex-text-layouts-progress-report-3/index.html
@@ -1,8 +1,9 @@
Complex text layouts progress report #3 – Godot Engine
This article is from December 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Introduction
This is the third part of my work on Complex Text Layouts for Godot 4.0.
Existing alignment tags ([left], [center], [right], [fill]), as well as new base direction, structured text override and language paragraph options are combined to the single [p] tag. Standalone alignment tags are still available for compatibility.
This article is from February 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Expecting a Vulkan progress report? Not this month! As Godot 3.2 was released by the end of January, February was purely dedicated to do large core refactoring in preparation for Godot 4.0. This is required to unblock other contributors and their areas.
Core refactoring?
Godot 3.0 was released more than two years ago. With it, the amount of Godot users kept growing quickly and steadily. While a lot of core changes happened in 3.0, we were far from doing everything we wanted because it would have taken forever. With the upcoming Godot 4.0, opportunity has arisen yet again to do improvements and refactoring to Godot core.
Following is the list of changes made so far during February:
Refactored ObjectID and Variant
This is mostly an internal change that most users won’t see outright but, besides improving performance considerably, it allows to fix a design flaw in Godot 3.0, where it was not always possible tell if an object instance was freed or not, resulting in bugs that could not be fixed. This is no longer a problem in the 4.x branch. After it gets some testing, it may get cherry-picked for 3.x branch.
Removed PoolArrays (PoolVector in C++), replaced by PackedArrays
Godot offered PoolArray as a type of variable, which was useful for storing large arrays in a compact way. They were designed for 32 bits CPUs with small address space, to allow packing memory and avoiding memory fragmentation.
Given pretty much all mainstream platforms are now 64 bits, this optimization is no longer required (64 bits operating systems have efficient memory allocation for large objects, putting them on opposite ends of the address space, which reduces memory fragmentation to the point of making it not a problem).
Having tightly packed arrays available to the user still makes sense, because regular script array ([]) elements are 24 bytes (containing a Variant). Having packed versions (including bytes) is desired, so they are renamed to “PackedArrays”.
This change also improves performance in all operations related to large memory allocations, as locking/unlocking is no longer required. As a side effect, put_pixel/get_pixel in images no longer requires locking either.
Reworked signal system to use Callables
Godot now has a Callable type. This allows having a generic interface for calling things from an object. Within GDScript (and C#, as well as other languages) this means more efficiently connecting signals to methods via first class function support (which was not available before) and eventually Lambda expression support on the API for all languages. Signals are also provided as a type, so this type of syntax became valid:
Besides this, this change allows to improve the internal C++ binding system, taking advantage of C++17 variadic argument templates to do all internal signal connections, without having to register them via ClassDB. It will also help improve usability and performance of C++ via GDNative.
Support for named binds in Skin.
Skin system was added in Godot 3.2, but it lacked named binds. This avoided you from merging objects with similar skeletons together (as an example, clothing exported as a separate scene to use for customizing a character).
Named binds ensure that, as long as the bone name exists, the mesh will be able to bind to it. This improvement may eventually be cherry picked to Godot 3.x branch too.
This is not strictly a core change, but was requested by users due to the limitations of the new system.
Support for StringNames in binding system.
A lot of APIs in Godot use StringNames instead of Strings. StringNames are special types that contain a unique pointer to a string. When assigned a String, the pointer is always assumed to be the same for that string (no matter when it was assigned), ensuring comparisons are much faster than actual string comparisons (because it’s just a pointer comparison).
There are plenty of APIs in Godot that do this for efficiency, like names, method names, property names, class names, animation names, shader parameter names, skeleton bone names, translations keys, etc (the list is very long actually).
Unfortunately GDScript and the binder (for C# and other languages) did not support this type, and all these functions received regular strings, which where very inefficiently converted to StringNames on each call.
With this change, users can pass StringNames directly to the Godot API and improve performance in critical areas.
Support for integer vector types
This was a widely requested feature by our users, specially for GDScript. It’s useful for games which require cell based integer vector logic in 2D and 3D. Using floats for vector types in these types of games was wasteful and prone to error.
The following new types were added:
Packed arrays are now references in GDScript
Users often complained that PoolArrays were immutable types, so accessing them inside sub-arrays, dictionaries, etc. or passing them to/from functions would always create copies.
In the 4.x branch, besides no longer being pool based, they became references.
Packed float and int arrays support 64 bit versions
GDScript uses 64 bits for scalar float and integer, but packed arrays are only 32 bits. Many users requested 64 bits to store more data, so these versions were optionally added.
Refactored threaded resource loading
Godot had the old “ResourceInteractiveLoader” class for background loading. This was a vestige from an era where Godot ran mainly on single core devices. While the engine supported loading resources on threads for a long time, the actual loading process (including dependencies) was single threaded.
This is no longer the case in the 4.x branch. The new API is much simpler to use and can take advantage of as many cores as available by your CPU to do resource loading. This results in 4x to 6x performance increases, and in considerably improves the usability for background loading.
Future
March will probably be another for core refactoring, and my Vulkan work will resume in April. The main goal for this month is to perform the separation of OS class into OS and DisplayServer. This will allow several things to happen:
Support for multiple windows (Editor support may or may not happen for 4.0, depending on time).
Implementation of Wayland and Linux+EGL (needed for official Raspberry PI support) back-ends.
General clean up of the API, which is messy.
As always, all this work is is done out of love for everybody making games, and because we believe the world needs quality free and open source game technology. If you are not yet, please help us by becoming our patron.
This article is from March 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
As promised in my previous post, the core refactoring work I am undertaking took two months to complete. This means rewriting large parts of the core engine for consistency and features.
Core refactoring
Core refactoring is mostly work on the most low level, critical and shared parts of the engine. This work is done only on major versions because it implies breaking compatibility and introducing instability and bugs (because of all the new added code), which is actually the case right now. The major refactoring undertaken for Godot 3.x, two years ago, changed a large part of the internals, but we were unable to do everything we wanted to do.
The migration to Vulkan already implied breaking compatibility and, together with all the user feedback we got since 3.x was released, we have a very good idea of what needed to change in this time.
So following is the list of what changed during March:
OS / DisplayServer split
One of the largest singletons in Godot is the OS class. It allows access to low-level OS functions as well as window management.
This was cumbersome for many reasons and also imposed limitations, such as:
Having a large, bloated OS class on every platform.
Inability to support different display APIs in a single binary. This is specially visible in Desktop Unixes, where you can use X11, Wayland or even EGL directly on Raspberry PI.
Proper support for multiple windows. This not only allows the editor to make some docks float so you can move them to another monitor (a very requested feature by users). This is also useful for games developed for certain types of dedicated hardware, or just for tools created with Godot as the base platform (which is something several users do).
Impossible to run the engine as headless (with a dummy display driver) in all platforms. The “server” platform had to be used as a workaround (and will now be deprecated).
Difficult to abstract window management functions to users, which had to access the OS class directly (and which is not as user friendly as working with nodes).
The new implementation moves all low level window management to a new singleton, DisplayServer, which handles everything regarding display. To make implementation simpler and more portable, Godot will always assume you have one main window and, if platform supports, allow you to create sub windows.
Window node
The new DisplayServer allows managing multiple windows, but using it directly is still too low level and unfriendly for most users. To compensate, a new Window node has been introduced. This node inherits Viewport and gives it the ability to appear as a floating window. Working with it is easy: just place your nodes as children of Window! You can create UIs (with controls), or display the 3D world on it (just adding a Camera node). It’ s basically the same as a Viewport, so Using this new node is extremely easy and straightforward.
Additionally, the root node in Godot (get_tree().get_root()), which used to be of type Viewport, has now changed to be of Window type. If you want to manage the game window, simple access this node directly.
All input events, which were previously sent to the MainLoop class, are now sent directly from DisplayServer to Window (so MainLoop and hence, SceneTree have been stripped of this functionality).
Multiple Window Support in Editor
Likewise, the Godot Editor now supports making the docks float. For now, only docks and existing windows are supported but we will extend support for other parts of the editor.
It is important to note that by default docks will remain docked ** and nothing will change. Some users expressed concerns that we would now force them to always use floating windows. This **is not the case, you can make windows separate from the main one only if you want (like as an example, you have a second monitor and you want to make use of more screen-space), but by default nothing will change.
Embedded mode
But, what if you are working on a full-screen game and need to use windows? Or what about platforms which don’t support floating windows such as iOS, Android, HTML5 or even consoles?
One of the new features of this system is that the Viewport class can now be instructed to embed all children Window nodes and provide internal windows for them, so it will emulate a window manager within it, including decorations, resizing, title bar, close button, etc. This can be done manually by toggling the “embed subwindows” property.
At the same time the new DisplayServer can be queried for features and one of them is subwindow support, so the new root Window will check whether this is supported on each platform and toggle the property automatically. This is completely transparent to the user, so games (or the editor) don’t need to be change to run on platforms that don’t support subwindows.
If, for debug purposes, you want to run the editor (or your game) using subwindows instead of hardware windows, use the --single-window command line flag.
Node renames
The Godot scene system is known for its ease of use and its ability to represent your mental map as a data and file structure. That said, many node names were not clear or confusing. This is mainly evidenced when comparing their 2D and 3D counterparts.
Contrary to what many believe, Godot started as a 3D engine, but soon migrated to be a 2D one. This is why the 3D nodes don’t have any suffix (like Area) while the 2D ones do (Area2D). This made it very misleading for users, where its not always obvious whether you are using the 2D or 3D versions.
To solve this, Godot 4.0 will rename all 3D nodes and give them proper suffixes. Nodes like “Area”,”RigidBody” or “Light” will become “Area3D”, “RigidBody3D” and “Light3D” respectively.
Additionally, due to popular demand, the “Spatial” node will be renamed to “Node3D”, to further enhance consistency with the 2D engine.
A compatibility system has been added so older scenes will convert the node types to the new ones on load.
Server renames
Most servers in Godot are very old, and their naming conventions were by now obsolete. Because of this, most are being renamed:
VisualServer (a name that became even more ambiguous thanks to the introduction of DisplayServer) has been renamed to RenderingServer.
NavigationServer and PhysicsServer have been renamed to NavigationServer3D and PhysicsServer3D respectively.
Likewise, to add more consistency, Physics2DServer and Navigation2DServer are now PhysicsServer2D and NavigationServer2D.
Future
My work on core refactoring is mostly done, so next month (April) I will go back to working on Vulkan as promised. Hope to have new and exciting stuff to show by the end of next month!
And as always, please remember than our work on Godot is done out of love for you and the game development community, we want to provide you with a top notch free and open source game engine, so you can own your work down to the last line of engine code. If you are not yet, please consider becoming our patron and help us realize this dream sooner.
Previous
diff --git a/article/csharp-android-support/index.html b/article/csharp-android-support/index.html
index 3c23c4fc66..348c0ab8a0 100644
--- a/article/csharp-android-support/index.html
+++ b/article/csharp-android-support/index.html
@@ -1,8 +1,9 @@
C# support on Android – Godot Engine
This article is from July 2019, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
In this devlog I will be talk about what I have been working on for the last two months. There are some nice new goodies coming for C# users with Godot 3.2.
Before starting, I would like to announce that this work is possible thanks to a generous donation of $24,000 by Microsoft. This grant will be used to fund my work on C# in Godot for a year. This is the second time I receive a grant from Microsoft to work in Godot and I’m extremely grateful.
This article is from April 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Initially and for quite some time C# was only supported in Godot on desktop platforms. In the last year we made good progress extending support to Android and WebAssembly, and now it’s time to add iOS to that list as well.
In this progress report I’m also introducing a new way of working with Godot signals in C#.
This article is from July 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
In a past progress report I announced a Godot extension for
diff --git a/article/csharp-wasm-aot/index.html b/article/csharp-wasm-aot/index.html
index fc04a5697d..f695783772 100644
--- a/article/csharp-wasm-aot/index.html
+++ b/article/csharp-wasm-aot/index.html
@@ -1,8 +1,9 @@
C# progress report: WebAssembly, MonoDevelop and AOT – Godot Engine
This article is from November 2019, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
There’s been some interesting progress going on with C# over the last few months since the first progress report as part of my work sponsored by Microsoft.
diff --git a/article/custom-sky-shaders-godot-4-0/index.html b/article/custom-sky-shaders-godot-4-0/index.html
index e8b5ca11b8..d7cd17e4c1 100644
--- a/article/custom-sky-shaders-godot-4-0/index.html
+++ b/article/custom-sky-shaders-godot-4-0/index.html
@@ -1,8 +1,9 @@
This article is from March 2020, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
Update (2020-03-24): The API has updated a little bit to reflect a problem explained in this pull request.
Update (2021-10-28): You can find a documentation page about Sky shaders in the Godot documentation.
A common problem facing users in Godot 3.x was the inability to create dynamic skies that update in real time. We aim to change that by introducing sky shaders.
If you are interested in the implementation, you can find the code on GitHub.
Sky resources
In Godot 3.x there were two Sky types, ProceduralSky and PanoramaSky. The common elements between the two came from the parent Sky class. In Godot 4.0, you will use the Sky class directly. The Sky class contains 3 properties:
Instead of subclasses, the behaviour of the Sky is contained in its Material. For all three *SkyMaterial types, users can select “Convert to ShaderMaterial” and edit the code directly.
PanoramaSkyMaterial
The PanoramaSkyMaterial behaves exactly the same as the previous PanoramaSky. Assign a panorama texture to the material and you are all done!
ProceduralSkyMaterial
The ProceduralSkyMaterial behaves very similarly to the old ProceduralSky with a few important differences:
Supports up to 4 suns.
Now updates instantly as calculations are done on the GPU.
Sun properties (direction, energy, and color) are pulled from the DirectionalLights in the scene.
These changes make the ProceduralSkyMaterial a great option for quickly putting together a sky when realism isn’t needed. It is easy to tweak and update and uses a lightweight shader to avoid consuming GPU resources.
PhysicalSkyMaterial
The banner image you see above is from a scene using the new PhysicalSkyMaterial. The PhysicalSkyMaterial is a new resource that draws the sky based on various physical properties, notable Rayleigh and Mie scattering. The PhysicalSkyMaterial is based on the Preetham daylight model (with a few hacks to make it more user friendly at the cost of physical accuracy).
The PhysicalSkyMaterial can only have one sun and it requires the presence of a DirectionalLight in the scene to illuminate the sky.
The main benefit of the PhysicalSkyMaterial is that you define properties of the sky and then plausible looking changes happen in the sky based on time of day (e.g. sunset and sunrise are automatic).
The PhysicalSkyMaterial is made to be fast and easy to tweak. There are more realistic models of daylight out there, if users need something more realistic they can use ShaderMaterials to implement their own sky models.
Sky Shaders
We anticipate that most users will be fine using one of the above three sky materials. But if you need more flexibility, or want to do something more complex (e.g. clouds or nebula) the Sky Shader system is designed to allow you to create whatever you need.
Sky Shaders are another type of shader that can be used in a ShaderMaterial.
This article is from April 2023, some of its contents might be outdated and no longer accurate. You can find up-to-date information about the engine in the official documentation.
This is Pedro J. Estébanez, a.k.a. RandomShaper in the Godot community.
You may already know that I have been implementing a Direct3D 12 rendering driver for Godot. Since the announcement that W4 Games donated my time working on that to the project, the code has received a lot of maintenance. In fact, the pull request still hasn’t been merged since there has been a continuous flow of improvements.
In this article I’d like to discuss specifically how I faced some of the challenges posed by different aspects of making shaders work. This was by far the most technically interesting area. Be warned that this piece is dense in technical information.
Translation of GLSL/SPIR-V to DXIL
Godot’s rendering architecture is built with the industry standard Vulkan graphics API in mind. And that’s great! However, once you want to plug new rendering APIs into the engine, you’ll find that some elements need to be wired in a manner that they work with the alternative API (Direct3D 12 in this case).
Shaders in Godot are written in its custom, very GLSL-like language. (The builtin shaders are already GLSL in the source code.) Shader code in this language is compiled by the engine (thanks to glslang) into SPIR-V, which is a well-defined format that stores the binary representation of a shader.
SPIR-V and Vulkan play nice. However, Direct3D 12 features its own binary shader format: DXIL. This format is structured as a container with its most important contained chunks being shader metadata and the compiled shader code in the form of LLVM bitcode (yes, the same kind of bitcode LLVM/Clang uses for an intermediate representation of the compiled code). As a consequence, this rendering driver would need a way to generate DXIL from either the GLSL or the SPIR-V representations of the Godot shaders.
First round: SPIRV-Cross
After assessing the available third-party libraries and open source projects capable of doing that (and license-compatible), I found SPIRV-Cross was the most sensible choice: it would translate GLSL to HLSL (the high-level counterpart of GLSL in the DirectX world). From that point, the D3D12 renderer would use the standard DirectX Shader Compiler library to compile HLSL into DXIL.
That worked quite well, but wasn’t without big headaches about writing the code that should match the resource bindings in the Vulkan-targeted shaders to those in the DXIL ones. I won’t delve into details on that here. Just know it required an insane amount of code and relying on certain SPIRV-Cross specifics. For now, the takeaway is that it was a hell of an approach, but worked in practice! (If you’re curious, in the first version of the pull request, you can see for yourself what I’m talking about.) This process also allowed me to make a few little contributions to SPIRV-Cross itself and learn its internals, which is always a good thing.
Second round: Via Mesa’s NIR
Months went by and I verified that Microsoft was making great progress with Dozen, the Vulkan-to-D3D12 translation layer found in Mesa.
Mesa was already capable of translating SPIR-V into its own intermediate representation (NIR), but Dozen would have added the ability to translate NIR to DXIL. That looked very promising because it would be a binary-to-binary translation (i.e., SPIR-V to DXIL). This would avoid having to go all the way back to a high-level language (GLSL/HLSL), which is slower and less convenient.
With some experimentation, I could make a shell script (included in the source code of the D3D12 renderer) that extracts from the Mesa source tree the relevant pieces of code to make the SPIR-V to DXIL translation possible.
I wouldn’t say that this integration was a piece of cake, but had major benefits in comparison to the SPIRV-Cross-based approach. For instance, the bindings matching issue was easily solved by a Godot-specific patch to the Mesa code by which the translation process gets some callbacks. With that mechanism, the D3D12 renderer is told about the original set-binding pair of every resource in the SPIR-V shader and then it trivially maps them to some register indices in the DXIL world with some simple arithmetic:
We can make such a liberal use of DXIL registers since they are logical, just a way of tagging the bindings. (In past versions that was not the case, as far as I can tell.)
Regarding the last multiplication, if we understand Vulkan numbered bindings as “slots” and so we do with Direct3D register indices, in principle there would be no reason for it. However, Vulkan slots can hold entire arrays, whereas D3D ones need one slot per array element. Therefore, with that multiplication we are reserving a big range of D3D bindings to account for however big a incoming Vulkan array may be.
The operation of mapping the Vulkan resource types (image, buffer, etc.) to their D3D12 counterparts (SRV, UAV, etc.) is not trivial. The exact resource type depends on extra attributes that decorate each binding, and even on actual usage! With the SPIRV-Cross approach, the Godot D3D12 renderer needed to do reflection on the DXIL shader to find out the D3D12 types the Vulkan ones ended up being mapped to (reflection was used for the bindings, too). In contrast, with the NIR-based approach, the callbacks mentioned earlier can also get information about which kind of Direct3D resource each binding is being translated to, on the go.
In conclusion, the NIR-based approach was kind of uncharted territory, but turned out to be much more convenient. I had to make a few PRs to Mesa to add or fix little pieces of translation logic to this part of Dozen, though. But again, that’s a great learning experience.
Specialization constants (creatively working around the lack thereof in Direct3D)
For the first version of the PR (the SPIRV-Cross + DirectX Shader Compiler way) I published a Twitter thread explaining how I approached this problem. Some parts are still true in the NIR-based PR. In any case, in this writeup I’m doing the full updated explanation of how it works now, so there’s no need to read the other one.
Vulkan features specialization constants (SCs from now on), which are some sort of compile-time constants in terms of optimization of the final shader code that runs on the GPU (branch pruning, informed loop unrolling, etc.). However, these are much more flexible, as they can be applied at runtime to create the graphics/compute pipelines with shaders already compiled to SPIR-V.
The closest in Direct3D is actual constants or preprocessor definitions in the HLSL code. That means that, in order to create multiple pipelines corresponding to different variants of the same shader, you have to compile multiple versions of the HLSL code with different values set each time at the source code level.
SPIRV-Cross does some work of assisting with that, making the process of patching the source code a bit more ergonomic, but the issue of having to re-compile the source is still present. Moreover, the PR in its current, definitive form is using an approach where the source code is not used at all (neither in GLSL nor translated to HLSL). Therefore, some way of applying different values to SCs for shaders compiled to DXIL is a must. (In the SPIRV-Cross way it was a nice-to-have feature, but patching HLSL and recompiling, even if very slow and forcing to store the source code in the shader cache, would have done the trick.)
The way Mesa approaches SPIR-V SCs is applying their values very early in the translation to NIR. In other words, a NIR representation is hardcoded to some specific set of SC values. That in turn leads to multiple DXIL versions of the shader. We don’t want that. Instead, our goal is to have a patchable DXIL blob (per shading stage) where the SC values are still unknown.
1. Dynamization of SC operations in SPIR-V
The SPIR-V specification defines a number of opcodes related to SCs, like declaring a SC that is true or false by default (SpvOpSpecConstantTrue/False) and doing logic/arithmetic on one of them (SpvOpSpecConstantOp with sub-opcodes for the specific operation).
Upstream Mesa’s SPIR-V to NIR code follows the SPIR-V specification on how to apply the SCs. In short, it replaces all the default values of them with any that has been provided by the caller code to specialize the shader and then runs all the operations offline with those now known values, “fossilizing” the shader on them. That unleashes optimizations like pruning conditional branches or pre-computing arithmetic operations wherever there are SCs involved, now their values are solid constants.
What I needed is that those operations are not performed offline, but be promoted to true dynamic operations, as if the original GLSL had used non-constant variables instead of SCs, and therefore not optimizable by now.
Mesa’s SPIR-V to NIR code is patched in the Godot D3D12 renderer to do precisely that. The values of the SCs are set to some carefully chosen magic sentinel value plus the SC id, so in a later step we can tell if a literal value corresponds to an SC, and which one.
Some extra NIR operations are added depending on the type of the SC. For instance, for a float, there’s some bit casting so the base value can be treated as a plain 32-bit integer but the shader eventually sees it as a floating-point value and thus does the right thing with it once patched.
2. Prevention of NIR level optimization
Mesa’s NIR machinery is powerful. It can apply a variety of optimization passes to the NIR representation of a shader. That’s awesome, but an issue for us because if we don’t inhibit it somehow, we end up again with a “fossilized” shader, only that this time it’s obeying some weird sentinel values instead of sensible SC values. Whatever the case, that’s bad for our purposes.
The core issues lies in the fact that NIR has a load constant opcode (nir_intrinsic_load_constant), which is used to “load” the sentinel value into some virtual register, and that the myriad of optimization passes NIR is run through can optimize it out (if it’s possible to pre-compute some ALU operation or however else take a static decision about the fate of that value, for instance).
The solution was simply to invent a new opcode (nir_intrinsic_load_constant_non_opt), which works exactly like the original one, but, by being in the end another one, is unkown to the optimization passes, which have no option but leaving it in place.
3. Obtaining patchable DXIL
The last thing we ask Mesa to do for us is generating DXIL from the nicely patched NIR we have at the moment. But our “deliverable” consists also of a table of the bit offsets to patch in the DXIL for each SC id.
I patched the code that emits constants to the DXIL stream so that it recognizes cases of SCs if they match the sentinel value mask. The rest of the bits are the SC id. On each occurrence, the corresponding callback is leveraged to provide the information to the Godot D3D12 driver. (It’s a bit more complicated than that, since the offset in the bitcode has later to be adjusted to match where the DXBC chunk ends up in the whole DXIL blob.)
4. Creating pipelines with patched DXIL
The Direct3D rendering driver is now able to apply whatever specialization constant values are needed to the already compiled shader, which was our initial goal.
Now I have to mention that LLVM bitcode is an akward beast and that it’s not trivial to patch a miserable integer due to variable bit-rate encoding. (Speaking of that, the former approach I implemented had a limit on the number of bits that could be patched. This imposed big limitations in the usable range of integers and imposed an elephant-sized epsilon for floating point ones; those have been happily lifted in the current one.)
This is the comparison of the assembly code produced by the same shader, only with different SC values, which allowed in the second case to optimize out a multiplication:
diff --git a/article/design-of-the-skeleton-modifier-3d/index.html b/article/design-of-the-skeleton-modifier-3d/index.html
index f87c5b7e2d..ed2155cea0 100644
--- a/article/design-of-the-skeleton-modifier-3d/index.html
+++ b/article/design-of-the-skeleton-modifier-3d/index.html
@@ -1,8 +1,9 @@
Design of the Skeleton Modifier 3D – Godot Engine
In Godot 4.3 we are adding a new node called SkeletonModifier3D. It is used to animate Skeleton3Ds outside of AnimationMixer and is now the base class for several existing nodes.
As part of this we have deprecated (but not removed) some of the pose override functionality in Skeleton3D including:
set_bone_global_pose_override()
get_bone_global_pose_override()
get_bone_global_pose_no_override()
clear_bones_global_pose_override()
Did the pose override design have problems?
Previously, we recommended using the property global_pose_override when modifying the bones. This was useful because the original pose was kept separately, so blend values could be set, and bones could be modified without changing the property in .tscn file. However, the more complex people’s demands for Godot 3D became, the less it covered the use cases and became outdated.
The main problem is the fact that “the processing order between Skeleton3D and AnimationMixer is changed depending on the SceneTree structure`.
For example, it means that the following two scenes will have different results:
If there is a modifier such as IK or physical bone, in most cases, it needs to be applied to the result of the played animation. So they need to be processed after the AnimationMixer.
In the old skeleton modifier design with bone pose override you must place those modifiers below the AnimationMixer. However as scene trees become more complex, it becomes difficult to keep track of the processing order. Also the scene might be imported from glTF which cannot be edited without localization, so managing node order becomes tedious.
Moreover, if multiple nodes use bone pose override, it breaks the modified result.
Let’s imagine a case in which bone modification is performed in the following order:
Godot 3.0 was released a few weeks ago, and the feedback we are getting so far is incredible. The new version is of course not perfect, but for a major compatibility breaking release with over 18 months of development, it seems to be pretty usable and satisfactory for most users.
Still, we still have many users who depend on the previous stable branch, 2.1, for various reasons:
They might need support for OpenGL 2.1 / OpenGL ES 2.0, which is missing in Godot 3.0, limiting it to higher end devices (especially on mobile). This support will come back with Godot 3.1, but in the meantime such users are stuck on 2.1.
They might have existing projects in development, or even already released, that they do not wish to port over to the new version. Migrating from Godot 2 to Godot 3 can be time consuming.
As such, we will continue to provide maintenance releases for Godot 2.1 until at least version 3.1 (to address point 1.), and likely a few months afterwards with only security fixes (for users with games in production as per 2.).
Godot 2.1.5 incoming
The previous stable version, Godot 2.1.4, was released in August 2017. Since then, there have been over 300 commits to the 2.1 branch, with bug fixes, enhancements, and even some new features.
We’ll go over the changes more in-depth in the actual release announcement, but until then, we need testers for this first beta 1 build! Download it and test it with your existing 2.1 projects (make sure to do backups or use version control, as always). If you spot any regression (something worked in 2.1.4 and is now broken), please make a bug report and mention it in the tracker bug.
In parallel, we’re also working on what will be the 3.0.1 release, with many bug fixes and enhancements to the current stable branch. Stay tuned for more info!
As mentioned in a previous blog post, we plan to continue supporting the 2.1.x branch for a while - at least until 3.1 is released, bringing back support for low and mid-end mobile and low-end desktop GPUs via OpenGL ES 2.0 / OpenGL 2.1.
The feedback on the previous 2.1.5 beta 1 build was relatively good, and many fixes have been done since, especially to the (still imperfect, but better) tool to convert 2.1 projects to the Godot 3 API.
Godot 2.1.5 incoming
The previous stable version, Godot 2.1.4, was released in August 2017. Since then, there have been over 300 commits to the 2.1 branch, with bug fixes, enhancements, and even some new features.
We’ll go over the changes more in-depth in the actual release announcement, but until then, we need testers for this new beta 2 build! Download it and test it with your existing 2.1 projects (make sure to do backups or use version control, as always). If you spot any regression (i.e. something that worked fine in 2.1.4 and is now broken), please make a bug report and mention it in the tracker bug.
In parallel, work on Godot 3.1 is still ongoing. Support for OpenGL ES 2.0 / OpenGL 2.1 for 2D was merged in the master branch recently, and karroffel is now focusing on the more complex 3D part.
Juan (reduz) implemented initial support for 2D meshes, and is now quite busy with preparations for GDC, where he will meet many companies as well as give a talk during our GDC Meetup at the GitHub HQ.
Other contributors are still quite active, and we’re slowly but surely reducing our backlog of awesome pull requests done by the community over the last couple of months.
There is still no ETA for 3.1, but basically we will wrap it up as soon as the 3D support via OpenGL ES 2.0 / OpenGL 2.1 is ready for production use.
Godot 3.0.3 in a few weeks
We will continue pushing bug fixes and improvements in a forward compatible way to the 3.0 branch (i.e. you should be able to use the newer versions on your existing 3.0.x project without logic change). Hein-Peter (TMM) did a great job so far on 3.0.1 and 3.0.2, and will continue doing so!
Unless regressions or critical bugs dictate it, we plan to have maintenance releases once a month or so, to keep you up-to-date with the latest and greatest in the stable branch.
Keep having fun working with Godot, and don’t hesitate to showcase your work on social media using the #GodotEngine hashtag!
As mentioned in a previous blog post, we plan to continue supporting the 2.1.x branch for a while - at least until 3.1 is released, bringing back support for low and mid-end mobile and low-end desktop GPUs via OpenGL ES 2.0 / OpenGL 2.1.
The feedback on the previous 2.1.5 beta 1 and 2 builds was relatively good, and many fixes have been done since, especially to the (still imperfect, but better) tool to convert 2.1 projects to the Godot 3 API.
Godot 2.1.5 is around the corner
The previous stable version, Godot 2.1.4, was released in August 2017. Since then, there have been over 350 commits to the 2.1 branch, with bug fixes, enhancements, and even some new features.
We’ll go over the changes more in-depth in the actual release announcement, but until then, we need testers for this first release candidate!
Download it and test it with your existing 2.1 projects (make sure to do backups or use version control, as always). If you spot any regression (i.e. something that worked fine in 2.1.4 and is now broken), please make a bug report and mention it in the tracker bug report.
The “toggle visibility” button in the SceneTree panel does not work for Spatial-derived nodes (#17722). It has been fixed in the 2.1 branch after the RC 1 build was made.
I planned to release it much sooner, but 3.0 and its subsequent maintenance releases happened, and I could only dedicate a few hours every now and then to the old stable branch.
On top of that, I decided to wait for this RC2 to have a proper fix for the Android placeholder permissions issue that crept up on Google Play in May and affected many published 2.1 games. HP’s APK fixer tool could already be used to fix those games, but I wanted 2.1.5 to export correct APKs out of the box. The proper fix was merged a few days ago, so I’m now considering 2.1.5 ready to go stable.
Download and test
This is the second release candidate for 2.1.5, and if all goes well, it should be the last. For this I will need the help of all 2.1.x users to test this release, use it to export your existing projects and check that there are no regressions from 2.1.4.
General feedback issue - you can collect your feedback on this RC build here, especially linking to other issues which might be open already but not fixed yet
Note that contrarily to 3.0 which can download the export templates for you automatically, with 2.1 you still need to download the .tpz file manually and use it to install templates within the editor.
Why do we still do 2.1.x releases again?
As mentioned in a previous blog post, since Godot 3.0 requires OpenGL 3.3 on desktop and OpenGL ES 3.0 on mobile, some developers are sticking to the 2.1.x branch for now while waiting for Godot 3.1, which will bring support for OpenGL 2.1 and OpenGL ES 2.0 again.
Moreover, some developers started big projects with Godot 2.1 before Godot 3.0 was released, and it might not be worth it for them to port their project over to Godot 3 for the time being, due to the important amount of work required to port/rewrite non-trivial projects in Godot 3.
Finally, distribution platforms like Google Play or the Apple Store keep increasing their requirements in terms of target systems (to force encourage more users to move to newer, supported versions), so we need to provide new export templates that match those guidelines so that people can update their published games. Same story with ensuring that the embedded libraries that we’re using don’t have known security vulnerabilities.
What’s new in 2.1.5?
We’ll go over the changes in detail in the stable release announcement (hopefully in a few days!), but in the meantime you can check the complete changelog since 2.1.4. Here are some highlights:
Android: APKs no longer include placeholder permissions that Google Play started complaining about
Android: Minimum SDK raised to 18, target SDK raised to 27.
Debug: New crash handler to generate backtraces when crashing on all desktop platforms (as in 3.0).
Editor: Tons of improvements to the “Godot 2 to 3 converter” tool, which can now convert many more resources than the one in 2.1.4. It even has an option to tentatively convert your scripts and change things like get_pos() (2.1) to get_position() (3.0) automatically.
Editor: Add class members overview in script editor.
Editor: New contextual menu in FileSystem dock.
Input: Hardware cursor support.
Input: Multitouch support.
iOS: Minimum SDK raised to 9.0, target SDK raised to 11.4.
OSX: Exporting for macOS from a Mac now generates a .dmg package.
Windows: New WASAPI audio driver (as in 3.0).
Performance optimisations.
Several crashes fixed, especially in Android backend.
That’s just a quick selection going through the changelog, there were a lot more nice changes in the 450 commits made to the 2.1 branch since 2.1.4-stable!
Happy testing, and please report any (new) issue you may find!
The illustration picture (full size) is from an upcoming Godot 2.1 game by Kit9Studio (composed of Sini and Jared), *Gun-Toting Cats. They helped a lot with testing the 2.1 branch and finding several bugs that are fixed in this RC2.*
“Wait,” I hear you say, “is the 2.1 branch still maintained 3 years after its first release?”
The answer is yes, on a “best effort” basis and focusing on release critical and security issues. What we consider “release critical” are issues which prevent people using Godot 2.1.x in production from releasing or updating their game, such as crash issues and adapting to the changing requirements of distribution platforms (mainly Google Play and Apple Store).
The upcoming 2.1.6 release is intended to address new requirements from Google Play and Apple store, as well as update thirdparty libraries to recent versions to fix known security vulnerabilities (in particular in libpng and openssl).
Google Play now mandates the support of its two 64-bit architectures, arm64v8 and x86_64. The former was already included in Godot 2.1.5, but x86_64 was missing and added first in Godot 3.1-stable. The templates for this architecture are now also included in Godot 2.1.6 RC 1, and will be included in an upcoming Godot 3.0.7 for the same reason.
Apple Store now requires binaries compiled against the iOS SDK 12.1 or later to support the latest iterations of its OS, so new binaries were also needed.
Who is this for?
As mentioned above, this new release is made for people using Godot 2.1.x in production. Many users started projects years ago with Godot 2.1 and are still developing them, about to release them or need to ship updates. Upgrading to Godot 3.0 or later is not straightforward due to various compatibility breakages that we did at the time, so these users need long term support.
If you want to start a new project, there is no reason to use Godot 2.1.6 which is based on a 3 years old code branch. You should instead use the latest stable release to benefit from all the new features and bug fixes included over the years.
Download
As a reminder, Godot 2.1.x does not have an export templates downloader, so you should make sure to download both the editor binary for your platform and the templates archive (.tpz file), and install these templates using the dedicated editor feature. You should not mix versions, i.e. using a 2.1.6 editor binary with 2.1.5 templates or the other way around. Export templates should match the exact commit used to build your editor binary.
Please test this release candidate on your 2.1 projects and make sure that both the editor and the exports work as expected. If you could test the upload of Android or iOS games to Google Play/Apple Store to confirm that they pass the platforms’ requirements, this would be very helpful too.
Please report any regression (a new bug in 2.1.6 RC 1 that you did not have in 2.1.5) or blocking bug in this tracker bug report.
Hi Godot! My name is HP van Braam. Some of you might know me on IRC/Discord/Matrix as ‘TMM’ and on GitHub as ‘hpvb’. To help Rémi (Akien) focus on making sure the master branch is as good as it can be, I’m looking after the stable branch. Currently the stable branch is the 3.0 branch.
I’m very happy to have been given this responsibility and I hope to work with all of you to make the Godot stable branches, well, just that! Stable!
TL;DR: Download Godot 3.0.1-rc1 here! And here is the changelog.
I’d like to thank all of our many wonderful contributors for their efforts!
So what does the stable branch mean
What ‘stable’ means has changed a bit since the Godot 2 times as we’re moving towards a more rapid release schedule. Starting with 3.0 the release numbers are in the form of ‘x.y.z’ where:
x = Major release. Any number of things may break in your project. You will need to port (like from 2.1.x to 3.0 currently).
y = Minor release. You may need to do some small changes to your scripts but no major breakage.
z = Patch release. We will make every effort to make sure you can upgrade your existing project without any changes. We may sometimes fix a bug that could impact your game in very rare cases. We will document these on the release notes. The goal here is that you can replace the Godot executable even on an already exported game and everything should ‘just work’.
Note that until further notice every project using C# should be prepared to rebuild and fix their code. We’re not currently considering C# support to have reached the level of stability required to make the same guarantees as we try to make for GDScript-based projects. Don’t worry! C# users got a popup when starting Godot 3.0 that explained this, and our C# contributors are still working on several improvements that should make the workflow much better.
On this release
This is the release candidate for the first patch release for the Godot 3.0 stable branch. The version that will become 3.0.1. We’d like to ask the community to give it a test, make sure that we didn’t break any of your ongoing projects (any project breakage will be considered a bug for 3.0.1). With the exception of the following:
If you relied on the Bullet physics engine and relied on the fact that the calculated effective gravity on KinematicBodies was always ‘0’ then you will need to fix your code as this is now correctly calculated. See #15554 for details.
Setting the v member of a color did not properly set the s member. This is now corrected. See #16916 for details.
RichTextLabels did not properly determine the baseline of all fonts. If you relied on the look of the previous implementation please let us know. See #15711 for details.
SpinBoxes didn’t calculate their width properly. This is now fixed but could subtly change your GUI layout. See #16432 for details.
OGG streams now correctly signal the end of playback. If you were relying on this not happening please let us know. See #15910 for details.
Last but not least, C# assemblies built with Godot 3.0 won’t be compatible with 3.0.1, and the editor might crash while trying to load old assemblies. Make sure to delete the .mono folder in your project folder to force a new build (this workflow will be improved in future releases).
What didn’t make it
Sadly the support for C# export templates hasn’t quite baked yet (a WIP has just been merged, but more work and testing is still needed). We will release a stable point release of Godot as soon as this support has sufficiently matured. Nobody will get the C# support a second later than it is done!
Exciting new stuff
Thanks to Fabio (Fales) and iFire the server platform has made a comeback. So headless Godot is back in the same form it was in 2.1!
Back by popular demand: Type icons! Enable them in project settings if you missed them.
This is the first release candiate for what will become Godot 3.0.3. This release has over 100 bugfixes and new features. A full human-readable changelog is still to be created but the git shortlog can be downloaded here.
The most important new feature for this release is initial support for Mono exports on the desktop platforms (Windows, Linux, and MacOSX). We’re still hard at work at making Mono exporting to mobile work.
Note that some early users have reported some issues with the Mono downloads. This is being investigated.
Please test this release with your existing projects and as usual: Any breakage of existing projects after upgrading is a bug. If we somehow missed something please report a bug.
I’d like to thank our wonderful community for smothering us in the warm glow of their pull requests and bug reports. This is looking like another great release!
On a sidenote: I (hp) was moving house last month so this release is somewhat later than usual. We’re aiming to have 3.0.4 available near the end of May. We’re aiming for a roughly monthly patch release cycle.
Downloads
The original uploads for the X11 binaries were accidentally the export templates instead of the editor. This has been corrected now.
As always, you will find the binaries for your platform on our mirrors:
Mono versions require Mono 5.10 on Linux and Windows and Mono 5.8 on MacOS
Known incompatibilities with Godot 3.0.2
None
Known incompatibilities with Godot 3.0.1
None
Known incompatibilities with Godot 3.0
If you use the Bullet physics engine and relied on the fact that the calculated effective gravity on KinematicBodies was always ‘0’ then you will need to fix your code as this is now correctly calculated. See #15554 for details.
Setting the v member of a color did not properly set the s member. This is now corrected. See #16916 for details.
RichTextLabels did not properly determine the baseline of all fonts. If you relied on the look of the previous implementation please let us know. See #15711 for details.
SpinBoxes didn’t calculate their width properly. This is now fixed but could subtly change your GUI layout. See #16432 for details.
OGG streams now correctly signal the end of playback. If you were relying on this not happening please let us know. See #15910 for details.
Known bugs in Godot 3.0.3
Vector3.snapped() does not work and just returns the original Vector3. Fixing this would have meant breaking ABI between Godot 3.0 and 3.0.2 so this function will remain non-functional.
move_and_slide() doesn’t quite work correctly. An easy workaround is to increase the safe margin to 0.05 (or higher if required). It is not yet clear how to implement the proper fix without impacting users who already implemented this workaround in their projects. See issue #16459 for an explanation.
Some users report crashes on Windows 10 after a recent Windows update. We currently don’t know what is causing this.
We’re pleased to announce the second release candidate for what will become Godot 3.0.3. We’ve added quite a few bugfixes compared to rc1 and a port of RandomShaper’s mouse input emulation code.
For this release I’ve had to redo our buildsystem (again) due to trouble with the rc1 packages. This is why it took a while to get rc2 out. I believe the problems have now been solved but please test on all your platforms! The most important user-visible changes compared to rc1 are that now the Mono builds should work on all platforms, and rc2 restores support for Windows 7. Windows 7 compatibility is now also being tested before releases happen.
Please test this release with your existing projects and as usual: Any breakage of existing projects after upgrading is a bug. If we somehow missed something please report a bug.
I’d like to take this time to thank all of our wonderful contributers who made this releases possible. You’re the best! Thank you for all your contributions, be it code, docs, or bugreports.
Downloads
As always, you will find the binaries for your platform on our mirrors:
Mono versions require Mono 5.10 on Linux and Windows and Mono 5.8 on MacOS
Known incompatibilities with Godot 3.0.2
None
Known incompatibilities with Godot 3.0.1
None
Known incompatibilities with Godot 3.0
If you use the Bullet physics engine and relied on the fact that the calculated effective gravity on KinematicBodies was always ‘0’ then you will need to fix your code as this is now correctly calculated. See #15554 for details.
Setting the v member of a color did not properly set the s member. This is now corrected. See #16916 for details.
RichTextLabels did not properly determine the baseline of all fonts. If you relied on the look of the previous implementation please let us know. See #15711 for details.
SpinBoxes didn’t calculate their width properly. This is now fixed but could subtly change your GUI layout. See #16432 for details.
OGG streams now correctly signal the end of playback. If you were relying on this not happening please let us know. See #15910 for details.
Known bugs in Godot 3.0.3
Vector3.snapped() does not work and just returns the original Vector3. Fixing this would have meant breaking ABI between Godot 3.0 and 3.0.2 so this function will remain non-functional.
move_and_slide() doesn’t quite work correctly. An easy workaround is to increase the safe margin to 0.05 (or higher if required). It is not yet clear how to implement the proper fix without impacting users who already implemented this workaround in their projects. See issue #16459 for an explanation.
Some users report crashes on Windows 10 after a recent Windows update. We currently don’t know what is causing this.
We’re pleased to announce the third release candidate for what will become Godot 3.0.3. Quite a lot of work went into making the Mono exports work for Windows targets. It turned out to be quite a hairy problem. But now Mono exports to Windows, Linux, and MacOS should work with a single click. It is no longer necessary to ship the Mono runtime DLL manually.
This release also restores the Javascript export templates. These were broken for rc2.
Please note that this release still has the Android Google Play bug. We will do an rc4 shortly with a fix. A tool will be released soon to fix existing APKs. I’ve had some trouble with getting signing to work reliably from a third-party tool.
Please test this release with your existing projects and as usual: Any breakage of existing projects after upgrading is a bug. If we somehow missed something please report a bug.
I’d like to take a moment to thank all of the superheroes that contribute to the project to make this release possible. If you’d like to be elevated to ‘super hero’ please file bugs, fix documentation, write patches, or just come hang out with us on Discord, IRC, or Matrix!
Downloads
As always, you will find the binaries for your platform on our mirrors:
Mono versions require Mono 5.12.0 on all platforms.
Known incompatibilities with Godot 3.0.2
None
Known incompatibilities with Godot 3.0.1
None
Known incompatibilities with Godot 3.0
If you use the Bullet physics engine and relied on the fact that the calculated effective gravity on KinematicBodies was always ‘0’ then you will need to fix your code as this is now correctly calculated. See #15554 for details.
Setting the v member of a color did not properly set the s member. This is now corrected. See #16916 for details.
RichTextLabels did not properly determine the baseline of all fonts. If you relied on the look of the previous implementation please let us know. See #15711 for details.
SpinBoxes didn’t calculate their width properly. This is now fixed but could subtly change your GUI layout. See #16432 for details.
OGG streams now correctly signal the end of playback. If you were relying on this not happening please let us know. See #15910 for details.
Known bugs in Godot 3.0.3
Vector3.snapped() does not work and just returns the original Vector3. Fixing this would have meant breaking ABI between Godot 3.0 and 3.0.2 so this function will remain non-functional.
move_and_slide() doesn’t quite work correctly. An easy workaround is to increase the safe margin to 0.05 (or higher if required). It is not yet clear how to implement the proper fix without impacting users who already implemented this workaround in their projects. See issue #16459 for an explanation.
Some users report crashes on Windows 10 after a recent Windows update. We currently don’t know what is causing this.
After almost one year of development, the master branch (future Godot 3.0) is mostly feature-complete and ready for broader testing by the Godot community. We are therefore releasing a first alpha snapshot for existing users to play with and report bugs.
Disclaimer
IMPORTANT: This is an alpha build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.0 would be on its release.
There is still a long way of bug fixing and usability improvement until we can release the stable version, and this release comes with virtually no documentation. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.
There is also no guarantee that projects started with the alpha1 build will still work in alpha2 or later builds, as we reserve the right to do necessary breaking adjustments up to the beta stage. Finally, the desktop platforms (Linux, macOS, Windows) are the only ones in a usable state, Android, iOS, UWP and JavaScript all need further fixes to properly support the new Godot 3.0 features.
Note: New Godot users should not use this build to start their learning. Godot 2.1 is still supported and well documented
The features
Now, there are still some cool features that can already be played with in this alpha1 build, and we are looking forward to seeing what you will come up with using the new 3D renderer. There is no exhaustive listing of all the new features to experiment with, but you can read past articles of this blog and check Juan’s Twitter feed for some teasers :)
Please use the community channels to discuss with existing users and learn how to use the new workflows of Godot 3.0 - as of this writing there is almost no documentation on the new features, but this alpha1 build should serve as a starting point for documentation writers.
Downloads
The download links are not featured on the Download page for now to avoid confusion for new users. Instead, browse one of our mirrors and download the editor binary for your platform and the export templates archive:
Also clone the godot-demo-projects repository to have demos to play with. Some of them might still need adjustments due to recent changes in the master branch, feel free to report any issue.
Bug reports
There are still many open bug reports for the 3.0 milestone, which means that we are aware of many bugs already. We still release this snapshot to get some early feedback while we work on fixing the known issues.
As a tester, you are encouraged to open bug reports if you experience issues with alpha1. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
You can also consult this list of known issues, which is a hand-picked list of the most visible problems you will likely encounter.
FAQ
We can already see many questions coming regarding this development snapshot, so here are some answers.
What is the ETA for Godot 3.0 stable?
When it’s ready. We’re all working on our free time on this project, and can’t commit to a given deadline. We consider the master branch to be feature-complete, and we are now working on fixing bugs in the new features and enhancing the usability of the new workflows. Depending on how it goes, we may be able to release 3.0 stable in a couple of months.
Does it support C#?
No, the alpha1 build does not contain the Mono/C# module yet. It should soon be merged in the master branch, so it might be available in alpha2. The 3.0 stable release will support C#, the integration is almost ready.
Does it support Vulkan?
No, and there are no plans for Vulkan support for the time being. Our resources are too limited to focus on too many renderers at the same time, and the new OpenGL ES 3.0 / OpenGL 3.3 renderer of this build was already a huge refactor. Vulkan being only relevant for a small fraction of our users, it’s low priority for now.
How to run my 2.1 game in the alpha?
Projects from Godot 2.1 are not compatible with Godot 3.0, as many things changed in the Godot API as well as in GDScript. There is no porting guide for now, but there is an export tool in Godot 2.1.3 and later which can be used to export 2.1 games to the formats expected for Godot 3.0.
Since the master branch is a moving target, the exporter in Godot 2.1.3 is already outdated and won’t work as smoothly as it should. Your best bet is to compile the 2.1 branch yourself to use the latest version of the exporter, and report any issue you experience with it.
How to use GDNative?
As for most features, it lacks documentation for now. Still, you will find some infos on the godot_headers main repository, as well as the CPP bindings. You can use the Q&A with the gdnative tag to mark your questions; karroffel will do all she can to help you get started.
Will there be more alpha builds?
Yes, as the name “alpha1” suggests, we plan to have newer builds regularly to bring the latest state of the master branch. Depending on the user feedback we get, we might make weekly releases or biweekly if it proves too much burden.
A little treat (or is it a trick?) for our community on this Halloween eve: Godot 3.0 alpha 2 is out, ready for your testing! It’s already been 3 months since our previous official development snapshot, and lots of bugs have been fixed, making us one big step closer to the final 3.0 stable release.
It’s also the first build to include the long awaited support for the C# programming language using Mono! This is of course still pretty rough, though usable, and we are looking forward to your feedback and bug reports. Some caveats are documented below as well as in the introduction blog post, so make sure to read them before filing issues.
Disclaimer
IMPORTANT: This is an alpha build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.0 would be on its release.
There is still a long way of bug fixing and usability improvement until we can release the stable version, and this release comes with incomplete documentation: the in-editor and online Class Reference is quite complete thanks to the awesome work of our documentation team, but there aren’t many tutorials about using Godot 3.0 yet. For the Mono build, there is no specific documentation yet. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.
There is also no guarantee that projects started with the alpha 2 build will still work later builds, as we reserve the right to do necessary breaking adjustments up to the beta stage.
Note: New Godot users should not use this build to start their learning. Godot 2.1 is still supported and well documented.
The features
Since the previous alpha build, there have been hundreds of bugs fixed, as well as many usability enhancements to make the new features as easy to use as possible.
There was also a strong focus on the documentation, with the Class Reference close to 70% complete now (which is already much higher than the completion level of the 2.x API documentation).
Quick Mono howto
Of course, the main feature many have been waiting for is the Mono support. It comes in separate binaries with an additional system requirement: the Mono SDK. You need to install the current stable version of Mono to use with Godot, as you will be developing applications which require the .NET Framework.
If you installed Mono in the classical system directories (using the upstream macOS or Windows installers, or the Linux repositories), everything should work out of the box.
If you installed Mono in a specific directory, things might get a bit more complex. You can override the MONO_PATH environment variable to point to the location of your .NET Framework 4.5, typically /path_to_mono_root/lib/mono/4.5/. You will also need msbuild in your PATH, so if you installed it in a location which is not included in the PATH, you can either override the latter or create a symbolic link.
Downloads
The download links are not featured on the Download page for now to avoid confusing new users. Instead, browse one of our mirrors and download the editor binary for your platform and the export templates archive:
Mono version (requires the Mono SDK): [HTTPS mirror]
Note: Export templates are currently missing due to a last minute regression in the HTML5 platform (Edit 2017-10-31 23:00 UTC: They are now available for the classical version).
diff --git a/article/dev-snapshot-godot-3-0-beta-1/index.html b/article/dev-snapshot-godot-3-0-beta-1/index.html
index 7c923a59c2..2955d38438 100644
--- a/article/dev-snapshot-godot-3-0-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-0-beta-1/index.html
@@ -1,8 +1,9 @@
Godot 3.0’s development officially entered the beta stage last week, which coincides for us with what we name the feature freeze: from now on, no new features will be merged in the master branch, as the focus will be fully on fixing existing issues to stabilize the current feature set.
diff --git a/article/dev-snapshot-godot-3-0-beta-2/index.html b/article/dev-snapshot-godot-3-0-beta-2/index.html
index e5d712a463..4f37225a39 100644
--- a/article/dev-snapshot-godot-3-0-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-0-beta-2/index.html
@@ -1,8 +1,9 @@
Edit 22.12.2017: Windows binaries (both the editor binaries and the export templates) have been replaced by versions without OpenMP support, the latter forcing the installation of the MS Visual C++ Redistributable 2017 to get the OpenMP DLL. If you downloaded export templates before 22.12.2017 at 23:59 UTC, we advise to download them anew to get the proper portable Windows binaries.
Three weeks after our 3.0 beta 1 development snapshot, it’s time for another beta release to bring us closer to the final 3.0 version.
We initially hoped for a stable release around Christmas, but given that we’re publishing 3.0 beta 2 today, you can probably assume that 3.0 stable will be an early 2018 release instead. And that’s just as well, since a lot of work continues to be done every day to fix issues in the master branch and improve usability, and Juan even took the time to sneak in a couple past-deadline but very requested features, like a lightmapper for static light baking (to provide an alternative to the real-time but resource-heavy GIProbe).
This release fixes many of the issues that you reported while testing beta 1, so it should be a lot more stable. There are definitely still bugs here and there, so please report anything you might stumble upon.
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.0 would be on its release.
There will still be many fixes and enhancements done before the final release, and we will need your detailed bug reports to debug issues and fix them. Notably, the 3D performance varies greatly depending on your graphics hardware, and will be improved and streamlined progressively as Godot 3 stabilizes.
Downloads
The download links are not featured on the Download page for now to avoid confusing new users. Instead, browse one of our mirrors and download the editor binary for your platform and the export templates archive:
Mono version (requires the Mono SDK): [HTTPS mirror]
Note that Godot can now download and install the export templates automatically, so you don’t need to download them manually. If you installed export templates for the previous 3.0 beta 1 release, make sure to uninstall them/replace them by the beta 2 ones, as they are not compatible. Export templates for the Mono flavour will not be provided for beta 2, as exporting Mono games is not fully implemented yet.
Also clone the godot-demo-projects repository to have demos to play with. Some of them might still need adjustments due to recent changes in the master branch, feel free to report any issue.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with beta 2. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
Have fun with this beta 2 and stay tuned for a release candidate (RC) in the first weeks of January!
So Godot 3.0 won’t be a 2017 release as we had hoped during the last semester, but we are pretty confident that you will get it in January 2018 to properly kickstart this new year!
We fixed hundreds of bugs and declared the release freeze, which means that many non critical bugs and enhancements have been moved to the 3.1 milestone, allowing us to tend faster towards the final 3.0 release by focusing on the big issues.
With this first Release Candidate (RC), we are now getting very close to the final release. We plan to have at least a second RC in the middle of the coming week, fixing some already-known regressions and probably some more important bugs that you will have reported until then.
Note that no release can be bug-free, even if we label it “stable”, so don’t be offended if the bugs you report are assigned to the 3.1 milestone - at this stage we focus only on the most critical stuff, but we still welcome your reports to know all that is not working perfectly. Many non-critical bug fixes and enhancements will be included in 3.0.x maintenance releases, the first one likely coming in February.
Mono version (requires the Mono SDK): [HTTPS mirror]
Note that Godot can now download and install the export templates automatically, so you don’t need to download them manually.
Export templates for the Mono flavour are still not available yet due to time constraints. It might be that they will only be made available in the first 3.0.1 maintenance release (so you can start working on C# projects in 3.0 nevertheless, but exports will have to wait a few weeks). Even though Godot 3.0 is reaching the gold state, it’s important to remember that C# support is a young feature and still to be considered at the beta stage. It will improve a lot in coming months.
Another caveat for users of 3.0 beta 2 with Mono: you might need to delete the mono folder of your Godot user folder, as well as the .mono folder in your project, to remove now-incompatible assemblies.
Also clone the godot-demo-projects repository to have demos to play with. Some of them might still need adjustments due to recent changes in the master branch, feel free to report any issue in that repository’s tracker.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with RC 1. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already. In particular, you can check the list of issues reported since last Thursday, many of which might affect RC 1 but be fixed already or known in the master branch.
If you’ve been following development closely, you might notice issues with physics/collision shapes in this RC 1 (recent regression, will be fixed soon in the master branch) as well as script error if you have variables shadowing newly exposed member variables (e.g. you can now accept Node.name directly, so if you declared your own name variables in scripts, you might need to rename those to avoid the conflict).
Have fun with this RC 1 and stay tuned for a new RC in the coming week as well as the stable release Very Soon™.
The final release of Godot 3.0 is getting closer and closer! We had a first Release Candidate (RC) last week, quite stable already but with some remaining blockers and late regressions.
After a week of bugfixing with a tight control of what gets merged and what must wait for the 3.1 development cycle, we should now have a pretty good RC 2.
This RC 2 build corresponds to commit fe2932a9 from almost two days ago already, and some more fixes have been made since then. We’ll have a RC 3 in a few days to get those tested, and if all goes fine, this RC 3 should become our stable release.
Note that no release can be bug-free, even if we label it “stable”, so don’t be offended if the bugs you report are assigned to the 3.1 milestone - at this stage we focus only on the most critical stuff, but we still welcome your reports to know all that is not working perfectly. Many non-critical bug fixes and enhancements will be included in 3.0.x maintenance releases, the first one likely coming in February.
There’s also a bad news for C# users: the export pipeline hasn’t been finalized yet for Mono projects, and we have decided that we won’t wait for it to release 3.0. That means that even though you can use 3.0 to develop games in C#, you won’t be able to export them just yet. This support will be added quickly after 3.0 is released, and should be available in February with 3.0.1, so the wait shouldn’t be long. Until then, you can start your projects and debug the likely numerous issues of our first public release with C# support.
Keep in mind that C# support is a work in progress, and your critical feedback will help greatly to shape the C# support in later releases. Even though the rest of Godot 3.0 is quite stable, users of the C# version should be aware of potential feature-specific instabilities.
Downloads
As always, you will find the binaries for your platform on our mirrors:
Mono version (requires the Mono SDK): [HTTPS mirror]
Edit 20/01/2018 @ 23:15 CET: The current Mono binaries display a non-blocking error about API hash mismatches. You can ignore it, the binaries should work fine regardless. Updated binaries with the proper API hashes will be available in the coming hours.
Edit 21/01/2018 @ 00:10 CET: Mono binaries for Linux and Windows are now fixed. 00:40 CET: macOS binary is fixed too.
Note that Godot can now download and install the export templates automatically, so you don’t need to download them manually.
As mentioned above, there are no export templates for Mono and likely won’t be any for 3.0 stable either, but they should be available in February with 3.0.1.
Also clone the godot-demo-projects repository to have demos to play with. Some of them might still need adjustments due to recent changes in the master branch, feel free to report any issue in that repository’s tracker.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with RC 2. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
Edit 21/01/2018 @ 00:20 CET: Known major issues in RC 2:
Resource preloading does not work after export due to converted paths (#15902)
Have fun with this RC 2 and stay tuned for the final release (still planned for January)!
Here’s another Release Candidate (RC) build on the way to 3.0 stable, fixing most of the remaining blocking bugs from RC 2.
This RC 3 build corresponds to commit d50c0ef for the classical build, and commit 59e83af for the Mono build. The classical build is thus already a couple days old, due to the system we currently use to produce binaries being particularly slow lately (this will be worked on after 3.0 to improve the release workflow).
Note that no release can be bug-free, even if we label it “stable”, so don’t be offended if the bugs you report are assigned to the 3.1 milestone - at this stage we focus only on the most critical stuff, but we still welcome your reports to know all that is not working perfectly. Many non-critical bug fixes and enhancements will be included in 3.0.x maintenance releases, the first one likely coming in February.
As mentioned in the RC 2 announcement, the export pipeline hasn’t been finalized yet for Mono projects, and has therefore been postponed to 3.0.1. You can use 3.0 for Mono projects nevertheless, but you won’t be able to export them as standalone release binaries just yet.
Keep in mind that C# support is a work in progress, and your critical feedback will help greatly to shape the C# support in later releases. Even though the rest of Godot 3.0 is quite stable, users of the C# version should be aware of potential feature-specific instabilities.
Downloads
As always, you will find the binaries for your platform on our mirrors:
Mono version (requires the Mono SDK in version 5.x, ideally 5.4.1.7): [HTTPS mirror]
Note: Due to a huge backlog of macOS builds on the buildsystem we use for release binaries, two macOS binaries are missing at the time of this announcement: 1) The Mono-flavoured macOS editor binary. 2) The macOS release export template (the one in the templates zip is for now a copy of the debug export template). This post will be updated once the missing macOS binaries are available.
Edit 25.01.2018 8:00 UTC: The Mono-flavoured macOS editor binary is now available.
Godot can now download and install the export templates automatically, so you don’t need to download them manually.
As mentioned above, there are no export templates for Mono and likely won’t be any for 3.0 stable either, but they should be available in February with 3.0.1.
Also clone the godot-demo-projects repository to have demos to play with. Some of them might still need adjustments due to recent changes in the master branch, feel free to report any issue in that repository’s tracker.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with RC 3. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
Have fun with this RC 3 and stay tuned for the final release (still planned for January)!
Long awaited, Godot 3.1 alpha 1 is our first milestone towards the stable release of Godot 3.1, packed with 7 months of development since Godot 3.0 (over 3,500 commits!).
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs.
The alpha stage corresponds for us to a feature freeze, as announced on GitHub a few days ago, which means that we will no longer consider pull requests with new features for merge in the master branch, and that until Godot 3.1 is released. This way, we can focus on what we already have, finish and polish the major features which are still in progress (e.g. OpenGL ES 2.0 support), and fix many of the old and new bugs reported by the community.
Alpha snapshots will be released regularly during this phase, to continuously test the master branch and make sure that it keeps getting more stable, reliable and ready for production.
Disclaimer
IMPORTANT: This is an alpha build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There is still a long way of bug fixing and usability improvement until we can release the stable version. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.
There is also no guarantee that projects started with the alpha 1 build will still work in alpha 2 or later builds, as we reserve the right to do necessary breaking adjustments up to the beta stage (albeit compatibility breaking changes at this stage should be very minimal, if any).
Note: New Godot users should not use this build to start their learning. Godot 3.0.x is our current stable branch and still received frequent updates.
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is working on.
As mentioned previously, our past devblogs should also give you an idea of the main highlights of the upcoming release.
Documentation writers are hard at work to catch up with the new features, and the latest branch should already include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page for now to avoid confusion for new users. Instead, browse one of our download repository and fetch the editor binary that matches your platform:
IMPORTANT: Make backups of your Godot 3.0 projects before opening them in any 3.1 development build. Once a project has been opened in 3.1, it’s project.godot file will be updated to a new format for input mappings which is not compatible with Godot 3.0 - the latter will thus refuse to open a 3.1 project. Moreover, using new 3.1 features in your project means that you can’t go back to 3.0, unless you do the necessary work to remove the use of those features. So either test 3.1-alpha1 in a copy of your 3.0 projects, or start new projects with it.
Due to some buildsystem problems alpha1 does not have working export templates for the UWP ARM target. Furthermore the upnp and websockets features are missing from UWP export templates entirely.
Bug reports
There are still hundreds of open bug reports for the 3.1 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.1 release and may end up be retargeted to a later release to allow releasing Godot 3.1 within a couple of months.
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 alpha. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
Two months after our previous alpha, we are pleased to release Godot 3.1 alpha 2, a new development snapshot of the master branch, moving slowly but steadily towards the beta status.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been 9 months since the 3.0 release and close to 5,000 commits, so expect a lot of nice things in the final 3.1 version!
The alpha stage corresponds for us to a feature freeze (see announcement on GitHub), which means that we will no longer consider pull requests with new features for merge in the master branch, and that until Godot 3.1 is released. This way, we can focus on what we already have, finish and polish the major features which are still in progress (e.g. OpenGL ES 2.0 support), and fix many of the old and new bugs reported by the community.
Alpha snapshots will be released regularly during this phase, to continuously test the master branch and make sure that it keeps getting more stable, reliable and ready for production.
Disclaimer
IMPORTANT: This is an alpha build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There is still a long way of bug fixing and usability improvement until we can release the stable version. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.
There is also no guarantee that projects started with the alpha 2 build will still work in alpha 3 or later builds, as we reserve the right to do necessary breaking adjustments up to the beta stage (albeit compatibility breaking changes at this stage should be very minimal, if any).
Note: New Godot users should not use this build to start their learning. Godot 3.0.x is our current stable branch and still receives frequent updates.
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is working on.
As mentioned previously, our past devblogs should also give you an idea of the main highlights of the upcoming release.
This alpha 2 comes with an impressive amount of bug fixes compared to the previous alpha 1. The OpenGL ES 2.0 backend has also seen a lot of work to push it towards feature-completion – it’s not done yet, but it’s getting close.
Documentation writers are hard at work to catch up with the new features, and the latest branch should already include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page for now to avoid confusion for new users. Instead, browse one of our download repository and fetch the editor binary that matches your platform:
Mono (alpha C# support) - you need Mono SDK 5.12.0 for this alpha (5.14 or newer won’t work)
IMPORTANT: Make backups of your Godot 3.0 projects before opening them in any 3.1 development build. Once a project has been opened in 3.1, its project.godot file will be updated to a new format for input mappings which is not compatible with Godot 3.0 - the latter will thus refuse to open a 3.1 project. Moreover, using new 3.1 features in your project means that you can’t go back to 3.0, unless you do the necessary work to remove the use of those features. So either test 3.1-alpha2 in a copy of your 3.0 projects, or start new projects with it.
Note: This release is still called “3.1.alpha” internally, same as alpha 1 and daily builds from the master branch. This means that the export templates share the same installation folder, yet you have to make sure to replace any “3.1.alpha” templates you currently have installed with the ones from the alpha 2 distribution.
Due to some buildsystem problems alpha2 does not have working export templates for the UWP ARM target. Furthermore the upnp and websockets features are missing from UWP export templates entirely.
Bug reports
There are still hundreds of open bug reports for the 3.1 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.1 release and may end up be retargeted to a later release to allow releasing Godot 3.1 in the near future.
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 alpha. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
Already more than a month since our previous alpha, yet we haven’t been idle in the meantime. Hundreds of fixes and enhancements have been done in the master branch, which we are pleased to bring to you as Godot 3.1 alpha 3. This new development snapshot brings us one step closer to the beta stage, which we should reach before Christmas.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been over 10 months since the 3.0 release and over 5,000 commits, so expect a lot of nice things in the final 3.1 version!
The alpha stage corresponds for us to a feature freeze (see announcement on GitHub), which means that we will no longer consider pull requests with new features for merge in the master branch, and that until Godot 3.1 is released. This way, we can focus on what we already have, finish and polish the major features which are still in progress (e.g. OpenGL ES 2.0 support), and fix many of the old and new bugs reported by the community.
Development snapshots will continue to be released regularly to continuously test the master branch and make sure that it keeps getting more stable, reliable and ready for production.
Disclaimer
IMPORTANT: This is an alpha build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There is still a long way of bug fixing and usability improvement until we can release the stable version. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.
There is also no guarantee that projects started with the alpha 3 build will still work in later builds, as we reserve the right to do necessary breaking adjustments up to the beta stage (albeit compatibility breaking changes at this stage should be very minimal, if any).
Note: New Godot users should not use this build to start their learning. Godot 3.0.x is our current stable branch and still receives frequent updates.
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is working on.
As mentioned previously, our past devblogs should also give you an idea of the main highlights of the upcoming release.
This alpha 3 comes with an impressive amount of bug fixes all around the engine, with Juan spending most of the month of November focusing on that. See this Patreon post for details on what happened since alpha 2.
Documentation writers are hard at work to catch up with the new features, and the latest branch should already include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page for now to avoid confusion for new users. Instead, browse one of our download repository and fetch the editor binary and export templates that matches your platform:
Mono (alpha C# support) - you need Mono SDK 5.12.0 for this alpha (5.14 or newer won’t work)
IMPORTANT: Make backups of your Godot 3.0 projects before opening them in any 3.1 development build. Once a project has been opened in 3.1, its project.godot file will be updated to a new format for input mappings which is not compatible with Godot 3.0 - the latter will thus refuse to open a 3.1 project. Moreover, using new 3.1 features in your project means that you can’t go back to 3.0, unless you do the necessary work to remove the use of those features. So either test 3.1-alpha3 on a copy of your 3.0 projects, or start new projects with it.
Note: This release is still called “3.1.alpha” internally, same as previous alphas and daily builds from the master branch. This means that the export templates share the same installation folder, yet you have to make sure to replace any “3.1.alpha” templates you currently have installed with the ones from the alpha 3 distribution.
Bug reports
There are still hundreds of open bug reports for the 3.1 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.1 release and may end up be retargeted to a later release to allow releasing Godot 3.1 in the near future.
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 alpha. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
The illustration picture is from Samuele Zolfanelli’s *Gumgem, a great-looking 2D game developed for the A Game By Its Cover 2018 jam. A big update is upcoming, be sure to follow their work!*
We released Godot 3.1 alpha 3 last week, and it’s now time for another alpha build, 3.1 alpha 4. We plan to have a last alpha build within one week, and then we should be ready to move into the beta stage, where we only merge critical bug fixes until the branch is stable enough for the final release.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been almost 11 months since the 3.0 release and over 5,500 commits, so expect a lot of nice things in the final 3.1 version!
The alpha stage corresponds for us to a feature freeze (see announcement on GitHub), which means that we will no longer consider pull requests with new features for merge in the master branch, and that until Godot 3.1 is released. This way, we can focus on what we already have, finish and polish the major features which are still in progress (e.g. OpenGL ES 2.0 support), and fix many of the old and new bugs reported by the community.
Development snapshots will continue to be released regularly to continuously test the master branch and make sure that it keeps getting more stable, reliable and ready for production.
Disclaimer
IMPORTANT: This is an alpha build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There is still a long way of bug fixing and usability improvement until we can release the stable version. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.
Note: New Godot users should not use this build to start their learning. Godot 3.0.x is our current stable branch and still receives frequent updates.
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is working on.
As mentioned previously, our past devblogs should also give you an idea of the main highlights of the upcoming release.
This alpha 4 comes after many of the pending PRs in the 3.1 milestone have been reviewed and merged over the last 10 days. This progress report outlines the changes that happened in the master branch since the last two weeks, which match more or less changes since the alpha 3 build.
Documentation writers are hard at work to catch up with the new features, and the latest branch should already include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page for now to avoid confusion for new users. Instead, browse one of our download repository and fetch the editor binary and export templates that matches your platform:
Mono (alpha C# support) - IMPORTANT: You need to have Nuget and MSbuild installed. However, alpha 4 no longer relies on a specific Mono SDK version.
IMPORTANT: Make backups of your Godot 3.0 projects before opening them in any 3.1 development build. Once a project has been opened in 3.1, its project.godot file will be updated to a new format for input mappings which is not compatible with Godot 3.0 - the latter will thus refuse to open a 3.1 project. Moreover, using new 3.1 features in your project means that you can’t go back to 3.0, unless you do the necessary work to remove the use of those features. So either test 3.1-alpha4 on a copy of your 3.0 projects, or start new projects with it.
Note: This release is still called “3.1.alpha” internally, same as previous alphas and daily builds from the master branch. This means that the export templates share the same installation folder, yet you have to make sure to replace any “3.1.alpha” templates you currently have installed with the ones from the alpha 4 distribution.
Bug reports
There are still hundreds of open bug reports for the 3.1 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.1 release and may end up be retargeted to a later release to allow releasing Godot 3.1 in the near future.
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 alpha. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
The illustration picture is a scene created with Marc Gilleron’s *HeightMap terrain plugin, available on the Asset Library and on GitHub.*
We released Godot 3.1 alpha 4 10 days ago, and it’s now time for another alpha build, 3.1 alpha 5. This is the last alpha build before the beta stage, where we only merge critical bug fixes until the branch is stable enough for the final release. This last alpha mainly focuses on the build and release system. More on that in a later blogpost.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been almost 11 months since the 3.0 release and over 5,500 commits, so expect a lot of nice things in the final 3.1 version!
The alpha stage corresponds for us to a feature freeze (see announcement on GitHub), which means that we will no longer consider pull requests with new features for merge in the master branch, and that until Godot 3.1 is released. This way, we can focus on what we already have, finish and polish the major features which are still in progress (e.g. OpenGL ES 2.0 support), and fix many of the old and new bugs reported by the community.
Development snapshots will continue to be released regularly to continuously test the master branch and make sure that it keeps getting more stable, reliable and ready for production.
Disclaimer
IMPORTANT: This is an alpha build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There is still a long way of bug fixing and usability improvement until we can release the stable version. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.
Note: New Godot users should not use this build to start their learning. Godot 3.0.x is our current stable branch and still receives frequent updates.
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is working on.
As mentioned previously, our past devblogs should also give you an idea of the main highlights of the upcoming release.
Documentation writers are hard at work to catch up with the new features, and the latest branch should already include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page for now to avoid confusion for new users. Instead, browse one of our download repository and fetch the editor binary and export templates that matches your platform:
Mono (alpha C# support) - IMPORTANT: You need to have Nuget and MSbuild installed. However, alpha 5 no longer relies on a specific Mono SDK version.
IMPORTANT: Make backups of your Godot 3.0 projects before opening them in any 3.1 development build. Once a project has been opened in 3.1, its project.godot file will be updated to a new format for input mappings which is not compatible with Godot 3.0 - the latter will thus refuse to open a 3.1 project. Moreover, using new 3.1 features in your project means that you can’t go back to 3.0, unless you do the necessary work to remove the use of those features. So either test 3.1-alpha4 on a copy of your 3.0 projects, or start new projects with it.
Note: This release is still called “3.1.alpha” internally, same as previous alphas and daily builds from the master branch. This means that the export templates share the same installation folder, yet you have to make sure to replace any “3.1.alpha” templates you currently have installed with the ones from the alpha 5 distribution.
Bug reports
There are still hundreds of open bug reports for the 3.1 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.1 release and may end up be retargeted to a later release to allow releasing Godot 3.1 in the near future.
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 alpha. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
After an alpha phase that took longer than anticipated, we’re now ready to enter the beta phase for Godot 3.1, which means that the feature work is finished for this version. From now on, we are in release freeze, which means that new features will no longer be merged, and we will focus solely on fixing release-critical bugs.
This should allow to finish polishing this release quickly and hopefully be ready to publish it by the end of this month. See this GitHub issue for details.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been almost a year since the 3.0 release and close to 6,000 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be many fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
As mentioned previously, our past devblogs should also give you an idea of the main highlights of the upcoming release.
Documentation writers are hard at work to catch up with the new features, and the latest branch should already include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page for now to avoid confusion for new users. Instead, browse our download repository and fetch the editor binary and export templates that matches your platform and Godot flavour:
Mono build (C# support + all the above). You need to have Nuget and MSbuild installed to use the Mono build. However, this build no longer mandates a specific Mono SDK version.
IMPORTANT: Make backups of your Godot 3.0 projects before opening them in any 3.1 development build. Once a project has been opened in 3.1, its project.godot file will be updated to a new format for input mappings which is not compatible with Godot 3.0 - the latter will thus refuse to open a 3.1 project. Moreover, using new 3.1 features in your project means that you can’t go back to 3.0, unless you do the necessary work to remove the use of those features. So either test this release on a copy of your 3.0 projects, or start new projects with it.
Bug reports
There are still hundreds of open bug reports for the 3.1 milestone, which means that we are aware of many bugs already. Yet, many of those issues are not critical for the 3.1 release and will end up retargeted to a later milestone.
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 beta. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
At this stage, we are mostly interested in critical bugs which could be showstoppers in Godot 3.1 stable. Yet feel free to report non-critical issues and enhancement proposals that will be worked on once 3.1 has been released.
As bugfixing is going at a steady pace towards Godot 3.1 stable, we plan to release beta builds frequently to have broad testing on the latest fixes and spot any regression. So we’re now publishing Godot 3.1 beta 10 with 70 commits made since beta 9 a few days ago.
Barring any big regression, this should be our last beta build, the next one being the first Release Candidate (RC 1) in a few days.
A big change since 3.1 beta 6 is that the Windows binaries are now properly code signed. Our release manager HP van Braam is now signing binaries with their own company’s certificate. From now on, you should thus expect (and can trust) our official binaries signed by Prehensile Tales B.V.. macOS binaries will be signed at a later time.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been over a year since the 3.0 release and over 6,500 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be various fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-11/index.html b/article/dev-snapshot-godot-3-1-beta-11/index.html
index 583953f6c3..ca6992da3b 100644
--- a/article/dev-snapshot-godot-3-1-beta-11/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-11/index.html
@@ -1,8 +1,9 @@
As bugfixing is going at a steady pace towards Godot 3.1 stable, we plan to release beta builds frequently to have broad testing on the latest fixes and spot any regression. So we’re now publishing Godot 3.1 beta 11 with over 110 commits made since beta 10 a few days ago.
We said that beta 10 would likely be the last one before the first Release Candidate (RC 1), but there were still quite a few big changes that warrant another beta. The list of remaining release-critical bugs is quite small, so we should be able to enter the RC phase soon.
A big change since 3.1 beta 6 is that the Windows binaries are now properly code signed. Our release manager HP van Braam is now signing binaries with their own company’s certificate. From now on, you should thus expect (and can trust) our official binaries signed by Prehensile Tales B.V.. macOS binaries will be signed at a later time.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been over a year since the 3.0 release and over 6,500 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be various fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-2/index.html b/article/dev-snapshot-godot-3-1-beta-2/index.html
index 983ff23b90..90e33fc8c5 100644
--- a/article/dev-snapshot-godot-3-1-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-2/index.html
@@ -1,8 +1,9 @@
We entered the release freeze last week with Godot 3.1 beta 1, and many high priority bug reports have been fixed since then. We’re now publishing a new beta 2 snapshot for testers to work with. This new release fixes various crash scenarios, as well as a performance regression in the GLES backend.
We’re still aiming for a release by the end of the month, so we’re under a tight schedule. From now on dev focus is on release-critical issues that would seriously hamper Godot 3.1’s usability and features.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been almost a year since the 3.0 release and close to 6,000 commits, so expect a lot of nice things in the final 3.1 version!
And a small note for C# users: Godot 3.1 beta 2 now bundles mono 5.18 instead of 5.16. It’s still bundled so you don’t need to upgrade your system mono.
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be many fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-3/index.html b/article/dev-snapshot-godot-3-1-beta-3/index.html
index 092fb3a98d..7dbfbb67ad 100644
--- a/article/dev-snapshot-godot-3-1-beta-3/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-3/index.html
@@ -1,8 +1,9 @@
We’ve been hard at work fixing bugs since the Godot 3.1 beta 2 last week, and our new beta 3 snapshot is a lot closer to what we want the final 3.1 to be like.
There were over 600 bugs listed for the 3.1 milestone at the start of the month, but we’ve been reviewed them tirelessly over the last few weeks, and many of them have been fixed, or postponed to the next milestone when they were not critical. The GLES2 backend is getting more and more mature, especially for the web and mobile platforms where severe issues have been fixed.
If all goes well, we may have a first release candidate next week :)
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been almost a year since the 3.0 release and over 6,000 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be many fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-4/index.html b/article/dev-snapshot-godot-3-1-beta-4/index.html
index 29fe7537bd..0d6c519df4 100644
--- a/article/dev-snapshot-godot-3-1-beta-4/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-4/index.html
@@ -1,8 +1,9 @@
The last couple of weeks have been busy, as many core developers were meeting in Brussels for the Godot Sprint, FOSDEM and GodotCon. We’ll post an update about what we did there and some of the topics discussed in coming days, stay tuned!
Nevertheless, other contributors have kept working in the meantime, and some of the Godot Sprint attendees also did some welcome bugfixing, so we have enough content for a new beta 4 build. We’re quite close to being ready for a first release candidate.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been almost a year since the 3.0 release and over 6,300 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be many fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-5/index.html b/article/dev-snapshot-godot-3-1-beta-5/index.html
index 590d455a0e..4a59258442 100644
--- a/article/dev-snapshot-godot-3-1-beta-5/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-5/index.html
@@ -1,8 +1,9 @@
It’s only been a few days since beta 4, but we’re making very good progress on polishing the 3.1 beta, with many bugs being fixed every day. We’ll soon be able to issue a Release Candidate (RC) build and from there, proceed quickly to the stable release. For now, we’re still calling this one beta 5, as there are some critical bugs left that we want to fix before RC 1.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been over a year since the 3.0 release and close to 6,500 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be various fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-6/index.html b/article/dev-snapshot-godot-3-1-beta-6/index.html
index cb7c8797e1..efe969092e 100644
--- a/article/dev-snapshot-godot-3-1-beta-6/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-6/index.html
@@ -1,8 +1,9 @@
As bugfixing is going at a steady pace towards Godot 3.1 stable, we plan to release beta builds frequently to have broad testing on the latest fixes and spot any regression. So we’re now publishing Godot 3.1 beta 6 with close to 150 commits made since beta 5 a few days ago.
A big change in this release is that the Windows binaries are now properly code signed. Our release manager HP van Braam is now signing binaries with their own company’s certificate. From now on, you should thus expect (and can trust) our official binaries signed by Prehensile Tales B.V.. macOS binaries will be signed at a later time.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been over a year since the 3.0 release and over 6,500 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be various fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-7/index.html b/article/dev-snapshot-godot-3-1-beta-7/index.html
index df36e2708c..61ba7d599c 100644
--- a/article/dev-snapshot-godot-3-1-beta-7/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-7/index.html
@@ -1,8 +1,9 @@
As bugfixing is going at a steady pace towards Godot 3.1 stable, we plan to release beta builds frequently to have broad testing on the latest fixes and spot any regression. So we’re now publishing Godot 3.1 beta 7 with close to 25 commits made since beta 6 a few days ago.
A big change in this release is that the Windows binaries are now properly code signed. Our release manager HP van Braam is now signing binaries with their own company’s certificate. From now on, you should thus expect (and can trust) our official binaries signed by Prehensile Tales B.V.. macOS binaries will be signed at a later time.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been over a year since the 3.0 release and over 6,500 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be various fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-8/index.html b/article/dev-snapshot-godot-3-1-beta-8/index.html
index 6b9cf1a313..0d9be478ae 100644
--- a/article/dev-snapshot-godot-3-1-beta-8/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-8/index.html
@@ -1,8 +1,9 @@
As bugfixing is going at a steady pace towards Godot 3.1 stable, we plan to release beta builds frequently to have broad testing on the latest fixes and spot any regression. So we’re now publishing Godot 3.1 beta 8 with close to 50 commits made since beta 7 a few days ago.
Our two previous betas had regressions on Bullet physics (beta 6), C# support and old CPUs supports (beta 7), which are fixed in this beta. There is still one big regression that we know of, which is that ETC import is now invalid, so GLES2 projects exported to Android or iOS would likely not work. This will be fixed shortly in beta 9.
A big change since 3.1 beta 6 is that the Windows binaries are now properly code signed. Our release manager HP van Braam is now signing binaries with their own company’s certificate. From now on, you should thus expect (and can trust) our official binaries signed by Prehensile Tales B.V.. macOS binaries will be signed at a later time.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been over a year since the 3.0 release and over 6,500 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be various fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-1-beta-9/index.html b/article/dev-snapshot-godot-3-1-beta-9/index.html
index 376858f2db..337dfbbb15 100644
--- a/article/dev-snapshot-godot-3-1-beta-9/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-9/index.html
@@ -1,8 +1,9 @@
As bugfixing is going at a steady pace towards Godot 3.1 stable, we plan to release beta builds frequently to have broad testing on the latest fixes and spot any regression. So we’re now publishing Godot 3.1 beta 9 with close to 50 commits made since beta 8 a few days ago.
The ETC issue on GLES2/Android has been fixed in this release.
A big change since 3.1 beta 6 is that the Windows binaries are now properly code signed. Our release manager HP van Braam is now signing binaries with their own company’s certificate. From now on, you should thus expect (and can trust) our official binaries signed by Prehensile Tales B.V.. macOS binaries will be signed at a later time.
Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It’s been over a year since the 3.0 release and over 6,500 commits, so expect a lot of nice things in the final 3.1 version!
Disclaimer
IMPORTANT: This is a beta build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.1 would be on its release.
There will still be various fixes made before the final release, and we will need your detailed bug reports to debug issues and fix them.
The features
Release notes are drafted already, but we don’t want to spoil the surprise of the 3.1 release announcement ;)
diff --git a/article/dev-snapshot-godot-3-2-2-beta-1/index.html b/article/dev-snapshot-godot-3-2-2-beta-1/index.html
index 2b0f8a8d29..58e880f510 100644
--- a/article/dev-snapshot-godot-3-2-2-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-2-2-beta-1/index.html
@@ -1,8 +1,9 @@
After refining our Godot 3.2 release with bug fixes in 3.2.1 last month, it’s time to integrate some of the new features that didn’t make it into the 3.2 merge window but have been further developed and backported since.
Notably, Godot 3.2.2 is going to add three major features:
We need your help to test and validate these changes before publishing 3.2.2-stable, which is why we publish this beta build now. If you find any new issue with this build, especially related to one of the listed big changes, please report it on GitHub, ideally including a minimal project that can be used to reproduce the issue.
How to test
It should be safe to test this build directly with pre-existing projects made with Godot 3.2.x. It’s of course always advised to use a version control system or backups in case you want to go back to the previous version (but testing 3.2.2-beta1 shouldn’t prevent you from doing so anyway).
C# support for iOS
C# support for iOS should work similarly to exporting a GDScript project for iOS. Note that the export needs to be done from a macOS system to use the included AOT compiler for iOS arm64. If you run into any issue with the export process, please also test the export of a simple GDScript project to verify if the issue relates to the new C# support or to the iOS export pipeline in general.
GLES2 2D batching
The new 2D batching is only implemented for the GLES2 renderer, so if you use GLES3 you will not be able to benefit from it. As the GLES3 renderer is being deprecated by Vulkan in Godot 4.0, we currently don’t plan to port the 2D batching to it. GLES2 batching is enabled by default both in-game and in the editor. You can turn it off or configure advanced settings in the Project Settings. Please see this dedicated issue for more details and to share your own testing results (we’re interested in all feedback, whether you gained a lot of performance, lost some or didn’t notice any chance). Note that currently, only rects are batched (TileMaps, draw_rect, text rendering, etc.), but we plan to include more primitive types once this has been well tested.
New Android plugin system
Godot 3.2 came with a brand new Android plugin system already, and notably the possibility to build custom APKs from your project folder with any additional plugins/modules that your project needs.
Fredia had done a lot of work back then to improve Juan’s initial custom build system, which led him to notice many things that could be modernized to be better suited to the current Android ecosystem. Notably, he re-architectured the plugin system to leverage the Android AAR library file format.
This new plugin system is backward-incompatible with the 3.2/3.2.1 system, but both systems are kept functional in future releases of the 3.2.x branch. Since we previously did not version our Android plugin systems, this new one is now labelled v1, and is the starting point for the modern Godot Android ecosystem.
See this Pull Request and the updated documentation for details. Fredia has already started helping some plugin authors to update theirs to the new v1 system, feel free to ask if you need help too.
Other changes
Apart from those three major features, there are also close to 200 cherry-picks for bug fixes and enhancements which have been merged since Godot 3.2.1. Here are some highlights:
Android: Re-architecture of the Godot Android plugin (GH-36336).
Android: Add signal support to Godot Android plugins (GH-37305).
AStar: Implements estimate/compute_cost for AStar2D (GH-37039).
Audio: Fix volume interpolation in positional audio nodes (GH-37279).
Core: Ensure COWData does not always reallocate on resize (GH-37373).
Editor: Add rotation widget to 3D viewport (GH-33098).
The download links for dev snapshots are not featured on the Download page to avoid confusion for new users. Instead, browse our download repository and fetch the editor binary that matches your platform:
Mono build (C# support + all the above). You need to have MSBuild (and on Windows .NET Framework 4.7) installed to use the Mono build. Relevant parts of Mono 6.6.0.166 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.2.2 beta 1. Please check first the existing issues on GitHub, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
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 3.2.1 no longer works in 3.2.2 beta 1).
After refining our Godot 3.2 release with bug fixes in 3.2.1, we’re now looking at integrating some new features that didn’t make it into the 3.2 merge window but have been further developed and backported since. We published a first beta a few weeks ago, and here’s the next round with Godot 3.2.2 beta 2.
Notably, Godot 3.2.2 is going to add 5 major features:
While this is not a feature per se, it fixes a major annoyance that users have had with pointers to freed objects unexpectedly being re-assigned to new objects, causing hard-to-debug issues.
We need your help to test and validate these changes before publishing 3.2.2-stable, which is why we publish this beta build now. If you find any new issue with this build, especially related to one of the listed big changes, please report it on GitHub, ideally including a minimal project that can be used to reproduce the issue.
How to test
It should be safe to test this build directly with pre-existing projects made with Godot 3.2.x. It’s of course always advised to use a version control system or backups in case you want to go back to the previous version (but testing 3.2.2-beta2 shouldn’t prevent you from doing so anyway).
Note: If using C#, the .csproj file will be converted with some bug fixes which makes it incompatible with earlier Godot 3.2 and 3.2.1. A backup of the file will be generated upon conversion so that you can revert to older releases if need be.
C# support for iOS
C# support for iOS should work similarly to exporting a GDScript project for iOS. Note that the export needs to be done from a macOS system to use the included AOT compiler for iOS arm64. If you run into any issue with the export process, please also test the export of a simple GDScript project to verify if the issue relates to the new C# support or to the iOS export pipeline in general.
GLES2 2D batching
The new 2D batching is only implemented for the GLES2 renderer, so if you use GLES3 you will not be able to benefit from it. As the GLES3 renderer is being deprecated by Vulkan in Godot 4.0, we currently don’t plan to port the 2D batching to it. GLES2 batching is enabled by default both in-game and in the editor. You can turn it off or configure advanced settings in the Project Settings. Please see this dedicated issue for more details and to share your own testing results (we’re interested in all feedback, whether you gained a lot of performance, lost some or didn’t notice any chance). Note that currently, only rects are batched (TileMaps, draw_rect, text rendering, etc.), but we plan to include more primitive types once this has been well tested.
New Android plugin system
Godot 3.2 came with a brand new Android plugin system already, and notably the possibility to build custom APKs from your project folder with any additional plugins/modules that your project needs.
Fredia had done a lot of work back then to improve Juan’s initial custom build system, which led him to notice many things that could be modernized to be better suited to the current Android ecosystem. Notably, he re-architectured the plugin system to leverage the Android AAR library file format.
This new plugin system is backward-incompatible with the 3.2/3.2.1 system, but both systems are kept functional in future releases of the 3.2.x branch. Since we previously did not version our Android plugin systems, this new one is now labelled v1, and is the starting point for the modern Godot Android ecosystem.
See this Pull Request and the updated documentation for details. Fredia has already started helping some plugin authors to update theirs to the new v1 system, feel free to ask if you need help too.
DTLS support and ENet integration
Fabio’s work on DTLS support was nearly done by the time 3.2 was released, but came too late to be thoroughly tested. Testing has happened since then both in the master branch and in the pending 3.2 Pull Request, so we’re now confident to include it in this beta build for further testing.
If you were running into this bug, it would typically be in situations where you’d check is_instance_valid() on what you expect to be a freed instance (which should give False), and it would actually return True and lead you to access a method or a property of a different object (causing an error if the object’s class does not include this method or property).
The fix made in the 3.2 is only done on debug builds for performance reasons, so make sure to fix any error reported by the editor or debug builds before shipping a release build to your players.
diff --git a/article/dev-snapshot-godot-3-2-2-beta-3/index.html b/article/dev-snapshot-godot-3-2-2-beta-3/index.html
index 62cb049b72..e9052d4a62 100644
--- a/article/dev-snapshot-godot-3-2-2-beta-3/index.html
+++ b/article/dev-snapshot-godot-3-2-2-beta-3/index.html
@@ -1,8 +1,9 @@
After refining our Godot 3.2 release with bug fixes in 3.2.1, we’re now looking at integrating some new features that didn’t make it into the 3.2 merge window but have been further developed and backported since. We already had twobetas, and here’s the next round with Godot 3.2.2 beta 3.
Notably, Godot 3.2.2 is going to add 5 major features:
While this is not a feature per se, it fixes a major annoyance that users have had with pointers to freed objects unexpectedly being re-assigned to new objects, causing hard-to-debug issues.
We need your help to test and validate these changes before publishing 3.2.2-stable, which is why we publish this beta build now. If you find any new issue with this build, especially related to one of the listed big changes, please report it on GitHub, ideally including a minimal project that can be used to reproduce the issue.
How to test
It should be safe to test this build directly with pre-existing projects made with Godot 3.2.x. It’s of course always advised to use a version control system or backups in case you want to go back to the previous version (but testing 3.2.2-beta3 shouldn’t prevent you from doing so anyway).
Note: If using C#, the .csproj file will be converted with some bug fixes which makes it incompatible with earlier Godot 3.2 and 3.2.1. A backup of the file will be generated upon conversion so that you can revert to older releases if need be.
C# support for iOS
C# support for iOS should work similarly to exporting a GDScript project for iOS. Note that the export needs to be done from a macOS system to use the included AOT compiler for iOS arm64. If you run into any issue with the export process, please also test the export of a simple GDScript project to verify if the issue relates to the new C# support or to the iOS export pipeline in general.
GLES2 2D batching
The new 2D batching is only implemented for the GLES2 renderer, so if you use GLES3 you will not be able to benefit from it. As the GLES3 renderer is being deprecated by Vulkan in Godot 4.0, we currently don’t plan to port the 2D batching to it. GLES2 batching is enabled by default both in-game and in the editor. You can turn it off or configure advanced settings in the Project Settings. Please see this dedicated issue for more details and to share your own testing results (we’re interested in all feedback, whether you gained a lot of performance, lost some or didn’t notice any chance). Note that currently, only rects are batched (TileMaps, draw_rect, text rendering, etc.), but we plan to include more primitive types once this has been well tested.
New Android plugin system
Godot 3.2 came with a brand new Android plugin system already, and notably the possibility to build custom APKs from your project folder with any additional plugins/modules that your project needs.
Fredia had done a lot of work back then to improve Juan’s initial custom build system, which led him to notice many things that could be modernized to be better suited to the current Android ecosystem. Notably, he re-architectured the plugin system to leverage the Android AAR library file format.
This new plugin system is backward-incompatible with the 3.2/3.2.1 system, but both systems are kept functional in future releases of the 3.2.x branch. Since we previously did not version our Android plugin systems, this new one is now labelled v1, and is the starting point for the modern Godot Android ecosystem.
See this Pull Request and the updated documentation for details. Fredia has already started helping some plugin authors to update theirs to the new v1 system, feel free to ask if you need help too.
DTLS support and ENet integration
Fabio’s work on DTLS support was nearly done by the time 3.2 was released, but came too late to be thoroughly tested. Testing has happened since then both in the master branch and in the pending 3.2 Pull Request, so we’re now confident to include it in this beta build for further testing.
If you were running into this bug, it would typically be in situations where you’d check is_instance_valid() on what you expect to be a freed instance (which should give False), and it would actually return True and lead you to access a method or a property of a different object (causing an error if the object’s class does not include this method or property).
The fix made in the 3.2 is only done on debug builds for performance reasons, so make sure to fix any error reported by the editor or debug builds before shipping a release build to your players.
diff --git a/article/dev-snapshot-godot-3-2-2-beta-4/index.html b/article/dev-snapshot-godot-3-2-2-beta-4/index.html
index bb2c096234..75c5aa3842 100644
--- a/article/dev-snapshot-godot-3-2-2-beta-4/index.html
+++ b/article/dev-snapshot-godot-3-2-2-beta-4/index.html
@@ -1,8 +1,9 @@
Yet another snapshot on the way to the feature-packed Godot 3.2.2! This beta 4 fixes some regressions and adds more bug fixes to make the upcoming release even better.
Notably, Godot 3.2.2 is going to add 5 major features:
While this is not a feature per se, it fixes a major annoyance that users have had with pointers to freed objects unexpectedly being re-assigned to new objects, causing hard-to-debug issues.
We need your help to test and validate these changes before publishing 3.2.2-stable, which is why we publish this beta build now. If you find any new issue with this build, especially related to one of the listed big changes, please report it on GitHub, ideally including a minimal project that can be used to reproduce the issue.
How to test
It should be safe to test this build directly with pre-existing projects made with Godot 3.2.x. It’s of course always advised to use a version control system or backups in case you want to go back to the previous version (but testing 3.2.2-beta4 shouldn’t prevent you from doing so anyway).
Note: If using C#, the .csproj file will be converted with some bug fixes which makes it incompatible with earlier Godot 3.2 and 3.2.1. A backup of the file will be generated upon conversion so that you can revert to older releases if need be.
C# support for iOS
C# support for iOS should work similarly to exporting a GDScript project for iOS. Note that the export needs to be done from a macOS system to use the included AOT compiler for iOS arm64. If you run into any issue with the export process, please also test the export of a simple GDScript project to verify if the issue relates to the new C# support or to the iOS export pipeline in general.
GLES2 2D batching
The new 2D batching is only implemented for the GLES2 renderer, so if you use GLES3 you will not be able to benefit from it. As the GLES3 renderer is being deprecated by Vulkan in Godot 4.0, we currently don’t plan to port the 2D batching to it. GLES2 batching is enabled by default both in-game and in the editor. You can turn it off or configure advanced settings in the Project Settings. Please see this dedicated issue for more details and to share your own testing results (we’re interested in all feedback, whether you gained a lot of performance, lost some or didn’t notice any chance). Note that currently, only rects are batched (TileMaps, draw_rect, text rendering, etc.), but we plan to include more primitive types once this has been well tested.
New Android plugin system
Godot 3.2 came with a brand new Android plugin system already, and notably the possibility to build custom APKs from your project folder with any additional plugins/modules that your project needs.
Fredia had done a lot of work back then to improve Juan’s initial custom build system, which led him to notice many things that could be modernized to be better suited to the current Android ecosystem. Notably, he re-architectured the plugin system to leverage the Android AAR library file format.
This new plugin system is backward-incompatible with the 3.2/3.2.1 system, but both systems are kept functional in future releases of the 3.2.x branch. Since we previously did not version our Android plugin systems, this new one is now labelled v1, and is the starting point for the modern Godot Android ecosystem.
See this Pull Request and the updated documentation for details. Fredia has already started helping some plugin authors to update theirs to the new v1 system, feel free to ask if you need help too.
DTLS support and ENet integration
Fabio’s work on DTLS support was nearly done by the time 3.2 was released, but came too late to be thoroughly tested. Testing has happened since then both in the master branch and in the pending 3.2 Pull Request, so we’re now confident to include it in this beta build for further testing.
If you were running into this bug, it would typically be in situations where you’d check is_instance_valid() on what you expect to be a freed instance (which should give False), and it would actually return True and lead you to access a method or a property of a different object (causing an error if the object’s class does not include this method or property).
The fix made in the 3.2 is only done on debug builds for performance reasons, so make sure to fix any error reported by the editor or debug builds before shipping a release build to your players.
diff --git a/article/dev-snapshot-godot-3-2-3-beta-1/index.html b/article/dev-snapshot-godot-3-2-3-beta-1/index.html
index 4dbf651ec7..255e672482 100644
--- a/article/dev-snapshot-godot-3-2-3-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-2-3-beta-1/index.html
@@ -1,8 +1,9 @@
Godot 3.2.2 was released on June 26 with over 3 months’ worth of development, including many bugfixes and a handful of features. Some regressions were noticed after the release though, so we decided that Godot 3.2.3 would focus mainly on fixing those new bugs to ensure that all Godot users can have the most stable experience possible.
GLES2: Fixed mesh data access errors in GLES2 (GH-40235).
GLES2: Batching - Fix FORCE_REPEAT not being set properly on npot hardware (GH-40410).
GLES3: Force depth prepass when using alpha prepass (GH-39865).
HTML5: Improvements and bugfixes backported from the master branch (GH-39604).
Note: This PR adds threads support, but as this support is still disabled in many browsers due to security concerns, the option is not enabled by default. Build HTML5 templates with threads_enabled=yes to test it.
HTML5: More fixes, audio fallback, fixed FPS (GH-40052).
IK: Fixed SkeletonIK not working with scaled skeletons (GH-39803).
Import: Fix upstream stb_vorbis regression causing crashes with some OGG files (GH-40174) [regression fix].
Input: Support SDL2 half axes and inverted axes mappings (GH-38724).
iOS: Add support of iOS’s dynamic libraries to GDNative (GH-39996).
macOS: Add support for the Apple Silicon (ARM64) build target (GH-39943).
Note: ARM64 binaries are not included in macOS editor or template builds yet. It’s going to take some time before our dependencies and toolchains are updated to support it.
macOS: Set correct external file attributes, and creation time (GH-39977) [regression fix].
The download links for dev snapshots are not featured on the Download page to avoid confusion for new users. Instead, browse our download repository and fetch the editor binary that matches your platform:
Mono build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.6.0.166 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.2.3 beta 1. Please check first the existing issues on GitHub, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
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 3.2.1 or 3.2.2 no longer works in 3.2.3 beta 1).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, and a handful of part or full-time developers, hired thanks to donations from the Godot community. A big thankyou to everyone who has contributed their time or 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 on Patreon or PayPal.
Godot 3.2.3 was released a month ago and the reception was great! It focused mostly on fixing bugs and therefore we were somewhat conservative on what could be merged before the release.
Now that we’re confident that 3.2.3 works well, we can take some time to add new features to the 3.2 branch while you wait for Godot 4.0 :)
This first beta build already includes a number of them which have been worked on by core contributors, with notable mentions to:
Android App Bundle and subview embedding support.
2D batching for GLES3 (remember that we added it for GLES2 in 3.2.2), and improvements to GLES2’s batching.
A new software skinning for MeshInstance to replace the slow GPU skinning on devices that don’t support the fast GPU skinning (especially mobile).
And this is just a first beta, there’s more in the works that will be included in future beta builds.
Changes
The main new features in need of testing are highlighted in bold. Refer to the linked pull requests for details.
Android: Add support for the Android App Bundle format (GH-42185).
Android: Add support for emedded Godot as a subview in Android applications (GH-42186).
The download links for dev snapshots are not featured on the Download page to avoid confusion for new users. Instead, browse our download repository and fetch the editor binary that matches your platform:
Mono build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.102 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.2.4 beta 1. Please check first the existing issues on GitHub, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
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 3.2.3 or earlier no longer works in 3.2.4 beta 1).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, and a handful of part or full-time developers, hired thanks to donations from the Godot community. A big thankyou to everyone who has contributed their time or 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 on Patreon or PayPal.
While development keeps going at full speed towards Godot 4.0 (see recent devblogs on GDScript typed instructions and Complex Text Layout), a lot of work is also being done on the 3.2 branch for the upcoming Godot 3.2.4.
Adding to the first beta version from last month ago, we now have even more great features coming in 3.2.4:
Android App Bundle and subview embedding support.
2D batching for GLES3 (remember that we added it for GLES2 in 3.2.2), and improvements to GLES2’s batching.
A new software skinning for MeshInstance to replace the slow GPU skinning on devices that don’t support the fast GPU skinning (especially mobile).
The download links for dev snapshots are not featured on the Download page to avoid confusion for new users. Instead, browse our download repository and fetch the editor binary that matches your platform:
Mono build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.111 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.2.4 beta 2. Please check first the existing issues on GitHub, using the search function with relevant keywords, to ensure that the bug you experience is not known already.
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 3.2.3 or earlier no longer works in 3.2.4 beta 2).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, and a handful of part or full-time developers, hired thanks to donations from the Godot community. A big thankyou to everyone who has contributed their time or 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 on Patreon or PayPal.
While development keeps going at full speed towards Godot 4.0 (see recent devblogs on GDScript typed instructions and Complex Text Layout), a lot of work is also being done on the 3.2 branch for the upcoming Godot 3.2.4.
This new beta 3 build comes shortly after last week’s beta 2 to fix some of the regressions and bugs reported against that release.
The only big change is that the classical build for macOS is now a universal binary, with both x86_64 and arm64 architectures included (to support the new ARM-based Apple M1 chip natively).
diff --git a/article/dev-snapshot-godot-3-2-4-beta-4/index.html b/article/dev-snapshot-godot-3-2-4-beta-4/index.html
index 84ec04f157..f6fa57a8c7 100644
--- a/article/dev-snapshot-godot-3-2-4-beta-4/index.html
+++ b/article/dev-snapshot-godot-3-2-4-beta-4/index.html
@@ -1,8 +1,9 @@