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!
Next
diff --git a/article/2d-games-godot-kickstarter-live/index.html b/article/2d-games-godot-kickstarter-live/index.html
index 9f268054de..6dc79d144a 100644
--- a/article/2d-games-godot-kickstarter-live/index.html
+++ b/article/2d-games-godot-kickstarter-live/index.html
@@ -1,6 +1,6 @@
Make Professional 2d Games with Godot: Kickstarter LIVE – Godot Engine
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:
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.
When we started working on the Patreon page with Juan, we expected that it would take a few months and the publication of Godot 3.0 to bring us near to our $3,000 monthly goal which could secure us Juan’s full-time dedication to the project.
And here we are, two weeks in and already 80% funded, with barely $600 missing to reach our main goal - and it keeps growing slowly but steadily, with a daily influx of new donors.
diff --git a/article/abandoning-gles3-vulkan-and-gles2/index.html b/article/abandoning-gles3-vulkan-and-gles2/index.html
index 00acc5299e..523052b9d3 100644
--- a/article/abandoning-gles3-vulkan-and-gles2/index.html
+++ b/article/abandoning-gles3-vulkan-and-gles2/index.html
@@ -1,6 +1,6 @@
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.
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.
The more bugs are found during the alpha and beta stage, the better the release will be.
Thank you for being here, and happy development!
Previous
diff --git a/article/about-official-console-ports/index.html b/article/about-official-console-ports/index.html
index 51b994094e..a175d89c97 100644
--- a/article/about-official-console-ports/index.html
+++ b/article/about-official-console-ports/index.html
@@ -1,6 +1,6 @@
About Official Console Ports – Godot Engine
With this post we aim to address the community’s questions about the lack of official console ports through the Godot Foundation.
diff --git a/article/agile-input-processing-is-here-for-smoother-gameplay/index.html b/article/agile-input-processing-is-here-for-smoother-gameplay/index.html
index 7df1700d6b..a7cea87290 100644
--- a/article/agile-input-processing-is-here-for-smoother-gameplay/index.html
+++ b/article/agile-input-processing-is-here-for-smoother-gameplay/index.html
@@ -1,6 +1,6 @@
Agile input processing is here for smoother, more responsive gameplay – Godot Engine
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.
Next
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 0b7149bf76..824eba0d8e 100644
--- a/article/android_godot_editor_play_store_beta_release/index.html
+++ b/article/android_godot_editor_play_store_beta_release/index.html
@@ -1,6 +1,6 @@
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.
Two fingers rotate & zoom. Use two fingers to rotate and zoom the camera of the viewport.