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!
-
+
\ No newline at end of file
diff --git a/article/2d-games-godot-kickstarter-live/index.html b/article/2d-games-godot-kickstarter-live/index.html
index ab8a6b58df..0728e852bb 100644
--- a/article/2d-games-godot-kickstarter-live/index.html
+++ b/article/2d-games-godot-kickstarter-live/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest22 May 2017
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:
-
+
\ No newline at end of file
diff --git a/article/80-funded-celebrating-patreon-rewards-upgrade/index.html b/article/80-funded-celebrating-patreon-rewards-upgrade/index.html
index 2a2fefd9bd..72fd8f070c 100644
--- a/article/80-funded-celebrating-patreon-rewards-upgrade/index.html
+++ b/article/80-funded-celebrating-patreon-rewards-upgrade/index.html
@@ -11,7 +11,7 @@
Overview of the rewards for each Patreon pledge tier
Apart from the tier level changes, those rewards were rephrased to make their scope more explicit:
Vote for tutorials and demos: Each month, the whole community will be able to propose ideas of tutorials and demos. The developers will make a pre-selection of what is doable and interesting, and will submit it to the vote of the $14+ patrons. The selected tutorial and demo will be produced during the month and shared with the whole community.
Live Q&A video: Each month, pledgers at this level or upper will be able to ask questions to the devs in written form. Those will be used to prepare a live video Q&A where these questions will be answered. During the live, the patrons will also be able to ask further questions via the video chat. After the live, the video Q&A will be made available to the whole community. Note that this reward used to give three vote points for tutorials and demos, but it was reduced to two to be better balanced.
Vote on the roadmap: Each month, the whole community will be able to propose features to put on the month’s roadmap. Live for tutorials and demos, the developers will make a pre-selection of what fits the interest of the project, and the patrons at the $26 tier or beyond will be able to vote for one of them, which should be implemented in the master branch during the month.
So as you can see, nothing earth-shattering in our rewards - as mentioned above, the main perk that we offer to everyone is the free and open source Godot Engine, and the Patreon rewards were designed to be positive additions for the whole community (new tutorials and demos every month, video Q&A, more transparency regarding the roadmap and a way to get suggestions reviewed). If you feel that some of the changes we made are not appropriate, please get in touch with us to discuss it.
What about direct donations?
Several users asked us if they could continue donating directly to our Conservancy account via PayPal, instead of using Patreon. This is of course possible, and you can do so from the donate page using the PayPal button. The donations that we get via this channel will be used as we did up to now, to cover project-related travel expanses, marketing material for events and specific hardware when necessary.
In the near future, we will add a way for you to donate via PayPal for our “hiring Juan and further devs” campaign, i.e. we will sum the Patreon and PayPal pledges to see how much funds we have each month to hire developers. We will post about it as soon as this is in place.
The awesome unrelated header of this blog post is a Godot 3.0 render of a scene by fracteed, one of our excellent PBR artists!
-
+
\ No newline at end of file
diff --git a/article/abandoning-gles3-vulkan-and-gles2/index.html b/article/abandoning-gles3-vulkan-and-gles2/index.html
index 698ceb2845..bfdff38e50 100644
--- a/article/abandoning-gles3-vulkan-and-gles2/index.html
+++ b/article/abandoning-gles3-vulkan-and-gles2/index.html
@@ -5,7 +5,7 @@
Juan Linietsky26 February 2018
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.
-
+
\ No newline at end of file
diff --git a/article/about-godot4-vulkan-gles3-and-gles2/index.html b/article/about-godot4-vulkan-gles3-and-gles2/index.html
index fccbc643e4..74c7cdfec1 100644
--- a/article/about-godot4-vulkan-gles3-and-gles2/index.html
+++ b/article/about-godot4-vulkan-gles3-and-gles2/index.html
@@ -6,7 +6,7 @@
The more bugs are found during the alpha and beta stage, the better the release will be.
-
+
\ No newline at end of file
diff --git a/article/about-official-console-ports/index.html b/article/about-official-console-ports/index.html
index 15e92bfc4b..5229b4717d 100644
--- a/article/about-official-console-ports/index.html
+++ b/article/about-official-console-ports/index.html
@@ -8,7 +8,7 @@
The great news is that the first ports of this sort are surfacing already! They are difficult to find as you often need to have the relevant NDAs to discover them. In the case of a Nintendo Switch port, RAWRLAB Games was able to publicly announce their open-source Nintendo Switch port for Godot Engine users. This sort of community effort is amazing and is something that the Godot Foundation heavily encourages!
While we are very excited about this progress, we aren’t going to put our limited Godot Foundation resources behind developing such ports either, for the following reasons.
Disproportionate Cost
The Godot Foundation as an entity receives donations from the community to spend on the development of the Godot Engine as a project. That being said, these resources — which currently pay for about 10 people to work on anything from release management to writing code to organizational tasks — are nothing in comparison to the amount of voluntary time that you as a community invest in making the Godot Engine as successful as it has become in the recent years. At the time of writing, 2,634 volunteer contributors are listed as authors of the project!
We are gifted with a huge community of such passionate contributors, and put a lot of weight on enabling and encouraging new people to join into the process. Sadly, the number of potential contributors with console experience, access to console vendor NDAs, and devkits is very small in comparison.
This would flip our current situation on its head. With console ports, nearly all the work would have to be done by the Godot Foundation, which means the cost per platform would be disproportionately higher than for all other platforms we officially maintain (i.e. Windows/Linux/Mac, web and mobile). Even more so if we want the console ports to be the same quality as the rest of our code base, including maintenance and catering to new hardware.
This is both inefficient, and unfair to community members who don’t plan to release on consoles. A significant portion of their donation would go towards maintaining platform ports for closed systems which they don’t have access to (and can’t have access to without spending a significant amount of money).
It is also worth keeping in mind that Godot is a very large and fully featured game engine compared to other open source game engines out there. We have extensive third party libraries, dedicated 2D and 3D renderers, networking, multiple scripting language support, external plugins, etc. It would be an undertaking of immense effort and time to create a console port that fully supports all Godot has to offer.
Finally, because we do have limited resources, diverting any resources away from the core product to work on consoles would require slowing down development of Godot itself to create and maintain the console ports.
Licensing
The board of the Foundation strongly feels that we should only be using funds to develop Free and Open Source Software (FOSS). We are committed to being a fully FOSS project. Further, we credit our FOSS stance with a lot of our success. When you contribute to Godot, you become a part owner of the project and you don’t sign away your rights to your code in a CLA (contributor license agreement). This way, every contributor has assurance that they have worked to benefit all users, and that their contribution won’t be yanked away from them by the entity controlling development.
In short, we want to develop Godot in a way that ensures that anyone who downloads Godot can be assured that they own the copy of Godot that they are using. We do that by remaining dedicated to two things:
Using the MIT license
FOSS principles
MIT license
We use the MIT license to distribute Godot. Unfortunately, the MIT license is incompatible with providing official middleware because it very clearly states that we won’t take on liability for the code (i.e. you can’t sue us if it turns out that Godot doesn’t work for you, or has a bug that costs you money — which is important since we only operate on your donations to begin with). Further it is incompatible with non-middleware ports as well because such ports would have to be limited in their distribution to authorized console developers only.
Accordingly, any console port would have to be distributed under a modified MIT license or another license that allowed us to limit who the code could be distributed to (and potentially limit the distribution in other ways). In either case, we would have to compromise our FOSS ideals, which we feel are our strength.
FOSS principles
Further, and more importantly, we do all of our development in the open. Everything is on GitHub or our developer chat (chat.godotengine.org, which is open to all who want to discuss development of the project or just listen in). We don’t want to put ourselves in a situation where our development has to happen behind closed doors and away from the eyes of the community, and this is exactly what would be required by the console vendors.
Right now, anyone can see the volume of work that is happening on Godot by visiting Godot’s GitHub page. They can also hang out on the chat and get a feel for the process of development or ask questions directly to the developers. If we shift our development behind closed doors, then you have to take our word that things are progressing and that the donations are being put to good use (unless you have the relevant NDAs).
Finally, we want to assure every contributor and every donor that their contribution benefits all Godot users. If we put donations towards a console port that is hidden behind closed doors, then we are taking resources away from everyone and putting them into something that only benefits a select few and that isn’t something we want to do.
Summary
For the above reasons, the Foundation has decided not to provide console ports for now. Not because we categorically do not want to, quite the opposite actually, but because it currently is not feasible for us and would require to compromise the things that make Godot great. In the future, if console manufacturers become more open about the licensing of console ports in particular, and maybe even agree to support that endeavor financially, then we will happily reconsider. We would love to have official console ports alongside the existing ones from third-party vendors for all of our community to use.
-
+
\ No newline at end of file
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 f1c7f1091e..0a8d1ed6a1 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
@@ -5,7 +5,7 @@
Pedro J. Estébanez21 August 2021
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.
-
+
\ No newline at end of file
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 1152c35e65..07f9c9a5b6 100644
--- a/article/android_godot_editor_play_store_beta_release/index.html
+++ b/article/android_godot_editor_play_store_beta_release/index.html
@@ -14,7 +14,7 @@
Development of this feature is currently happening on GitHub, and we have been making solid progress toward enabling and running the Godot XR Editor on the Meta Quest and on PCVR devices. If you’re interested in helping out with testing or even contributing to the XR editor, please at a look at this pull-request.
Your feedback
As mentioned multiple times throughout the article, we are very much looking forward to your feedback on the Android editor. It’s a new territory and a great opportunity to bring more people to the Godot community, people with unique set of tools and limitations. As always, we couldn’t make Godot better without your help, so if you are planning to test this beta release, consider leaving a bug report on GitHub or joining the Godot Contributors Chat to talk to the project maintainers directly about your experience.
-
+
\ No newline at end of file
diff --git a/article/animation-data-redesign-40/index.html b/article/animation-data-redesign-40/index.html
index 5008b5f51e..b1f9dcc3dd 100644
--- a/article/animation-data-redesign-40/index.html
+++ b/article/animation-data-redesign-40/index.html
@@ -5,7 +5,7 @@
Juan Linietsky1 November 2021
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.
-
+
\ No newline at end of file
diff --git a/article/animation-retargeting-in-godot-4-0/index.html b/article/animation-retargeting-in-godot-4-0/index.html
index c6ac78ec2b..ace31a641e 100644
--- a/article/animation-retargeting-in-godot-4-0/index.html
+++ b/article/animation-retargeting-in-godot-4-0/index.html
@@ -10,7 +10,7 @@
Godot 4’s animation features have been improved as well as retargeting. Skeleton bones can now be manipulated directly in the viewport (GH-45699), and broken blend animations have been fixed (GH-57675).
To be honest, the retargeting feature is not a blocker for creating 3D games. Anyone familiar with 3D character animation workflow can do it outside of Godot. However, the implementation of retargeting makes it easier and keeps more of your workflow contained inside Godot.
There is still a lot to improve, and with more people diving into 3D development, there will be more demand to improve this aspect of the engine. I hope to see games taking advantage of this and all the other new features that Godot 4 brings.
-
+
\ No newline at end of file
diff --git a/article/announcing-2020-showreel/index.html b/article/announcing-2020-showreel/index.html
index 28b2a82508..ee27f8209d 100644
--- a/article/announcing-2020-showreel/index.html
+++ b/article/announcing-2020-showreel/index.html
@@ -5,7 +5,7 @@
Juan Linietsky25 April 2020
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!
-
+
\ No newline at end of file
diff --git a/article/announcing-2021-godot-games-showreel/index.html b/article/announcing-2021-godot-games-showreel/index.html
index 2d50aece17..3e543576b6 100644
--- a/article/announcing-2021-godot-games-showreel/index.html
+++ b/article/announcing-2021-godot-games-showreel/index.html
@@ -6,7 +6,7 @@
Hugo Locurcio13 November 2021
The Godot games showreel for 2021 is up! As every year, more and more quality submissions fall in our hands, making the selection job very difficult. This year was not an exception, as we had had a record submission amount (over 300). This time, several core contributors had to take the work of ranking 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 for providing his music!
Stay tuned for an upcoming showreel video featuring applications made with Godot :)
-
+
\ No newline at end of file
diff --git a/article/announcing-godot-2022-showreels/index.html b/article/announcing-godot-2022-showreels/index.html
index e0f4414af1..85fc48c8c1 100644
--- a/article/announcing-godot-2022-showreels/index.html
+++ b/article/announcing-godot-2022-showreels/index.html
@@ -5,7 +5,7 @@
Emi6 October 2022
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.
-
+
\ No newline at end of file
diff --git a/article/announcing-gogodotjam-3/index.html b/article/announcing-gogodotjam-3/index.html
index 2bf7df64f9..7af756dc9c 100644
--- a/article/announcing-gogodotjam-3/index.html
+++ b/article/announcing-gogodotjam-3/index.html
@@ -5,7 +5,7 @@
Ilaria Cislaghi16 May 2022
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
-
+
\ No newline at end of file
diff --git a/article/announcing-gogodotjam/index.html b/article/announcing-gogodotjam/index.html
index 56863f60df..acff1796ca 100644
--- a/article/announcing-gogodotjam/index.html
+++ b/article/announcing-gogodotjam/index.html
@@ -7,7 +7,7 @@
They include:
Showcases of the use-cases, workflows, and features of Godot
Comparisons of Godot with other game engines to debunk myths
Tutorials to help beginners get started with gamedev on Godot
Then Go Godot Jam will have the game jam while the events continue. The game jam is open to everyone.
We will announce the themes of the Jam before the start.
The Jam leaves time to design, develop, and test a game with plenty of time to learn Godot too. But why wait until then? Head over to the Learning Resources on gogodotjam.com/learn and start learning today!
The Go Godot Jam timeline in a nutshell is:
May 6 - June 9 (the entire period):
High-Quality Streaming
May 24 - June 2 (10 days):
The Game Jam
June 3 - June 8 (6 days):
Voting Period
June 9:
Online Award Ceremony
How do I join?
We prepared everything at gogodotjam.com. Here you will find:
The complete Go Godot Jam timeline with links to all content
Jam-specific information: rules, themes, submission, etc.
Learning resources from our partners and many more
Yes. Go Godot Jam is open for anyone who wants to make games. You don’t have to be a Godot Developer to enter the Jam! Whether you are starting or have developed games in other engines, we got you covered.
Who are the people behind the festival?
Several active members of the community have partnered up to bring Go Godot Jam to life. The organisers are:
Thank you for the interview, Adrian! Any words at the end?
Thank you too!
Go Godot Jam will be so much fun!
I am really glad to take part of what has been a growing community of content creators and events organisers aroung Godot and I can’t wait to see more of it!
-
+
\ No newline at end of file
diff --git a/article/announcing-monthly-live-q/index.html b/article/announcing-monthly-live-q/index.html
index 9b59bdb6f9..884eb2c346 100644
--- a/article/announcing-monthly-live-q/index.html
+++ b/article/announcing-monthly-live-q/index.html
@@ -6,7 +6,7 @@
Juan Linietsky22 July 2020
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.
What has been an idea (and something many community members suggested for a long time) is now a reality. We will be hosting a Live Q&A session with Godot core contributors the last week of each month.
Live Q&A
The idea is to stream a Jitsi a call between core contributors to our Youtube channel. A moderator will pick questions from the chat and we will try to answer them as best as possible. There will be some quirks to this format though:
Every month, besides core contributors who are hired by the project, we will also rotate other guest contributors to answer questions about the areas they contribute to.
Patrons over the $26 tier will be able to submit questions in advance (depending on the volume we may change this to lower tiers, or change the benefits, we’ll see over time), which will be preselected and answered at the beginning of the Live Q&A session.
Save the date!
The next live Q&A will take place on Thursday 30 of July at 18hs (6pm) UTC on our Youtube channel.
EDIT: The Youtube stream is now up, you can subscribe and set a reminder on it!
-
+
\ No newline at end of file
diff --git a/article/announcing-new-community-map-user-groups/index.html b/article/announcing-new-community-map-user-groups/index.html
index d03c7b9451..0efec2df05 100644
--- a/article/announcing-new-community-map-user-groups/index.html
+++ b/article/announcing-new-community-map-user-groups/index.html
@@ -7,7 +7,7 @@
Alternatively, you can also send an e-mail to webmaster at godotengine · org to request your community to be added to the list.
-
+
\ No newline at end of file
diff --git a/article/announcing-new-hire-gilles-roudiere/index.html b/article/announcing-new-hire-gilles-roudiere/index.html
index cf8d6c797f..b2354723c4 100644
--- a/article/announcing-new-hire-gilles-roudiere/index.html
+++ b/article/announcing-new-hire-gilles-roudiere/index.html
@@ -5,7 +5,7 @@
Juan Linietsky26 August 2020
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!
-
+
\ No newline at end of file
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 f442ea7502..214abe785e 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
@@ -5,7 +5,7 @@
Juan Linietsky13 October 2017
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!
-
+
\ No newline at end of file
diff --git a/article/asset-library-web-frontend-reaches-beta/index.html b/article/asset-library-web-frontend-reaches-beta/index.html
index 7b203a121f..a35b9559bc 100644
--- a/article/asset-library-web-frontend-reaches-beta/index.html
+++ b/article/asset-library-web-frontend-reaches-beta/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde31 October 2016
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!
-
+
\ No newline at end of file
diff --git a/article/atlas-support-returns-godot-3-2/index.html b/article/atlas-support-returns-godot-3-2/index.html
index b65d68c8f1..f5fd300647 100644
--- a/article/atlas-support-returns-godot-3-2/index.html
+++ b/article/atlas-support-returns-godot-3-2/index.html
@@ -7,7 +7,7 @@
As always, if you are not yet, please consider becoming our patron, help us hire an extra developer and ensure that Godot development remains free.
-
+
\ No newline at end of file
diff --git a/article/basic-cryptography-ssl-improvements/index.html b/article/basic-cryptography-ssl-improvements/index.html
index ea89e29309..34006e7292 100644
--- a/article/basic-cryptography-ssl-improvements/index.html
+++ b/article/basic-cryptography-ssl-improvements/index.html
@@ -98,7 +98,7 @@
Future work
This has been quite a long work, and included some refactoring of the core code to use a single library for cryptography (mbedTLS) instead of multiple specific libraries for hashing algorithms and AES. This work will allow us to introduce support for AES encryption and more at scripting level in future versions.
Additionally, the SSL overhaul helped a lot in developing the upcoming DTLS implementation.
-
+
\ No newline at end of file
diff --git a/article/become-godot-contributor-hacktoberfest-2018/index.html b/article/become-godot-contributor-hacktoberfest-2018/index.html
index 9c185b03ac..b93985299f 100644
--- a/article/become-godot-contributor-hacktoberfest-2018/index.html
+++ b/article/become-godot-contributor-hacktoberfest-2018/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde1 October 2018
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!
-
+
\ No newline at end of file
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 25df4a34c9..41b6c27a78 100644
--- a/article/ben-tristem-gamedevtv-are-kickstarting-godot-course/index.html
+++ b/article/ben-tristem-gamedevtv-are-kickstarting-godot-course/index.html
@@ -6,7 +6,7 @@
You’ll see all the details about the course’s purpose and contents on the Kickstarter page.
Ben tells us why they support Godot
GameDev.tv had already been showing its interest in Godot by sponsoring us financially on Patreon over the last few months, and now they show their commitment and trust by actual making their own teaching product based on Godot.
We believe in the future of Godot, and that’s the reason we’ve been sponsoring the project for a while. It’s also the fundamental reason we’re creating courses for the engine – to help support it and spread the word.
I’ve asked Ben to give us some details about what they see in Godot, and why they are so enthusiastic about it and willing to give it a top-tier position among their game development courses:
We’re big fans of Godot’s:
Language flexibility
Separate 2D and 3D pipelines
Open source(ness), allowing users to modify and even contribute
And it’s fun! It’s fun to use, it’s simple when you open it, it’s powerful if you need it, it unfolds the complexity as and when you require it. We find that so inviting!
These points really echo what we hear on all Godot community channels, where users really enjoy the flexibility offered by Godot’s design and license, and simply have a lot of fun experimenting and working on long term projects alike.
-
+
\ No newline at end of file
diff --git a/article/beta-release-python-support/index.html b/article/beta-release-python-support/index.html
index f28e6e0d27..e7aaf49deb 100644
--- a/article/beta-release-python-support/index.html
+++ b/article/beta-release-python-support/index.html
@@ -6,7 +6,7 @@
Binaries for all platforms will eventually be provided when Godot 3.0 gets stable.
As always, keep in mind this is a beta and you are expected to encounter issues and maybe crashes. If so, make sure to report them on the project’s bug tracker ;-)
-
+
\ No newline at end of file
diff --git a/article/betsy-gpu-texture-compressor/index.html b/article/betsy-gpu-texture-compressor/index.html
index 26ac1e406e..647e88e33e 100644
--- a/article/betsy-gpu-texture-compressor/index.html
+++ b/article/betsy-gpu-texture-compressor/index.html
@@ -8,7 +8,7 @@
A 64-core Ryzen Threadripper paired with a GeForce 1030 or Radeon HD 7350, the CPU will obviously beat the GPU.
However if you own the latest GeForce 3080 or Radeon 6800 XT, chances are a GPU encoder will win in encoding time.
It is important to mention that my work was mostly porting existing codecs written in C or C++ for the CPU, and convert them into GPU-friendly compute shaders. A notable exception is ETC2’s P-mode which has been extended with our own efforts to significantly improve encoding quality of this mode.
You can find more information in the LICENSE and README pages.
Benchmark Performance
OK enough boring explanation! Let’s see how Betsy fares against other encoders:
Notes:
CPU is Intel i7 7700 3.6Ghz (4.2Ghz turbo). 2x16GB RAM 3000Mhz. 4 core, 8 threads.
GPU is AMD Radeon HD 560 2GB VRAM
Benchmark was done on Linux Ubuntu 18.04 LTS (HWE), Mesa 20.1.3
ConvectionKernels aka CVTT, which uses SIMD/SSE to run compress multiple blocks at once, similarly to what Betsy does.
Multithreaded tests were done spawning one process for each texture. This is suboptimal as it results in oversubscription for CVTT, and excessive contention of access to GPU for Betsy. The exception is etc2comp which supports native per-texture multithreading out of the box.
Single threaded numbers for CVTT are included because multithreading is not supported out of the box by CVTT
Single threaded numbers for etc2comp are not included because it supports multithreading out of the box, and single threaded version is simply way too slow.
The original Kodim set’s resolution was too small to fully saturate the GPU in Betsy (according to radentop, around 60% GPU usage), which is why there is a strong difference between the ‘multithreaded’ and ‘singlethreaded’ versions. This difference gets much smaller for the 2048 upscaled set (keeping aspect ratio).
Betsy was run for every texture independently, which includes a small overhead for initializing OpenGL every time. This could be further improved to support encoding multiple textures with one single invocation.
Betsy’s first run in a system may take considerably larger time as compute shaders must be compiled and will later be cached by the driver in subsequent runs. This will happen again if the driver is updated.
All values are time in seconds.
Betsy’s Quality = 1 (medium quality) was included because it only affects ETC1 modes (not the extended T, H and P ETC2 modes), the quality difference is very low, but the performance gains are gigantic.
This needs more research, but it appears BC1 is bottleneck by GPU initialization, GPU uploads and data download, rather than encoding time
CVTT supports BC1, however its CLI tool doesn’t come with BC1 support out of the box and I had no time to add support for it to do the benchmark
BC5
Betsy ST
Betsy MT
nvcompress ST (CPU)
nvcompress MT (CPU)
Kodim set (25 textures)
2,94
0,73
1,97
0,42
Upscaled to 2048xN Kodim set
5,84
1,70
13,18
0,86
Notes:
This needs more research, but it appears BC5 is bottleneck by GPU initialization, GPU uploads and data download, rather than encoding time
CVTT supports BC5, however its CLI tool doesn’t come with BC5 support out of the box and I had no time to add support for it to do the benchmark
Benchmark quality
Notes:
RSMLE: Lower is better. It means Root Mean Squared Logarithmic Error.
Betsy q = 1 is medium quality
Betsy q = 2 is maximum quality
It is unknown why ConvectionKernels some RSMLE increased in ETC2 over ETC1. It could be a CVTT bug, or a difference in how CVTT measures error vs how I measured it.
ETC1 RGB
Betsy (q = 1)
Betsy (q = 2)
ConvectionKernels
etc2comp
Average
0.0244532
0.02389376
0.02383864
0.02502284
kodim01.png
0.027957
0.027166
0.026895
0.028578
kodim02.png
0.021755
0.021433
0.021336
0.021954
kodim03.png
0.019651
0.019205
0.01924
0.019886
kodim04.png
0.021453
0.021123
0.020989
0.021704
kodim05.png
0.033579
0.032763
0.032588
0.034686
kodim06.png
0.024893
0.024265
0.024038
0.02545
kodim07.png
0.021911
0.021344
0.021057
0.022076
kodim08.png
0.032968
0.032022
0.031604
0.034042
kodim09.png
0.02002
0.019602
0.01945
0.020201
kodim10.png
0.01986
0.019409
0.019306
0.020063
kodim11.png
0.023587
0.023122
0.022928
0.024056
kodim12.png
0.018662
0.018255
0.018087
0.018833
kodim13.png
0.035328
0.034559
0.034416
0.036992
kodim14.png
0.030336
0.029845
0.029985
0.030972
kodim15.png
0.02186
0.021373
0.021296
0.02207
kodim16.png
0.019238
0.018806
0.018663
0.019542
kodim17.png
0.020262
0.019792
0.019767
0.020738
kodim18.png
0.027783
0.02724
0.02728
0.028719
kodim19.png
0.023358
0.022718
0.022477
0.023831
kodim20.png
0.019751
0.019281
0.019395
0.020377
kodim21.png
0.025063
0.024488
0.024325
0.025592
kodim22.png
0.02337
0.022873
0.023036
0.023909
kodim23.png
0.020536
0.020071
0.020435
0.021016
kodim24.png
0.028179
0.027181
0.028165
0.029515
kodim25.png
0.02997
0.029408
0.029208
0.030769
ETC2 RGB
Betsy (q = 1)
Betsy (q = 2)
ConvectionKernels
etc2comp
Average
0.02432348
0.02378536
0.02400548
0.02412212
kodim01.png
0.027986
0.027183
0.027318
0.027943
kodim02.png
0.021448
0.021169
0.020991
0.020887
kodim03.png
0.019842
0.019471
0.018829
0.018195
kodim04.png
0.021408
0.021105
0.020959
0.020991
kodim05.png
0.03355
0.032722
0.033068
0.033774
kodim06.png
0.02492
0.024283
0.024317
0.024731
kodim07.png
0.02115
0.020651
0.020834
0.020812
kodim08.png
0.033198
0.032233
0.03278
0.033356
kodim09.png
0.019712
0.019335
0.019633
0.01955
kodim10.png
0.019716
0.019285
0.019424
0.019459
kodim11.png
0.023473
0.022995
0.023223
0.023395
kodim12.png
0.018597
0.018215
0.018109
0.017998
kodim13.png
0.03541
0.034635
0.035375
0.036008
kodim14.png
0.030282
0.029791
0.029887
0.029976
kodim15.png
0.021945
0.021515
0.021449
0.021243
kodim16.png
0.01877
0.018382
0.01866
0.018717
kodim17.png
0.020175
0.019729
0.019988
0.019844
kodim18.png
0.028034
0.027471
0.027707
0.02808
kodim19.png
0.023166
0.022545
0.022932
0.023125
kodim20.png
0.019773
0.019299
0.019545
0.019642
kodim21.png
0.02487
0.024313
0.024721
0.024833
kodim22.png
0.02336
0.022859
0.023109
0.02323
kodim23.png
0.019306
0.018971
0.019284
0.018592
kodim24.png
0.028032
0.027072
0.02846
0.028448
kodim25.png
0.029964
0.029405
0.029535
0.030224
BC1
Betsy
nvcompress
Average
0.028589
0.026943
kodim01.png
0.034792
0.032564
kodim02.png
0.02562
0.024146
kodim03.png
0.020277
0.018898
kodim04.png
0.023814
0.022424
kodim05.png
0.040001
0.037991
kodim06.png
0.0298
0.028163
kodim07.png
0.024172
0.022762
kodim08.png
0.042638
0.040288
kodim09.png
0.022284
0.020803
kodim10.png
0.022031
0.020619
kodim11.png
0.028216
0.026493
kodim12.png
0.020243
0.01892
kodim13.png
0.045498
0.042873
kodim14.png
0.034357
0.032726
kodim15.png
0.024274
0.023026
kodim16.png
0.021505
0.019977
kodim17.png
0.023141
0.021715
kodim18.png
0.033236
0.031521
kodim19.png
0.027642
0.025856
kodim20.png
0.02268
0.021438
kodim21.png
0.029862
0.028107
kodim22.png
0.026809
0.02531
kodim23.png
0.020595
0.019312
kodim24.png
0.034883
0.033199
kodim25.png
0.036355
0.034444
BC5
Betsy
nvcompress
Average
0,40713988
0,4071152
kodim01.png
0,380992
0,380943
kodim02.png
0,147688
0,147673
kodim03.png
0,341727
0,341719
kodim04.png
0,35518
0,355176
kodim05.png
0,317971
0,317893
kodim06.png
0,467379
0,467362
kodim07.png
0,368736
0,368721
kodim08.png
0,507863
0,507801
kodim09.png
0,511146
0,511134
kodim10.png
0,482672
0,482662
kodim11.png
0,364467
0,364442
kodim12.png
0,570088
0,570084
kodim13.png
0,388023
0,387951
kodim14.png
0,313848
0,313811
kodim15.png
0,495639
0,49563
kodim16.png
0,404634
0,404633
kodim17.png
0,329696
0,329685
kodim18.png
0,229002
0,228954
kodim19.png
0,424489
0,424464
kodim20.png
0,70348
0,703468
kodim21.png
0,487161
0,487138
kodim22.png
0,393033
0,393022
kodim23.png
0,364163
0,364154
kodim24.png
0,424539
0,424513
kodim25.png
0,404881
0,404847
Get Technical
If you’re a GPU nerd, we have an in-depth analysis of how betsy’s compute shaders are implemented.
Keep in mind it is quite advanced and assumes you’re somewhat familiar with GPU shader coding.
-
+
\ No newline at end of file
diff --git a/article/beyond-100000-you-re-breathtaking/index.html b/article/beyond-100000-you-re-breathtaking/index.html
index d4e1b3e735..96ae858606 100644
--- a/article/beyond-100000-you-re-breathtaking/index.html
+++ b/article/beyond-100000-you-re-breathtaking/index.html
@@ -8,7 +8,7 @@
I will make the case that it is a bit of both :)
The two accumulated curves show the total number of issues created over the lifetime of the repository (topmost curve), and the subset of those which have been closed (as fixed or invalid). The difference between the two curves represents the number of issues still open at a given point in time - currently exactly 11,000, out of 53,648 issues total, so roughly 20%.
This is a fairly normal percentage of yet-unresolved issues in software projects of this scale, but it can definitely be better.
I annotated the graph with some key events of Godot’s development which match peaks in either reported bugs (usually at the start of a beta phase, or shortly after a stable release), or closed issues (when we do a “spring cleaning” going through old issues to check if they are still reproducible in a newly released Godot version). You can see notably two big peaks of closed issues around the 3.2 release, when we had a coordinated effort from maintainers to go through the whole backlog and ask reporters to confirm whether their issues were still valid, or had been fixed. This reduced the percentage of open issues from 29% to 19%, and it’s been mostly stable since, with minor fluctuations.
We are preparing a new “spring cleaning” to properly reassess a lot of the old issues which have been opened before the 4.0 release, or in the early days of 4.0 or 4.1, and may no longer be relevant nowadays with 4.3 and soon 4.4 beta.
As the volume of issues keeps increasing steadily, but the number of active bug triagers doesn’t really grow as fast, we are working on improving and documenting our workflows so that we can:
Onboard new volunteers to help triage new and old issues;
Spread the workload and be more consistent with our issue triage;
Be confident that while doing so, we do increase the quality of our open issues, which isn’t something that can be easily tracked in numbers.
We will share more details here and on the Godot blog when this process is ready to welcome new volunteers.
In the meantime, you can already do some simple things which help greatly the existing bug triage team:
Regularly re-assess your own issues (you can bookmark that URL). Make sure that they are reproducible in the latest stable release and dev snapshots, and that there is a minimal reproduction project that contributors can use to reproduce and fix the issue. If your issue is no longer relevant, please close it with a comment explaining why.
Feel free to apply the same process to other people’s issues that you stumble upon, especially if their last update was a long time ago. In this case you can’t close issues yourself, but you can suggest it by commenting that the issue is no longer reproducible in the version you tested. Bug triagers will get a notification and can double check.
Godot gets almost the same number of new pull requests per month as new issues, roughly 600 of each per month (that’s 20 PRs and 20 issues per day).
The PR volume increased a lot over the lifetime of the project to culminate at over 700 PRs per month at the end of the 4.0 development. Since then, as the Godot userbase grew a lot and we are more careful with compatibility and API design, reviews can take a bit longer and the total monthly volume seems to have plateaued around 500-600. That’s still plenty enough for a fairly small group of reviewers.
Someone should plot this data with relative percentages, but it seems like the size/complexity of pull requests is slightly increasing recently. Whether that trend gets confirmed or not, I can attest that reviewing 600 PRs per month is hard, and that we need more help for interested contributors and users to both test and review the PRs that get opened on a daily basis.
That’s all for now, I was already way too long and verbose while drafting this at the last minute to (try to) snatch the 100,000th issue number ;)
Aside from showing some cool numbers, I mostly want to convey that we are well aware that we have a significant backlog, though it’s not as dire as it might look from the outside.
To deal with it, we need better triage and review processes (which we are designing now), more volunteers involved in these processes, but also importantly more funding. Volunteer contributors do a ton of work, but many critical parts of the workflow depend on a few paid contractors, and we need to grow that group to better manage the increasing scale of the project.
I’ll make a quick note that 100,000 is the combined number of issues and PRs, which share the same index system on GitHub.
At the time of writing, we’ve actually had 53,648 issues and 45,213 PRs created. Astute minds will notice that the sum is not 100,000; the difference comes from spam issues or PRs which have been deleted by GitHub. ↩
-
+
\ No newline at end of file
diff --git a/article/bugs-lets-catch-em-all-saturday/index.html b/article/bugs-lets-catch-em-all-saturday/index.html
index 21d2892f7f..3049221f5a 100644
--- a/article/bugs-lets-catch-em-all-saturday/index.html
+++ b/article/bugs-lets-catch-em-all-saturday/index.html
@@ -8,7 +8,7 @@
Rémi Verschelde8 December 2017
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.
-
+
\ No newline at end of file
diff --git a/article/call-for-participation-online-godotcon-2021/index.html b/article/call-for-participation-online-godotcon-2021/index.html
index 134eaf1dc4..79a8508be8 100644
--- a/article/call-for-participation-online-godotcon-2021/index.html
+++ b/article/call-for-participation-online-godotcon-2021/index.html
@@ -5,7 +5,7 @@
Julian Murgia3 December 2020
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!
-
+
\ No newline at end of file
diff --git a/article/call-participation-godotcon-2019/index.html b/article/call-participation-godotcon-2019/index.html
index 415e4d40ed..e3ad1a0590 100644
--- a/article/call-participation-godotcon-2019/index.html
+++ b/article/call-participation-godotcon-2019/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde18 December 2018
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.
-
+
\ No newline at end of file
diff --git a/article/call-volunteers-organizing-regional-communities/index.html b/article/call-volunteers-organizing-regional-communities/index.html
index 1e578e885b..c7729b1398 100644
--- a/article/call-volunteers-organizing-regional-communities/index.html
+++ b/article/call-volunteers-organizing-regional-communities/index.html
@@ -5,7 +5,7 @@
Juan Linietsky26 February 2020
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!
-
+
\ No newline at end of file
diff --git a/article/camille-mohr-daurat-hired-work-physics/index.html b/article/camille-mohr-daurat-hired-work-physics/index.html
index e9889ed5d6..7ebd3d682a 100644
--- a/article/camille-mohr-daurat-hired-work-physics/index.html
+++ b/article/camille-mohr-daurat-hired-work-physics/index.html
@@ -6,7 +6,7 @@
http://www.fracteed.com/godot.html
-
+
\ No newline at end of file
diff --git a/article/cfp-game-development-room-fosdem-2020/index.html b/article/cfp-game-development-room-fosdem-2020/index.html
index 57ae372118..918db2a435 100644
--- a/article/cfp-game-development-room-fosdem-2020/index.html
+++ b/article/cfp-game-development-room-fosdem-2020/index.html
@@ -6,7 +6,7 @@
We also plan a 1-hour session in the middle of the day to have several lightning talks of 10 min each, so you can apply for this too if you prefer this format.
Please submit the proposal at the latest on December 1st. FOSDEM has a hard limit on December 14th, but we want some leeway to properly arrange the schedule. We can’t guarantee participation after our deadline.
If you have any doubts or want to volunteer to help us organizing (manning the camera, helping speaker transitions, moderating audience questions, etc.) you can let us know by sending a message to contact at godotengine dot org.
Audience
We naturally want people to watch the presentations. Entrance to FOSDEM is free and doesn’t require registration. If you want to meet fellow game developers in the open source world, this is the opportunity.
Note that barring any technical difficulties, the talks should be recorded and made available under a Creative Commons license on the FOSDEM website shortly after the event.
-
+
\ No newline at end of file
diff --git a/article/change-image/index.html b/article/change-image/index.html
index 525225a7b1..d245420521 100644
--- a/article/change-image/index.html
+++ b/article/change-image/index.html
@@ -5,7 +5,7 @@
Juan Linietsky22 September 2016
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!
-
+
\ No newline at end of file
diff --git a/article/code-of-conduct-godot-community/index.html b/article/code-of-conduct-godot-community/index.html
index d7f7285c94..ec1d098100 100644
--- a/article/code-of-conduct-godot-community/index.html
+++ b/article/code-of-conduct-godot-community/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde4 November 2019
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.
-
+
\ No newline at end of file
diff --git a/article/collaboration-with-google-forge-2023/index.html b/article/collaboration-with-google-forge-2023/index.html
index b50330ef13..61e0bb5bb4 100644
--- a/article/collaboration-with-google-forge-2023/index.html
+++ b/article/collaboration-with-google-forge-2023/index.html
@@ -5,7 +5,7 @@
Clay John14 December 2023
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.
-
+
\ No newline at end of file
diff --git a/article/communications-update-2023/index.html b/article/communications-update-2023/index.html
index 8c9feb1428..7de55871ac 100644
--- a/article/communications-update-2023/index.html
+++ b/article/communications-update-2023/index.html
@@ -5,7 +5,7 @@
Godot Foundation18 December 2023
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!
-
+
\ No newline at end of file
diff --git a/article/community-forum-back/index.html b/article/community-forum-back/index.html
index 00cd32ac7f..b42c75f604 100644
--- a/article/community-forum-back/index.html
+++ b/article/community-forum-back/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde4 April 2016
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.
-
+
\ No newline at end of file
diff --git a/article/complex-text-layouts-progress-report-1/index.html b/article/complex-text-layouts-progress-report-1/index.html
index a267c65ecc..4be1c5d889 100644
--- a/article/complex-text-layouts-progress-report-1/index.html
+++ b/article/complex-text-layouts-progress-report-1/index.html
@@ -10,7 +10,7 @@
TextServerFallback - No BiDi and contextual shaping.
TextServerGDNative
Wrapper class for the GDNative text server implementations.
UTF-32 transition - https://github.com/godotengine/godot/pull/40999 (merged to the master branch).
Text server implementations - https://github.com/godotengine/godot/pull/41100 (first 4 commits, PR is regularly rebased to keep up with upstream changes, exact commit hashes may vary).
BiDi and shaping process overview diagram - https://bruvzg.github.io/media/files/gdtl_operation_notes_1_shaping_draft.pdf
Line breaking process overview diagram - https://bruvzg.github.io/media/files/gdtl_operation_notes_2_line_breaking_draft.pdf
Line justification process overview diagram - https://bruvzg.github.io/media/files/gdtl_operation_notes_3_justification_draft.pdf
GDNative library template - https://github.com/bruvzg/gdnative_text_server_template (dummy GDNative library implementation, intended as a base for future CoreText, DirectWrite based text servers or/and moving ICU/HarfBuzz based text server out of the core engine distribution).
-
+
\ No newline at end of file
diff --git a/article/complex-text-layouts-progress-report-2/index.html b/article/complex-text-layouts-progress-report-2/index.html
index 8574ed7d86..030d3ba1f0 100644
--- a/article/complex-text-layouts-progress-report-2/index.html
+++ b/article/complex-text-layouts-progress-report-2/index.html
@@ -20,7 +20,7 @@
Controls OpenType font features for the node e.g. ligature types to use, number styles, small caps, etc. (Full list of standard tags, fonts can have custom features as well).
OpenType features:
Reference work
UI improvements for implementing BiDi aware apps proposal: godot-proposals#1183.
UI mirroring, Font, Theme, and control changes: godot#41100 (commits 5 to 8, the PR is regularly rebased to keep up with upstream changes, exact commit hashes may vary).
-
+
\ No newline at end of file
diff --git a/article/complex-text-layouts-progress-report-3/index.html b/article/complex-text-layouts-progress-report-3/index.html
index d23982077c..c6c5b9c27d 100644
--- a/article/complex-text-layouts-progress-report-3/index.html
+++ b/article/complex-text-layouts-progress-report-3/index.html
@@ -22,7 +22,7 @@
Fallback text server without CTL support, it uses same text server API and provides roughly the same text rendering capabilities as in Godot 3.2 (fb).
Text servers can be enabled/disabled by using following build options: module_text_server_adv_enabled, module_text_server_fb_enabled.
If an editor or export template is built with the multiple text servers enabled, the default one can be selected in Project Settings or by using the --text-driver Name command line argument.
At runtime, the text server can be changed by using the TextServerManager class, but doing so will cause all existing fonts and text buffers to become invalid. It’s the user’s responsibility to free all such resources before switching text server.
Additional text servers can be implemented as C++ modules or GDNative libraries, and loaded / used in the same way default servers are.
Some languages do not use spaces between words, and dictionaries (or other type of rule-based word breaking data) are required for better line breaking. ICU provides such data, but its size can be substantial for smaller projects. To reduce export size, ICU data is not included by default, but it can be added at export and stored in the PCK archive. ICU data is always embedded in the editor binaries. Also, you can avoid the necessity for ICU data at all by manually adding valid breaking points (by adding zero-width breaking spaces, which can be inserted from Godot input controls’ context menu).
Demos and docs
CTL documentation and tutorials PR - https://github.com/godotengine/godot-docs/pull/4319
-
+
\ No newline at end of file
diff --git a/article/core-refactoring-progress-report-1/index.html b/article/core-refactoring-progress-report-1/index.html
index 016884e8a6..56068566a5 100644
--- a/article/core-refactoring-progress-report-1/index.html
+++ b/article/core-refactoring-progress-report-1/index.html
@@ -5,7 +5,7 @@
Juan Linietsky29 February 2020
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.
-
+
\ No newline at end of file
diff --git a/article/core-refactoring-progress-report-2/index.html b/article/core-refactoring-progress-report-2/index.html
index 3757c860b8..6de0156891 100644
--- a/article/core-refactoring-progress-report-2/index.html
+++ b/article/core-refactoring-progress-report-2/index.html
@@ -5,7 +5,7 @@
Juan Linietsky28 March 2020
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.
-
+
\ No newline at end of file
diff --git a/article/csharp-android-support/index.html b/article/csharp-android-support/index.html
index cca445f09b..282515fd39 100644
--- a/article/csharp-android-support/index.html
+++ b/article/csharp-android-support/index.html
@@ -6,7 +6,7 @@
C# interactive shell from the game SkyOfSteel by ForLoveOfCats running on an Android emulator. Edit (2021-06-07): This game development has halted and the domain expired, so the link was changed to point to archived GitHub repository.
Up until now Godot supported scripting with C# only on desktop platforms. Our plan has been to add support for other platforms over time and Android has been by far the most requested one. Even when it comes to overall feedback, not only about platforms, Android tends to be at the top of the list.
Today I’m glad to announce we’ve finally made it happen. Godot 3.2 will ship with support for exporting C# games to the Android platform.
The process of exporting a game for Android with C# is the same as it would be if you were using GDScript. Godot will make sure to add all the assemblies and dependencies to the exported APK. No extra steps are required from you.
It supports all target ABIs Godot does (armeabi-v7a, arm64-v8a, x86 and x86_64). Currently, we only use JITed code, with AOT support coming in the future.
If you can’t wait for a 3.2 release and you feel brave enough, you may be interested in building Godot from source to try it out. In order to do that you will also need to build the Mono runtime from source. We’re considering the possibility of providing prebuilt Mono packages, but that’s still uncertain.
If you’re interested in building Godot from source with C# support, we have a page documenting this process, as well as a section specific for Android.
I’ve created a repository with scripts to help in the process of building the Mono runtime for Android. You can find it here. You may need to apply some patches to the Mono repository in order to be able to build it for armeabi-v7a and x86 on newer NDK releases.
Rewriting the module’s editor code in C#* *
Excluding the C# bindings, most of the C# module’s code is written in C++. This includes the editor code in charge of building the project, opening scripts with external editors/IDEs, and exporting the C# game. This is an obstacle for the future as not only is C++ a lower level language, but the API available is also a more limited one (adding thirdparty libraries cannot be done lightly).
We’ve gotten away with this until now by moving some small parts of the code to C#. This allowed us to benefit from .NET where we needed it. However, this requires a lot of boilerplate code in order to invoke C# from C++, quickly turning into bloat.
All of this together makes adding new features to the editor a much slower and painful process than it should be. As such I decided that, before embarking on such tasks, I had to do something about this.
Last month I worked on moving most of the editor code to C# to make it easier to maintain and extend. The new code only has one method that gets invoked from C++, which is called during editor initialization. All the other C++ to C# calls are instead handled by the existing scripting implementation (signals, object calls, etc.).
The interesting part is that the new code is pretty much a Godot addon. It uses the same C# API Godot projects and addons use. There are only two differences with real addons:
Unlike other addons, this one is not part of your project and is not listed in Project Settings > Plugins. Instead, it’s enabled by the module when the editor is loaded.
If you peek into the code you may notice that classes derived from Godot.Object are not marked with ToolsAttribute. This is intentional as everything there is meant to run in the editor. Using this attribute would be redundant so we decided to add a special case for it.
There were several bugs that needed to be fixed to get things working properly; especially related to hot-reloading. Since this is pretty much a glorified Godot addon with some extra privileges, those fixes also benefit other Godot addons and editor plugins written in C#.
There were also some great build system improvements. The most important: SCons will now take care of building the C# API to be bundled with the Godot editor, a step that had to be done manually before.
What’s to come next
The next step in the roadmap is integration with the MonoDevelop IDE. More details will come in the next devblog, in a bit less than a month. You can expect much awaited features like debugging as well as better experience for opening files with this IDE (currently we use the command line with bad results). Thanks to the editor re-write, this will be a much easier task.
If you’re wondering about support for WebAssembly and iOS or integration with Visual Studio and VS Code, don’t fear. Those are all on the roadmap. You can expect to hear more about them in the future.
-
+
\ No newline at end of file
diff --git a/article/csharp-ios-signals-events/index.html b/article/csharp-ios-signals-events/index.html
index 4c0bcb43a3..b87afab571 100644
--- a/article/csharp-ios-signals-events/index.html
+++ b/article/csharp-ios-signals-events/index.html
@@ -34,7 +34,7 @@
As seen in the example, the most important part that’s missing is support for raising the event. This right now would only invoke the event delegates, but it won’t emit the signal, which is important to notify engine and GDScript listeners. As such, we still need to use the classic EmitSignal call, which will emit the signal as well as raise the event. More work will be needed in order to support event raising.
What comes next
This progress report came really delayed. You can expect a new one in the next weeks, in which I’ll be announcing Godot extensions for both Visual Studio and VS Code!
After that there are two more tasks in my current roadmap. One of them is separating the Godot API into namespaces (right now we have everything in the same bloated namespace).
The other task is writing a C# API to wrap the Godot file system. This new API is meant to replace the auto-generated Directory and File classes (which will still be available for compatibility). The new API is meant to be very similar to what developers are used to in .NET.
C# is now working on almost every platform Godot supports, with the exception of the Universal Windows Platform (UWP). While UWP is not part of my current roadmap, support for it is likely to happen before 4.0 is released. Also WebAssembly, while already working, is still lacking AOT compilation from Godot which is of high priority.
-
+
\ No newline at end of file
diff --git a/article/csharp-vs-and-vscode/index.html b/article/csharp-vs-and-vscode/index.html
index 921858acd4..7a67862b65 100644
--- a/article/csharp-vs-and-vscode/index.html
+++ b/article/csharp-vs-and-vscode/index.html
@@ -43,7 +43,7 @@
roadmap for Godot 4.0 before starting any new work.
-
+
\ No newline at end of file
diff --git a/article/csharp-wasm-aot/index.html b/article/csharp-wasm-aot/index.html
index 7084bbb4b7..bfcc7d8742 100644
--- a/article/csharp-wasm-aot/index.html
+++ b/article/csharp-wasm-aot/index.html
@@ -10,7 +10,7 @@
Also more progress will be made on AOT compilation over time and it will be a priority to have it working on WebAssembly as soon as possible.
-
+
\ No newline at end of file
diff --git a/article/custom-sky-shaders-godot-4-0/index.html b/article/custom-sky-shaders-godot-4-0/index.html
index 2c97deb612..202b108238 100644
--- a/article/custom-sky-shaders-godot-4-0/index.html
+++ b/article/custom-sky-shaders-godot-4-0/index.html
@@ -28,7 +28,7 @@
Please test out these new shaders and share what you create!
And as always, if you are not yet, consider becoming our patron. This ensures that Godot development remains free from the control of any company and we can keep working like now, with the freedom to listen to everyone equally.
-
+
\ No newline at end of file
diff --git a/article/d3d12-adventures-in-shaderland/index.html b/article/d3d12-adventures-in-shaderland/index.html
index e9d7a1b730..0a0986d206 100644
--- a/article/d3d12-adventures-in-shaderland/index.html
+++ b/article/d3d12-adventures-in-shaderland/index.html
@@ -6,7 +6,7 @@
Microsoft may very well end up adding SCs natively to Direct3D. Nonetheless, in the current state of things this hack/technique/magic is very close to what real SCs would be in terms of performance. The ISA assembly takes the patched values into account so it can run its own informed optimization passes. This way, it can provide a late form of what we were making an effort to prevent at earlier stages. Maybe the biggest downside is that the DXIL blob has to be validated-signed every time it’s patched. This takes some extra time and forces us to include the dxil.dll file with the binary distribution of the engine.
Closing words
First of all, if you have reached here, you’re amazing and thank you for reading. I really wanted to share the story of my adventures in this territory.
My ways into this issues may or may not be the best, but what I’m pretty sure about is that they are at least interesting or exotic enough for people interested or curious about these topics.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors in their free time, and a handful of part or full-time developers hired thanks to donations from the Godot community. A big thank you 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.
-
+
\ No newline at end of file
diff --git a/article/design-of-the-skeleton-modifier-3d/index.html b/article/design-of-the-skeleton-modifier-3d/index.html
index df2e6cd91c..ce50a409cb 100644
--- a/article/design-of-the-skeleton-modifier-3d/index.html
+++ b/article/design-of-the-skeleton-modifier-3d/index.html
@@ -72,7 +72,7 @@
You can see the pose is different depending on the signal.
Do I always need to create a custom SkeletonModifier3D when modifying a Skeleton3D bone?
As explained above, the modification provided by SkeletonModifier3D is temporary. So SkeletonModifier3D would be appropriate for effectors and controllers as post FX.
If you want permanent modifications, i.e., if you want to develop something like a bone editor, then it makes sense that it is not a SkeletonModifier3D. Also, in simple cases where it is guaranteed that no other SkeletonModifier3D will be used in the scene, your judgment will prevail.
What kind of SkeletonModifier3D nodes are included in Godot 4.3?
For now, Godot 4.3 will be containing only SkeletonModifier3D which is a migration of several existing nodes that have been in existence since 4.0.
But, there is good news! We are planning to add some built in SkeletonModifier3Ds in Godot 4.4, such as new IK, constraint, and springbone/jiggle.
If you are interested in developing your own effect using SkeletonModifier3D, feel free to make a proposal to include it in core.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-2-1-5-beta-1/index.html b/article/dev-snapshot-godot-2-1-5-beta-1/index.html
index 4066fcb4b1..b8f76b13c6 100644
--- a/article/dev-snapshot-godot-2-1-5-beta-1/index.html
+++ b/article/dev-snapshot-godot-2-1-5-beta-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde19 February 2018
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!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-2-1-5-beta-2/index.html b/article/dev-snapshot-godot-2-1-5-beta-2/index.html
index f7f31de337..57c1cb025a 100644
--- a/article/dev-snapshot-godot-2-1-5-beta-2/index.html
+++ b/article/dev-snapshot-godot-2-1-5-beta-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 March 2018
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!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-2-1-5-rc-1/index.html b/article/dev-snapshot-godot-2-1-5-rc-1/index.html
index 4ae5aadbc9..792544cda0 100644
--- a/article/dev-snapshot-godot-2-1-5-rc-1/index.html
+++ b/article/dev-snapshot-godot-2-1-5-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde24 March 2018
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-2-1-5-rc-2/index.html b/article/dev-snapshot-godot-2-1-5-rc-2/index.html
index 7675a2184d..782915db99 100644
--- a/article/dev-snapshot-godot-2-1-5-rc-2/index.html
+++ b/article/dev-snapshot-godot-2-1-5-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde19 July 2018
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.*
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-2-1-6-rc-1/index.html b/article/dev-snapshot-godot-2-1-6-rc-1/index.html
index 6545f8fb71..85ef7a0745 100644
--- a/article/dev-snapshot-godot-2-1-6-rc-1/index.html
+++ b/article/dev-snapshot-godot-2-1-6-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde4 June 2019
“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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-1-rc1/index.html b/article/dev-snapshot-godot-3-0-1-rc1/index.html
index e6f99f8c02..a8542870c6 100644
--- a/article/dev-snapshot-godot-3-0-1-rc1/index.html
+++ b/article/dev-snapshot-godot-3-0-1-rc1/index.html
@@ -5,7 +5,7 @@
HP van Braam23 February 2018
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-3-rc-1/index.html b/article/dev-snapshot-godot-3-0-3-rc-1/index.html
index 24d4da5e57..5e941eff9d 100644
--- a/article/dev-snapshot-godot-3-0-3-rc-1/index.html
+++ b/article/dev-snapshot-godot-3-0-3-rc-1/index.html
@@ -5,7 +5,7 @@
HP van Braam2 May 2018
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-3-rc-2/index.html b/article/dev-snapshot-godot-3-0-3-rc-2/index.html
index a2006450bd..13273865ec 100644
--- a/article/dev-snapshot-godot-3-0-3-rc-2/index.html
+++ b/article/dev-snapshot-godot-3-0-3-rc-2/index.html
@@ -5,7 +5,7 @@
HP van Braam14 May 2018
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-3-rc-3/index.html b/article/dev-snapshot-godot-3-0-3-rc-3/index.html
index 28ef40c5a4..47a8de36b2 100644
--- a/article/dev-snapshot-godot-3-0-3-rc-3/index.html
+++ b/article/dev-snapshot-godot-3-0-3-rc-3/index.html
@@ -5,7 +5,7 @@
HP van Braam2 June 2018
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-alpha-1/index.html b/article/dev-snapshot-godot-3-0-alpha-1/index.html
index 55393e11c3..28949cab6b 100644
--- a/article/dev-snapshot-godot-3-0-alpha-1/index.html
+++ b/article/dev-snapshot-godot-3-0-alpha-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde26 July 2017
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-alpha-2/index.html b/article/dev-snapshot-godot-3-0-alpha-2/index.html
index 2d995d5c27..eeca1899b6 100644
--- a/article/dev-snapshot-godot-3-0-alpha-2/index.html
+++ b/article/dev-snapshot-godot-3-0-alpha-2/index.html
@@ -6,7 +6,7 @@
Export templates for the Mono flavour will not be provided, as exporting Mono games is not completely 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
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 alpha 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 alpha 2 and stay tuned for future, more stable releases :)
-
+
\ No newline at end of file
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 62a9dd0c39..405f01389e 100644
--- a/article/dev-snapshot-godot-3-0-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-0-beta-1/index.html
@@ -7,7 +7,7 @@
Export templates for the Mono flavour will not be provided for beta 1, 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
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 more testing coverage while we work on fixing the known issues.
As a tester, you are encouraged to open bug reports if you experience issues with beta 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.
Have fun with this beta 1 and stay tuned for a potential beta 2, or directly a release candidate (RC) if we’re happy with the test results.
-
+
\ No newline at end of file
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 4a2dbc3a74..130aaa7913 100644
--- a/article/dev-snapshot-godot-3-0-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-0-beta-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde21 December 2017
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:
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!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-rc-1/index.html b/article/dev-snapshot-godot-3-0-rc-1/index.html
index 97ff04ba08..ee0106259c 100644
--- a/article/dev-snapshot-godot-3-0-rc-1/index.html
+++ b/article/dev-snapshot-godot-3-0-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde14 January 2018
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.
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™.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-rc-2/index.html b/article/dev-snapshot-godot-3-0-rc-2/index.html
index 12cfcdd7aa..d5238fa920 100644
--- a/article/dev-snapshot-godot-3-0-rc-2/index.html
+++ b/article/dev-snapshot-godot-3-0-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde20 January 2018
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:
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)!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-0-rc-3/index.html b/article/dev-snapshot-godot-3-0-rc-3/index.html
index 43c8a8cbe2..f9269ba68a 100644
--- a/article/dev-snapshot-godot-3-0-rc-3/index.html
+++ b/article/dev-snapshot-godot-3-0-rc-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde24 January 2018
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] [HTTP 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)!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-1-alpha-1/index.html b/article/dev-snapshot-godot-3-1-alpha-1/index.html
index 2bce4d3517..075059b8e6 100644
--- a/article/dev-snapshot-godot-3-1-alpha-1/index.html
+++ b/article/dev-snapshot-godot-3-1-alpha-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde31 August 2018
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-1-alpha-2/index.html b/article/dev-snapshot-godot-3-1-alpha-2/index.html
index 54e56c3bdf..f04bf67e0a 100644
--- a/article/dev-snapshot-godot-3-1-alpha-2/index.html
+++ b/article/dev-snapshot-godot-3-1-alpha-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde2 November 2018
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-1-alpha-3/index.html b/article/dev-snapshot-godot-3-1-alpha-3/index.html
index d5fcd85859..58953df0e7 100644
--- a/article/dev-snapshot-godot-3-1-alpha-3/index.html
+++ b/article/dev-snapshot-godot-3-1-alpha-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde12 December 2018
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!*
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-1-alpha-4/index.html b/article/dev-snapshot-godot-3-1-alpha-4/index.html
index 4b7dfced7a..1454d12939 100644
--- a/article/dev-snapshot-godot-3-1-alpha-4/index.html
+++ b/article/dev-snapshot-godot-3-1-alpha-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde22 December 2018
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.*
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-1-alpha-5/index.html b/article/dev-snapshot-godot-3-1-alpha-5/index.html
index d4a3444328..6c53159ca0 100644
--- a/article/dev-snapshot-godot-3-1-alpha-5/index.html
+++ b/article/dev-snapshot-godot-3-1-alpha-5/index.html
@@ -5,7 +5,7 @@
HP van Braam2 January 2019
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-1-beta-1/index.html b/article/dev-snapshot-godot-3-1-beta-1/index.html
index e2cd7eb9da..3f94d0b71e 100644
--- a/article/dev-snapshot-godot-3-1-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde8 January 2019
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-1-beta-10/index.html b/article/dev-snapshot-godot-3-1-beta-10/index.html
index 91de8cc4bd..9c4ec66b5c 100644
--- a/article/dev-snapshot-godot-3-1-beta-10/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-10/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog, as well as past devblogs.
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 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 MSbuild installed to use the Mono build. However, this build no longer mandates a specific Mono SDK version; it comes bundled with Mono 5.18.
Important: As mentioned above, Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
There is still a couple 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.
The illustration picture is from carrotcake.studio’s *The Garden Path, a beautiful sandbox gardening game developed with Godot. Follow its development on their Devlog and Twitter.*
-
+
\ No newline at end of file
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 3b9474e1a7..3a8f883d9f 100644
--- a/article/dev-snapshot-godot-3-1-beta-11/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-11/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog, as well as past devblogs.
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 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 MSbuild installed to use the Mono build. However, this build no longer mandates a specific Mono SDK version; it comes bundled with Mono 5.18.
Important: As mentioned above, Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
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.
The illustration picture is from Odyssey Entertainment’s upcoming sci-fi puzzle platformer *Transmogrify, which is schedule to release in coming weeks on itch.io and Steam.*
-
+
\ No newline at end of file
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 76a3ae0478..a904248147 100644
--- a/article/dev-snapshot-godot-3-1-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-2/index.html
@@ -6,7 +6,7 @@
In the meantime, you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining, as well as past devblogs.
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. Juan added several tutorials on new 3.1 features last week (2D meshes, 2D skeletons and AnimationTree docs).
Downloads
The download links are not featured on the Download page 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.
The illustration picture is a screenshot from Miskatonic Studio’s first game, *Intrepid, a sci-fi esape room game, which was released last month. Steam, Twitter.*
-
+
\ No newline at end of file
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 2068f65505..eb3d5b97e6 100644
--- a/article/dev-snapshot-godot-3-1-beta-3/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-3/index.html
@@ -6,7 +6,7 @@
In the meantime, you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining, as well as past devblogs.
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. Juan added several tutorials on new 3.1 features this month (2D meshes, 2D skeletons and AnimationTree docs).
Downloads
The download links are not featured on the Download page 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; it comes bundled with Mono 5.18.
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 is still a couple 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.
The illustration picture is a screenshot from John Watson’s upcoming game, *Gravity Ace, a gorgeous arcade twin-stick shooter currently in public alpha on itch.io.*
-
+
\ No newline at end of file
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 f135842d16..c0ccaa230b 100644
--- a/article/dev-snapshot-godot-3-1-beta-4/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-4/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog, as well as past devblogs.
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 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; it comes bundled with Mono 5.18.
Bug reports
There is still a couple 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.
Known regressions:
GH-25804: 3d workspace disappears in the editor (fixed in master)
GH-25839: Visual Shader compile error with CanvasShaderGLES2 (fixed in master)
-
+
\ No newline at end of file
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 962726a6c7..636fb50e01 100644
--- a/article/dev-snapshot-godot-3-1-beta-5/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-5/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog, as well as past devblogs.
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 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 MSbuild installed to use the Mono build. However, this build no longer mandates a specific Mono SDK version; it comes bundled with Mono 5.18.
Bug reports
There is still a couple 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.
The illustration picture is a screenshot from *Primal Light, a gorgeous action platformer developed in Godot 3.1 by a team of two, scheduled to release on Steam in 2019. Check their many GIFs on Twitter!*
-
+
\ No newline at end of file
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 94c60c46fd..17603f0309 100644
--- a/article/dev-snapshot-godot-3-1-beta-6/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-6/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog, as well as past devblogs.
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 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 MSbuild installed to use the Mono build. However, this build no longer mandates a specific Mono SDK version; it comes bundled with Mono 5.18.
Important: As mentioned above, Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
There is still a couple 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.
Known issues:
GH-26149 - Recent area optimization commit causes massive FPS swings (fixed in master branch).
-
+
\ No newline at end of file
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 50199f24bb..13e20fc5b8 100644
--- a/article/dev-snapshot-godot-3-1-beta-7/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-7/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog, as well as past devblogs.
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 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 MSbuild installed to use the Mono build. However, this build no longer mandates a specific Mono SDK version; it comes bundled with Mono 5.18.
Important: As mentioned above, Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
There is still a couple 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.
Known issues:
26243: Crash with “Illegal instruction” on pre-2011 CPUs (fixed in master)
-
+
\ No newline at end of file
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 626b9f142d..5e308cec5f 100644
--- a/article/dev-snapshot-godot-3-1-beta-8/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-8/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog, as well as past devblogs.
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 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 MSbuild installed to use the Mono build. However, this build no longer mandates a specific Mono SDK version; it comes bundled with Mono 5.18.
Important: As mentioned above, Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
There is still a couple 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.
Known issues:
GH-26301 and others: GLES2 projets with ETC textures on Android crash on start
The illustration picture is a screenshot from the FOSS game *Tanks of Freedom by P1X, initially released in 2015 and continuously updated since then. Source code (Godot 2.1), itch.io.*
-
+
\ No newline at end of file
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 48b5ec437f..915b63fc2f 100644
--- a/article/dev-snapshot-godot-3-1-beta-9/index.html
+++ b/article/dev-snapshot-godot-3-1-beta-9/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog, as well as past devblogs.
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 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 MSbuild installed to use the Mono build. However, this build no longer mandates a specific Mono SDK version; it comes bundled with Mono 5.18.
Important: As mentioned above, Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
There is still a couple 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.
Known issues:
GH-26359: Previous scenes/scripts and project layout not loading up (fixed in master)
The illustration picture is from HeartBeast Studios’ byte-sized roguelike *Endhall, released in December on itch.io and Steam.*
-
+
\ No newline at end of file
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 82842c8a4e..14e1037f7f 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
@@ -5,7 +5,7 @@
Rémi Verschelde19 April 2020
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).
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-2-beta-2/index.html b/article/dev-snapshot-godot-3-2-2-beta-2/index.html
index 93c25cfa91..b597f1ed8c 100644
--- a/article/dev-snapshot-godot-3-2-2-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-2-2-beta-2/index.html
@@ -6,7 +6,7 @@
In the upcoming Godot 4.0, this bug was fixed with a more comprehensive approach which prevents dangling Variant pointers in both release and debug builds.
Other changes
Apart from those major features, there are also over 350 cherry-picks (part 1, part 2) for bug fixes and enhancements which have been merged since Godot 3.2.1. Here are some highlights:
2D: Expose the cell_size affecting VisibilityNotifier2D precision (GH-38286).
2D: Add MODULATE builtin to canvas item shaders (GH-38432).
VR: Fix aspect ratio on HMD projection matrix (GH-37601).
Windows: Make stack size on Windows match Linux and macOS (GH-37115).
API documentation updates.
Editor translation updates.
And many more bug fixes and usability enhancements all around the engine!
See the full changelog on GitHub (part 1, part 2) for details.
Downloads
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 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.1 no longer works in 3.2.2 beta 2).
-
+
\ No newline at end of file
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 f273d4cdfc..4173710aab 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
@@ -6,7 +6,7 @@
In the upcoming Godot 4.0, this bug was fixed with a more comprehensive approach which prevents dangling Variant pointers in both release and debug builds.
Other changes
Apart from those major features, there are close to 500 cherry-picks (beta 1, beta 2, beta 3) for bug fixes and enhancements which have been merged since Godot 3.2.1. Here are some highlights:
2D: Expose the cell_size affecting VisibilityNotifier2D precision (GH-38286).
2D: Add MODULATE builtin to canvas item shaders (GH-38432).
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.
Note: Due to a technical issue, Linux x86 (32-bit) binaries with C# support are not included in this build (neither the editor build nor the export template).
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.2.2 beta 3. 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 3).
-
+
\ No newline at end of file
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 96a743bb4b..da60778699 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
@@ -6,7 +6,7 @@
In the upcoming Godot 4.0, this bug was fixed with a more comprehensive approach which prevents dangling Variant pointers in both release and debug builds.
Other changes
Apart from those major features, there are more than 600 cherry-picks (beta 1, beta 2, beta 3, beta 4) for bug fixes and enhancements which have been merged since Godot 3.2.1. Here are some highlights:
2D: Expose the cell_size affecting VisibilityNotifier2D precision (GH-38286).
2D: Add MODULATE builtin to canvas item shaders (GH-38432).
Android: Reimplementation of the GodotPayment plugin using the Google Play Billing library (GH-39034).
Note: Breaks compatibility slightly, but the Android plugin re-architecture already did so. See GH-39034 for usage instructions, docs will be updated before the 3.2.2 release.
AStar: Implements estimate/compute_cost for AStar2D (GH-37039).
Audio: Fix volume interpolation in positional audio nodes (GH-37279).
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.2 beta 4. 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 4).
-
+
\ No newline at end of file
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 ba7ee7ff89..f836b0966d 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
@@ -5,7 +5,7 @@
Rémi Verschelde20 July 2020
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-4-beta-1/index.html b/article/dev-snapshot-godot-3-2-4-beta-1/index.html
index 9b98592db9..424f90e2e4 100644
--- a/article/dev-snapshot-godot-3-2-4-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-2-4-beta-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde21 October 2020
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-4-beta-2/index.html b/article/dev-snapshot-godot-3-2-4-beta-2/index.html
index d08a512447..d80b84dc08 100644
--- a/article/dev-snapshot-godot-3-2-4-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-2-4-beta-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde18 November 2020
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-4-beta-3/index.html b/article/dev-snapshot-godot-3-2-4-beta-3/index.html
index 5232242a77..20c0cb5cf4 100644
--- a/article/dev-snapshot-godot-3-2-4-beta-3/index.html
+++ b/article/dev-snapshot-godot-3-2-4-beta-3/index.html
@@ -6,7 +6,7 @@
This update also re-adds UWP templates which we missing in beta 1 and beta 2 due to a temporary buildsystem issue.
Highlights
The main changes coming in Godot 3.2.4 and included in this beta are:
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 3. 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 3).
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.
-
+
\ No newline at end of file
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 eeb3f0d81d..7fc6c4345d 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
@@ -5,7 +5,7 @@
Rémi Verschelde11 December 2020
This new beta 4 adds a new round of bugfixes and enhancements over the previous dev snapshots, as well as some nice new features.
In particular, this build adds optional GDNative support to the HTML5 target, on top of the pre-existing optional multithreading support. The HTML5 export templates now come in three flavors which you can select in the export preset: normal, threads enabled and GDNative enabled. Multithreading and dynamic linking (GDNative) can’t be used at the same time due to current WebAssembly limitations. Note: Threads enabled and GDNative enabled templates are only available for standard builds for now, as there are other issues to solve to make them work with Mono.
Additionally, beta 4 adds support for MP3 loading and playback! Until recently, the MP3 audio format was patent-encumbered and could therefore not be included in Godot, but the last patent expired in 2017, so a MP3 loader and decoded could finally be implemented.
There are also a number of fixes to the rewritten FBX importer which should improve compatibility, so if you ran into issues with it in previous builds, make sure to retry your models!
Highlights
The main changes coming in Godot 3.2.4 and included in this beta are:
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 4. 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 4).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-4-beta-5/index.html b/article/dev-snapshot-godot-3-2-4-beta-5/index.html
index 1b9705ecc2..9f8fa38cfa 100644
--- a/article/dev-snapshot-godot-3-2-4-beta-5/index.html
+++ b/article/dev-snapshot-godot-3-2-4-beta-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde7 January 2021
This new beta 5 comes with 4 weeks’ worth of bugfixes and enhancements over the previous dev snapshots, as well as some nice new features.
In particular, this build adds WebXR support for VR games! It also adds a much-requested minimap to GraphEdit, and thus to the VisualScript and Visual Shader editors. Moreover, there have been many fixes to features introduced in previous betas, so make sure to test this build and ensure that everything works as you’d want it.
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.114 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 5. 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 5).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-4-beta-6/index.html b/article/dev-snapshot-godot-3-2-4-beta-6/index.html
index ef84bb5080..48464a0396 100644
--- a/article/dev-snapshot-godot-3-2-4-beta-6/index.html
+++ b/article/dev-snapshot-godot-3-2-4-beta-6/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde16 January 2021
While our main focus stays on the 4.0 branch, the current stable 3.2 branch is receiving a lot of great improvements, and the upcoming 3.2.4 release is going to be packed with many new features.
With this beta 6 build, there are several recently merged changes that will require heavy testing to be stabilized before 3.2.4-stable:
Note: It’s currently not available for macOS ARM64 as the libraries used are specific to x86_64. We hope to be able to solve that eventually. On Apple M1 devices, you can use the x86_64 version in the “universal” binary with Rosetta to test the new lightmapper.
New dynamic BVH for rendering and the GodotPhysics backends, which should fix some issues and improve performance significantly in games using a high number of dynamic objects.
The previous Octree-based system is still available, though the dynamic BVH is meant to replace it once all potential issues are ironed out. In this beta, the dynamic BVH is the default option for both physics and rendering. You can revert back either of them to octree in the Project Settings.
The Bullet physics backend already used its own dynamic BVH implementation, it’s not affected by this change.
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.114 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 6. 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 6).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-alpha-1/index.html b/article/dev-snapshot-godot-3-2-alpha-1/index.html
index 521a32d3ec..4ec1d6e396 100644
--- a/article/dev-snapshot-godot-3-2-alpha-1/index.html
+++ b/article/dev-snapshot-godot-3-2-alpha-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde6 October 2019
After close to 7 months of development and over 4,000 commits since the 3.1 release, we are now happy to release Godot 3.2 alpha 1, our first milestone towards the next stable installment of our free and open source game engine.
This first alpha build comes relatively late in our planned release schedule, mostly because of work done on our official build infrastructure to adapt to 3.2 requirements (changes to the Android buildsystem and packaging, especially with the new C# support), as well as a build server upgrade. But we have been in the alpha stage since August 31, and testers and developers were not idle in the meantime, so the master branch from which 3.2 will be released is already quite stable. As such we expect the alpha and beta phases to be quite short for Godot 3.2, and a stable release within one or two months should be possible.
The alpha stage corresponds for us to a feature freeze, as announced on GitHub a month 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.2 is released. This way, we can focus on what we already have, finish and polish the major features which are still in progress, 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.
Note: Illustration credits at the bottom of this page.
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.2 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.
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).
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is working on.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 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 build (C# support + all the above). You need to have MSbuild installed to use the Mono build. Relevant parts of Mono 5.18.1.3 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Notes:
Due to some build issues alpha1 does not have export templates for the UWP platform. This will be fixed in later builds.
Release exports of Mono projects seem to crash in some configurations. Deleting the res://.mono/ folder to force its recreation with the new Godot version seems to be a good workaround. We are working on solving this issue for later builds.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.2 release and may end up be retargeted to a later release to allow releasing Godot 3.2 within a couple of months.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-alpha-2/index.html b/article/dev-snapshot-godot-3-2-alpha-2/index.html
index 3388c62b23..0a09b9b670 100644
--- a/article/dev-snapshot-godot-3-2-alpha-2/index.html
+++ b/article/dev-snapshot-godot-3-2-alpha-2/index.html
@@ -6,7 +6,7 @@
The new official buildsystem that our contributor HP van Braam (hpvb) set up for us is now quite efficient, so we can roll out builds fast and easily.
We thus publish Godot 3.2 alpha 2 as a second snapshot, fixing various issues from the last build. 152 commits have been merged since 3.2 alpha 1. This release is built from commit 3cc94b2.
As a reminder, the alpha stage corresponds for us to a feature freeze, as announced on GitHub a month 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.2 is released. This way, we can focus on what we already have, finish and polish the major features which are still in progress, and fix many of the old and new bugs reported by the community.
Note: Illustration credits at the bottom of this page.
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.2 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.
There is also no guarantee that projects started with an alpha build will still work in later alpha 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).
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is working on.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSbuild installed to use the Mono build. Relevant parts of Mono 5.18.1.3 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Notes:
Due to some build issues alpha1 does not have export templates for the UWP platform. This will be fixed in later builds.
The alpha 1 issue with release exports of Mono projects should now be solved.
This build should also fix a regression for GLES2 rendering on some Windows and macOS devices.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.2 release and may end up be retargeted to a later release to allow releasing Godot 3.2 within a couple of months.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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 the gorgeous puzzle platformerSeedlingsby Bardsley Creative. Follow its development on Twitter and play the recently updated demo on itch.io.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-alpha-3/index.html b/article/dev-snapshot-godot-3-2-alpha-3/index.html
index 5a9bd216c3..75fdc7105d 100644
--- a/article/dev-snapshot-godot-3-2-alpha-3/index.html
+++ b/article/dev-snapshot-godot-3-2-alpha-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde24 October 2019
While many core contributors were busy with the Godot Sprint and GodotCon last week, the rest of the world has not been idle and we got lots of nice contributions fixing bugs and improving usability.
We thus publish Godot 3.2 alpha 3 as our next iteration, fixing various issues from the last build. 150 commits have been merged since 3.2 alpha 2. This release is built from commit 35944ae.
As a reminder, the alpha stage corresponds for us to a feature freeze, as announced on GitHub at the end of August, which means that we will no longer consider pull requests with new features for merge in the master branch, and that until Godot 3.2 is released. This way, we can focus on what we already have, finish and polish the major features which are still in progress, and fix many of the old and new bugs reported by the community.
Note: Illustration credits at the bottom of this page.
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.2 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.
There is also no guarantee that projects started with an alpha build will still work in later alpha 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).
The features
Release notes are not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is working on.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSbuild installed to use the Mono build. Relevant parts of Mono 5.18.1.3 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Notes:
Due to some build issues alpha3 does not have export templates for the UWP platform. This will be fixed in later builds.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.2 release and may end up be retargeted to a later release to allow releasing Godot 3.2 within a couple of months.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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 the low-poly, SNES-like 3D rail shooterEx-Zodiacdeveloped by Ben Hickling. Follow its development on Twitter and itch.io, and stay tuned for an upcoming demo version!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-beta-1/index.html b/article/dev-snapshot-godot-3-2-beta-1/index.html
index cf11ba7d40..047f1c9293 100644
--- a/article/dev-snapshot-godot-3-2-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-2-beta-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde6 November 2019
After three well-tested and quite stable alpha builds, we’re now ready to enter the beta stage for the upcoming Godot 3.2 release.
We thus publish Godot 3.2 beta 1 as our next iteration, fixing various issues from previous builds. 263 commits have been merged since 3.2 alpha 3. This release is built from commit 077b5f6.
The beta stage corresponds for us to a release freeze, as announced today on GitHub, which means that we will only consider critical bug fixes for merging in the master branch, and that until Godot 3.2 is released. This way, we can focus on making the 3.2 release as stable as possible with continuously increasing the scope of its new features.
Note: Illustration credits at the bottom of this page.
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.2 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 not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSbuild installed to use the Mono build. Relevant parts of Mono 5.18.1.3 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Notes:
Due to some build issues beta1 does not have export templates for the UWP platform. This will be fixed in later builds.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.2 release, and now that we reached the release freeze, they will be reviewed again and some pushed back to later milestones.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
The illustration picture is from the gorgeous procedural arcade shooterInfinistate, developed by James Redmond (Fracteed). Fracteed is an early adopter of Godot 3.0’s new PBR pipeline, and helped a lot testing and improving it with his impressive artwork. Follow Infinistate’s development on Twitter and stay tuned for a possible Early Access release next year!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-beta-2/index.html b/article/dev-snapshot-godot-3-2-beta-2/index.html
index 0d23d8625e..1437eb7d0d 100644
--- a/article/dev-snapshot-godot-3-2-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-2-beta-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde22 November 2019
Update: It turns out that the update to Mono 6.x did not go as smoothly as we hoped. The Mono binaries in this beta appear not to work properly on Windows and macOS, so unless you’re running Linux, it is recommended to stay with 3.2 beta 1 or compile from the master branch if you use C#. If you don’t use C#, the classical build still works as usual.
We published a first beta build for Godot 3.2 two weeks ago, and many bug fixes and improvements have been merged in the meantime. It’s time for Godot 3.2 beta 2!
The most notable is the WebAssembly support for Mono exports, which means that C# projects can now run on the Web! See Ignacio’s progress report for details. I spent most of my time the past week working on the buildsystem to be able to ship Wasm templates for Mono, with a lot of help from Ignacio to iron out issues with both Emscripten and Mono. At long last, we managed to get a working build which is included in the Mono export templates for this beta!
Another noteworthy change for the Mono version is that we now use Mono 6.6.0 Preview, which provides support for C# 8 and many other enhancements. While 6.6.0 has not been labelled stable yet, this should happen soon and we needed a very recent version for proper WebAssembly support in Mono, which has matured a lot over the past few months.
Note that the AOT compilation support merged recently for C# is not included in those builds. This will be worked on in coming months and should be shipped in a 3.2.x maintenance update once it has been extensively tested.
313 commits have been merged since 3.2 beta 1. This release is built from commit b7ea22c.
Note: Illustration credits at the bottom of this page.
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.2 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 not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSbuild installed to use the Mono build. Relevant parts of Mono 6.6.0 Preview are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Notes:
Due to some build issues beta2 does not have export templates for the UWP platform. This will be fixed in later builds.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.2 release, and now that we reached the release freeze, they will be reviewed again and some pushed back to later milestones.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
The illustration picture is from the innovative action adventure RPGBloom: Memoriesby Studio Fawn, which has been 7 years in the making (ported to Godot along the way) and is close to being released. You can wishlist it on Steam, follow the developer on Twitter or Patreon, and see the gorgeous trailer on YouTube.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-beta-3/index.html b/article/dev-snapshot-godot-3-2-beta-3/index.html
index 692c7373a7..3ca2246c36 100644
--- a/article/dev-snapshot-godot-3-2-beta-3/index.html
+++ b/article/dev-snapshot-godot-3-2-beta-3/index.html
@@ -6,7 +6,7 @@
A proper fix is in the works and will be contributed back upstream, and in the meantime this beta 3 comes without Mono build. C# users should for now stay on 3.2 beta 1, or wait for 3.2 beta 4 which should have fixed Mono 6.x binaries.
There are still many important changes in this beta which are worth testing in the classical build:
More work has been done on the rendering, fixing many long-standing bugs as well as some recent regressions that would affect GLES2 mobile and low-end desktop devices. A huge thankyou to Clay John for debugging and fixing so many rendering issues.
Notably, a fix was merged in both GLES2 and GLES3 to address some performance issues on iOS (which might also benefit Android). Thanks to @oeleo1 for doing the research, testing and providing patches.
For Windows, many users are having stutter issues when playing games in windowed mode due to conflicts with the system compositor. After many attempts and research, a fix was finally merged today thanks to Steve Rogers. It’s currently opt-in, so you have to enable this option if you want to try it. We’re not 100% confident yet that the fix is the correct approach, but it does seem to improve the situation for a number of users, so it’s worth having it as an option until we can look into it some more.
For iOS, the addition of ARKit support by Bastiaan Olij a few months back caused unexpected issues, as the code added to handle the device’s camera is flagged as sensitive when uploading games to the App Store, so users were forced to require camera permissions even if not using ARKit or the camera. Thanks to bruvzg, the Camera and ARKit modules are now opt-in when exporting an iOS project, and their relevant code will only be linked in Xcode if it’s requested.
Marcel Admiraal reviewed and fixed recent changes to KinematicBody’s move_and_slide API (both 2D and 3D). If you’re using these nodes, we could really use more test reports to ensure that everything works the same (or better, if you had bugs) in your projects as it did in 3.1.x.
176 commits have been merged since 3.2 beta 2. This release is built from commit 73fb082.
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.2 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 not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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.1 projects before opening them in any 3.2 development build.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues may not be critical for the 3.2 release, and now that we reached the release freeze, they will be reviewed again and some pushed back to later milestones.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
The illustration picture is fromDoor in the Woods, an open world roguelike inspired by the lovecraftian mythos and developed in Godot by teedoubleuGAMES. The game was just released today on Steam, so congrats to the developers for the release!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-beta-4/index.html b/article/dev-snapshot-godot-3-2-beta-4/index.html
index 6f6ee186d5..cb72c35e63 100644
--- a/article/dev-snapshot-godot-3-2-beta-4/index.html
+++ b/article/dev-snapshot-godot-3-2-beta-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde18 December 2019
Update 2019-12-21 @ 10:00 UTC: Two packaging issues have been fixed with the Mono builds:
The Mono export templates .tpz lacked the Windows and Unix-specific base class libraries, so it was not possible to export Linux/macOS binaries from Windows and the other way around. This is now fixed in the export templates for new downloads. Users who already installed the Mono templates can simply get this hotfix archive and install it from the editor on top of the existing templates (it should add net_4_x and net_4_x_win folders in the templates bcl folder).
The macOS editor binary had a configuration issue, which has been fixed. macOS users should redownload it if they got it before this update.
After another two weeks since our previous beta build, here comes Godot 3.2 beta 4, bringing back the Mono build for all supported platforms (including Android and WebAssembly, new in Godot 3.2).
Note: Illustration credits at the bottom of this page.
A month ago, we attempted to upgrade our Mono version to 6.6.0 (from 5.18.1.3) which is necessary for the WebAssembly target. It brought some issues with the cross-compilation and packaging of our binaries, so the Windows and macOS Mono builds were not functional in beta 2, and we skipped Mono builds altogether in beta 3.
Since then, HP spent some time debugging and fixing our cross-compilation issues. He has some work-in-progress patches that will be contributed back to the upstream Mono project, but for now we used a workaround using Wine.
Apart from fixing Mono builds, there have been various important changes since beta 3. Here’s a short selection:
Android: Acquire MulticastLock on Android when using broadcast/multicast (GH-33910).
GDScript: Fix some cases where typed assignment gets invalid (GH-34333).
GLES2: Fix shadow color in GLES2 by making sRGB (GH-34367).
GLES2: Force 32 bit depth buffer for WebGL (GH-34237).
GLES2: Use renderbuffer depth for post-process buffers when appropriate (GH-34238).
iOS: Allow to change the home indicator behaviour (GH-34229).
iOS: Disable armv7 target by default as we no longer provide templates for it (GH-34138). Users who still want to support armv7 iOS devices need to compile their own export templates.
Localization: Fixes in the handling of language code and localized resources (GH-34103).
macOS: Fix potential crash when moving window between Retina and non-Retina monitors (GH-34202).
Mono: Fix class parser bug with ‘where T : struct’ (GH-34334).
Mono: Support for JetBrains Rider as external editor (GH-34181).
Mono: Various fixes to Android support (GH-34101).
Physics: Change CollisionPolygon convex shapes generation to use the same algorithm as CollisionPolygon2D, now also available at runtime (GH-34293).
Windows: Fix extremely slow linking with MinGW due to exceeding command line size limit (GH-23447).
Various crash fixes on wrong API usage.
A good number of documentation and translation updates.
246 commits have been merged since 3.2 beta 3. This release is built from commit d1bce5c.
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.2 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 not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.6.0.160 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues are not critical for the 3.2 release and will be pushed back to later milestones.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
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.1.x no longer works in 3.2 beta).
The illustration picture is fromHive Time, a bee-themed base-building game released last week by Cheeseness, Mimness and Peter. Available now on itch.io. Follow updates on the game’s Twitter account.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-beta-5/index.html b/article/dev-snapshot-godot-3-2-beta-5/index.html
index f7b8d91406..3e5289973c 100644
--- a/article/dev-snapshot-godot-3-2-beta-5/index.html
+++ b/article/dev-snapshot-godot-3-2-beta-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde3 January 2020
To start the new year with a bang, we finally release the long awaited… Godot 3.2 beta 5! Right, yet another beta build, but this one is so much closer to the release candidate ;)
More seriously, we are quite happy with the current state of the master branch and a lot of important bug fixes have been made since the previous beta 4. The Mono build seems to behave and barring any big regression, we should be able to have a release candidate within a week or so.
Note: Illustration credits at the bottom of this page.
245 commits have been merged since 3.2 beta 4. This release is built from commit 399e53e.
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.2 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 not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.6.0.160 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues are not critical for the 3.2 release and will be pushed back to later milestones.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
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.1.x no longer works in 3.2 beta).
The illustration picture is a screenshot fromHaiki, a juicy platformer developed in Godot by Richard since 2017. Follow Richard on Twitter for updates about the game.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-2-beta-6/index.html b/article/dev-snapshot-godot-3-2-beta-6/index.html
index 46ed4831d1..0e943879e4 100644
--- a/article/dev-snapshot-godot-3-2-beta-6/index.html
+++ b/article/dev-snapshot-godot-3-2-beta-6/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde11 January 2020
After a very busy week with many important bug fixes (plus a bunch of low risk enhancements and a lot of documentation updates), here’s Godot 3.2 beta 6! As mentioned in the previous post, we’re close to the Release Candidate stage and I hesitated to name this build as such. Since there were a number of big changes though I opted for making it another beta, and if all goes well testing it we should have a RC 1 in coming days.
Note: Illustration credits at the bottom of this page.
219 commits have been merged since 3.2 beta 5. This release is built from commit 0ab1726.
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.2 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 not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.6.0.161 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Bug reports
There are still hundreds of open bug reports for the 3.2 milestone, which means that we are aware of many bugs already. Yet, many of those issues are not critical for the 3.2 release and will be pushed back to later milestones.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
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.1.x no longer works in 3.2 beta).
The illustration picture is fromSealed Bite, a delightful pixel art metroidvania by Securas with music by Wandard, which is the winning entry of the GitHub Game Off 2019! Check it out on http://itch.io, or play with the source files on GitHub. Be sure to follow Securas on Twitter, who is allegedly one of the most prolific and talented Godot jammers!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-4-beta-2/index.html b/article/dev-snapshot-godot-3-4-beta-2/index.html
index 870b9670fb..61ffab00f9 100644
--- a/article/dev-snapshot-godot-3-4-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-4-beta-2/index.html
@@ -6,7 +6,7 @@
With the changed API, the “far” amount and quality settings will take precedence and also affect the “near” DOF.
Rendering: Import option to split vertex buffer stream in positions and attributes (GH-46574).
Rendering: Fix flipped binormal in SpatialMaterial triplanar mapping (GH-49950).
Rendering: Fix CanvasItem bounding rect calculation in some cases (GH-49160).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Shaders: Add support for structs and fragment-to-light varyings (GH-48075).
TextureButton: Add flip_h and flip_v properties (GH-30424).
TextureProgress: Improve behavior with nine patch (GH-45815).
Theme: Various improvements to the Theme API (GH-49487).
TileSet: Fix selection of spaced atlas tile when using priority (GH-50886).
Viewport: Allow input echo when changing UI focus (GH-44456).
VisualScript: Allow dropping custom node scripts in VisualScript editor (GH-50696).
VisualScript: Expose visual script custom node type hints (GH-50705).
VisualScript: Improve and streamline VisualScriptFuncNodes CallSetGet (GH-50709).
Windows: Send error logs to stderr instead of stdout, like done on other OSes (GH-39139).
XR: Add VIEW_INDEX variable in shader to know which eye/view we’re rendering for (GH-48011).
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 dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.147 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.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.3.2 or earlier no longer works in 3.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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-4-beta-3/index.html b/article/dev-snapshot-godot-3-4-beta-3/index.html
index 74f27c9d64..5ef10ba893 100644
--- a/article/dev-snapshot-godot-3-4-beta-3/index.html
+++ b/article/dev-snapshot-godot-3-4-beta-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde6 August 2021
The upcoming Godot 3.4 release will provide a number of new features which have been backported from the 4.0 development branch (see our release policy for details on the various Godot versions). We had a beta 2 build ten days ago, and a number of issues have since been found and fixed, so it’s time for Godot 3.4 beta 3.
Rendering: Fixes depth sorting of meshes with transparent textures (GH-50721).
Rendering: Add soft shadows to the CPU lightmapper (GH-50184).
Rendering: Import option to split vertex buffer stream in positions and attributes (GH-46574).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Shaders: Add support for structs and fragment-to-light varyings (GH-48075).
VisualScript: Improve and streamline VisualScriptFuncNodes CallSetGet (GH-50709).
All these need to be thoroughly tested to ensure that they work as intended in the upcoming 3.4-stable.
Changes
Here’s a curated changelog with links to the relevant pull requests for details. The list is not exhaustive and will be completed in the future to include more noteworthy changes.
Note that some of the changes in 3.4 have already been backported and published in Godot 3.2.1 and 3.2.2, and therefore they were not listed here again. You can refer to the changelogs of those maintenance releases for details on what you might have missed since 3.3-stable.
Android: Add basic user data backup option (GH-49070).
Android: Add GDNative libraries to Android custom Gradle builds (GH-49912).
Android: Remove non-functional native video OS methods (GH-48537).
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 dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.147 are included in this build.
Update 2021-08-07 @ 13:00 UTC: The original Mono version for 3.4 beta 3 had a breaking regression and was later fixed. The binaries have been replaced, if you downloaded them prior to this update, you might want to redownload them.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4 beta 3. 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.3.2 or earlier no longer works in 3.4 beta 3).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-4-beta-4/index.html b/article/dev-snapshot-godot-3-4-beta-4/index.html
index e55ee418b5..4764d1e43f 100644
--- a/article/dev-snapshot-godot-3-4-beta-4/index.html
+++ b/article/dev-snapshot-godot-3-4-beta-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde19 August 2021
The upcoming Godot 3.4 release will provide a number of new features which have been backported from the 4.0 development branch (see our release policy for details on the various Godot versions). This beta 4 build provides additional features and fixes to bugs reported against previous builds.
Rendering: Fixes depth sorting of meshes with transparent textures (GH-50721).
Rendering: Add soft shadows to the CPU lightmapper (GH-50184).
Rendering: Import option to split vertex buffer stream in positions and attributes (GH-46574).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Shaders: Add support for structs and fragment-to-light varyings (GH-48075).
VisualScript: Improve and streamline VisualScriptFuncNodes CallSetGet (GH-50709).
Windows: Fix platform file access to allow file sharing with external programs (GH-51430).
All these need to be thoroughly tested to ensure that they work as intended in the upcoming 3.4-stable.
Changes
Here’s a curated changelog with links to the relevant pull requests for details. The list is not exhaustive and will be completed in the future to include more noteworthy changes.
Note that some of the changes in 3.4 have already been backported and published in Godot 3.3.1 and 3.3.2, and therefore they were not listed here again. You can refer to the changelogs of those maintenance releases for details on what you might have missed since 3.3-stable.
Android: Add partial support for Android scoped storage (GH-50359).
This also means we’re now targeting API level 30 as required to publish new apps on Google Play.
Android: Improve input responsiveness on underpowered Android devices (GH-42220).
Android: Add GDNative libraries to Android custom Gradle builds (GH-49912).
Android: Resolve issue where the Godot app remains stuck when resuming (GH-51584).
Android: Add basic user data backup option (GH-49070).
Android: Add support for prompting the user to retain app data on uninstall (GH-51605).
Android: Remove non-functional native video OS methods (GH-48537).
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 dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.147 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4 beta 4. 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.3.2 or earlier no longer works in 3.4 beta 4).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-4-beta-5/index.html b/article/dev-snapshot-godot-3-4-beta-5/index.html
index 1a5145f04c..1df6f0c05f 100644
--- a/article/dev-snapshot-godot-3-4-beta-5/index.html
+++ b/article/dev-snapshot-godot-3-4-beta-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde22 September 2021
The upcoming Godot 3.4 release will provide a number of new features which have been backported from the 4.0 development branch (see our release policy for details on the various Godot versions). This beta 5 build provides additional features and fixes to bugs reported against previous builds.
If you already reviewed the changelog for the previous beta, you can skip right to the differences between beta 4 and beta 5 (part 1, part 2).
Rendering: Add a new high quality tonemapper: ACES Fitted (GH-52477).
Rendering: Fixes depth sorting of meshes with transparent textures (GH-50721).
Rendering: Add soft shadows to the CPU lightmapper (GH-50184).
Rendering: Import option to split vertex buffer stream in positions and attributes (GH-46574).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Shaders: Add support for structs and fragment-to-light varyings (GH-48075).
VisualScript: Improve and streamline VisualScriptFuncNodes CallSetGet (GH-50709).
Windows: Fix platform file access to allow file sharing with external programs (GH-51430).
All these need to be thoroughly tested to ensure that they work as intended in the upcoming 3.4-stable.
Changes
Here’s a curated changelog with links to the relevant pull requests for details. The list is not exhaustive and will be completed in the future to include more noteworthy changes.
Note that some of the changes in 3.4 have already been backported and published in Godot 3.3.1 and 3.3.2, and therefore they were not listed here again. You can refer to the changelogs of those maintenance releases for details on what you might have missed since 3.3-stable.
Android: Add partial support for Android scoped storage (GH-50359).
This also means we’re now targeting API level 30 as required to publish new apps on Google Play.
Android: Add initial support for Play Asset Delivery (GH-52526).
Android: Improve input responsiveness on underpowered Android devices (GH-42220).
Android: Add GDNative libraries to Android custom Gradle builds (GH-49912).
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 dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.147 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4 beta 5. 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.3.3 or earlier no longer works in 3.4 beta 5).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-4-beta-6/index.html b/article/dev-snapshot-godot-3-4-beta-6/index.html
index 9365d208f9..f1bf8c450c 100644
--- a/article/dev-snapshot-godot-3-4-beta-6/index.html
+++ b/article/dev-snapshot-godot-3-4-beta-6/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde6 October 2021
The upcoming Godot 3.4 release will provide a number of new features which have been backported from the 4.0 development branch (see our release policy for details on the various Godot versions). This beta 6 build provides additional features and fixes to bugs reported against previous builds.
Rendering: Add a new high quality tonemapper: ACES Fitted (GH-52477).
Rendering: Fixes depth sorting of meshes with transparent textures (GH-50721).
Rendering: Add soft shadows to the CPU lightmapper (GH-50184).
Rendering: Import option to split vertex buffer stream in positions and attributes (GH-46574).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Shaders: Add support for structs and fragment-to-light varyings (GH-48075).
Viewport: Add a 2D scale factor property (GH-52137).
VisualScript: Improve and streamline VisualScriptFuncNodes CallSetGet (GH-50709).
Windows: Fix platform file access to allow file sharing with external programs (GH-51430).
All these need to be thoroughly tested to ensure that they work as intended in the upcoming 3.4-stable.
Changes
Here’s a curated changelog with links to the relevant pull requests for details. The list is not exhaustive and will be completed in the future to include more noteworthy changes.
Note that some of the changes in 3.4 have already been backported and published in Godot 3.3.1 and 3.3.2, and therefore they were not listed here again. You can refer to the changelogs of those maintenance releases for details on what you might have missed since 3.3-stable.
Android: Add partial support for Android scoped storage (GH-50359).
This also means we’re now targeting API level 30 as required to publish new apps on Google Play.
Android: Add initial support for Play Asset Delivery (GH-52526).
Android: Improve input responsiveness on underpowered Android devices (GH-42220).
Android: Add GDNative libraries to Android custom Gradle builds (GH-49912).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.147 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4 beta 6. 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.3.3 or earlier no longer works in 3.4 beta 6).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-5-beta-1/index.html b/article/dev-snapshot-godot-3-5-beta-1/index.html
index 4dd7ca18c5..dc19d3274b 100644
--- a/article/dev-snapshot-godot-3-5-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-5-beta-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde13 January 2022
Godot 3.4 was released 2 months ago, and some of the major planned features for Godot 3.5 have since been merged and are now ready for wider testing.
So we’re starting the beta testing phase with this already significant set of changes, and we’ll have frequent beta builds to polish them for the stable release. Some more features are still being worked on and will be included in future beta builds.
All this work is done by contributors on the side while our main development focus remains on the upcoming Godot 4.0 alpha (see our release policy for details on the various Godot versions).
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020!
This adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Watch the Releases page for upcoming testing builds of the Git plugin to use with 3.5 beta 1!
Core: Support deep comparison of Array and Dictionary (GH-42625).
Networking: Add proxy support for HTTPClient and the editor (GH-55988).
Rendering: Add material_overlay property to MeshInstance (GH-50823).
Rendering: Faster editor line drawing - Path2D and draw_line (GH-54377).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.5 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.4.x no longer works in 3.5 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-5-beta-2/index.html b/article/dev-snapshot-godot-3-5-beta-2/index.html
index 6c944230ae..6fc0082ce0 100644
--- a/article/dev-snapshot-godot-3-5-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-5-beta-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 March 2022
It’s already been 2 months since 3.5 beta 1! Between biweekly 4.0 alpha builds and maintenance releases for the stable branch (3.4.3, 3.4.4 RC 1), the release team – i.e. me – is spread thin… but these two months gave time for a lot of improvements in the 3.x branch and this new 3.5 beta 2 should be worth the wait!
This is a big update with close to 350 commits from 82 contributors since the previous beta! Some of the main highlights added in beta 2 are physics interpolation for 3D, and a new OccluderShapePolygon for your 3D occlusion needs.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020!
This adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in preliminary docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5 beta.
Rendering: Add support for saving multiple Images in BakedLightmap (GH-58102).
Shaders: Many improvements backported from master (GH-56794).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Notes:
The Windows builds are signed, but the certificate expired recently. The next builds should be signed with a new certificate.
The macOS editor builds are signed but not notarized. The next builds should be notarized again.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.5 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.4.x no longer works in 3.5 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-5-beta-3/index.html b/article/dev-snapshot-godot-3-5-beta-3/index.html
index 3c56fc7126..c97b54547a 100644
--- a/article/dev-snapshot-godot-3-5-beta-3/index.html
+++ b/article/dev-snapshot-godot-3-5-beta-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde30 March 2022
We’re getting closer to the Godot 3.5 stable release with a third beta snapshot! Like with 4.0 alpha builds, we’re trying to release 3.5 beta builds every other week to ensure that new features can be tested, bugs can be reported and bugfixes can be validated.
This new beta 3 adds two much awaited changes for Android users: an initial Android editor port, and a fix for the low processor usage mode which used to flicker on Android. See the highlight section below for details and a download link for the editor APK.
This is a big update with close to 350 commits from 82 contributors since the previous beta! Some of the main highlights added in beta 2 are physics interpolation for 3D, and a new OccluderShapePolygon for your 3D occlusion needs.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020!
This adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in preliminary docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5 beta.
And more!
Android: Initial port of the Godot editor (GH-57747).
Android: Fix flickering issues with low processor mode (GH-59606).
Audio: Allow configuring loop mode on WAV import (GH-59170).
Rendering: Add support for saving multiple Images in BakedLightmap (GH-58102).
Rendering: Bind mesh merging functionality in MeshInstance (GH-57661).
Shaders: Many improvements backported from master (GH-56794).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Notes:
The Windows builds are signed, but the certificate expired recently. The next builds should be signed with a new certificate.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.5 beta 3. 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.4.x no longer works in 3.5 beta 3).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-5-beta-4/index.html b/article/dev-snapshot-godot-3-5-beta-4/index.html
index 40437a4251..dcf5598e22 100644
--- a/article/dev-snapshot-godot-3-5-beta-4/index.html
+++ b/article/dev-snapshot-godot-3-5-beta-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 April 2022
We’re getting closer to the Godot 3.5 stable release with a fourth beta snapshot! Like with 4.0 alpha builds, we’re trying to release 3.5 beta builds every other week to ensure that new features can be tested, bugs can be reported and bugfixes can be validated.
This beta 4 is a small update with just 83 commits excluding merges, focusing on fixing bugs to stabilize the current feature set for 3.5 stable.
The previous beta 3 introduced a brand new Android editor port! In this build, we also built it for 32-bit platforms (armv7 and x86) as there was some demand for it, so you’ll find the APK is a bit heavier.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020!
This adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in preliminary docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5 beta.
And more!
Android: Initial port of the Godot editor (GH-57747).
Android: Fix flickering issues with low processor mode (GH-59606).
Rendering: Add support for saving multiple Images in BakedLightmap (GH-58102).
Rendering: Bind mesh merging functionality in MeshInstance (GH-57661).
Shaders: Many improvements backported from master (GH-56794).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Notes:
The Windows builds are signed, but the certificate expired recently. The next builds should be signed with a new certificate.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this beta. 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.4.x no longer works in this 3.5 beta).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-5-beta-5/index.html b/article/dev-snapshot-godot-3-5-beta-5/index.html
index 9bb57a8193..ae92667474 100644
--- a/article/dev-snapshot-godot-3-5-beta-5/index.html
+++ b/article/dev-snapshot-godot-3-5-beta-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde3 May 2022
We’re getting closer to the Godot 3.5 stable release with a fifth beta snapshot! Like with 4.0 alpha builds, we’re trying to release 3.5 beta builds every other week to ensure that new features can be tested, bugs can be reported and bugfixes can be validated.
This beta adds what should be the last batch of new features (together with a lot of bug fixes, as that’s our focus at this stage), with scene unique node names and the new SceneTreeTween backported from Godot 4.0.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020!
This adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in preliminary docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5 beta.
And more!
Android: Initial port of the Godot editor (GH-57747).
Android: Fix flickering issues with low processor mode (GH-59606).
Rendering: Add support for saving multiple Images in BakedLightmap (GH-58102).
Rendering: Bind mesh merging functionality in MeshInstance (GH-57661).
Shaders: Many improvements backported from master (GH-56794).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Notes:
The Windows builds are signed, but the certificate expired recently. Future builds should be signed with a new certificate.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this beta. 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.4.x no longer works in this 3.5 beta).
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-6-beta-1/index.html b/article/dev-snapshot-godot-3-6-beta-1/index.html
index 29e99fa986..cc876c0653 100644
--- a/article/dev-snapshot-godot-3-6-beta-1/index.html
+++ b/article/dev-snapshot-godot-3-6-beta-1/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde13 April 2023
Our biggest milestone in 4 years, Godot 4.0, has just been released a month ago. The reception has been great, and we’re already hard at work on the 4.1 milestone with a bunch of improvements. But that doesn’t mean we’re forgetting Godot 3 users and their projects, which they plan to maintain for months or years to come.
The current stable Godot 3 version, 3.5, has just received a new maintenance update, addressing several reported issues. At the same time we’ve been working on the next feature update to the 3.x branch — Godot 3.6.
The development is slower paced, as most contributors focus on the 4.x branch, which is where the future of Godot lies. But little by little, improvements and bugfixes are being backported and we’ve accumulated enough of those now to propose a 3.6 beta 1, to start the testing phase leading to the stable release.
See the curated changelog for a selection of some of the main changes since Godot 3.5.2. We now also have a great interactive changelog you can use to review all 500+ changes since Godot 3.5 more extensively, with convenient links to the relevant PRs on GitHub.
Here are some of the main changes you might be interested in:
3D: Add rotation ability to material editor preview (GH-49466).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 3.5.x, but no longer works in 3.6 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-6-beta-2/index.html b/article/dev-snapshot-godot-3-6-beta-2/index.html
index caa7ec36cd..ebfff9b018 100644
--- a/article/dev-snapshot-godot-3-6-beta-2/index.html
+++ b/article/dev-snapshot-godot-3-6-beta-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde25 May 2023
While most of our development focus is on the upcoming Godot 4.1, and maintenance releases for the stable 4.0 branch (with 4.0.3 published last week), a handful of dedicated contributors still work as time permits on finalizing the 3.6 release, to bring important fixes and some welcome new features to users who prefer not to port their projects to Godot 4.
We had a first 3.6 beta 1 build a month ago, and it’s time for the second one. We’ve only merged around 50 changes since beta 1, but some of those are pretty substantial and have long been in development, so there’s a lot to test!
A lot of work is also being done to improve the Android editor port. We’re looking for interested users to help test the beta snapshots via Google Play, and provide us with feedback and automated reports on potential issues. You can join the testing group here to get access.
The illustration picture for this article is fromMurtop by hiulit, a fast-paced arcade game packed with action, as if it was taken out directly from the 80’s, where Dig Dug meets Bomberman. It’s available on Nintendo Switch, Steam, and itch.io.
What’s new
See the curated changelog for a selection of some of the main changes since Godot 3.5.2. We now also have a great interactive changelog you can use to review the changes since the previous beta, with convenient links to the relevant PRs on GitHub.
Here are some of the main changes you might be interested in:
2D: Add option in VisibilityEnabler2D to hide the parent for better performance (GH-63193).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 3.5.x, but no longer works in 3.6 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-6-beta-3/index.html b/article/dev-snapshot-godot-3-6-beta-3/index.html
index 275287db84..37acc493c4 100644
--- a/article/dev-snapshot-godot-3-6-beta-3/index.html
+++ b/article/dev-snapshot-godot-3-6-beta-3/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde16 August 2023
The core of the Godot development focus is on the upcoming Godot 4.2, currently with a 3rd dev snapshot. But we haven’t forgotten about the 3.6 release, which has a slow but steady influx of important bug fixes, platform improvements, and rendering features. Godot 3 is still very important for a significant part of the ecosystem - notably people with released games, games close to being released, or who need to target OpenGL 2 / WebGL 1 to maximize device compatibility.
It’s been a long time since the earlier 3.6 beta snapshots, so check the beta 1 and beta 2 announcements for details on what changed since 3.5.
A lot of work is also being done to improve the Android editor port. We’re looking for interested users to help test the beta snapshots via Google Play, and provide us with feedback and automated reports on potential issues. You can join the testing group here to get access.
The illustration picture for this article showcasesRobotherapy, an emotional dark comedy about robots doing therapy. It was developed by Lucas Molina with Godot 3.5, and just got released on Steam!
Highlights
Two new important features for 2D are introduced in this beta, courtesy of lawnjelly.
2D hierarchical culling
Previously, each 2D item was checked individually to see whether it was off screen and so not needing to be drawn (culling). With hierarchical culling, entire branches of the scene tree can be culled at once, which can significantly increase performance on large 2D maps that contain a lot of off screen items.
Hierarchical culling defaults to on, but can be switched back to the legacy (“Item”) mode with the project setting rendering/2d/options/culling_mode, in case of regressions.
2D physics interpolation
Godot 3.5 introduced 3D physics interpolation with great success, and users have been awaiting its 2D counterpart, so here it comes! This initial version of 2D physics interpolation supports most objects, including CPUParticles2D, but is a work in progress that will depend on your feedback. Notably (GPU) Particles2D is not yet supported, but the initial version should be good for experimentation. There will be bugs and special cases for lawnjelly to fix, please report these on GitHub.
Some preliminary documentation can be found here: 2D FTI docs. Note that physics interpolation is disabled by default, refer to the docs for how to enable it.
What’s new
See the curated changelog for a selection of some of the main changes since Godot 3.5.2. We now also have a great interactive changelog you can use to review the changes since the previous beta, with convenient links to the relevant PRs on GitHub.
Here are some of the main changes you might be interested in:
2D: Make autotiles fall back to the most similar bitmask (GH-71533).
2D: Fix AnimatedSprite normal map loading (GH-80406).
3D: Fix OccluderPolyShape handles disappear after release click (GH-79947).
Assetlib: Add support for svg images in the asset library (GH-70502).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 3.5.x no longer works in 3.6 beta 3).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-6-beta-4/index.html b/article/dev-snapshot-godot-3-6-beta-4/index.html
index 9e9a25a48d..cd5e3d80d7 100644
--- a/article/dev-snapshot-godot-3-6-beta-4/index.html
+++ b/article/dev-snapshot-godot-3-6-beta-4/index.html
@@ -11,7 +11,7 @@
Make a Donation
Standard build includes support for GDScript, GDNative, and VisualScript.
.NET build includes support for C#, as well as GDScript, GDNative, and VisualScript.
You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.198 are included in this build.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 3.x releases no longer works in this release).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-3-6-beta-5/index.html b/article/dev-snapshot-godot-3-6-beta-5/index.html
index aad22bb644..92355c1b1d 100644
--- a/article/dev-snapshot-godot-3-6-beta-5/index.html
+++ b/article/dev-snapshot-godot-3-6-beta-5/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript, GDNative, and VisualScript.
.NET build includes support for C#, as well as GDScript, GDNative, and VisualScript.
You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.198 are included in this build.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 3.x releases no longer works in this release).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-1/index.html b/article/dev-snapshot-godot-4-0-alpha-1/index.html
index bad1249e56..94b1f60c1b 100644
--- a/article/dev-snapshot-godot-4-0-alpha-1/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-1/index.html
@@ -7,7 +7,7 @@
Notably, C# support is undergoing a port to .NET 6, which is why Mono builds are not included in this alpha.
As we get closer to the stable release of Godot 4, expect us to cover the key changes in more detail in dedicated blog posts.
In the meantime, if you don’t quite feel adventurous enough to try the alpha, Godot 3 keeps getting bigger and better with every backport and fix. Many contributors don’t stop at developing a feature, but also go one step further and deliver it to the stable release of the engine. Thanks to them, you can experience a taste of what’s coming – today. And share some feedback, if you can! Now is the best time to shape the future of Godot.
Downloads
The downloads for this dev snapshot can be found directly on our repository:
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Known issues
As this is our first alpha release of the next major version of Godot there are still many-many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone. Below we list a few of them that may be important to a lot of users:
Crash when minimising any window when a sub window is open (GH-51537).
Duplicated files or resources retains the same UID (GH-54774).
Navigating the editor UI with the Tab key doesn’t work (GH-54602).
The Vulkan Mobile backend has a lot of known bugs. We recommend testing rendering features with Vulkan Clustered for now.
AMD FSR implementation may not be working as expected (GH-56173, GH-56174).
TileMap terrain feature doesn’t work as expected (GH-54587).
Particle trails work incorrectly with random lifetime (GH-55842).
There are of course many more known issues as it’s only the first alpha release. We’ll add more to this post if we see testers stumbling on them.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-10/index.html b/article/dev-snapshot-godot-4-0-alpha-10/index.html
index 8327a61555..3be12a8f80 100644
--- a/article/dev-snapshot-godot-4-0-alpha-10/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-10/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 June 2022
Another couple of weeks, another alpha snapshot from the development branch, this time with 4.0 alpha 10! We’re getting in 2-digit territory, both because 4.0 is a huge release that requires a lot of work, and because we’re committed to providing dev snapshots frequently so that pre-release testers can quickly access the new features and bug fixes.
This snapshot comes with a handful of interesting new features, notably:
Early version of a command-line tool to convert Godot 3.x projects to the 4.0 API (GH-51950). You can test it on a separate copy of your project with the --convert-3to4 command line argument.
Adds TileMap terrain center bit to support “connect” and “path” draw modes (GH-61809).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 10 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 9 (149 commits – excluding merge commits ― from 51 contributors).
Some of the most notables feature changes in this update are:
2D: Add TileMap terrain center bit to support “connect” and “path” draw modes (GH-61809).
2D: Fix terrains for isometric tilemaps (GH-61998).
2D: Fix global properties and add global_skew for Node2D (GH-52415).
3D: Add support for saving lightmap as multiple images (GH-61861).
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 10. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-11/index.html b/article/dev-snapshot-godot-4-0-alpha-11/index.html
index 9d0876ed0b..5b53bcce92 100644
--- a/article/dev-snapshot-godot-4-0-alpha-11/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-11/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde1 July 2022
Another couple of weeks, another alpha snapshot from the development branch, this time with 4.0 alpha 11! Same deal as usual, lots of bugs fixed and more refactoring and feature work. We’re etching closer and closer to the beta stage, things are starting to fall into place!
Some noteworthy changes in this release:
Exporting Node pointers as NodePaths (@export var some_node: Node)
Movie Maker run mode to record in-game footage for trailers/movies
Fix GDScript bug causing return values to be reset in release builds
AnimationTree advance expressions to drive complex state machines
Note: There was a change in the internal format that PNG files get imported to, which you might experience as projects from earlier alphas reporting broken dependencies. You can fix this by deleting the .godot/imported/ folder to force a reimport. (Or manually triggering a reimport for your image resources.)
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 11 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 10 (200 commits – excluding merge commits ― from 71 contributors).
Some of the most notables feature changes in this update are:
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 11. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-12/index.html b/article/dev-snapshot-godot-4-0-alpha-12/index.html
index 75bf36426e..0e6a68d7af 100644
--- a/article/dev-snapshot-godot-4-0-alpha-12/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-12/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde14 July 2022
Another couple of weeks, another alpha snapshot from the development branch, this time with 4.0 alpha 12! Same deal as usual, lots of bugs fixed and more refactoring and feature work. We’re etching closer and closer to the beta stage, things are starting to fall into place!
Some noteworthy changes in this release:
Grouping annotations for exported variables in GDScript (@export_group).
Full support for Android scoped storage (also in 3.5 RCs).
Font resource refactoring.
Lots of GDScript 2.0 bugs squashed.
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 12 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 11 (129 commits – excluding merge commits ― from 54 contributors).
Some of the most notables feature changes in this update are:
2D: Account for relative Z indices when Y-sorting (GH-62837).
3D: Add global_position and global_rotation to Node3D (GH-50755).
Android: Add full support for Android scoped storage (GH-62459).
Android: Refactor Custom Build options in export preset (GH-62611).
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 12. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-13/index.html b/article/dev-snapshot-godot-4-0-alpha-13/index.html
index 1e60dd7b9a..dc9873e2fa 100644
--- a/article/dev-snapshot-godot-4-0-alpha-13/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-13/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 July 2022
We just announced that we’ll enter feature freeze next week to focus on stabilizing the existing functionality in Godot 4.0 and prepare the first beta release. But we’re not there yet and we’ll keep having frequent alpha builds until we’re ready to slap the beta label on the engine. So here we go with 4.0 alpha 13!
Update 2022-07-29 @ 10:30 UTC: A regression was found in the original build that prevented exporting projects to Windows and Linux with official templates. All editor builds for this alpha have been updated with a hotfix. If you downloaded alpha 13 before this update, you can re-download the editor build for your platform. Export templates are unimpacted so you don’t need to update them.
Some noteworthy changes in this release:
Shader preprocessor support and shader includes.
Grouping annotations for shaders (uniform_group).
Vector4, Vector4i and Projection types.
Support for loading system fonts on desktop and iOS.
Peer visibility support in MultiplayerSynchronizer.
Variable Rate Shading support.
Worker Thread Pool.
Feature build profiles for custom builds.
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 13 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 12 (204 commits – excluding merge commits ― from 66 contributors).
Some of the most notables feature changes in this update are:
Audio: Implement BPM support in AudioStream files (GH-63265).
Mono builds are currently not available as our focus is on porting to .NET 6. As soon as the .NET 6 port is ready to test, it will be included in dev snapshots.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 13. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-14/index.html b/article/dev-snapshot-godot-4-0-alpha-14/index.html
index ed9e780b90..a57ca84a2c 100644
--- a/article/dev-snapshot-godot-4-0-alpha-14/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-14/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde11 August 2022
We’re working towards finalizing the feature set for 4.0 beta, reviewing many PRs which have been opened prior to our roadmap feature freeze announced a couple of weeks ago. While this process is ongoing, we’ll keep releasing alpha builds so here’s 4.0 alpha 14! Same deal as usual, lots of bugs fixed and more refactoring and feature work.
Some noteworthy changes in this release:
Add turbulence/noise for ParticlesMaterial (GH-55387).
Add often used built-ins to spatial shaders (NODE_POSITION_WORLD, CAMERA_POSITION_WORLD, CAMERA_DIRECTION_WORLD, NODE_POSITION_VIEW) (GH-63597).
Improve usability of non-default values in the property inspector (GH-63429).
Modularize multiplayer, expose MultiplayerAPI to extensions (GH-63049).
Various enhancements and fixes to the Godot 3 to 4 converter (GH-63887).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 14 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 13 (288 commits – excluding merge commits ― from 93 contributors).
Some of the most notables feature changes in this update are:
Porting: Implement keep_screen_on option for macOS and Windows (GH-63882, GH-63953).
Shaders: Add often used built-ins to spatial shaders (NODE_POSITION_WORLD, CAMERA_POSITION_WORLD, CAMERA_DIRECTION_WORLD, NODE_POSITION_VIEW) (GH-63597).
Mono builds are currently not available as our focus is on porting to .NET 6. As soon as the .NET 6 port is ready to test, it will be included in dev snapshots.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 14. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-15/index.html b/article/dev-snapshot-godot-4-0-alpha-15/index.html
index 2a3428c33d..058f6256db 100644
--- a/article/dev-snapshot-godot-4-0-alpha-15/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-15/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde30 August 2022
We’re working towards finalizing the feature set for 4.0 beta, reviewing many PRs which have been opened prior to our roadmap feature freeze announced a month ago. While this process is ongoing, we’ll keep releasing alpha builds so here’s 4.0 alpha 15! Same deal as usual, lots of bugs fixed and more refactoring and feature work.
This alpha doesn’t include official builds with .NET 6 support yet, as we still have more work to do to enable this. For now, it’s possible to compile it yourself from source, see modules/mono/README.md for instructions.
The beta feature freeze will soon lock the API more or less in place, so contributors have been hard at work evaluating and merging or rejecting the last proposals for a more consistent and user-friendly API.
For users of previous alphas, we don’t always have compatibility code to ease transition. If you run into upgrade issues that you can’t solve easily, please let us know so we can consider how much inter-alpha compatibility code we need to add.
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 15 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 14 (362 commits – excluding merge commits ― from 73 contributors).
Some of the most notables feature changes in this update are:
3D: Add line breaking support to the TextMesh (GH-64243).
3D: Remove QuadMesh and add orientation parameter to PlaneMesh (GH-64801).
Animation: Add bezier preset and refactor bezier editor (GH-64647).
Buildsystem: Unify bits, arch, and android_arch into env[“arch”] (GH-55778).
For people compiling from source, note that this changes the name of the compiled binary to use the architecture name as a suffix (e.g. .x86_64.exe instead of .64.exe).
.NET 6 support should be included in 4.0 beta 1. The initial support has been merged, but more work is required to make official builds easily. For now, it’s possible to compile it yourself from source, see modules/mono/README.md for instructions.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
In this build specifically, we mistakenly compiled only the arm64v8 libraries for the Android templates and editor builds. That’s why the whole templates package ended up significantly smaller, and Android exports would not work on armv7, x86 and x86_64 architectures.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 15. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-16/index.html b/article/dev-snapshot-godot-4-0-alpha-16/index.html
index fabf6a72ec..32919e343e 100644
--- a/article/dev-snapshot-godot-4-0-alpha-16/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-16/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde7 September 2022
We’re working towards finalizing the feature set for 4.0 beta, reviewing many PRs which have been opened prior to our roadmap feature freeze announced a month ago. While this process is ongoing, we’ll keep releasing alpha builds so here’s 4.0 alpha 16! Same deal as usual, lots of bugs fixed and more refactoring and feature work.
Some noteworthy changes in this release:
Re-enable support for Web exports using the OpenGL 3 / WebGL 2 renderer.
This is the first alpha to include export templates for the Web platform again. The Web editor build is not functional yet.
Implement MSAA for 2D with Vulkan.
Implement physical light units in Vulkan renderers.
Implement navigation links via NavigationLink2D/3D nodes.
Re-enable per-pixel transparency support on Linux, macOS, and Windows.
Lots of fixes to theme propagation issues, both regressions in the previous alpha 15 and pre-existing bugs that it helped uncover. And various editor theme improvements.
Core: More renames!
The beta feature freeze will soon lock the API more or less in place, so contributors have been hard at work evaluating and merging or rejecting the last proposals for a more consistent and user-friendly API.
For users of previous alphas, we don’t always have compatibility code to ease transition. If you run into upgrade issues that you can’t solve easily, please let us know so we can consider how much inter-alpha compatibility code we need to add.
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 16 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 15 (180 commits – excluding merge commits ― from 61 contributors).
Some of the most notables feature changes in this update are:
Core: More renames!
Rename or_lesser range property hint to or_less (GH-59589).
Rename Curve/Curve2D/Curve3D/Gradient interpolate() to sample() (GH-63394).
Rename every instance of caret_blink_speed to caret_blink_interval (GH-64361).
Rename CanvasItem update() to queue_redraw() (GH-64377).
Rename AABB/Rect2/Rect2i has_no_* methods with has_* methods (GH-64417).
Rename TileMap/GridMap world_to_map() and opposite to local_to_map() (GH-64661).
Rename uniform to parameter across the engine (GH-64952).
Rename ProgressBar percent_visible to show_percentage (GH-65038).
Rename Object constant CONNECT_ONESHOT to CONNECT_ONE_SHOT (GH-65197).
Rename JavaScript singleton to JavaScriptBridge (GH-65239).
.NET 6 support should be included in 4.0 beta 1. The initial support has been merged, but more work is required to make official builds easily. For now, it’s possible to compile it yourself from source, see modules/mono/README.md for instructions.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 16. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-17/index.html b/article/dev-snapshot-godot-4-0-alpha-17/index.html
index b6127e263d..ab9d750e37 100644
--- a/article/dev-snapshot-godot-4-0-alpha-17/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-17/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde13 September 2022
We’re getting prepared for the imminent release of Godot 4.0 beta 1, and to do so we’re having a (last?) alpha 17 release to ensure that things work as best as we can reasonably expect before the beta phase.
Some noteworthy changes in this release:
Add option to convert project from 3.x to 4.0 from the Project Manager (GH-64927).
Refactored Android input implementation with better handling of gestures (GH-65434).
.NET 6 support no longer requires libnethost, makes it easier to build(GH-65438).
Allow images to be imported “for editor use” and respect editor settings (GH-64938).
Fix Ctrl/Cmd key remapping changes when moving from macOS to other platform (GH-65241).
Fix multiwindow support in GLES3 for X11, Windows and macOS (GH-65727).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 17 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 16 (90 commits – excluding merge commits ― from 34 contributors).
Some of the most notables feature changes in this update are:
Android: Clean-up and refactor the Android input implementation (GH-65434).
Android: Update the versioning logic for the Android editor (GH-65682).
Animation: Rework AnimatedTexture’s fps into speed_scale (GH-65188).
Animation: Harmonize AnimatedSprite3D and its 2D counterparts (GH-64155).
Animation: Don’t store the frame property of playing AnimatedSprite (GH-65720).
Buildsystem: Refactor LTO options with lto=<none|thin|full> (GH-63288).
C#: Replace libnethost dependency to find hostfxr (GH-65438).
Core: A few more renames:
Rename and move Node.raise() to CanvasItem.move_to_front() (GH-60108).
Rename SceneTree change_scene() and change_scene_to() to remove ambiguity (GH-63596).
Rename “ssl” references to “tls” in methods and properties (GH-65460).
Core: Fix Time.get_datetime_* methods possibly return wrong time on day change (GH-65509).
Core: Allow negative indices in Node move_child() (GH-65595).
Core: Add ability to flag classes and methods as experimental or deprecated (GH-64982).
Editor: Fix editing of remote objects in the Inspector (GH-63640, GH-65520).
Editor: Improve Scene Tree dock’s node filter (allow multiple terms & more) (GH-65352).
Editor: Add option to convert project from 3.x to 4.0 from the Project Manager (GH-64927).
GDScript: Fix last modified time not being properly tracked when reloading scripts (GH-65687).
GUI: Allow SplitContainer to have a grab area larger than its visual grabber (GH-65355).
Import: Allow images to be imported “for editor use” and respect editor settings (GH-64938).
Input: Fix Ctrl/Cmd key remapping changes when moving from macOS to other platform (GH-65241).
.NET 6 support should be included in 4.0 beta 1. The initial support has been merged, but more work is required to make official builds easily. For now, it’s possible to compile it yourself from source, see modules/mono/README.md for instructions.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 17. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-2/index.html b/article/dev-snapshot-godot-4-0-alpha-2/index.html
index af5baa7aae..f8bffe2e9d 100644
--- a/article/dev-snapshot-godot-4-0-alpha-2/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde9 February 2022
Two weeks ago we finally released Godot 4.0 alpha 1 ― the first official alpha build of our upcoming major milestone, enabling all interested users to try it out and report bugs, as well as provide feedback on the new features.
We got lots of bug reports and many have been fixed already in these two weeks! To keep iterating on stabilizing the 4.0 branch, we’re going to release new alpha builds every other week, so that testers can always have a recent version to test the latest changes.
So here’s Godot 4.0 alpha 2 with a great deal of fixes and new features!
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 2 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 1 (260 commits – excluding merge commits ― from 48 contributors).
Some of the most notables feature changes in this update are:
Multiplayer replication
Built into the engine core we now have scene, spawn, and property replication over the network. This means the engine can now do a lot of the heavy lifting and get you started on the next multiplayer hit much quicker. You don’t have to worry about manually keeping your scenes in sync across connected devices, even for players connecting mid-game. Long gone are boilerplate functions and remote calls just to change some property for every player in the session.
Of course, you still can do all of it, or part of it, manually, depending on your needs. And you can mix and match — all of the additions are completely extendable, configurable, and replaceable. If you are still going to use RPCs, those received some love too and now have their own annotations in GDScript 2.0.
We got a series of 3D editor usability improvements and bugfixes in this alpha, with the implementation of Blender-style shortcuts for 3D transformations (GH-56543), and various fixes for the 3D rotation gizmo (GH-56946). And there’s more to come in the next alpha!
AudioStreamRandomizer
The AudioStreamRandomPitch node has been renamed to AudioStreamRandomizer and extended with new functionalities (GH-52592):
Random or sequential playback of a selection of streams
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone. Below we list a few of them that may be important to a lot of users:
The Vulkan Mobile backend has a lot of known bugs. We recommend testing rendering features with Vulkan Clustered for now.
AMD FSR implementation may not be working as expected (GH-56173, GH-56174).
Particle trails work incorrectly with random lifetime (GH-55842).
There are of course many more known issues as we’re still in the alpha stage. We’ll add more to this post if we see testers stumbling on them.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-3/index.html b/article/dev-snapshot-godot-4-0-alpha-3/index.html
index f860114c5e..fc9f3cdcb6 100644
--- a/article/dev-snapshot-godot-4-0-alpha-3/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde22 February 2022
We’re continuing on our fortnightly release schedule for alpha snapshots of Godot 4.0 - this time with 4.0 alpha 3. See past alpha releases for details (alpha 1, alpha 2).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 3 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 2 (191 commits – excluding merge commits ― from 47 contributors).
Some of the most notables feature changes in this update are:
Animation: Allow the drawing and editing of all animation bezier curves (GH-55030).
Core: Fix Variant Ref<> assignment (fixes crashes in GDExtension) (GH-57968).
Core: Fix internal resource reuse in binary loader (GH-58007).
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone. Below we list a few of them that may be important to a lot of users:
The Vulkan Mobile backend has a lot of known bugs. We recommend testing rendering features with Vulkan Clustered for now.
AMD FSR implementation may not be working as expected (GH-56173, GH-56174).
Particle trails work incorrectly with random lifetime (GH-55842).
There are of course many more known issues as we’re still in the alpha stage. We’ll add more to this post if we see testers stumbling on them.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 3. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-4/index.html b/article/dev-snapshot-godot-4-0-alpha-4/index.html
index 91e53c642b..df12f38b81 100644
--- a/article/dev-snapshot-godot-4-0-alpha-4/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde8 March 2022
We’re continuing on our fortnightly release schedule for alpha snapshots of Godot 4.0 - this time with 4.0 alpha 4. See past alpha releases for details (alpha 1, alpha 2, alpha 3).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 4 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 3 (158 commits – excluding merge commits ― from 45 contributors).
Some of the most notables feature changes in this update are:
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Note: The Windows builds are signed, but the certificate expired recently. We’re working on having it renewed, this should be fixed in the next build.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone. Below we list a few of them that may be important to a lot of users:
The Vulkan Mobile backend has a lot of known bugs. We recommend testing rendering features with Vulkan Clustered for now.
AMD FSR implementation may not be working as expected (GH-56173, GH-56174).
Particle trails work incorrectly with random lifetime (GH-55842).
There are of course many more known issues as we’re still in the alpha stage. We’ll add more to this post if we see testers stumbling on them.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 4. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-5/index.html b/article/dev-snapshot-godot-4-0-alpha-5/index.html
index bf0b363522..9c205abc74 100644
--- a/article/dev-snapshot-godot-4-0-alpha-5/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde24 March 2022
We’re continuing on our fortnightly release schedule for alpha snapshots of Godot 4.0 - this time with 4.0 alpha 5. See past alpha releases for details (alpha 1, 2, 3, 4).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 5 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 4 (199 commits – excluding merge commits ― from 57 contributors).
Some of the most notables feature changes in this update are:
2D: Invert Camera2D zoom to make it intuitive (GH-57392).
3D: Properly handle CSGShape parent and visibility updates (GH-40814).
Animation: Fix blend animation to solve TRS track bug & blend order inconsistency (GH-57675).
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Note: The Windows builds are signed, but the certificate expired recently. We’re working on having it renewed, this should be fixed in the next build.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 5. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-6/index.html b/article/dev-snapshot-godot-4-0-alpha-6/index.html
index d197b6c205..758705c3b5 100644
--- a/article/dev-snapshot-godot-4-0-alpha-6/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-6/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde6 April 2022
We’re continuing on our fortnightly release schedule for alpha snapshots of Godot 4.0 - this time with 4.0 alpha 6. See past alpha releases for details (alpha 1, 2, 3, 4, 5).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 6 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 5 (166 commits – excluding merge commits ― from 55 contributors).
Some of the most notables feature changes in this update are:
Android: Initial port of the Godot editor (GH-58160).
Android: Fix flickering issues with low processor mode (GH-59607).
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Note: The Windows builds are signed, but the certificate expired recently. We’re working on having it renewed, this should be fixed in future builds.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 6. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-7/index.html b/article/dev-snapshot-godot-4-0-alpha-7/index.html
index 47cf00a26e..8cabab1109 100644
--- a/article/dev-snapshot-godot-4-0-alpha-7/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-7/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 April 2022
This new 4.0 alpha 7 comes with one week delay on our every-other-week release schedule, since I was taking some time off :) But that means it got time for even more features and bug fixes to be finalized, reviewed and merged. See past alpha releases for details (alpha 1, 2, 3, 4, 5, 6).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 7 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 6 (192 commits – excluding merge commits ― from 65 contributors).
Some of the most notables feature changes in this update are:
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Note: The Windows builds are signed, but the certificate expired recently. We’re working on having it renewed, this should be fixed in future builds.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 7. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-8/index.html b/article/dev-snapshot-godot-4-0-alpha-8/index.html
index db4021736b..e65270ecbf 100644
--- a/article/dev-snapshot-godot-4-0-alpha-8/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-8/index.html
@@ -6,7 +6,7 @@
It includes notably Text-to-Speech support on all platforms (as a feature for games/applications, the Godot editor itself doesn’t make use of it for now), and a refactoring of the module/extension initialization levels to allow more flexibility for third-party code.
See past alpha releases for details (alpha 1, 2, 3, 4, 5, 6, 7).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 8 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 7 (157 commits – excluding merge commits ― from 55 contributors).
Some of the most notables feature changes in this update are:
Audio: Implement text-to-speech support on all platforms (GH-56192).
Buildsystem: Upgraded official build system to newer toolchains (build-containers#104):
Windows: MinGW GCC 11.2.1 and binutils 2.37.
macOS/iOS: LLVM 14 - Edit: Seems like macOS doesn’t like LLVM 14, it’s crashing.
Core: Make {call,set,notify}_group() immediate by default (GH-51591).
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Note: The Windows builds are signed, but the certificate expired recently. We’re still working on having it renewed.
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
macOS builds in 4.0 alpha 8 are crashing on Apple M1, we’re investigating why. In the meantime, you can keep using 4.0 alpha 7 which should work fine.
Edit: A new macOS editor binary has been uploaded which should work fine. Export templates for ARM64 might still be broken.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 8. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-alpha-9/index.html b/article/dev-snapshot-godot-4-0-alpha-9/index.html
index ded3f5199c..fefe64ee61 100644
--- a/article/dev-snapshot-godot-4-0-alpha-9/index.html
+++ b/article/dev-snapshot-godot-4-0-alpha-9/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde2 June 2022
Straight out of the Godot Sprint in Barcelona, here’s another alpha snapshot of the development branch, this time with 4.0 alpha 9! See past alpha releases for details (alpha 1, 2, 3, 4, 5, 6, 7, 8).
Be aware that during the alpha stage the engine is still not feature-complete or stable. There will likely be breaking changes between this release and the first beta release. Only the beta will mark the so-called “feature freeze”.
As such, we do not recommend porting existing projects to this and other upcoming alpha releases unless you are prepared to do it again to fix future incompatibilities. However, if you can port some existing projects and demos to the new version, that may provide a lot of useful information about critical issues still left to fix.
Most importantly: Make backups before opening any existing project in Godot 4.0 alpha builds. There is no easy way back once a project has been (partially) converted.
If you’re interested in an overview of what’s new in Godot 4.0 alpha in general, have a look at the detailed release notes for 4.0 alpha 1. In this alpha 9 blog post, we will only cover the main changes since the previous alpha release.
See the changelog on GitHub for an overview of all changes since 4.0 alpha 8 (255 commits – excluding merge commits ― from 60 contributors).
Some of the most notables feature changes in this update are:
Mono builds are currently not available as our focus is on porting to .NET 6. You’ll get a chance to test it with later alpha releases!
Known issues
As we are still in the alpha phase of development, there are still many issues to fix, some of which have already been reported and are being worked on.
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 alpha 9. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-1/index.html b/article/dev-snapshot-godot-4-0-beta-1/index.html
index 9d9160b34d..16dfdc8288 100644
--- a/article/dev-snapshot-godot-4-0-beta-1/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-1/index.html
@@ -31,7 +31,7 @@
See the Github issue tracker for a list of bugs in the 4.0 milestone.
Some noteworthy issues you might run into in this beta 1:
GDScript preload() fails in standalone build for imported resources and scenes converted to binary formats on export (GH-56343).
We already have a fix for this but it didn’t make it in time for beta 1. It will be in beta 2. In the meantime use load() instead of preload() if you want to export a project with beta 1.
Exporting a Web build fails on Windows due to some file locking issue (GH-65660).
See the issue for a potential workaround.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 4.0 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors in their free time, and a handful of part or full-time developers, hired thanks to donations from the Godot community. A big thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-10/index.html b/article/dev-snapshot-godot-4-0-beta-10/index.html
index a273486e14..8d75577a6a 100644
--- a/article/dev-snapshot-godot-4-0-beta-10/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-10/index.html
@@ -7,7 +7,7 @@
(GH-69349).
Navigation: Stop NavigationAgents without a target from moving to world origin (GH-69688).
Navigation: Fix typo and ensure backwards compatibility for changed property names (GH-70244).
Navigation: Restore weight scale for AStarGrid2D (partially) (GH-70339).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-11/index.html b/article/dev-snapshot-godot-4-0-beta-11/index.html
index b67ac6acfb..b8ca15b557 100644
--- a/article/dev-snapshot-godot-4-0-beta-11/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-11/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde10 January 2023
With the end-of-the-year celebrations past us, we are ready to get back to work and continue our regular Godot 4.0 beta releases. Over the course of the last four months the engine has seen many changes, making it more stable and feature complete, and it’s getting very close to the state that we would be happy with.
We took a bit longer to prepare this beta as there were a number of fairly big GDScript refactoring PRs (needed to fix many bugs), which we wanted to merge all at once. As such we expect that this beta 11 might introduce some new GDScript regressions, which we’ll aim to fix for beta 12 next week. Be sure to report anything that stops working as expected in your scripts.
This beta includes a few big changes which may interest a lot of users:
Animated sprites, both 2D and 3D, now support options for more precise timing of individual frames (GH-65609).
More engine enums are now bound with BitField, making their usage more type-safe, especially in C# (GH-71037, GH-71045, GH-71116).
Our copyright statement has been updated to be ever-green, and to put the bulk of our beloved contributors on the first line; it’s completely compatible with the previous version otherwise (GH-70885).
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is fromThe Mirror, an upcoming all-in-one game and game development platform currently in Closed Alpha. They’ve been building upon Godot 4.0 since early alpha releases; follow them on Twitter for updates.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 10 (163 commits – excluding merge commits ― from 71 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
Use this method to access the window your Node is in to change its properties. Notably, for nodes in the main window, this is the same as the scene tree’s root node (get_tree().get_root()).
GUI: Expose Tree::deselect_all to scripting (GH-71056).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-12/index.html b/article/dev-snapshot-godot-4-0-beta-12/index.html
index 0856321206..e4141260d9 100644
--- a/article/dev-snapshot-godot-4-0-beta-12/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-12/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde13 January 2023
After a short end-of-year break, and then a lot of heavy merging work prior to 4.0 beta 11, we found a lot of regressions – as we expected!
Our contributors could fix many of the new regressions quickly, and we merged another big batch of important fixes and improvements. As the pace intensifies in the lead-up to the first Release Candidate, we decided to make more frequent beta snapshots for testing.
This beta includes a few big changes which may interest a lot of users:
Regression fix for a major GDScript issue that could lead to seemingly random crashes (e.g. when dealing with PackedArrays) which many beta 11 users experienced (GH-71228).
A lot more GDScript fixes and improvements! See the list below.
A refactor of Animation APIs to change the stop(reset: bool) to two separate stop() and pause() methods (GH-71218), as was heavily requested by the community.
A couple fixes to the text resource loader which could impact notably reloading scripts (GH-71170).
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is fromGawr Gura: Quest for Breadby Kenny Park. The game is currently being ported to Godot 4.0 beta. Follow Kenny Park on Twitter or Mastodon for development updates, and check his website to discover other games and applications.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 11 (76 commits – excluding merge commits ― from 39 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
Animation: Split pause() from AnimationPlayer’s stop() (GH-71218).
Core: Fix escaping closing brackets in ConfigFile tags (GH-68450).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-13/index.html b/article/dev-snapshot-godot-4-0-beta-13/index.html
index 8c1fc6ae6f..bbafd68d4c 100644
--- a/article/dev-snapshot-godot-4-0-beta-13/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-13/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde17 January 2023
With the first Godot 4.0 Release Candidate on the horizon we continue to release beta snapshots frequently and relentlessly! Such cadence allows us to better measure the overall stability and quickly catch regressions, especially when a lot of features are worked on at the same time.
This week we release a new batch of improvements and fixes, as well as some new features. Unfortunately, we also have to rollback one of the core animations features. After a lot of testing and consideration we’ve decided to postpone improvements to the inverse kinematics system until a future Godot 4.x release, removing the currently unstable SkeletonModificationStack3D. This decision allows us to better focus efforts of the Animation team on stabilizing other features.
This beta includes a few big changes which may interest a lot of users:
SkeletonModificationStack3D has been removed, with the 3D inverse kinematic API being more or less reset to the state of Godot 3.x. We will focus on fixing regressions in SkeletonIK3D for the remaining time, and work has already started on an improved IK system for a future Godot 4.x version (GH-71137).
You can now deploy your projects to all desktop platforms over SSH, as well as run a remote debug session similar to what we already offered for Android and Web. This is especially useful for the developers targeting the Steam Deck, as you can configure it to have one-click deploy to your device. As the number of remote debug options is quite big by now, we’ve packed them neatly in a single drop-down menu (GH-63312, GH-70701).
Methods for drawing 2D lines and primitive shapes that take width as a parameter have been fixed and can now correctly handle widths at 1.0 or below (GH-69851).
The list of all global script classes (and their icons) is no longer stored in the project.godot file. It is now saved to a dedicated file inside of the .godot folder (GH-70557). This should improve VCS diffs for your projects.
Note: If you’re exporting your project from the command line and don’t have the .godot folder available, you currently need to make sure to run the editor at least once (in the headless mode) before trying to export it, similarly to what is required to import resources. This is a bug and should be solved eventually (so that you can --export-debug or --export-release directly from a Git checkout without .godot folder).
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is fromLone Knightby Jean Makes Games. The project is currently being ported to Godot 4 beta. Follow Jean Makes Games on Twitter for updates.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 12 (88 commits – excluding merge commits ― from 39 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
Animation: Reset animation on playback stop (GH-33733).
Animation: Remove SkeletonModificationStack3D, and Skeleton3D API cleanup (GH-71137).
Animation: Implement toggling pause / stop button to AnimationPlayerEditor (GH-71321).
Buildsystem: Fix feature build profile being parsed too late (and rename the option to build_profile) (GH-71508).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-14/index.html b/article/dev-snapshot-godot-4-0-beta-14/index.html
index bc186f4304..5ce3116710 100644
--- a/article/dev-snapshot-godot-4-0-beta-14/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-14/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde20 January 2023
With the first Godot 4.0 Release Candidate on the horizon we continue to release beta snapshots frequently and relentlessly! Such cadence allows us to better measure the overall stability and quickly catch regressions, especially when a lot of features are worked on at the same time.
This beta includes a few big changes which may interest a lot of users:
Fixes to CanvasItem draw methods to better handled lines of different widths and filled rectangles (GH-41239, GH-71623, GH-71679).
Add next/reset function to AnimationStateMachine (GH-71264, GH-71418).
Add astcenc compression and decompression (GH-70363).
Fix issue where failed start of OpenXR causes issues (GH-71450).
For shaders, we removed the now-redundant SCREEN_TEXTURE, DEPTH_TEXTURE, and NORMAL_ROUGHNESS_TEXTURE (GH-70967). The PR and in-editor errors give instructions on what’s the new way to access these features via hints.
BiDi overrides are now properly handled to better display complex texts in the GDScript editor (GH-71598).
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is fromDauphin, a 2D RPG in development by Ben / devduck which was recently ported to Godot 4.0 beta. You can follow development via Ben’s awesome YouTube devlogs and Twitter account.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 13 (73 commits – excluding merge commits ― from 40 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
2D: Fix CanvasItem.draw_rect() function with filled = false (GH-41239).
Plugins: Make EditorResourceConversionPlugin usable (GH-71443).
Rendering: Remove SCREEN_TEXTURE, DEPTH_TEXTURE, and NORMAL_ROUGHNESS_TEXTURE (GH-70967).
See the PR for details on the rationale and how to adapt your code. Note that there’s a helpful error in the shader editor telling you how to port code, but there’s a typo: filter_linear_mipmaps should be filter_linear_mipmap (no ‘s’).
Rendering: Decompress RA_AS_RG formats on Web platform in GLES3 renderer and disable texture swizzling (GH-71574).
Rendering: Remove light from dynamic light list when removing scenario (GH-71584).
Web: User FS (user://) now correctly uses project name (GH-71599).
Windows: Fix sub-window initial transparency and always-on-top state (GH-71660).
XR: Fix issue where failed start of OpenXR causes issues (GH-71450).
XR: Get OpenXR with OpenGL working on SteamVR (GH-71708).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-15/index.html b/article/dev-snapshot-godot-4-0-beta-15/index.html
index ec2899657f..0c508ef8b4 100644
--- a/article/dev-snapshot-godot-4-0-beta-15/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-15/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde25 January 2023
We’re getting dangerously close to the first Release Candidate for Godot 4.0, and focus on finalizing many of the remaining high priority issues. The beta snapshots cadence allows us to better measure the overall stability and quickly catch regressions, especially when a lot of features are worked on at the same time.
This beta includes quite a few big changes which may interest a lot of users:
Add support for Unicode identifiers in GDScript and Expression (GH-71676).
Support script global resource name in EditorFileSystem, making Quick Open work with custom resources (GH-71683, GH-71687).
Rework EditorPlugin editing logic, allowing multiple plugins to be active at the same time (GH-71770).
Auto-update instances of scenes which have been reimported (GH-57606).
Cleanup and unify keyboard input, adds new Key Label property for localized key mappings (GH-70052).
Add “dedicated server” export mode which can strip unneeded visual resources (GH-70377).
Fix some SpotLight3D issues (clustering artifacts, leaking light, AABB) (GH-71832).
Add AudioStreamPolyphonic to simplify sound playback from code (GH-71855, GH-71906).
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 14 (111 commits – excluding merge commits ― from 40 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
2D: Add a method to get global CanvasItem modulate (GH-70294).
Android: Update the logic to calculate the screen scale (GH-71836).
Audio: Add AudioStreamPolyphonic to simplify sound playback from code (GH-71855, GH-71906).
C#: Move LinearToDb and DbToLinear to Mathf (GH-71932).
Core: Add range iterator to LocalVector (GH-70773).
Editor: Add “Open in External Program” option (GH-68489).
Editor: Fix various gradient editor bugs (GH-70548).
Editor: Improve performance of imported file scan (GH-71441).
Editor: Support script global resource name in EditorFileSystem (GH-71683, GH-71687).
Makes EditorQuickOpen work with custom resources.
Editor: Add InputMap conversion to Project Converter (GH-71753).
Allows multiple plugins to be active at the same time.
GDScript: Add support for Unicode identifiers in GDScript and Expression (GH-71676).
GDScript: Remove function of continue for match statement (GH-71914).
This was conflicting with the use of continue in for and while loops. We intend to implement pattern guards for 4.1 which will allow this use case and a lot more. So we’re removing the continue fallthrough behavior now to avoid breaking compatibility in 4.1.
GDScript: Fix updating export variables when saving via LSP (GH-71781).
GUI: Clean-up, harmonize, and improve StyleBox API (GH-71686).
There are a few known regressions which we’ll aim to address in a later build (GH-71891, GH-71913).
GUI: Fix BiDi override for the characters outside BMP (e.g., emojis) (GH-71909).
Import: Update instances of scenes which have been reimported (GH-57606).
Input: Cleanup and unify keyboard input, adds new Key Label property for localized key mappings (GH-70052).
Given the scope of this change for all platforms, we expect some regressions, which will be fixed for beta 16. Some have already been reported, and possibly fixed: GH-72006, GH-72012, GH-72013, GH-72026.
iOS: Restore OpenGL ES 3.0 renderer support (GH-71848).
It is deprecated by Apple, but still works, so it’s exposed as an option.
Linux: Include headers for dynamically loaded libraries to simplify build dependencies (GH-71263).
Networking: Add “dedicated server” export mode which can strip unneeded visual resources (GH-70377).
Physics: Warn against using non-uniform scale for 3D physics (GH-67847).
Physics: Fix regression in collision detection for uniform scaling (GH-71707).
Rendering: Fix Vulkan validation errors related to enabling extensions (GH-70429).
Rendering: Fix DirectionalLight3D shadow opacity on Forward Mobile rendering backend (GH-71690).
Rendering: Use proper space for forward GI reflections (GH-71694).
Rendering: Add mutex when adding geometry instances to the dirty list in the Forward Clustered renderer (GH-71705).
Rendering: Sort decals and lights based on camera origin (GH-71709).
Rendering: Decrement texture_binding count when using screen textures (GH-71764).
Rendering: Assign light indices after sorting in OpenGL renderer (GH-71772).
Rendering: Stop incrementing light_count once max number of lights are reached in 2D canvas renderer (GH-71776).
Rendering: Allowed negative DoF blur transition in the editor (GH-71778).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-16/index.html b/article/dev-snapshot-godot-4-0-beta-16/index.html
index 4f7ae770a9..e1448876f5 100644
--- a/article/dev-snapshot-godot-4-0-beta-16/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-16/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde27 January 2023
We’re now just days away from the Release Candidate, working at full capacity on finalizing as many of the remaining high priority issues as we can. The beta snapshots cadence allows us to better measure the overall stability and quickly catch regressions, especially when a lot of features are worked on at the same time.
This beta includes quite a few big changes which may interest a lot of users:
Make AnimatedSprite’s playback API consistent with AnimationPlayer (GH-71907).
Disable OGG and MP3 looping by default on import (GH-71858).
Initial .NET 7 support (GH-71825), C# API renames to follow .NET naming conventions (GH-69547), and more! Still a lot of compatibility breaking changes as we harmonize the C# API with now mostly stabilized core API.
Add method picker to signal connect dialog (GH-66313).
Match RichTextLabel minimum size calculation with Label (proper content fitting) (GH-71330).
Handle mipmaps and VRAM compression for glTF binary images (GH-62499).
Flag dirty dependencies when GeometryInstance dependencies change in renderer (GH-71581).
Fix a handful of regressions from some of the bigger input and animation changes merged for beta 15.
In the last few betas, as we tie up some loose ends, you may have noticed an increase in last minute compatibility breaking changes. Those typically shouldn’t add instability to the engine, but may require doing some changes in your scripts, scenes, and shaders if you were using the affected APIs. At this stage, we’re trying to avoid unnecessary compat breakage, and focus on issues which cause user confusion and which can be solved with better naming or behavior of the APIs.
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is fromHalls of Torment, a roguelite action RPG with retro late-90s pre-rendered 2D graphics. It is developed by Chasing Carrots using Godot 4.0 beta, and you can wishlist it on Steam.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 15 (105 commits – excluding merge commits ― from 40 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
3D: Make SurfaceTool.generate_normals() behave consistently with smoothing groups (GH-68034).
Android: Fix Android editor crash when returning from the launched and running game (GH-72106).
Animation: Transition progress display in Animation State Machine Editor (GH-71284).
Animation: Make AnimatedSprite’s playback API consistent with AnimationPlayer (GH-71907).
Audio: Disable OGG and MP3 looping by default on import (GH-71858).
C#: Renames to follow .NET naming conventions (GH-69547).
These renames break compatibility and will likely affect most projects. Check the PR for details. We recommend deleting the res://.godot/mono/ folder before using this beta, to ensure that no older assemblies are used.
C#: Lookup signals and methods in Get method (GH-71356).
C#: Skip methods with pointer parameters (GH-71535).
C#: Add float and double overloads to Mathf (GH-71583).
C#: Restore Scale and Rotation properties (GH-71787).
GUI: Improve clarity of Tree’s activated/double-clicked signals (GH-70290).
GUI: Match RichTextLabel minimum size calculation with Label (proper content fitting) (GH-71330).
GUI: Remove size restrictions from StyleBoxTexture (GH-72124).
As a side-effect, projects that used StyleBoxTexture for controls that relied on the old center rect code, such as ScrollBars, will need readjustment. Now content margin properties are respected, just like in any other control, and you need to use those to give your stylebox a min size.
GUI: Fix char offset calculation when processing RichTextLabel line caches (GH-72149).
GUI: Fix LineEdit and TextEdit context menus not customizable (GH-72167).
Import: Handle mipmaps and VRAM compression for glTF binary images (GH-62499).
Import: Avoid nested skeletons, and handle skinned meshes with children (GH-72158).
Import: Make BoneAttachment3D and Skeleton3D names consistent (GH-72162).
Input: Make InputEventAction.as_text() return the text of the first valid event for the action (GH-67783).
Input: Make Input.get_vector() check for plain strength instead of the raw one (GH-69028).
Navigation: Rename Navigation uses of ‘location’ to ‘position’ (GH-69689).
Rendering: Flag dirty dependencies when GeometryInstance dependencies change in renderer (GH-71581).
Rendering: Add dependency tracker info on geometry create on mobile renderer (GH-72064).
Rendering: Fix LCD font AA on OpenGL renderer (GH-72125).
Rendering: Properly append global uniform buffer name in gl_compatibility shaders (GH-72138).
Shaders: Several shader preprocessor parser fixes and improvements (GH-72058).
Shaders: Add derivative functions with precision to shaders (GH-72109).
XR: Make screen texture and depth texture work in Multiview (GH-71455).
XR: Correctly apply world_scale in WebXR (Godot 4) (GH-71948).
Requires .NET SDK 6.0 or 7.0 installed in a standard location. .NET 7.0 support was just merged and requires testing, please report any issue you experience with either version.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-17/index.html b/article/dev-snapshot-godot-4-0-beta-17/index.html
index 6d821961b1..6da7a0d9ba 100644
--- a/article/dev-snapshot-godot-4-0-beta-17/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-17/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde1 February 2023
We’re now just days away from the Release Candidate, working at full capacity on finalizing as many of the remaining high priority issues as we can. The beta snapshots cadence allows us to better measure the overall stability and quickly catch regressions, especially when a lot of features are worked on at the same time.
This beta includes quite a few big changes which may interest a lot of users:
Rework how current Camera2D is determined (GH-65698).
Implement audio blending feature to AnimationTree (GH-72233).
Fix a couple dozen issues with GDScript typed arrays (GH-69248), and a lot more GDScript fixes, check the list below.
Refactor high quality texture import, enabling ASTC support (GH-72031).
Fix several shader preprocessor include issues (GH-72174).
In the last few betas, as we tie up some loose ends, you may have noticed an increase in last minute compatibility breaking changes. Those typically shouldn’t add instability to the engine, but may require doing some changes in your scripts, scenes, and shaders if you were using the affected APIs. At this stage, we’re trying to avoid unnecessary compat breakage, and focus on issues which cause user confusion and which can be solved with better naming or behavior of the APIs.
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is fromDrift, an upcoming co-op open world survival and crafting game, in space! It is developed in Godot 4.0 beta by KAR Games, and has a playable demo already on Steam.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 16 (159 commits – excluding merge commits ― from 58 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
2D: Rework how current Camera2D is determined (GH-65698).
2D: Rename TileData texture_offset and unclamp it (GH-72129).
2D: Improve TileSet 3-to-4 conversion, avoiding some data loss (GH-72186).
3D: Replace extents with size in VoxelGI, ReflectionProbe, FogVolume, Decal and GPUParticles*3D (GH-72075).
3D: Expose alpha antialiasing properties for Sprite3D/Label3D (GH-72441).
Requires .NET SDK 6.0 or 7.0 installed in a standard location. .NET 7.0 support was recently merged and requires testing, please report any issue you experience with either version.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-2/index.html b/article/dev-snapshot-godot-4-0-beta-2/index.html
index 6d91c91063..980b39a397 100644
--- a/article/dev-snapshot-godot-4-0-beta-2/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-2/index.html
@@ -15,7 +15,7 @@
XR improvements all around
Contributors in the XR area have been busy, and a lot of their work got merged these past two weeks!
While XR maintainer Bastiaan Olij (BastiaanOlij) was busy finalizing OpenXR hand tracking (GH-60313) and palm pose extension support (GH-66282), other contributors have been working magic:
Gergely Kis (kisg) and korompg implemented support for dynamically loading the OpenXR loader on Android (GH-65798). This makes it possible to load the Meta Quest OpenXR loader on Meta devices.
David Snopek (dsnopek) got WebXR minimally working again (GH-64514) using the WebGL 2 renderer implemented by Clay John (clayjohn).
konczg implemented the OpenXR passthrough extension wrapper (GH-65898).
And more!
And there’s a lot more, but I’m running out of time to describe it and I want to release this beta today :P so please read on and check the PRs referenced below for details.
One thing worth noting though: With the beta phase, we’re mostly done with feature implementation and we’re doing our best to preserve compatibility so that beta users can easily move to future betas and stable builds. That being said, there are still occasions where changing an API before committing to it for the whole 4.x lifetime is worth it (e.g. the File/FileAccess change above), so some minor porting from beta to beta might still be needed.
We’re trying to be reasonable with it and it shouldn’t take more than a few minutes each time, if and when there are compat breaking changes. We’re going to carefully apply the breaks compat label to PRs which do break compatibility from now on, so you can always review that list to see if any change impacts your projects. Here’s the list of breaks compat changes made between beta 1 and beta 2.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this beta 2 blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub for an overview of all changes since 4.0 beta 1 (236 commits – excluding merge commits ― from 67 contributors).
Some of the most notables feature changes in this update are:
Animation: Allow negative speed_scale in AnimatedSprite2D & 3D (GH-65148).
Buildsystem: Refactor handling of production flag and per-platform LTO defaults (GH-65745).
Requires .NET SDK 6.0 installed in a standard location.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Some noteworthy issues you might run into in this beta 2:
Exporting a Web build fails on Windows due to some file locking issue (GH-65660).
See the issue for a potential workaround.
Following GH-65541, the rendering/renderer/rendering_method.mobile project setting wrongly defaults to forward_plus, which means using the high-end forward+ rendering method on mobile. Change it to mobile if you want to export projects to Android or iOS.
LightmapGI and VoxelGI are reported to be broken in this beta (GH-66618, GH-66639).
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-3/index.html b/article/dev-snapshot-godot-4-0-beta-3/index.html
index 414350890a..9212dc1847 100644
--- a/article/dev-snapshot-godot-4-0-beta-3/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-3/index.html
@@ -7,7 +7,7 @@
Vitika Soni (Vitika9) reworked the features and user experience of Godot’s ColorPicker during Google Summer of Code 2022. The second part of her work has just been merged, and should significantly improve the ColorPicker’s UX. You can read more about it in the GSoC 2022 progress report. This implementation was based on wireframes contributed by Taylor Wright (redlamp).
Networking maintainer Fabio Alessandrelli (Faless) finalized a complete refactor of the WebSocket module, to modernize its API and re-evaluate some of the earlier design choices made for it. Note that this change breaks compatibility - it couldn’t be done in time for 4.0 beta 1, but the maintainers agreed that it was still worth changing now before the 4.0 release.
Our rendering contributors keep working on finalizing the implementation of all expected features for Godot 4.0, notably with the following major changes by Clay John (clayjohn) and Bastiaan Olij (BastiaanOlij):
Emulate double precision for regular rendering operation when REAL_T_IS_DOUBLE (GH-66178).
Default CanvasItem materials to use sRGB space for uniform colors (GH-66683).
Fix self reflection and roughness quality artifacts in SSR (GH-66756).
OpenGL3: Use a giant UBO to optimize performance in 2D (GH-66861).
OpenGL3: Add 2D lights to canvas renderer (GH-67335).
Buildsystem: Unify tools/target build type configuration (GH-66242)
This doesn’t affect most users directly, but for anyone compiling Godot from source, we’ve refactored the way we define what to build. Our SCons setup used to have tools and target options that were combined to build either the editor or the export templates, and define whether it’s a “release” or “debug” build. The “debug” term in that setup was quite ambiguous however and the source of a lot of confusion, as described in godot-proposals#3371.
So we refactored all this to have a single target option for the main three supported configurations which should be familiar to Godot users:
target=editor: Editor build, optimized, with debugging code
target=template_debug: Debug template, optimized, with debugging code
And for people doing engine development, there’s a new dev_build option which can be used together with target to enable dev-specific code and also affects a few presets. It’s still somewhat confusing, but better than it used to be - check the PR for details. We’ll soon have updated docs to clarify the new options and go in depth on all relevant customization options.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this beta 3 blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub for an overview of all changes since 4.0 beta 2 (274 commits – excluding merge commits ― from 88 contributors).
Some of the most notables feature changes in this update are:
2D: Add debug_color property to CollisionShape2D (GH-39072).
2D: Add rotation smoothing to Camera2D (GH-65776).
3D: Fix bug in CylinderMesh when computing normals (GH-67336).
Animation: Add animation slices for individual animations (GH-40274).
Buildsystem: Add serve and run SCons targets to test Web editor builds (GH-64886, GH-67325).
Buildsystem: Unify tools/target build type configuration (GH-66242).
If you compile Godot from source, be sure to read the description of that PR to know what changed.
Requires .NET SDK 6.0 installed in a standard location.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Some noteworthy issues in this beta:
Opening a project prints ERROR: Condition "font.is_null()" is true at: _shape (scene/gui/line_edit.cpp:2202). This is a harmless error which you can ignore (GH-67388).
2D rendering on Web exports seems to have regressed when implementing 2D lights in the OpenGL3 renderer (GH-67392).
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-4/index.html b/article/dev-snapshot-godot-4-0-beta-4/index.html
index 5839cc13e0..439d3d288c 100644
--- a/article/dev-snapshot-godot-4-0-beta-4/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-4/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde4 November 2022
We released Godot 4.0 beta 1 in September, and that was a big milestone on our journey to finalize our next major release – be sure to check out that blog post if you haven’t yet, for an overview of some of the main highlight of Godot 4.0.
But the “1” in beta 1 means that it’s only the first step of the journey, and like for the alpha phase, we’re going to release new beta snapshots roughly every other week.
We’re now at beta 4, slightly delayed as I was on holiday, but all the more interesting to try out. It adds less new features than previous beta snapshots did, but instead has more focus on bugfixing and stabilization, which should make it a much nicer experience than previous betas.
The illustration picture for this article is a screenshot ofGodot 4 Beginners, an Early Access interactive course for Godot 4, made with Godot 4, developed by Bramwell. You can check out a demo on itch.io, and follow Bram on YouTube and Twitter for updates and free video tutorials.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this beta 4 blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 3 (209 commits – excluding merge commits ― from 78 contributors).
Some of the most notables feature changes in this update are:
Android: Use proper types for converting Java float/double arrays (GH-67581).
2D: Make TileMap terrain painting not change neighbors centers bits (GH-67390).
C#: Reflection-less delegate callables and nested generic Godot collections (GH-67987).
Requires .NET SDK 6.0 installed in a standard location.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-5/index.html b/article/dev-snapshot-godot-4-0-beta-5/index.html
index daa8f0de6b..05569841ce 100644
--- a/article/dev-snapshot-godot-4-0-beta-5/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-5/index.html
@@ -7,7 +7,7 @@
Some of the most notable changes in this update include:
GDScript: Fix countless errors with inner class in GDScript compiler (GH-68374).
GUI: Implement SVG in OT support, enabling SVG emoji fonts (GH-64530).
Rendering: A ton of fixes for all rendering backends, and missing features implemented for the OpenGL3 one.
Web: The Web editor is now somewhat functional for the first time! It’s fairly slow and there are still a lot of issues to iron out, but you should be able to start it, edit a project and run it. It is not yet usable in production.
The illustration picture for this article is a screenshot ofObject Wars, an upcoming multiplayer third person shooter in a cute, homey environment where everyday objects fight it off in battle royale or team deathmatch. The game is developed by Vedg Studio / NoirosL and was recently ported to Godot 4.0 beta. Wishlist it on Steam!
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this beta 5 blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 4 (227 commits – excluding merge commits ― from 70 contributors).
Some of the most notables feature changes in this update are:
Android: Upgrade Android gradle plugin to version 7.2.1 (GH-68497).
C#: Add implicit conversion from arrays to Variant (GH-68092).
Core: Restore numeric from String constructors (GH-62814).
Core: Add support for empty delimiter in String.split() (GH-64321).
Core: Unexpose confusing String + int and int + String operations (GH-66361).
Core: Add call_deferred() method to Callable (GH-67730).
Requires .NET SDK 6.0 installed in a standard location.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-6/index.html b/article/dev-snapshot-godot-4-0-beta-6/index.html
index 7ab41502c1..73122b8df7 100644
--- a/article/dev-snapshot-godot-4-0-beta-6/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-6/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde23 November 2022
Godot 4.0 has been in beta for a little over two months, and the overall feature completeness, stability and usability have improved a lot during that time.
We’ve had beta snapshots every other week, and now we’ve decided to accelerate the cadence to release a new snapshot every week, to get even faster feedback on our bugfixes, and the potential regressions they may introduce.
This beta 6 includes a few big changes which may interest a lot of users:
GDScript cyclic reference issues begone! Or so we hope, with the amazing work done by Adam Scott in GH-66714. It has been tested thoroughly before merging, but the real trial starts now, with users trying out beta 6 on existing big GDScript codebases. Some regressions are to be expected, so please report any issue and mention differences in behavior between betas.
Lots of improvements to the Multiplayer features, and notably the editor tooling. With all this, Fabio expects this API to be feature complete, so please test the new features and report any issue!
Beta testers were starting to be vocal about the missing implementation of the Canvas Enviroment background mode, so Clay went ahead and fixed it! (GH-68805).
Tokage greatly optimized the animation blend tree process, which should give a nice performance boost on complex animations (GH-68593).
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is a screenshot of an island scene by HungryProton, made in Godot 4.0 beta with their Scatter addon. You can follow HungryProton on Twitter or Mastodon, and try out the Scatter addon for Godot 3.x or 4.0 beta.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this beta 6 blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 5 (105 commits – excluding merge commits ― from 46 contributors).
Some of the most notables feature changes in this update are:
Animation: Optimize animation blend tree process (GH-68593).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
Animation: AnimationTree forces properties to be at value in RESET track in UPDATE_DISCRETE and UPDATE_TRIGGER mode (GH-69066). Will be fixed by (GH-68993) in beta 7.
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-7/index.html b/article/dev-snapshot-godot-4-0-beta-7/index.html
index c098dc4b3f..50f708172d 100644
--- a/article/dev-snapshot-godot-4-0-beta-7/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-7/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde1 December 2022
Godot 4.0 has been in beta for over two months, and the overall feature completeness, stability and usability have improved a lot during that time.
We’ve had beta snapshots every other week, and now we’ve decided to accelerate the cadence to release a new snapshot every week, to get even faster feedback on our bugfixes, and the potential regressions they may introduce.
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is a screenshot ofDisinfection, a space horror game by indie duo Evil Turtle Productions which is currently being ported to Godot 4.0 beta. You can follow the developers on Twitter and Mastodon, and wishlist the game on Steam.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this beta 6 blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 6 (136 commits – excluding merge commits ― from 56 contributors).
Some of the most notables feature changes in this update are:
Android: Bump the minimum Android target API to 21 (Android Lollipop) (GH-67610).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-8/index.html b/article/dev-snapshot-godot-4-0-beta-8/index.html
index 8c24eac323..2c47e53659 100644
--- a/article/dev-snapshot-godot-4-0-beta-8/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-8/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde9 December 2022
Godot 4.0 has been in beta for over two months, and the overall feature completeness, stability and usability have improved a lot during that time.
We initially had beta snapshots every other week, and now we’ve decided to accelerate the cadence to release a new snapshot every week, to get even faster feedback on our bugfixes, and the potential regressions they may introduce.
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is a screenshot ofSandfire, an upcoming 3D person action-adventure game by Kmitt. The game was recently ported to Godot 4, see Kmitt’s YouTube channel and Twitter for devlogs and updates.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 7 (149 commits – excluding merge commits ― from 49 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
Animation: Add track validator to AnimationPlayerEditor to detect tracks which have error (GH-68770).
Animation: Refactor process of animation to retrive keys more exactly (GH-69336).
Animation: Remove UPDATE_TRIGGER mode from ValueTrack::UpdateMode & match behaviors between AnimationTree and AnimationPlayer (GH-69357).
C#: Fix signature of generated signal callbacks (GH-67023).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Some notable regressions in this build:
Moving/renaming resources cause unopened/unused tscn/res files to become corrupted (GH-69794).
OpenGL: Project crashes when there’s an OmniLight3D or a SpotLight3D in the scene, but not both (GH-69886).
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-0-beta-9/index.html b/article/dev-snapshot-godot-4-0-beta-9/index.html
index 002ce893ac..4ff8678910 100644
--- a/article/dev-snapshot-godot-4-0-beta-9/index.html
+++ b/article/dev-snapshot-godot-4-0-beta-9/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde19 December 2022
Godot 4.0 has been in beta for over three months, and the overall feature completeness, stability and usability have improved a lot during that time.
We continue to release a new snapshot every week to get fast feedback on our bugfixes, and potential regressions they may introduce. Thank you for your rigorous testing and timely reports!
This beta includes a few big changes which may interest a lot of users:
String and StringName are now mostly cross-compatible throughout the engine API, as well as in various GDScript-specific expressions and statements (GH-68747).
GDScript now fully supports out of order member resolution (GH-69471).
Every supported renderer option is now selectable from the project creation screen, which means you can create OpenGL 3 (“Compatibility”) projects without using the command line (GH-70028).
The OpenGL renderer now use an instanced array buffer instead of UBO for canvas item batching, increasing performance and compatibility on low-end devices, including Intel Macs (GH-70065).
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is from Raffaele Picca’s car scene, rendered in Godot 4.0 using the Movie Maker mode, for the main menu of the upcomingFRANZ FURYgame (made with Godot 3.x). Also check out Raffaele’sBeat Invadersreleased earlier this year.
What’s new
If you’re interested in an overview of what’s new in Godot 4.0 beta in general, have a look at the detailed release notes for 4.0 beta 1. In this blog post, we will only cover the main changes since the previous beta release.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 8 (178 commits – excluding merge commits ― from 63 contributors).
While we do our best to minimize compatibility breaking changes for existing beta users, there are still occasional changes in the API which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notables feature changes in this update are:
3D: Switch Mesh surface indexing to start at 0 so string name matches integer index (GH-70176).
Buildsystem: Rename float=64 SCons option to precision=double (GH-67399).
C#: Rename SignalInfo to Signal and make awaitable (GH-69968).
Core: Add feature tags to signify engine float precision (GH-69538).
Core: Handle corner cases for curve baking (GH-69726).
Core: Make VariantParser readahead optional, fixing scene corruption when renaming dependencies (GH-69961).
Editor: Add one-way indicator to tile collision editor (GH-67283).
Editor: Add open scene button in Inspector for PackedScene resource (GH-69938).
Editor: Add remote history to EditorUndoRedoManager (GH-69732).
Editor: Add gl_compatibility as an option to the project creation screen (GH-70028).
Editor: Fix autocomplete on functions returning variants (GH-69897).
GUI: Copy local theme overrides from Control to Window (GH-69353).
GUI: RichTextLabel: Add baseline inline alignment mode for objects and tables (GH-69776).
Import: Add a dialog for customizing FBX import (GH-59810).
Navigation: Enable assigning an owner to navigation regions and links (GH-66729).
Navigation: Rename some methods and properties in the API for consistency (GH-69331).
Note: This breaks compatibility intentionally, but we missed merging relevant transition code in this beta (GH-70244). If you have existing scenes and resources with navigation polygons and meshes, you might want to skip beta 9 and wait for beta 10 in a few days so that your scenes and resources are ported seamlessly.
Navigation: Mark navigation classes and nodes as experimental (GH-70230).
Physics: Fix 2D & 3D Continuous Collision Detection sometimes adjusting velocity too much (GH-69934).
Rendering: Detect and report if 2D particles use the screen SDF (GH-69735).
Rendering: Various fixes and documentation for CanvasGroup (GH-70003).
Rendering: Remove high quality glow as it is not any higher quality than regular glow (GH-70009).
Rendering: Implement render_target_was_used API so that Viewports can properly check if they have been used (GH-70132).
Rendering: OpenGL: Fix scene shader error when using Omni or Spot but not both (GH-69901).
Rendering: OpenGL: Use instanced array buffer instead of UBO for canvas item batching (GH-70065).
Requires .NET SDK 6.0 installed in a standard location. .NET 7.0 is not supported yet, so make sure to install .NET 6.0 specifically.
Known issues
As we are still in the early beta phase of development, there are still many issues to fix, some of which have already been reported and are being worked on. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release there are going to be compatibility breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-1-beta-1/index.html b/article/dev-snapshot-godot-4-1-beta-1/index.html
index bda5de60cd..14e5bf1b22 100644
--- a/article/dev-snapshot-godot-4-1-beta-1/index.html
+++ b/article/dev-snapshot-godot-4-1-beta-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov8 June 2023
The main focus of this release is gradual changes that polish user experience and stabilize features added in Godot 4.0. At the same time, engine contributors managed to implement quite a few exciting new tools, as well as majorly rework some of the existing systems to make creating games and apps with Godot even more convenient.
The beta testing stage is dedicated to fixing bugs and making sure that Godot 4.1 is ready for its formal release next month. As such, this is a great opportunity to put it to test and report any issues that you may find. Make sure to back up your projects before migrating to a new version of the engine, or use a version control system such as Git so you can easily restore if anything goes wrong.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about changes that come in Godot 4.1. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is fromHalls of Torment, a roguelite action RPG with retro aesthetics calling back to late-90s pre-rendered 2D graphics. It is developed by Chasing Carrots using Godot 4.0, and it just released in early access on Steam, so you can buy it right now! Congrats to the team for the overwhelmingly positive reception!
Highlights
A significant amount of work in every release goes towards resolving issues reported by the Godot community, and with such a huge release as had been Godot 4.0 there were many new reports. Together we addressed multiple problems with CSG (GH-74771, GH-76521), GDScript (GH-62830, GH-74842), Voxel GI (GH-76437, GH-76550), and platform support (GH-73878, GH-76040, GH-76399). Thanks to your feedback, as well as personal drive of several contributors, the editor also received a lot of polish. Many kinks in various workflows were ironed out (GH-47628, GH-70940, GH-74959), and even editor icons saw some love (GH-77376, GH-77492, GH-77652).
You may have noticed that some of these improvements have found their way into already published Godot 4.0.x releases. If you are not ready to update to 4.1 yet, we are committed to providing compatible fixes to Godot 4.0 as long as our capacity allows it.
This release is made possible thanks to 258 contributors who submitted over 1000 changes during this development cycle. You can review the complete list of changes since 4.1 dev 4 with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Read on for highlights in specific engine areas.
Core
Godot’s novel approach to building your games and apps revolves around hierarchies of nodes. Most everything about your project can be represented by a node or a composition of nodes. It stands to reason that the manipulation of a tree of nodes is a very common operation and as such it must be fast and efficient. In 4.1 Juan Linietsky dedicated time to rethink the node management and make it more performant in a wider variety of situations (GH-75627, GH-75701, GH-75760). While in some cases it may perform a little bit slower, in others operations take a fraction of time at a cost of a small increase in the memory usage.
Another core design aspect of Godot is its coordinate system. The engine uses -Z for the forward direction within its 3D environment, and this applies to both camera and models imported into the engine. By convention, 3D assets are usually created facing the camera, which means that they would appear rotated upon being imported into Godot. This introduces a big usability problem for anyone making 3D games in the engine, as some amount of boilerplate is required to use models in levels. After a long and nuanced discussion, Juan, Tokage, and Aaron Franke devised a solution that streamlines things without shattering the core of the engine:
Add an option to use model space with the look_at method and other similar methods (GH-76082).
Switch “front” and “back” camera views in the editor to be consistent with itself (GH-76052).
Fix a long-standing PathFollow issue with the forward direction (GH-72842).
Finally, Godot 4.1 brings back frame delta smoothing, first introduced in Godot 3.4 (GH-52314) by lawnjelly. You can read more about it in our 3.4 release blog post.
C#
The team of .NET contributors have mostly bridged the gap between C# and GDScript in Godot 4 in terms of feature parity. However, one glaring missing feature was global classes. In GDScript you can register any class as globally accessible with the class_name keyword, which, among other things, makes it appear in various parts of the editor UI. For example, you can create custom resources and instantiate them from the appropriately typed fields in the inspector dock. C# has lacked this functionality, but thanks to efforts from Raul Santos and Will Nations (as well as rigorous testing from many other contributors) this is no longer the case (GH-72619). You can get started with this new feature by reading the freshly updated documentation on global classes in Godot C#.
Another area of C# development that received attention during this release cycle is configurability. For example, Alex de la Mare provided an option for fine-grained disabling of source generators (GH-71049) and RedworkDE made include scripts customizable on the export preset level (GH-72896), where previously you would have a global project setting. In fact, this last feature comes with a positive change for anyone creating editor export plugins, as they now have a new API to define custom export options for users to supply (GH-72895).
Editor
Many developers have a multi-monitor setup and long have been requesting that the Godot editor supports such environments better. With the release of Godot 4.0 it became possible to create multi-window applications with Godot, and the editor itself acquired this feature as well. In Godot 4.1 we expand on this functionality and introduce the ability to detach code editors. Thanks to the Google Summer of Code 2022 project by trollodel both the script editor and the shader editor can now be removed from the main window and placed elsewhere in your desktop environment (GH-62378).
This is the latest addition to the arsenal of editor customization options available to Godot users. With such an adjustable interface it’s important that the configuration changes are persistent between launches. Which is why Hendrik Brucker and Tomasz Chabora worked on improving how editor state is maintained and stored (GH-72277, GH-74682, GH-75563). As a result of their work, launching Godot 4.1 you should much more often find yourself exactly where you’ve left off.
In Godot 4.0 contributors have introduced two new features related to exporting class properties to the inspector: typed arrays and the ability to export node types. Unfortunately, these two features didn’t play well together, so you might’ve found your excitement fading. Good news is, Tomasz and Timothe Bonhoure looked into the problems related to exported typed arrays and fixed their behavior (GH-73256, GH-76389). This work improves the robustness of the feature and, of course, finally allows you to export arrays of node types.
One editor area that received a lot of suggestions for improvement through years is project management. The current manager lacks many options for organizing your project list. While there are many approaches to improving this user interfaces, at the core of almost all of them lies some kind of tagging system. So this is where we’ve started, with Tomasz adding a system for assigning custom tags to your Godot projects (GH-75047).
GDExtension
For now the GDExtension system remains in a beta state, but the work to stabilize the API and expand its capabilities is very much active. David Snopek took the initiative to oversee the development and help the GDExtension system get to a stable state. Among his contributions, aside from time dedicated to review the work of others, is a big rework of the internal structure of the GDExtension interface (GH-76406). This rework allows extensions to provide information about their compatibility status, which engine and API version they support.
The API and ABI compatibility is one of the most challenging aspects of the GDExtension interface. Godot has a huge API surface which is versioned all together, with each stable release. Among supported API consumers, GDScript is the most tolerant one to modifications, being tightly integrated with the engine. Because of that it is very easy for contributors to overlook how their submissions may have negative effects on other API consumers, such as GDExtension. For Godot 4.1 the team had to devise a system for preserving ABI compatibility, and Juan Linietsky and RedworkDE worked on implementing and improving it (GH-76446, GH-76647). This work puts in place the necessary safeguards for maintainers to catch compatibility regressions and provide fallback methods.
The functionality of GDExtensions have also been improved. Yuri Rubinsky made it possible to define new visual shader nodes with extensions (GH-70911), while David implemented the framework for custom editor plugins (GH-77010). And if you register custom nodes with your extensions, you can now give them fitting individual icons thanks to a contribution from Yuri Sizov (GH-75472).
GDScript
After a big refactoring and a plethora of new features that GDScript received in Godot 4.0, it was time for polish and internal clean-up, squashing inconsistencies and bugs. One notable improvement to an existing feature comes from ocean who took a deep dive into the script documentation generation and emerged with a solid rework (GH-72095). Among other things, this rework significantly improves how enumeration types are treated in the generated documentation, making them proper named types.
Experienced Godot users have long noted that while GDScript supported static methods, it was impossible to preserve any sort of state from such methods due to lack of static class variables. In Godot 3 some developers devised tricks using the fact that a constant Dictionary is mutable or relied on object metadata to work around this limitation. Unfortunately, many such tricks became impossible in Godot 4 as a result of language improvements and bug fixes. The good news is that starting Godot 4.1, GDScript officially supports static class variables (GH-76264), enabling new programming patterns and bringing a much needed quality-of-life change, thanks to George Marques.
Multi-threading
A major goal of Godot 4 is the modernization of the engine core and engine’s systems — to serve as a foundation for many years of development and further improvements. With a decade of advancements in CPU core and thread count, it is essential for modern software to be able to utilize these available hardware resources. A strong multi-threading support allows developers to better scale their games, both single-player and multiplayer, and provide a smoother, more performant experience to their users.
Godot 4.1 is the first in a line of releases that are aiming to aid developers in that regard. Thanks to multiple contributions from Pedro J. Estébanez, a big chunk of multi-threading related issues have been addressed, bringing significant improvements to the WorkerThreadPool class (GH-76945, GH-76999) and threaded resource loading (GH-74405, GH-77143). In turn, Juan Linietsky kickstarted work on an exciting new feature — scene multi-threading (GH-75901). It’s still an experimental feature and will require additional work from all maintainers and contributors in Godot 4.2, 4.3, and further — to ensure thread safety and stability of all engine components. To be clear, we don’t recommend using scene multi-threading in existing projects just yet.
Navigation
The existing implementation of obstacle avoidance in Godot’s navigation has its limitations and is mainly suitable for very simplified scenarios. The reciprocal velocity obstacle (RVO) avoidance system only considers a flat plane that ignores the navigation mesh and cannot have defined logical layers akin to those of rendering and physics engines. This is where smix8’s navigation avoidance rework comes in (GH-69988). It boasts dedicated 2D and 3D RVO avoidance systems, a new static obstacle avoidance mechanism, a system of layers and masks for obstacles and agents, and better debug tools, among many other changes and fixes.
To help you get started with the navigation server smix8 has prepared an updated documentation for both 2D and 3D navigation.
Rendering
In April we published a list of rendering priorities for Godot 4.1 and future 4.x releases. As expected, many of these tasks were not finished in time to be included in 4.1, but they will remain priorities for the 4.2 dev cycle and beyond if necessary. We spent more time than expected on bug fixing and investigating performance issues, but we are still quite happy with what we accomplished. One of the more notable improvements in this release is the newly implemented Vulkan pipeline cache (GH-76348) by Alexander Streng. While Godot already cached shaders to reduce shader compilation stutter, compiling pipelines still lead to some stuttering and slower load times. While the pipeline compilation stuttering issue is far from solved, this represents a step in the right direction and should also lead to a slight decrease in load times when using one of the RenderingDevice-based rendering backends.
Particles are another part of the visual tech behind the engine that has received a lot of attention in this release. The particle turbulence system originally introduced in 4.0 has been reworked to better empower technical artists to create impressive and beautiful dynamic effects (GH-64606, GH-77154). It took a bit of deliberation and time, but KdotJPG and Raffaele Picca were able to get everything just right and the team cannot wait to see your upcoming creations!
To help even more with setting up the atmosphere of your 3D scenes, contributors Clay John, Johan, and Patrick implemented new and fixed existing shader built-ins (GH-71364, GH-76109, GH-76290). Last but not least, Lasuch and Clay worked on the new 3D noise texture (GH-76486, GH-76557) which can be used to add more depth to your volumetric fog or to affect the behavior of 3D particles. Quite the first contribution to the engine for Lasuch!
Downloads
The downloads for this dev snapshot can be found directly on our repository:
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.1 milestone.
Windows users with an AMD GPU might find the OpenGL renderer crashing, notably affecting the project manager which defaults to OpenGL (GH-77760). The regression was introduced in 4.1 dev 4 and was fixed shortly after the beta 1 release, so it will be solved in the upcoming beta 2 build. As a workaround, you can force opening the project manager with Vulkan using Godot_v4.1-beta1_win64.exe --rendering-driver vulkan on the command line.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-1-beta-2/index.html b/article/dev-snapshot-godot-4-1-beta-2/index.html
index 09e2de50db..c5b9e8f050 100644
--- a/article/dev-snapshot-godot-4-1-beta-2/index.html
+++ b/article/dev-snapshot-godot-4-1-beta-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde14 June 2023
Continuing on our planned schedule for Godot 4.1, we’re advancing through the beta phase and getting ready for a stable release in early July. The feature freeze happened in late May, and we had a first beta release last week. If you missed them, have a look at the 4.1 beta 1 release notes for a great write-up by Yuri on what’s new in this milestone.
For this beta 2 build specifically, we’ve outlined a number of relevant changes below. Some key highlights you might want to pay particular attention to:
Core: Let user scripts disable thread safety checks (GH-78000).
The thread guards added in 4.1 may have unexpected effects on your own usage of Threads if you know that you’re not breaking thread safety. This new option lets you tell Godot “I know what I’m doing” and disable the thread guards for a given thread.
GDExtension: Standardize Object ptrcall encoding on Object ** (GH-77410).
This change was necessary to fix a number of crashes, but it breaks compatibility with Godot 4.0’s GDExtension API in a way that we cannot easily work around. This was evaluated as a necessary tradeoff to make GDExtension usable in production, but it means that you will need to keep separate branches or add your own compatibility code for Godot 4.0 and Godot 4.1+ GDExtension interfaces if you want to support both.
GDScript: Sort code autocompletion with rules (GH-75746).
The way sorting worked for code completion in 4.0 was quite unpredictable in many situations, ranking less pertinent results higher than perfect matches. This has been heavily reworked and should now perform much closer to what you would expect.
GUI: Ensure that controls update all their sizing information when required (GH-78009).
We’d like to have more user testing of this change on GUI heavy projects, to ensure that we’re not introducing regressions.
Input: Fix just pressed and released with short presses (GH-77055).
Have a look at the PR and make sure it behaves like you’d expect :)
Shaders: Fix shader uniform storage conversions and crash (GH-74937).
This fixed a bazillion issues with shader uniforms, so be sure to report if anything regressed, or if it actually fixed some issue you reported in the past.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about changes that come in Godot 4.1. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is showingBeehave(GitHub), an addon for Godot 3.x and 4.x that enables you to create robust AI systems using behavior trees. It is developed by bitbrain, who also makes Godot tutorials on YouTube, as well as developing a Dwarven RPG with Godot 4. Follow them on Twitter, Mastodon or join his Discord.
What’s new
50 contributors made 130 changes for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
Here are some of the main changes you might be interested in:
2D: Fix crash when opening a TileSet with invalid tiles (GH-78165).
3D: Store lock view rotation whether its on or off (GH-76372).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.1 milestone.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-1-beta-3/index.html b/article/dev-snapshot-godot-4-1-beta-3/index.html
index 16a0a0cdf5..f772f201b1 100644
--- a/article/dev-snapshot-godot-4-1-beta-3/index.html
+++ b/article/dev-snapshot-godot-4-1-beta-3/index.html
@@ -6,7 +6,7 @@
Yuri Sizov21 June 2023
An important part of the new release schedule for Godot is the change in mentality. Instead of working towards “the one true” release, such as has been the case with Godot 4.0, we aim to bring incremental changes to the engine at regular intervals. Godot 4.1 builds on top of the foundation created by the previous release, and we are getting confident in its current state.
This means that 4.1 beta 3 is likely to be the final beta release of this cycle, and the first release candidate is soon to follow. Please make sure to give these builds a good test. If you find an issue that affects your work, please give one of the previous releases a try as well, and Godot 4.0.3 too for good measure. Engine contributors are after regressions at this point, so testing your case with multiple releases ensures that what you’re experiencing is new and thus critical. Don’t hesitate to open bug reports in any case, every bit helps!
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is fromThe Adventures of Mouth Man, an action-packed 3D platformer made by Retrocade Media and friends in just one week for the Pursuing Pixels Game Jam. If you are a fan of quirky retro-looking games, you can check it out for free on itch.io. And you can follow Ashton on Twitter if you want to learn more about his projects.
What’s new
74 contributors submitted around 150 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
Here are some of the main changes you might be interested in:
2D: Consider all triangles for retention in Delaunay triangulation (GH-78368).
2D: Tilemaps: Fix crashes when painting a large area in a tilemap (GH-76548).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.1 milestone.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 beta 3).
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-1-dev-1/index.html b/article/dev-snapshot-godot-4-1-dev-1/index.html
index 1b084f7432..781fa415d0 100644
--- a/article/dev-snapshot-godot-4-1-dev-1/index.html
+++ b/article/dev-snapshot-godot-4-1-dev-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov21 April 2023
As we have announced earlier this week Godot development is ramping up and you can expect Godot Engine 4.1 to be stable before mid-Summer this year. Right now we are in the middle of the feature merging phase, with the main focus being on improving usability, performance, and the feature set of the engine based on your feedback and our prioritized plans.
Many of you have told us how you enjoyed regular preview builds of the engine during the later stages of the Godot 4.0 development. And we have enjoyed getting quick responses, reports of new issues and regressions, and opinions about recently implemented features. So we are going to continue this practice going forward, and to start things off today we’re releasing the first dev snapshot of Godot 4.1.
Unlike our previous release cycles, 4.1-dev builds are an official part of the process, and you will receive new versions regularly leading up to the beginning of the testing phase and the first beta. Beware that these builds are not guaranteed to be stable or bug-free and may contain features that have only been lightly tested. Make sure to back up your work or, better yet, to use a version control system.
That’s enough for the introduction! Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about included changes.
The illustration picture for this article is fromAether’s Edge, a scenic open world game by Ancient Stone Studios currently being developed with Godot 4. Follow them on Twitter for updates and more beautiful work-in-progress screenshots and clips.
What’s new
We now have a great interactive changelog you can use to review all 500 or so changes since Godot 4.0 more extensively, with convenient links to the relevant PRs on GitHub.
Here are some of the main changes you might be interested in:
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 dev 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-1-dev-2/index.html b/article/dev-snapshot-godot-4-1-dev-2/index.html
index 11fb81ce42..7ce08cb409 100644
--- a/article/dev-snapshot-godot-4-1-dev-2/index.html
+++ b/article/dev-snapshot-godot-4-1-dev-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde10 May 2023
A lot of work is also being done to improve the Android editor port. We just created a separate Play Store release for the Godot 4.1 dev snapshots, so that interested users can test it easily and provide us with feedback and automated reports on potential issues. You can join the testing group here to get access.
The illustration picture for this article is fromSpring Dash, a momentum-packed parkour platformer by Dillon Steyl, which was just ported to Godot 4. You can wishlist it on Steam, and find a demo on Dillon’s Discord (find all links here).
What’s new
We now have a great interactive changelog you can use to review all 150 or so changes since the previous dev snapshot more extensively, with convenient links to the relevant PRs on GitHub.
Here are some of the main changes you might be interested in:
2D: Add proper snapping to tile polygon editor (GH-70488).
2D: Tilemaps: Add method to fetch the layer for a given body (GH-76246).
2D: Improve reliability of 2D shape editor redrawing (GH-76492).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 dev 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-1-dev-3/index.html b/article/dev-snapshot-godot-4-1-dev-3/index.html
index 929fe589d2..f250b851bf 100644
--- a/article/dev-snapshot-godot-4-1-dev-3/index.html
+++ b/article/dev-snapshot-godot-4-1-dev-3/index.html
@@ -6,7 +6,7 @@
Yuri Sizov25 May 2023
The development of Godot 4.1 is coming to the end of the feature merging phase, and we expect to enter feature freeze very soon. That means that contributors are putting finishing touches on every enhancement that is going to make it into the final release, and so once again we need you to help us test these improvements.
This dev snapshot comes with a bouquet of fixes, optimizations, and usability tweaks. Among those there are several changes that can be of interest to many:
We introduce an option to use model space for the look_at method, and other similar methods. It has been a long standing problem that by convention many models are sculpted facing the camera, which conflicts with Godot’s coordinate system design. As a result, trying to use methods like look_at with such models causes them to face forward with their backs and not their fronts. To address that problem and other related issues the following changes have been made:
Add an option to use model space with look_at and similar (GH-76082).
Switch “front” and “back” camera views in the editor to be consistent with itself (GH-76052).
Fix a long-standing PathFollow issue with the forward direction (GH-72842).
The frame delta smoothing feature, first introduced in Godot 3.4, has been finally ported to Godot 4 (GH-52314).
We continue to improve Godot’s multi-threaded behavior and fix bugs from the recent changes. Such improvements include multiple fixes to multi-threaded resource loading (GH-74405, GH-77143), multiple fixes to the WorkerThreadPool class (GH-76945, GH-76999), and an early version of the multi-threaded node processing (GH-75901). Thread safety of many engine and editor types has been improved, though this work is still ongoing and will continue into Godot 4.2.
This release also includes one of the most anticipated editor usability features — the ability to detach script and shader editors into their own window (GH-62378). Please give us your feedback on the look and feel of this new tool in your productivity belt!
GDExtension contributors made many improvements and changes, including a rework of the GDExtension interface (GH-76406) and a new backwards compatibility system (GH-76446).
The navigation avoidance system has been completely reworked (GH-69988). This massive change affects both 2D and 3D navigation, and closes a good chunk of related issues and proposals. Check out the linked PR for a lot more details and demos.
For the technical artists this release comes with a rework of the turbulence system for particles, making it easier to create impressive and beautiful dynamic effects (GH-77154).
That’s quite a lot for one dev release, isn’t it? Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about included changes.
We created a separate Play Store release for the Godot 4.1 dev snapshots, so that interested users can test it easily and provide us with feedback and automated reports on potential issues. You can join the testing group here to get access.
The illustration picture for this article is fromLiminal Tower, an experimental project by lowraiz being developed in Godot 4. It has liminal spaces, portals, and it works in VR! You can follow lowraiz on Twitter for more work-in-progress screenshots and clips, and other experiments.
What’s new
We now have a great interactive changelog you can use to review all 200 or so changes since the previous dev snapshot more extensively, with convenient links to the relevant PRs on GitHub.
Here are some of the main changes you might be interested in:
2D: Make tile atlas merge dialog use filter nearest (GH-77385).
3D: Fix PathFollow direction and add Z forward option (GH-72842).
3D: Fix 3D viewport front/rear axis and “Focus” button (GH-76052).
3D: Add the ability to look-at in model-space (GH-76082).
3D: Fix CSGPolygon3D in path mode disappearing at runtime (GH-77118).
Animation: Add TRANS_SPRING mode to Tween (GH-76899).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.1 milestone. Of note:
ExtResource IDs in existing scenes might change when using this build, causing some diffs for your version control. It’s not clear yet whether it’s an intentional, one off change to the id system, or a regression that would be fixed in a future build (GH-77172).
During the import process you may see a lot of the “Attempting to parent and popup a dialog that already has a parent” messages. This error has no effect on the importing process and should be fixed in the next build (GH-77426).
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 dev 3).
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-1-dev-4/index.html b/article/dev-snapshot-godot-4-1-dev-4/index.html
index f37f6a034a..f5877d1856 100644
--- a/article/dev-snapshot-godot-4-1-dev-4/index.html
+++ b/article/dev-snapshot-godot-4-1-dev-4/index.html
@@ -6,7 +6,7 @@
Yuri Sizov1 June 2023
With the release of Godot 4.1 dev 4 we are closing the feature merging phase, and the project enters a “feature freeze”. This means that the next official build is going to be the first beta of 4.1, and starting with that release we are only going to be focusing on bug fixes and documentation improvements.
We’ve been very happy with how the outlined release schedule has been coming to live, and we think that after 3 months of development Godot 4.1 is turning out to be a significant improvement to 4.0. If you have a chance, please give this and the following pre-release builds a test. With your help, we hope to iron out remaining bugs and publish the stable version in early July.
The feature freeze starts now, but before that Godot contributors have managed to finalize a few more highly requested and important features. So what are they?
C# developers among you will be happy to learn that our .NET framework now supports global classes. It’s an analog to GDScript’s class_name feature, which registers a class with the engine and the editor for advanced integration. For example, with global classes you will finally be able to utilize C#-powered custom resources within the editor UI. Please see the implementing PR to learn how this feature can be used (GH-72619).
Many active Godot users long have voiced their need for better project organization options in the project manager. While there are multiple ways in which we can improve the UI to help with that, at the core of many of them lies some sort of tagging system. So this is where we’ve started, adding a system for assigning custom tags to your Godot projects (GH-75047). Make sure to give us your feedback on the usability of this new feature and feel free to open proposals regarding possible improvements to it!
While GDExtension API allows for a low-level access and extension of the engine and its capabilities, it previously lacked a way to register new editor plugins. This has now been implemented (GH-77010), so you can create efficient and fast plugins in any language that is available to you.
We created a separate Play Store release for the Godot 4.1 dev snapshots, so that interested users can test it easily and provide us with feedback and automated reports on potential issues. You can join the testing group here to get access.
The illustration picture for this article is fromMagic Football World, a turn-based football game by DD - Dinh Quang Dung where you build and manage a team of fantastical creatures. The original 2D version of the game was build with Godot 3, but multiple improvements to the 3D workflow in Godot 4 convinced them to increase the number of dimensions and the version of the engine. Follow DD on Twitter for more updates and work-in-progress screenshots, and download the original game from Google Play or itch.io.
What’s new
57 contributors made over 100 changes for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
Here are some of the main changes you might be interested in:
2D: Add “Center View” button to 2D editor (GH-57252).
Core: Fix grayscale alpha for Image::convertFORMAT_L8 using REC.709 (GH-77456).
Core: Expose method to set a project setting as internal (GH-77668).
Editor: Remove constrained view in the 2D editor (GH-47628).
Editor: Add an editor option to copy system info to clipboard (GH-65902).
If you are reporting engine bugs, consider using this option, as it extracts a lot of useful information for contributors who are going to look into your report.
Editor: Get rid of mouse wheel switch in scene tabs (GH-70800).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.1 milestone.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 dev 4).
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-beta-1/index.html b/article/dev-snapshot-godot-4-2-beta-1/index.html
index e8a17bf5a2..9a429dfe11 100644
--- a/article/dev-snapshot-godot-4-2-beta-1/index.html
+++ b/article/dev-snapshot-godot-4-2-beta-1/index.html
@@ -15,7 +15,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 beta 1).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-beta-2/index.html b/article/dev-snapshot-godot-4-2-beta-2/index.html
index 5b2102ca59..5eaf311caa 100644
--- a/article/dev-snapshot-godot-4-2-beta-2/index.html
+++ b/article/dev-snapshot-godot-4-2-beta-2/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
The previous beta 1 introduced a change to the mesh format which you might experience as some nagging warnings and slowdowns when opening a 3D project. To solve it, you need to resave all meshes to commit the changes (GH-83287). We’re working on improving that UX so it’s done automatically (GH-83613).
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 beta 2).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-beta-3/index.html b/article/dev-snapshot-godot-4-2-beta-3/index.html
index 34c6979a8d..9acdbca1f3 100644
--- a/article/dev-snapshot-godot-4-2-beta-3/index.html
+++ b/article/dev-snapshot-godot-4-2-beta-3/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
.NET 8.0 should also be supported, but keep in mind this version of the .NET SDK is still in preview. Give it a try and let us know if you find any bugs.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 beta 3).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-beta-4/index.html b/article/dev-snapshot-godot-4-2-beta-4/index.html
index 0d2fcd7e5e..bce5e39e27 100644
--- a/article/dev-snapshot-godot-4-2-beta-4/index.html
+++ b/article/dev-snapshot-godot-4-2-beta-4/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
.NET 8.0 should also be supported, but keep in mind this version of the .NET SDK is still in preview. Give it a try and let us know if you find any bugs.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 beta 4).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-beta-5/index.html b/article/dev-snapshot-godot-4-2-beta-5/index.html
index 2742bde0f8..4919bfdf0f 100644
--- a/article/dev-snapshot-godot-4-2-beta-5/index.html
+++ b/article/dev-snapshot-godot-4-2-beta-5/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
.NET 8.0 should also be supported, but keep in mind this version of the .NET SDK is still in preview. Give it a try and let us know if you find any bugs.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 beta 5).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-beta-6/index.html b/article/dev-snapshot-godot-4-2-beta-6/index.html
index f1d14abff8..f8ce4c356d 100644
--- a/article/dev-snapshot-godot-4-2-beta-6/index.html
+++ b/article/dev-snapshot-godot-4-2-beta-6/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
.NET 8.0 should also be supported, but keep in mind this version of the .NET SDK is still in preview. Give it a try and let us know if you find any bugs.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
We’re currently tracking issues that we consider release blockers very closely. The main remaining ones that we’re aware of are below:
Following GH-84657, the .NET-enabled Godot editor seems to get stuck on exit (GH-84728). We’re working on solving this for the next build.
If you use both Godot 4.1 and 4.2 as self-contained with separate caches, you may run into this edge case: GH-84732. Deleting the .godot folder and doing a clean import with Godot 4.2 should work around this problem.
If you run into any other showstopper while testing this beta, please make sure that it’s reported and reproducible, and let us know if you think we may have missed prioritizing it.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this beta).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-dev-1/index.html b/article/dev-snapshot-godot-4-2-dev-1/index.html
index 7b06523030..48e40f8419 100644
--- a/article/dev-snapshot-godot-4-2-dev-1/index.html
+++ b/article/dev-snapshot-godot-4-2-dev-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov19 July 2023
Two weeks ago we wrapped up the development of Godot 4.1, bringing more polish and stability to the Godot 4 series, and just two days ago we shipped its first maintenance release, addressing some of the more urgent issues that slipped in. In preparation for both of these releases we temporarily put aside many improvements to ensure stability and to avoid any last minute regressions.
Today, we are ready to share these improvements with you with 4.2 dev 1 being available for public testing (you can read about the most notable changes below). This first development snapshot marks the proper start of the new development cycle, which means in the coming weeks we will be quickly merging many changes as contributors implement new features and fix long-standing bugs. You should expect a dev snapshot every 1 or 2 weeks, depending on how stable the development branch is after any given series of merges.
Please note that dev 1 includes many changes that just barely missed being included in 4.1, so expect it to be a little bit more feature packed than normal dev builds.
Keep in mind that while we try to make sure each dev snapshot is stable enough for general testing, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is fromTerrain3D— an editor plugin for 3D terrain sculpting and painting, created by Roope Palmroos (Outobugi Games) and Cory Petkovsek (Tokisan Games). This is an essential tool for any open world 3D game, and it’s made from the ground up for Godot 4. The project is in alpha, but stable enough for public testing — so download it now from GitHub! Also follow Roope (Twitter, YouTube) and Cory (Twitter, YouTube) on social for more updates on their ongoing projects, built with Terrain3D.
What’s new
83 contributors submitted over 200 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Some of the changes present in this release are also available in Godot 4.1.1.
Below are the most notable changes compared to 4.1.1-stable:
Porting: macOS: Fix uncapped frame rate for windows in the non-active workspaces (GH-79572).
Rendering: Draw frustum splices on top of direction shadow atlas for debug purposes (GH-77085).
Rendering: Split raster barrier into vertex and fragment barrier (GH-77420).
This change currently breaks compatibility by modifying some of the values for the BarrierMask enumeration. If you don’t rely on the values of BarrierMask, no modifications are necessary.
Rendering: Replace sampler arrays with constant sampler elements (GH-77740).
Rendering: Use Gaussian approximation for backbuffer mipmaps in GL Compatibility renderer (GH-78168).
Shaders: Add DEPTH to the visual shader output (for spatial mode) (GH-73691).
Shaders: Allow more hint types for uniform arrays (GH-79100).
Shaders: Add autocomplete for filter/repeat hints on uniform arrays (GH-79402).
Thirdparty: Fix ZIPReader failing to open empty zip files (GH-73310).
Standard build includes support for GDScript and GDExtension.
.NET 6 build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 dev 1).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-dev-2/index.html b/article/dev-snapshot-godot-4-2-dev-2/index.html
index e50cd390a9..c9c0b472d2 100644
--- a/article/dev-snapshot-godot-4-2-dev-2/index.html
+++ b/article/dev-snapshot-godot-4-2-dev-2/index.html
@@ -6,7 +6,7 @@
Yuri Sizov28 July 2023
These final days of July mark the end of the first month of the Godot 4.2 development cycle, and things are starting to pick up steam. With Godot contributors having had a few weeks to agree on, work on, review, and approve some of the new features, bigger changes are starting to appear in the upcoming dev snapshots.
As always, we try to offer a mix of smaller improvements, bug fixes, and bigger features for the Godot community to test and provide feedback. Here are some of the highlights in 4.2 dev2, with a bigger list available below:
The tilemaps system and the tilemaps editor are going through an internal rework, aimed at creating a foundation for the most requested improvements (GH-78328). The work will continue and you should see more user-facing changes in the upcoming builds. In the meantime a menagerie of workflow enhancements has been added, both in a form of improved tooling (GH-79512, GH-79899) and more UI hints (GH-79676, GH-79904).
In the core area of the engine, maintainers have worked on addressing some design limitations. With these changes included you should no longer experience crashes when trying to change scenes on the fly (GH-78988) or when renaming nodes during the ready step (GH-78706).
You can now interact with and extend the OpenXR API through GDExtension (GH-68259)! Support for another previously missing feature, indexed properties, has also been added (GH-79763).
The script debugger now comes with full support for threaded code (GH-76582), including the execution stack and breakpoints. This is something that has been requested since Godot 3 days, and now with better multithreading support of Godot 4 it is finally possible to debug extra threads.
This release also includes a security fix, previously disclosed in the 4.0.4 RC1 blog post. If your project uses ENetMultiplayerPeer or the low-level ENetConnection, there is a potential denial of service attack that utilizes a flaw in the ENet library. We strongly recommend updating to this version once it is released as stable. Be sure to test the build right now to prepare and have a smooth transition. Thanks to Facundo Fernández for reporting this vulnerability. A patch has been submitted to the upstream ENet repository as well.
On the rendering side of things there is a constant influx of fixes and improvements to both Vulkan and GLES backends. Of top of that, this release introduces the ability to create custom texture objects, which should be very useful to people dabbling in compute shaders (GH-79288). You can see how it works in practice with this soon-to-be merged compute texture demo.
Keep in mind that while we try to make sure each dev snapshot is stable enough for general testing, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article showcases aVR system for ship design visualization,created by Dan Silden (Mastodon, Twitter). Modelled with Blender and brought to live with Godot 4’s XR capabilities, it provides Dan with a reusable solution for demonstrating future design project. While the project is not public, you can see a bit more of it in action in this great video on Dan’s ArtStation page.
What’s new
63 contributors submitted over 120 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Below are the most notable changes compared to 4.2-dev1:
2D: Allow using floating-point bone sizes and outline widths in the 2D editor (GH-79434).
2D: Tilemaps: Add option to expand tile polygon editors (GH-79512).
2D: Tilemaps: Add placeholder items to TileSet layer list (GH-79676).
Standard build includes support for GDScript and GDExtension.
.NET 6 build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 dev 2).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-dev-3/index.html b/article/dev-snapshot-godot-4-2-dev-3/index.html
index bd16de878d..7f0ac520bb 100644
--- a/article/dev-snapshot-godot-4-2-dev-3/index.html
+++ b/article/dev-snapshot-godot-4-2-dev-3/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde11 August 2023
Development is well under way for our next milestone, Godot 4.2. After our dev 2 snapshot, we kept merging new features and important bug fixes, and gathered quite a number of them — so now we’re ready for the third dev snapshot to put those under broader user testing. It’s been around a month since we started this release cycle, with roughly two months to go until 4.2 beta 1, and then another month to reach stable in early November 2023.
I’d like to outline the amazing work done by the Production team, and especially by Yuri Sizov, who took care of PR reviews, merges, and the whole release process while I was on holiday in the second half of July. Godot 4.1.1, the first two dev snapshots for 4.2, and 4.0.4 — all were fully handled by Yuri. While I used to be the only one responsible for making and publishing releases, we’re now fully sharing the role of release manager. That should enable us to keep this sustained pace with a high quality standard.
Back to today’s development snapshot, here are some of the highlights of 4.2 dev 3, with a bigger list available below:
Initial support for C# on Android has been merged (GH-73257)! It’s still a work in progress, with caveats outlined in the PR, and we haven’t had time to look into what it takes to provide official Android export templates for the .NET build. So at this time you’ll have to try compiling templates from source and provide feedback on what works and what doesn’t.
The long-awaited 2D HDR rendering is now implemented (GH-80215). This makes it possible to use 3D effects such as glow in 2D games, and can be used to substantially improve quality of 2D rendering at the cost of performance. Use the rendering/viewport/hdr_2d project setting to enable HDR in 2D. Note: this setting only has an effect when using the Forward+ or Mobile rendering methods.
More rendering goodies have been merged, such as ShaderRD compilation groups (GH-79606), the ability to call code on the render thread (GH-79696), and performance fixes around depth prepass (GH-80070).
A lot of work is happening behind the scene around Viewport mouse handling, starting with GH-67791 and numerous follow-ups for platform-specific adjustments. You may expect some instability while we take note of and iron out the consequence of these changes, so be sure to report any crash or improper mouse/GUI behavior in this build.
A very popular feature proposal was implemented to improve the editing of box collision shapes (GH-71092), allowing to extend the box size one face at a time.
Alongside bugfixing, some optimization work is being done on GDScript, starting with operators (GH-79990).
Keep in mind that while we try to make sure each dev snapshot is stable enough for general testing, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article showcasesEasy Charts, an open source addon for plotting general purpose charts, compatible with Godot 3.x and 4.x. It is developed by Nicolò Santilio (GitHub, Twitter, Mastodon), and can be installed from the Asset Library.
What’s new
75 contributors submitted over 190 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Below are the most notable changes compared to 4.2-dev2:
Standard build includes support for GDScript and GDExtension.
.NET 6 build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 dev 3).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-dev-4/index.html b/article/dev-snapshot-godot-4-2-dev-4/index.html
index bbe65563b1..5ffd8dca04 100644
--- a/article/dev-snapshot-godot-4-2-dev-4/index.html
+++ b/article/dev-snapshot-godot-4-2-dev-4/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde5 September 2023
We’re making great progress in the development branch for Godot 4.2! The faster paced release cycle we started following after the 4.0 release seems to be working well, with pull requests being opened, reviewed, and merged at a steady rate. This fourth dev snapshot contains nearly 250 PRs merged in a little over 3 weeks since the dev 3 snapshot.
The overall state of the master branch seems pretty good and on track for reaching the beta stage at the start of October, and stable in early November 2023.
This snapshot brings a lot of goodies! Here are some of the highlights, with a bigger list available below:
The initial support for C# on Android merged for dev 3 (GH-73257) is now ready for mass testing! Official export templates are provided in the .NET (“Mono”) build, so you can start exporting your C# projects to Android and give us feedback on what works and what doesn’t. Keep in mind that this feature requires using .NET 7.0 as the target framework, which you can set in the .csproj file with <TargetFramework>net7.0</TargetFramework>. It’s still a work in progress, with caveats outlined in the PR. Notably, we already know that it’s not working on the arm32 architecture.
A number of rendering bugfixes and improvements were merged for this snapshot, including:
Motion vectors for skeletons/blend shapes and particles (GH-80618 and GH-80688). This is the last bit of work necessary before we implement AMD’s FSR 2.2 into Godot. On that note, there is already a PR for FSR 2.2 support (GH-81197), so please test it out and give us your feedback.
Fixing a crash caused by having more than 204 Lights/Decals/ReflectionProbes in a scene at once (GH-80845). This bug stopped users from fully flexing the strength of the Forward+ renderer as it limited users to a combined 204 OmniLight3Ds/SpotLight3Ds/Decals/ReflectionProbes (by default). Now users are free to use up to 512 of each in the default configuration (this limit can be increased).
Additionally, rendering contributors have been busy removing barriers and preparing to implement more items from the list of rendering priorities.
A solution was finally merged (GH-80859) for an infamous input bug affecting the typical input action combinations used for character movement (e.g. WASD + D-Pad). We’re expecting potential regressions (and already found one, with a pending fix as GH-81170), so please test it thoroughly and report any issue.
GDScript got a number of bug fixes, but also new features such as static typing for for loop variables (GH-80247), improved documentation generation (GH-80745), and the possibility to use local constants (e.g. preloaded scripts) as type hints (GH-80964).
Initial work was merged to improve the developer experience with GDExtension on Windows, by copying DLLs to a temporary location before opening them (GH-80188). This makes it possible to overwrite the original DLL (e.g. by compiling a new version) without running into Windows file locking conflicts. This paves the way to implementing live reloading of GDExtension, for which a PR is currently open and ready for testing (GH-80284).
The editor got a lot of usability improvements, such as custom color support for project folders in the FileSystem dock (GH-80440), and improvements to the signals connection dock (GH-80411, GH-81092).
On the import side, support was merged for the KTX image format so that we can use Basis Universal for GLTF (GH-76572).
A project setting was added to define the content scale stretch modes, implementing the long-requested integer scaling out of the box (GH-75784).
Keep in mind that while we try to make sure each dev snapshot is stable enough for general testing, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article showcasesAssetPlacer, a level design plugin by CookieBadger. It is developed in C# and supports Godot 4.0 and 4.1 at the time of writing. You can get it on itch.io and browse the documentation.
What’s new
100 contributors submitted over 250 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Below are the most notable changes compared to 4.2-dev3:
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location. To export to Android, .NET 7.0 is required, and should be set as the target framework in the .csproj file.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 dev 4).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-dev-5/index.html b/article/dev-snapshot-godot-4-2-dev-5/index.html
index de2f2a0c19..32109dbcfe 100644
--- a/article/dev-snapshot-godot-4-2-dev-5/index.html
+++ b/article/dev-snapshot-godot-4-2-dev-5/index.html
@@ -6,7 +6,7 @@
Yuri Sizov19 September 2023
We are entering the final stretch of the feature development for this dev cycle. There is probably one more Godot 4.2 dev snapshot left before the project enters the feature freeze and all efforts turn towards fixing remaining bugs and stabilizing the release. In the past 2 months contributors have been shaping what Godot 4.2 is going to be, and we will soon pass the mark of 1000 changes.
A significant part of this snapshot contains changes aimed at improving the user experience throughout the editor. We are also introducing a new version of the Godot Android plugin API. As always, many bugs and crashes have been squashed and other issues resolved. Here’s a short highlights section, ahead of a more complete list below:
The 3D viewport received a de-cluttering and will now display auxiliary visual information only for selected objects (GH-75303). At the same time elements like decals and fog volumes now have extra indicators which make them easier to select via the viewport (GH-81554). Various parts of the inspector and signal docks were enhanced with documentation tooltips and related bugfixes (GH-81221). Code region support was added to the code editor, allowing you to define parts of the script to fold them and help with navigation within longer scripts (GH-74843). And if you are working on editor plugins, you can now preview the current editor theme on your GUI elements directly in the 2D viewport (GH-81130).
Two very important issues related to tilemaps and the tilemap editor were addressed for this release. You can now flip and rotate tiles and entire tile patterns when placing them in the world (GH-80144). A significant boost to performance, thanks to smart tile grouping and other optimizations, should make larger tilemaps considerably less laggy (GH-81070).
Godot aims to be as version-control-friendly as possible, and contributors are well aware of several issues related to sporadic resource ID changes. In this snapshot we’re shipping one of the fixes that aims to address the issue (GH-65011). Related to this, multiple problems with renamed and moved files causing crashes and scene corruption have been fixed (GH-80503, GH-81657).
A new version of the Godot Android plugin framework is introduced in this release (GH-80740, GH-81368). Please make sure to test these changes and provide feedback to our Android platform maintainers who want to ensure a smooth migration process. You can refer to this draft documentation PR for more information about the changes and new requirements.
Speaking of Android, this release adds Android Stylus pressure and tilt support (GH-80644). This complements Apple Pencil support added in Godot 4.0.
If you’re relying on GraphEdit in your games and tools, you will be happy to know that this snapshot concludes the main part of the refactoring of the node (GH-79307, GH-79308, GH-79311). Please make sure to give it a test and see if everything is working as expected. For the time being the comment node feature has been removed — to be reintroduced later as a dedicated node with improved behavior together with other nodes. Until the feature freeze there may still be smaller compatibility breaking changes, so make sure to read future release notes.
Keep in mind that while we try to make sure each dev snapshot is stable enough for general testing, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is taken fromStarter Kit 3D Platformer, a template project made by Kenney for Godot 4. Kenney is a one-man powerhouse producing game assets, tools, and template projects like this one, and sharing them for free. Kenney’s assets come in all popular formats, so even if something is not made for Godot specifically you can still import it and kickstart your fun gamedev adventure by focusing on the gameplay and what makes your game interesting and unique! You can follow Kenney on social networks (Twitter, Mastodon) to get updates on and help shape new asset packs. And please consider sponsoring his work which benefits everyone in the gamedev community!
What’s new
68 contributors submitted almost 200 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Below are the most notable changes compared to 4.2-dev4:
2D: Add per-tile flipping and transposing (GH-80144).
2D: Improve TileMap performances by using quadrants only for rendering (GH-81070).
2D: Allow configuring primary guide line X/Ys separately (GH-81255).
3D: Show visual-oriented 3D node gizmos only when selected (GH-75303).
3D: Add helper for 3D gizmos and unify box (GH-80278).
3D: GridMap: Ensure the visibility is updated when entering the tree (GH-81106).
3D: Fix some keys triggering their actions twice in GridMap (GH-81531).
3D: Add 3D editor gizmo icons for Decal, LightmapProbe and FogVolume (GH-81554).
Animation: Fix animation keyframes being skipped when played backwards (GH-81452).
Animation: Remove animation tracks with correct indices (GH-81651).
AssetLib: Improve handling of archives when installing assets (GH-81358).
Audio: Add a bus_renamed AudioServer signal (GH-81641).
Buildsystem: Fix build options configuration for Visual Studio projects (GH-79238).
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location. To export to Android, .NET 7.0 is required, and should be set as the target framework in the .csproj file. .NET 8.0 is not supported yet.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 dev 5).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-2-dev-6/index.html b/article/dev-snapshot-godot-4-2-dev-6/index.html
index e22f39959d..013f072fd9 100644
--- a/article/dev-snapshot-godot-4-2-dev-6/index.html
+++ b/article/dev-snapshot-godot-4-2-dev-6/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde3 October 2023
This is the final dev snapshot for 4.2, signaling the end of the feature development cycle, and the start of the beta phase. We spent the past couple of weeks wrapping up many of the big feature PRs which had been in development for the past few weeks and months. We still have a handful that the production team is keeping tabs on, but we’ll soon declare the full feature freeze for 4.2 and get ready for the first beta snapshot. But don’t wait for the beta to try what’s new in 4.2 – there are tons of amazing new features in this dev snapshot which require testing and user feedback, so we can iron out the main issues before the stable release.
Here’s a selection of some of the biggest changes since our previous 4.2 dev 5 build, ahead of a more complete list below:
The rendering contributors have outdone themselves this cycle, and a lot of their work has been merged for this snapshot:
AMD’s FSR 2.2 has been implemented as a new upscaling option in the project settings. Have fun testing it and let us know how it goes :)
An optional ANGLE-backed OpenGL renderer was added for macOS and Windows (GH-72831). ANGLE is a compatibility layer for OpenGL on top of Metal and Direct3D 11, which allows us to work around the deprecated and unmaintained OpenGL drivers on macOS, and similarly outdated OpenGL drivers on Windows for some older integrated chipsets. This should increase the portability of Godot games on lower end devices.
Talking about the OpenGL Compatibility renderer, one of its main missing features, 3D shadows, has now been implemented (GH-77496)!
For lightmapping, we replaced the extremely bulky and slow OIDN denoiser with a lightweight and much faster JNLM denoiser compute shader (GH-81659). Differences in denoising quality are likely to show up with the JNLM approach, sometimes for better or worse. While it lacks an AI component, it can leverage the albedo and normal information to fix errors that were impossible to address with OIDN. Please try it out and let us know if you’re happy with the results. If there’s demand for it, we might re-introduce OIDN as an option, using it as a standalone command line tool instead of building it together with Godot. With the built-in OIDN removed, editor binaries are now approximately 4-5 MB smaller.
We also forward-ported the OpenXR foveated rendering support from Godot 3.x (GH-80881).
Glow behavior has been optimized to be closer to the high quality mode we had in Godot 3.x (GH-82353).
On the animation front, AnimationPlayer and AnimationTree APIs have been partially unified via a common AnimationMixer base class, solving a number of issues in the process (GH-80813).
The C# integration received a number of improvements, both in the bindings (GH-81101, GH-81783), language interoperability (GH-67304), backward compatibility (GH-80527), and editor UX (GH-80260).
The GDExtension team has been wrapping up their feature work, notably with the long awaited support for hot reloading extensions in the editor (GH-80284), as well as an option to include the class reference in the extension API JSON (GH-82331).
After some fixes in previous snapshots, the Web platform should now support loading dynamic libraries, i.e. GDExtension support! The latest fix was just merged (GH-82633) and still needs user testing, so please let us know if you can compile a GDExtension for the Web and load it successfully in your Godot project.
GDScript also got a number of new features, such as raw string literals (GH-74995), pattern guards for match statements (GH-80085), and a new --lsp-port command line argument that will be useful for authors of LSP plugins to support both Godot 3.x and 4.x, as well as multiple editor instances.
Lots of improvements in the editor, such as an overhaul of the Gradient editor (GH-71915), the ability to select where to install the assets that you’re downloading from the Asset Library (GH-81620), and various fixes to the script editor and FileSystem docks, among others.
After a massive performance improvement to TileMap quadrants in the previous snapshot (GH-81070), the Y-sort performance now got a significant increase (GH-73813).
2D navigation mesh baking was added (GH-80796), including support for TileMaps (GH-82465).
Visual shaders got some nice improvements with the addition of drop-down list properties to custom nodes (GH-81688), and output ports for vector types are now expandable by default (GH-82088).
Keep in mind that while we try to make sure each dev snapshot is stable enough for general testing, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture shows the ‘Restaurant Bits’ asset pack byKay Lousberga.k.a. KayKit, imported in Godot 4. Kay recently uploaded many of their CC0-licensed asset packs to Godot’s Asset Library, so you can download them in a click, and all the GLTF and OBJ models work out of the box with their textures and animations. See this tweet/toot for a demo of how to install and use one of these asset packs. You can follow Kay on Twitter or Mastodon, and support their work on Patreon.
What’s new
108 contributors submitted 220 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Below are the most notable changes compared to 4.2-dev5:
2D: Greatly improve Y-sort performance on TileMaps (GH-73813).
2D: Add is_conformal method to Basis and Transform2D (GH-79523).
3D: Fix Curve3D baking up vectors for nontrivial curves (GH-81885).
3D: Make 3D editor gizmos and debug shapes ignore fog (GH-82413).
Animation: Implement AnimationMixer as a base class of AnimationPlayer and AnimationTree (GH-80813).
Animation: Fix BoneAttachment3D signal connection (GH-81695).
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location. To export to Android, .NET 7.0 is required, and should be set as the target framework in the .csproj file. .NET 8.0 is not supported yet.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in 4.2 dev 6).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-beta-1/index.html b/article/dev-snapshot-godot-4-3-beta-1/index.html
index 01b808738f..287985e667 100644
--- a/article/dev-snapshot-godot-4-3-beta-1/index.html
+++ b/article/dev-snapshot-godot-4-3-beta-1/index.html
@@ -14,7 +14,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or later (.NET 8.0 recommended) installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
During the beta stage, we focus on solving both regressions (i.e. something that worked in a previous release is now broken) and significant new bugs introduced by new features. You can have a look at our current list of regressions and significant issues which we aim to address before releasing 4.3. This list is dynamic and will be updated if we discover new showstopping issues after more users start testing the beta snapshots.
With every release, we accept that there are going to be various issues which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-beta-2/index.html b/article/dev-snapshot-godot-4-3-beta-2/index.html
index 076cd5f4d6..890bc6d052 100644
--- a/article/dev-snapshot-godot-4-3-beta-2/index.html
+++ b/article/dev-snapshot-godot-4-3-beta-2/index.html
@@ -12,7 +12,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or later (.NET 8.0 recommended) installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
During the beta stage, we focus on solving both regressions (i.e. something that worked in a previous release is now broken) and significant new bugs introduced by new features. You can have a look at our current list of regressions and significant issues which we aim to address before releasing 4.3. This list is dynamic and will be updated if we discover new showstopping issues after more users start testing the beta snapshots.
With every release, we accept that there are going to be various issues which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-beta-3/index.html b/article/dev-snapshot-godot-4-3-beta-3/index.html
index 9fb84b840e..d815fe27ce 100644
--- a/article/dev-snapshot-godot-4-3-beta-3/index.html
+++ b/article/dev-snapshot-godot-4-3-beta-3/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or later (.NET 8.0 recommended) installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
During the beta stage, we focus on solving both regressions (i.e. something that worked in a previous release is now broken) and significant new bugs introduced by new features. You can have a look at our current list of regressions and significant issues which we aim to address before releasing 4.3. This list is dynamic and will be updated if we discover new showstopping issues after more users start testing the beta snapshots.
With every release, we accept that there are going to be various issues which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-dev-1/index.html b/article/dev-snapshot-godot-4-3-dev-1/index.html
index d420c5e743..b772afcbd2 100644
--- a/article/dev-snapshot-godot-4-3-dev-1/index.html
+++ b/article/dev-snapshot-godot-4-3-dev-1/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-dev-2/index.html b/article/dev-snapshot-godot-4-3-dev-2/index.html
index a60dc4a696..bf7a322f48 100644
--- a/article/dev-snapshot-godot-4-3-dev-2/index.html
+++ b/article/dev-snapshot-godot-4-3-dev-2/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-dev-3/index.html b/article/dev-snapshot-godot-4-3-dev-3/index.html
index 41cd6b83fe..67852f0eff 100644
--- a/article/dev-snapshot-godot-4-3-dev-3/index.html
+++ b/article/dev-snapshot-godot-4-3-dev-3/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-dev-4/index.html b/article/dev-snapshot-godot-4-3-dev-4/index.html
index 6cd8c82589..f686615cc2 100644
--- a/article/dev-snapshot-godot-4-3-dev-4/index.html
+++ b/article/dev-snapshot-godot-4-3-dev-4/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or later (.NET 8.0 recommended) installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-dev-5/index.html b/article/dev-snapshot-godot-4-3-dev-5/index.html
index 1ad0b0f9a1..ea86304fc3 100644
--- a/article/dev-snapshot-godot-4-3-dev-5/index.html
+++ b/article/dev-snapshot-godot-4-3-dev-5/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or later (.NET 8.0 recommended) installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-3-dev-6/index.html b/article/dev-snapshot-godot-4-3-dev-6/index.html
index 3a7e5d6c83..950bbc1803 100644
--- a/article/dev-snapshot-godot-4-3-dev-6/index.html
+++ b/article/dev-snapshot-godot-4-3-dev-6/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or later (.NET 8.0 recommended) installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-4-dev-1/index.html b/article/dev-snapshot-godot-4-4-dev-1/index.html
index a5cf6eee9d..b81a3b82c6 100644
--- a/article/dev-snapshot-godot-4-4-dev-1/index.html
+++ b/article/dev-snapshot-godot-4-4-dev-1/index.html
@@ -39,7 +39,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-4-dev-2/index.html b/article/dev-snapshot-godot-4-4-dev-2/index.html
index 8e5c651607..429a555873 100644
--- a/article/dev-snapshot-godot-4-4-dev-2/index.html
+++ b/article/dev-snapshot-godot-4-4-dev-2/index.html
@@ -16,7 +16,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
Typed dictionaries: Different typed keys/values are wrongly allowed when using the [] operator (GH-96772). A fix is already in the pipeline for the next dev snapshot.
Windows: Detecting newly added assets (GH-96828), export variables (GH-96810), and the last modification dates for projects (GH-96812) is not working in this snapshot, due to a toolchain bug exposed by a recent FileAccess change on Windows. This was already fixed by GH-74830.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-4-dev-3/index.html b/article/dev-snapshot-godot-4-4-dev-3/index.html
index 31534111ec..3e3f2cb8ae 100644
--- a/article/dev-snapshot-godot-4-4-dev-3/index.html
+++ b/article/dev-snapshot-godot-4-4-dev-3/index.html
@@ -71,7 +71,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
“Attempting to use an uninitialized RID” error is printed when opening the editor (GH-97694). This is a harmless error, and should have no noticeable impact on your project.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-4-dev-4/index.html b/article/dev-snapshot-godot-4-4-dev-4/index.html
index dc7574c5c3..f550862545 100644
--- a/article/dev-snapshot-godot-4-4-dev-4/index.html
+++ b/article/dev-snapshot-godot-4-4-dev-4/index.html
@@ -48,7 +48,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-4-dev-5/index.html b/article/dev-snapshot-godot-4-4-dev-5/index.html
index b5b2f9e538..5f8d04294d 100644
--- a/article/dev-snapshot-godot-4-4-dev-5/index.html
+++ b/article/dev-snapshot-godot-4-4-dev-5/index.html
@@ -18,7 +18,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/dev-snapshot-godot-4-4-dev-6/index.html b/article/dev-snapshot-godot-4-4-dev-6/index.html
index 0c4257a887..b10f6726fc 100644
--- a/article/dev-snapshot-godot-4-4-dev-6/index.html
+++ b/article/dev-snapshot-godot-4-4-dev-6/index.html
@@ -16,7 +16,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Here are some known regressions introduced in this snapshot:
Occlusion culling randomly occluding things completely in the open (GH-10032).
A pull request is already open to fix this in the next dev snapshot (GH-100060).
Error “Manifold creation from mesh failed” with Plane and Quad shapes, which do not get rendered (GH-100014).
Planes and Quads cannot be used with CSG, and just seemed to be usable previously. We’ll improve the usability so they cannot be selected for CSGMesh3D. Instead, use MeshInstance3D to place Planes and Quads.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/development-fund-perks/index.html b/article/development-fund-perks/index.html
index e956051a51..147ca251c6 100644
--- a/article/development-fund-perks/index.html
+++ b/article/development-fund-perks/index.html
@@ -8,7 +8,7 @@
Not ready to become a member yet?
While this won’t give you a fancy badge or role, we have recently added the option for one-time donations. With this update, we also switched to Stripe as our payment provider to offer the option to donate via credit card in addition to PayPal.
For those of you that have been with the project for a long time already, you might remember our Patreon. In case you haven’t already, we encourage you to move your donation over to this self-hosted solution, as we receive more of your contributions here without the provider fees. Nonetheless, the page will stay up for the time being and also connect to the Discord mentioned above.
Thank you for ensuring that we can keep developing the Godot Engine!
-
+
\ No newline at end of file
diff --git a/article/dlscript-here/index.html b/article/dlscript-here/index.html
index 08b9119586..e1cfdfc1d2 100644
--- a/article/dlscript-here/index.html
+++ b/article/dlscript-here/index.html
@@ -66,7 +66,7 @@
If you’re interested, message me (karroffel) on IRC or Discord.
Thanks for reading this and happy waiting for Godot!
-
+
\ No newline at end of file
diff --git a/article/donation-changes/index.html b/article/donation-changes/index.html
index 8ddf5dce59..f832ec74f3 100644
--- a/article/donation-changes/index.html
+++ b/article/donation-changes/index.html
@@ -8,7 +8,7 @@
rocess.
Corporate sponsoring categories will change as follows:
$500 - Silver Sponsor: Small logo on homepage and name + URL in Godot’s About dialog
$1500 - Gold Sponsor (outside Patreon, min. 6 months invoice): Small logo (icon size) on splash screen, medium logo on homepage
$3000 - Platinum Sponsor (outside Patreon, min. 6 months invoice): Logo + name on splash screen (like now), big logo on homepage
Combined funding sources
We constantly get requests to use alternative funding sources to Patreon and to show our total donation/grant income combined on the Godot website. This requires a significant amount of work and it will be among our priorities when we can hire someone to do this website work (let’s hope soon) - in the meantime, Rémi will put together a simple overview and update it regularly to provide more transparency on our budget and current hires.
We’ll work on a visualization that properly reflects the different natures of our funding sources, such as one-time grants which provide us for funds for a limited amount of time. Our policy is to always stay cash flow positive (i.e. we get more donation income than we use) - with a few exceptions for occasional project-specific temporary contracts - so this visualization should reflect it.
Thank you!
Finally, thanks so much to all of you, current, former, and future patrons, for your amazing support. When we joined Patreon three years ago, we never imagined reaching such a high level of funding in support of such a rapidly growing project!
Godot is developed by more than a thousand contributors, and coordinating this massive community requires a full-time involvement of several of us (and hopefully soon even more full-timers), which your generosity enables.
-
+
\ No newline at end of file
diff --git a/article/dtls-report-1/index.html b/article/dtls-report-1/index.html
index 2518198229..2a3da3023b 100644
--- a/article/dtls-report-1/index.html
+++ b/article/dtls-report-1/index.html
@@ -11,7 +11,7 @@
Simply call take_connection() when is_connection_available() is true to get the connected PacketPeerUDP.
DTLSServer
As mentioned, the DTLSServer class is used to store the DTLS state. DTLS must use a thing called cookies, to avoid amplification attacks.
In simple terms, for the way UDP works, anyone can send you UDP packets (without the need for a connection), and since one can fake its source (by spoofing, i.e. altering the source filed in the IP protocol), one can force a server to send the reply of the received packet to a different address than the original sender. This is very bad when a protocol has the reply message which is much bigger than the original packet, as this will allow a simple client with low bandwidth to amplify their bandwidth capabilities by exploiting the server.
Imagine this:
A has limited bandwidth of 1 Mb/s.
A sends a spoofed packet (masquerading as B) to the server Z (which has a bandwidth of 100Mb/s).
The server Z sends the reply to B, but the reply is much bigger (e.g. 10 times bigger) than the data sent by A.
Thus A can, with its 1 Mb/s, force server Z to flood B of packets with a 10 Mb/s bandwidth (1 Mb/s from A times 10 for the reply size).
To avoid this, DTLS uses cookies. When the client sends data for the first time to the server, the server will reply with a smaller packet that assigns it a cookie (e.g. a random number) and stores the cookie/client association in a state.
Only when the clients sends their requests with the received cookie, will the server start to send bigger packets.
This way, when A sends the spoofed packet, it will not receive the cookie (which B will receive instead) and will not be able to amplify its bandwidth exploiting Z (since the cookie packet is smaller than the packet sent by A).
If this seems a bit confusing, it’s because it’s actually a pretty twisted kind of attack. But you don’t have to worry about it, because the DTLSServer class does the job for you :)
This class has 2 interesting methods: setup, to generate the state (and where you set the RSA key and certificate), and take_connection that accepts a connected PacketPeerUDP (from UDPServer) and will return a PacketPeerDTLS in the “connecting” state when the cookie is correct, or in the “error” state when the cookie is missing or not known.
PacketPeerDLTS
PacketPeerDTLS is the core class of the whole DTLS implementation in Godot, the one that provides access to the actual data transfer functionalities.
There are two ways of getting a working PacketPeerDLTS:
Use DTLSServer as explained above.
Call connect_to_host on a PacketPeerUDP and then pass it to the PacketPeerDTLS.connect_to_peer.
Remember to call PacketPeerDTLS.poll frequently, and at some point it will reach the “connected” state. At that point, you can start transfer data and it will be automatically encrypted.
Consideration, further work
First of all, I’m sorry it took me so long to publish this report. It has been a crazy few months between the upcoming 3.2 release, the Godot Sprint, GodotCon, and the nerd flu that got us there.
I had stopped working on this feature to focus on improvements and fixes for 3.2 but I will get on it again in the coming month (November) working on the integration with NetworkedMultiplayerENet so that the high level multiplayer can benefit from this technology.
Stay tuned for more on DTLS, and for the report on September/October work (some merged already, some still in the process of being merged).
I will try to speed up my reporting capabilities ;-)
-
+
\ No newline at end of file
diff --git a/article/editor-improvements-godot-40/index.html b/article/editor-improvements-godot-40/index.html
index aff14be350..8a6bf7e7f2 100644
--- a/article/editor-improvements-godot-40/index.html
+++ b/article/editor-improvements-godot-40/index.html
@@ -5,7 +5,7 @@
Juan Linietsky29 March 2021
This article is from March 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.
If you are following me on Twitter (where I post my progress on different Godot features I work on), you might have noticed that I took a two month break from rendering to work on many long standing editor improvements and features.
While I am far from being the only contributor working on editor-related tasks, I put together a list of everything I have been working for the past two months!
Improved Subresource Editing
With the new inspector in Godot 3.1, a lot of new possibilities opened, including the ability to open sub-resources in the same inspector tab. Before this, users had to go back and forth in the list of properties of each sub-resource, which was very confusing.
The new inspector worked well, but on the visual side we never really managed to nail how to deal with sub-resources. After asking the community for help and ideas, some work as put into it which hugely improved usability.
The final version does a bit less color shifting by default so it’s a bit more homogeneous. Also, the new layout makes it much clearer where each subresource begins and ends.
Improved and reorganized Project Settings
The Project Settings dialog has seen a makeover. The categories have been reorganized to make more sense and reduce bloat and a new “advanced” mode has been introduced.
This new mode removes most project settings other than the basic ones to ensure that new users don’t feel overwhelmed by the huge amount of options and flexibility and can learn their way through the most important customization options available.
Once confident enough, the “advanced” tab is set, which allows for editing of the rest of the settings as well as the extra customization options.
Once enabled, the “advanced” setting is remembered for the current project.
Improved Process/Pause mode
While not entirely an editor feature, Godot 4.0 unifies the process and pause settings into a single menu. This allows for disabling of nodes in a tree fashion. This was one of the most user-requested features, as Godot allows for easily hiding nodes but not disabling them.
Additionally, as can be seen above the scene tree editor will show the disabled nodes in a more grayed out fashion.
Preview Sun and Sky
Another very requested feature was also implemented, which is the ability to have a preview light and preview sun in the 3D editor. The new dialog was created mainly with two goals:
Allow to have a quick frame of reference regarding to lighting when importing or editing 3D scenes stand-alone.
Give new Godot users the ability to visualize their assets with a default set of high quality settings, as it is always a common source of confusion that, when just imported, assets look too plain in Godot.
As these settings are only meant for preview, they won’t be visible when running the game but both have a quick way to create the actual nodes based on these settings with just a button press at the bottom.
When either nodes (DirectionalLight3D or WorldEnvironment) exist in a scene, the preview setting also disables automatically, ensuring consistency and ease of use.
Default Importer Settings
Another common problem Godot users run into is that setting default values for certain types of imported assets was confusing. This is resolved by the new “Default Importer Settings” tab in the Project Settings dialog.
Thew new tab allows to precisely customize importer options for each type of resource. This feature was also back-ported to Godot 3 and will be available on the upcoming Godot 3.3 release.
New 3D asset import workflow
Importing 3D assets was a hit or miss experience in Godot. Import options were limited to a tiny “Import” menu that attempted to do too much and fell short.
The new importer has an “Advanced” mode, which allows to precisely customize every individual node, mesh, material and animation.
Additionally, handling of external assets was re-thought. In Godot 3.x, assets are simply saved to file by name, which can be very confusing or create chaotic situations when overwriting files.
In the new importer, this process is done via manual steps, so the user has more control on which assets are moved to external files, which paths are used, etc.
As a result, it’s more obvious where everything goes and what’s happening during the import process.
The new system also solves the problem of assigning external materials to replace the ones in the imported file in a very elegant way, allowing to either make the materials that come with the asset external, or just replace them by existing external ones.
Ability to “keep” files
Often, users would prefer that Godot does not import some files (like PNG, CSV, etc) and deal with them manually during the game run-time.
This is now possible with the “keep” option. When selected, the assets will be kept and put in the game export “as-is”.
Threaded importing
Another very common problem users face in Godot is the long time it takes to import large amounts of images. To aid this, the new importer has been reworked to operate using multiple threads.
This results in a performance improvement of over ten times (if you have a modern computer with multiple cores).
Future
With the editor work done, I will now go back to working on rendering for the next month to finalize the missing bits and pieces pending in my TODO list. Afterwards, it will be time to start working towards our first Godot 4.0 alpha! And again, remember we do this out of love for you and the game development community so you can have the best possible engine we can make with the same freedom as if you made it yourself.
-
+
\ No newline at end of file
diff --git a/article/emulating-double-precision-gpu-render-large-worlds/index.html b/article/emulating-double-precision-gpu-render-large-worlds/index.html
index cf2328ea77..bc7e7a17b3 100644
--- a/article/emulating-double-precision-gpu-render-large-worlds/index.html
+++ b/article/emulating-double-precision-gpu-render-large-worlds/index.html
@@ -13,7 +13,7 @@
Are we done?
Yes, this is the solution we settled on and we are happy with the tradeoffs we ended up with. This solution should work on all our supported hardware and should only reduce performance by a small amount. However, there are a couple limitations:
It doesn’t work with the skip_vertex_transform render mode: In other words, users have to use the default path where Godot handles your model to view space transformation,
Users can’t do shader math in world space: User shaders will still be limited by single-precision floating point, so world space calculations will still be subject to low-precision artifacts,
This only applies to precision issues from object positions. In other words, it won’t fix your earth-sized sphere, for model vertex positions, you still need to work around single-precision floating point limitations.
Overall, we are quite happy with how this solution turned out. We think it is the closest to “just works” that we can get.
Note: This change has already been merged into the engine, however it is only available in the “doubles” version of the engine, so to take advantage of it, you will still have to build the engine yourself using the compile flag precision=double (formerly float=64).
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.
-
+
\ No newline at end of file
diff --git a/article/enet-dtls-encryption/index.html b/article/enet-dtls-encryption/index.html
index c22322cb0c..07e2c7482b 100644
--- a/article/enet-dtls-encryption/index.html
+++ b/article/enet-dtls-encryption/index.html
@@ -75,7 +75,7 @@
Here you can see a screenshot of the result of sending an RPC with and without DTLS enabled:
-
+
\ No newline at end of file
diff --git a/article/enjin-coin-supports-godot-and-announces-upcoming-module/index.html b/article/enjin-coin-supports-godot-and-announces-upcoming-module/index.html
index 5841e76e0b..0a7bc8d7de 100644
--- a/article/enjin-coin-supports-godot-and-announces-upcoming-module/index.html
+++ b/article/enjin-coin-supports-godot-and-announces-upcoming-module/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde24 November 2017
This article is from November 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.
Right after our announcement that we want to hire a second contributor part-time, our Patreon campaign got a huge boost beyond that goal and towards the next.
It was in fact due to arrival of our first Platinum sponsor, Enjin Coin, bringing us an additional USD 1,500 of funding every month!
On top of this sponsorship, they announced their support of our project and intent to develop a Godot module to make their open source framework available for Godot developers.
About Enjin Coin
Enjin Coin (ENJ) is a “smart cryptocurrency for gaming” coupled to the Enjin gaming platform. This cryptocurrency can be used as a backend for in-game virtual goods, which can therefore be traded and transfered between different games relying on Enjin Coin. You can check their detailed whitepaper and website for more details on this blockchain-based technology.
As mentioned, they intend to make their platform available for Godot games by developing an official module for Godot 3, and they will likely get help from experienced Godot developers(*) to ensure that the module works out of the box.
“Godot is an incredible game engine and the Enjin Coin integration will open up true gameplay innovation. We look forward to supporting game developers using Enjin Coin based virtual goods in Godot powered games”, says Maxim Blagov, Enjin Coin’s CEO.
We are thrilled to see such companies take an interest in our engine, and are looking forward to the opportunities that it may offer to our community.
Support our development!
Enjin Coin is our first Platinum sponsor, but not the first company to show their interest in our engine via financial support. Since the Patreon campaign started, two other companies became Gold sponsors: Gamblify and GameDev.tv. We will soon post new blogs about each of them to thank them properly and tell you about their interest in Godot Engine!
If you are interested in becoming a sponsor of the Godot project, head over to Patreon to see our sponsoring tiers and corresponding perks. Stay tuned for more details about our sponsoring plans this blog!
(*) As per Godot’s non-profit structure and charity backing, as well as our SDK agnostic development philosophy, this work cannot be carried out by core Godot Engine developers directly as part of the project’s roadmap. Still, any company is allowed and welcome to propose work for hire to Godot contributors if they want help proposing thirdparty modules for their technology.
-
+
\ No newline at end of file
diff --git a/article/fbx-importer-rewritten-for-godot-3-2-4/index.html b/article/fbx-importer-rewritten-for-godot-3-2-4/index.html
index 4fd466a08d..293287cf5f 100644
--- a/article/fbx-importer-rewritten-for-godot-3-2-4/index.html
+++ b/article/fbx-importer-rewritten-for-godot-3-2-4/index.html
@@ -5,7 +5,7 @@
Gordon MacPherson5 November 2020
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.
I’m Gordon MacPherson (RevoluPowered), a C++ contractor from the United Kingdom. I’ve worked in games for a while now, building upon general software development experience from electronics and RF equipment. I found Godot while working on personal game projects, and started being involved as a contributor a bit over a year ago. In particular, I was very lucky to work as a consultant at Prehensile Tales for IMVU’s Godot projects. This work involved adding support for the FBX 3D asset exchange format to Godot.
First importer in 3.2, now rewritten
The first version of our FBX importer was added in Godot 3.2, and relied on the Open Asset Importer library (Assimp). A lot of work was done at that time directly in the upstream Assimp project to improve the FBX support, but we hit roadblocks with the compatibility with Maya’s FBX exports. Maya is one of the most used 3D assets creation tools in the game industry, and IMVU needed good support for its FBX files.
Due to these roadblocks, we decided to rewrite the importer fully and tailor it to Godot, instead of trying to keep things generic as done in Assimp - Assimp can importer dozens of file formats, which is great, but imposes many restrictions on the support of individual complex formats like FBX, especially for animations. In the game industry, a lot of people assume that FBX works with traditional animation algorithms but we found that it is simply not the case. FBX has its own standard for handling animations which has not been fully reverse engineered correctly by any open source importer/exporter, so we had to start from scratch and only keep the FBX file parser from Assimp.
We removed 70,000 lines of code and our new FBX importer comes in around 12,000 lines of code. The new code has been commented and documented with the things we learned about FBX along the way. It’s made so we can make changes easily and improve behaviour on a per-file basis along the road. We expect bugs with the beta, even some regressions which we have seen already, but we are working on fixes to the reported problems to be ready for the 3.2.4 stable release.
It took us about 14 months to get a proper FBX importer working fully, since we had to engineer everything again:
We rewrote all the mesh code to support all formats of FBX meshes correctly.
We built an entire abstraction for the FBX transform information, which was a very complex and convoluted undertaking to get working properly.
We designed a better handler for the animations which can compensate for the complex transform information, which means that we can handle animations correctly.
Our ethos for the importer ended up being: When you import a FBX file, it should import flawlessly like you intended it to be when exporting. This was the new design goal of the importer to ensure we had SOLID importing ability for commercial FBX files and for your own files too!
This complete rewrite has now been merged in the 3.2 branch with GH-42941. We’ll focus first on fixing reported issues with the new importer so that it’s ready for release in Godot 3.2.4 stable (it will soon be available for testing in 3.2.4 beta 2). Once fixes have been made, we’ll also update the foward port to the master branch to ensure that the new importer is also available in Godot 4.0.
So, for the uninitiated, what is FBX?
FBX is the industry-standard 3D asset exchange file format for games. It is developed by Autodesk as a proprietary format and thus not a great philosophical match for Godot, but given its widespread use, we want to support it nevertheless. We’re also hyped about and support glTF 2.0, which is the open source new kid on the block, and thus brilliant for our engine (and especially the Blender pipeline). But a caveat of glTF 2.0 is that it’s not officially supported by Autodesk software, which many use for content creation in the game industry.
FBX has been through 24 years of usage in the game industry. With its first revision being back in 1996, this means it’s super well tested and pretty much available everywhere by default.
Supporting it is a must, for compatibility with the big wigs but also with the software you might want to try out.
Whoa, it’s been over a year. Why did it take so long?
Reverse engineering a lot of the functionality required to make FBX work properly was very hard. For 2 months we were stuck understanding how pivots mattered in the file format, why they were used internally and where they are supposed to be applied in the animations. Most FOSS tooling could not properly import FBX files or had horrible bugs.
We found the available information to being completely wrong in some cases for determining the skin, bind pose and skeleton information along with animations. It was a nightmare initially, and turned out to be quite time consuming. But we got through and sorted it out, persistence was key.
At some stages we were unsure how the project would get completed and had doubts but we kept hammering away, and eventually, we found a path through in March 2020. Slowly but surely functionality started working bit by bit.
The main problem FBX is that it’s closed source, and therefore the official FBX SDK is a black box. It just gives you values and you don’t know why it is that value, you just have to trust that it’s correct. This means that for some functionality, we literally had to use trial and error to figure out the implementation. Looking at what other importers did was also a serious help.
Some cool things about FBX
It does partial updates like a database and won’t rewrite the entire file when you make a small change. This is good when you don’t want to accidentally break an exported file.
It handles bones, with a truly robust ID and targeting system which can work easily without relying on path information for bones.
It supports various unit formats.
Images can be embedded in the FBX file.
It’s supported by default in most packages for 3D modelling.
Why did you decide not to use the FBX SDK?
In short, we wanted to add official support directly in the engine, and Godot being open source, it can not (and should not!) depend on any proprietary component. Integrating the proprietary FBX SDK could have been done as a thirdparty plugin, but it would not be officially maintained by the Godot team. It’s not just licensing though, here’s what motivated the decision not use the Autodesk FBX SDK:
It’s not open source, which is a deal-breaker as mentioned above.
It’s much larger than our importer, we only net 12,000 lines of code (the FBX SDK is over 50 MB - that’s bigger than Godot!).
We can’t modify the behaviour to improve performance or increase flexibility.
Our importer is faster than the official SDK.
It requires a lot of work. Much like the work we have done with FBX we’d just be repeating work for example with mesh conversion.
It’s a bad move to support it if we don’t know what the code is doing, especially when we care about importing things optimally, especially for creating a reliable 3D workflow.
How much coding went into this? Less coding than you would think. A lot of the time was establishing why standard algorithms do not solve FBX problems, and in this process we came to the conclusion that FBX does things in a different way to most other formats. For good reasons though, the linear skinning method used in the format is in short absolutely genius. Most of the work was learning about FBX and how it worked, and cross comparing the results across many many many versions of the importer.
Pivots are hard. The formula is simple but their application in the correct places required months of reverse engineering, especially when dealing with animations
We rewrote the importer approximately 4 times during my work on it. Before my involvement, it was rewritten twice by Ernest Lee (fire) with help from Juan Linietsky (reduz), and Assimp had done an astounding job at learning what they did with the time and resources they had.
Testing & validation
IMVU, who sponsored this work, had a validation team confirming that their Maya models were working correctly, and testing and helping me fix bugs. This means that we know it’s good enough for animators and modellers to use in a Maya environment.
Thousands of models we use have been validated in Maya, mostly with default export settings in the application. If you find something which doesn’t work, please file a bug report so we evaluate if we can add support for it.
Funding
IMVU not only paid for me to work on this for a year or more but paid for hundreds of hours from various teams internally. Some of the QA engineers also validated the FBX importer in the engine in multiple Godot projects using FBX assets.
Even when the project was stagnated due to research walls (pivot applications) and proprietary information (secret sauce), they continued to support the project. We had many people in the community at our workplace make test assets and validate a lot of models. It was a huge undertaking for them.
Be sure to give @imvu a follow. We are working in house on some projects in Godot Engine and you can follow us on our journey.
My personal journey
During this project I had gaps in my knowledge which were filled in with time and experience. Many talented people helped me fill these gaps quickly, and learning from trial and error helped a lot in those cases where things were done “the FBX way”, instead of the usual way.
In some cases, FBX did not do what people would consider reasonable.
After researching these methods for pivots and various parts of the skinning, I have found them to improve the behaviour in most cases. Now the differences make a lot of sense to me, even if they are complex.
Future plans
Finish porting the rewrite to Godot 4.0 (we use the 3.2 branch in production, so that’s where this was developed and quality controlled by many users).
Locator bones. Right now, you need to bake your animation before exporting.
Improve material mappings (most are supported, some need mapping).
Fix bugs in the beta phase, we expect them.
Known issues
Sometimes skins will inflate larger than they should be due to ‘remove unused influences setting’ in Maya, for now, disable this option in Maya, or you can go to Mesh -> Skin -> Clear temporarily, I expect a fix to land in the next week or so for this problem.
Some materials might have some properties needing to be fine-tuned, but can be easily fixed.
It’s going to be in the beta release, we will test this and resolve regressions we find with existing projects.
Huge thanks to:
Everyone at IMVU Inc, you did an amazing job helping with FBX and ensuring its success. You made Godot have a commercial-grade FBX importer, thank you so much for spending the time and money getting this to be a reality for 2020.
All the people who helped me debug issues, who helped with various logic and also to the Godot core development team.
A big shoutout to Prehensile Tales for helping me through the tough FBX project, especially HP van Braam who has been an amazing employer and great person to me personally and professionally.
Andrea Catania for his amazing work improving our mesh creation code and helping fix hard to find bugs.
Ernest Lee for his continued support and information, along with helping me get to grips with Godot codebase and many many other things, including the first prototype for the importer :)
Juan Linietsky for being there when I needed to ask complex questions on his time.
Rémi Verschelde for helping with the review process and being super helpful.
Assimp for providing an amazing template of a MVP importer which we could improve drastically, Kim Kulling and the various developers who worked on the FBX parser.
Clay John for helping fix the Z-fighting issue with transparent layers from FBX in the NVIDIA bistro, and for doing the fix in the upstream engine <3
Ilaria Cislaghi for being a massive help when finding bugs which are hard to spot.
Everyone who helped on the various PRs with memory leaks and issues.
I guess my cat too ;)
That’s it! As a reminder, the code for the new importer is in GH-42941, and it will be available for testing in Godot 3.2.4 beta 2 in coming days. We’re looking forward to your testing results and bug reports!
-
+
\ No newline at end of file
diff --git a/article/fill-blank-class-reference/index.html b/article/fill-blank-class-reference/index.html
index 27d3ae887c..a979b59095 100644
--- a/article/fill-blank-class-reference/index.html
+++ b/article/fill-blank-class-reference/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde27 April 2016
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.
In the Godot community, we all love waiting. Waiting for Vulkan, waiting for WebAssembly, waiting for C#, waiting for advanced 3D editor features… waiting for Godot!
But there’s one thing that we should not be idly waiting for: API documentation. It won’t just happen that hundreds of lines of class descriptions are written by the core devs; their time is much better spent developing the great features we are all so fond of waiting for.
The good news is, contributing to the class reference is quite easy; it’s a (partly boring, but also rewarding) game that most of us played as kids: fill in the blank. The whole reference is in one XML file in Godot’s source repository, used both by the editor for the offline help feature and by the online documentation.
Current status
So that’s where we need YOU. There was already an important effort before 2.0 to complete the class reference, but the work is far from finished. As of today, the class reference has 369 classes, 4420 methods, 1763 constants, 152 member variables and 142 signals. Out of which only 34% have proper descriptions so far. (You can get a nice overview for yourself using bojidar_bg’s awesome script in doc/tools/doc_status.py)
You can also see the detailed status in this collaborative pad that we use to coordinate the contribution effort.
How to help?
Everything is described in the docs page Updating the class reference. Basically the workflow is to fork and clone Godot’s source repository, edit the doc/base/classes.xml file and make a pull request for your changes.
For more efficiency, and because it’s funnier to work on such things together (especially when you have questions about what a given method does), you are very welcome to join the #godotengine-doc IRC channel on Freenode to discuss live with the rest of the documentation team.
Our objective: have the class reference 100% complete for the upcoming 2.1 release!
What’s next in the pipeline?
Once this task is done, it will be the time for a thorough review of the rest of the online documentation. Most of the tutorials were written in the early days of Godot’s open source existence, and though they have seen improvements here and there, there are many new features that were added over the last two years and that are not well documented (e.g. light baking, networking, plugins, pathfinding, etc.). That’s why we plan to make a complete review of the existing content, reorganise it and start a coordinated effort to, again, fill in the blank. This will be another big task, but with the help of the community we will make Godot Engine even easier to learn, for newcomers and experienced users alike!
A similar effort will be done for the demos; most of them were also designed to showcase the usage of early Godot versions. Since then, many new features and usability improvements have been done, so some of those demos might have become obsolete, or might need to be modernized a bit. Many cool new concepts are not showcased yet in demos either, such as scene inheritance or navigation polygons. We are also thinking about writing tutorials attached to each of them for you to learn how they work. But of course, this will be done only once the class reference has been sufficiently enhanced…
So don’t wait, and help us give Godot the documentation it deserves!
-
+
\ No newline at end of file
diff --git a/article/first-godot-3-docs-sprint-sept-9/index.html b/article/first-godot-3-docs-sprint-sept-9/index.html
index 32bdbffda9..95d4603444 100644
--- a/article/first-godot-3-docs-sprint-sept-9/index.html
+++ b/article/first-godot-3-docs-sprint-sept-9/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest6 September 2017
This article is from September 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.
Update: one month later
After 5 docs sprints, the class reference went up from 35% to 60% complete! We run Write the Docs events every week-end on the #documentation channel on Discord
Godot 3’s API reference is only 40% complete. With so many changes since 2.0, we must review classes and their descriptions. The engine can only grow and attract tons of users if it has great docs. And this cannot happen without you.
Next Saturday, on September 9, we’re teaming up with Julian StraTon and Chris, a.k.a. KidsCanCode, for Godot 3.0’s first Docs Sprint!
Godot needs you
Anyone is welcome to give a hand, especially:
Experienced 3d users to focus on 3d. There is no documentation yet.
Seasoned users to contribute to everything related to 2d, the User Interface nodes, the new Audio system…
Native English speakers to review both existing and new descriptions. Make sure they follow the guidelines and they’re clear and precise.
Godot 3.0’s 3d API has close to no documentation for now. Let’s write it!
Writing the docs is a rewarding job
Good documentation is as important as new features for any open source project. It’s a rewarding job:
Help thousands of new users to better learn Godot!
Get to learn how to better use the engine, discover tricks and subtleties nobody else knows.
Become a contributor, give back to the project.
Hang out together with the community, get to know fellow contributors better.
You’ll explore Godot’s source code, and understand how experienced developers built the engine.
Together, we have the power to write great docs. To make them better than ever! Better than that of proprietary engines out there.
Join us on Discord
The sprint will happen on the official Discord server . Chris, Julian and I will take turns and be around for most of the day. Other contributors will join too.
-
+
\ No newline at end of file
diff --git a/article/first-public-release/index.html b/article/first-public-release/index.html
index ac10234875..2f66c775cc 100644
--- a/article/first-public-release/index.html
+++ b/article/first-public-release/index.html
@@ -7,7 +7,7 @@
Juan Linietsky14 January 2014
Writing a game engine is a really difficult process which takes a long time and we realize a life is not enough to add every single feature we’d like to it. Godot has been an in-house engine for a long time and the priority of new features were always linked to what was needed for each game and the priorities of our clients.
Because of this we are opening the engine to the community so anyone can develop games using Godot and benefit from it’s amazing workflow design. We are also opening the source code with the most generous license, MIT with the hope that other developers will contribute to it and publish their games without any restriction.
We understand that for developers to gain interest, releasing incomplete software is not enough, so we are publishing, for this first version, a fully featured beta. At this point, the engine is stable and everything works, but we need the feedback and input from the “real users” to complete adjusting the experience to make it perfectly smooth.
So, thanks for your interest in Godot Engine! With your help, we want it to become the most amazing game engine the world has ever seen!
-
+
\ No newline at end of file
diff --git a/article/first-steps-towards-1-2/index.html b/article/first-steps-towards-1-2/index.html
index d5fbcb6a89..4e7d633595 100644
--- a/article/first-steps-towards-1-2/index.html
+++ b/article/first-steps-towards-1-2/index.html
@@ -5,7 +5,7 @@
Juan Linietsky6 June 2015
This article is from June 2015, 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.
Waiting for Vulkan
As many of you know, Vulkan will be the next open and multi platform rendering 2D and 3D API. While many claim it will just be an additional API, those of us who have been in the industry for long enough know well that Vulkan will make other APIs obsolete.
CAD and 3D DCC applications will most likely continue to using OpenGL, but for anything related to games OpenGL will be no more.
Vulkan will work on all PC platforms: Windows, OSX and Linux. It will also work on any modern mobile devices, iOS and Android. Vulkan will run in so many platforms that even the idea of using DirectX in the future is starting to look unfamiliar for large studios. It also fixes most of the gripes everyone has with modern OpenGL: Better drivers (due to much less intrinsic complexity) and much larger industry backing. Industry backing for Vulkan is, in fact, so big that everyone but Microsoft is on board.
As this will be undoubtedly the new, de facto, 3D API for games, all work on improving the current 3D renderer has been halted until drivers and API reference are published (which will be this year at some point).
Godot developers love 3D programming, and can’t wait to begin working on a new, awesome backend, with support for physically based rendering, modern global illumination, etc. But this will have to be sometime later this year or beginning of next, otherwise all the work will go to the trashbin once Vulkan comes out.
Next goal: usability
The next version of Godot (1.2) will, then, focus almost exclusively on usability. Godot has a great underlying architecture which has proven to be rock solid during the past years, but the user interface still needs more work to be as friendly as possible. Other (commercial) game engines have set the bar high in this area. Current work is already underway and showing nice progress:
New animation editor.
New file selector, with thumbnails, favorites and recent folders.
New website, documentation and asset DB
The community is also working on a new website, which will allow more open access to adding documentation to the wiki. An asset database where you can share or search for assets, templates, etc. is also planned.
Legal status
We are looking for a way to officialise Godot as a non profit so it can stand on it’s own and not rely or belong to anyone. Effort towards this is in the works, so expect exciting news in the near future!
Participate and make noise!
If you are using Godot, plan to use Godot or are you just interested about it and want to support it, make sure to join our amazing community! The Facebook group and IRC are always active, as well as the forum (Edit: replaced by Q&A in the new website). Remember that we don’t have millions to spend in marketing and PR, so we rely on you to talk about Godot and spread the love!
-
+
\ No newline at end of file
diff --git a/article/fixing-godot-games-published-google-play/index.html b/article/fixing-godot-games-published-google-play/index.html
index d945180331..7343d43876 100644
--- a/article/fixing-godot-games-published-google-play/index.html
+++ b/article/fixing-godot-games-published-google-play/index.html
@@ -170,7 +170,7 @@
There are instructions on how to do this for Godot 2 and Godot 3.
4. Set your new APKs as custom export templates
In the export settings for Android, set the custom debug and release APKs generated by Gradle and use those. This should fix the problem.
5. If needed, add a privacy policy
The reason why Google removed Godot games from their store is that they were using placeholder permissions looking like normal permissions, without having a privacy policy telling users how potentially collected data is being used.
If you don’t add any permission that justifies it, you don’t need a privacy policy, but if you do, make sure to write one. Refer to the Google documentation/emails they might have sent you for details about this.
Future
HP/TMM is working on a fix to to be integrated in Godot 2.1.5 and Godot 3.0.3 so that you can continue setting the permissions you want without having those leftover placeholders.
Godot 3.1 will use a different export approach where you will have more control over the manifest file.
-
+
\ No newline at end of file
diff --git a/article/fixing-tangents-accurate-normal-maps/index.html b/article/fixing-tangents-accurate-normal-maps/index.html
index 62436aa683..9843bca62f 100644
--- a/article/fixing-tangents-accurate-normal-maps/index.html
+++ b/article/fixing-tangents-accurate-normal-maps/index.html
@@ -5,7 +5,7 @@
Bastiaan Olij21 November 2018
This article is from November 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.
While normal maps have been a staple of the Godot render engine for years, new capabilities of the render engine introduced in Godot 3.1 also require the generation of tangents and bi-tangents (often refered to as binormals in engines’ documentation) to function correctly.
Tangents and bi-tangents are two vectors that together with the normal vector give enough orientation detail of a face to provide correct lighting. To save on space Godot uses the approach where only the tangents are store and bi-tangents are calculated by combining them with the normal vector. For this a direction flag is also included with each tangent.
Support for these so far has been spotty. The new CSG nodes lacked support for generating the tangents, there were orientation issues when importing Collada or glTF files, and the new primitive meshes reversed the direction of these.
We spent a great deal of time over the last week going through all these issues and correcting them. All primitive meshes now generate correct tangents, all CSG nodes now support tangents, Sprite3D now supports tangents and the importers have been fixed.
This does mean that if you’ve worked around the existing issues by inverting your normal maps on one or both axes, or by using the “flip tangent” or “flip binormal” settings within materials, you may need to undo these changes when you upgrade to the current master build or the upcoming 3.1 alpha 3.
Note: on December 11th a further change was merged that ensures Godot can directly use normal maps, tangents and bi-tangents as generated by Blender and other modeling software following the same orientation rules.
-
+
\ No newline at end of file
diff --git a/article/fog-volumes-arrive-in-godot-4/index.html b/article/fog-volumes-arrive-in-godot-4/index.html
index 51baf44f76..d95a2147dc 100644
--- a/article/fog-volumes-arrive-in-godot-4/index.html
+++ b/article/fog-volumes-arrive-in-godot-4/index.html
@@ -36,7 +36,7 @@
While the results aren’t perfect (we added too much red), the results are close enough and we are able to do this validation very quickly. On top of that, this avoids any memory synchronization issues as all the writes to albedo are done with atomic operations. There’s a gap between the two atomic calls where other atomicAdd()s may modify the memory, but since we’re essentially clamping the value with the overflow factor, we can trust that the other atomicAdd()s won’t hurt anything.
An alternative solution we explored (which was suggested to me by my brother while on a camping trip) was to add a padding bit between each color channel. In binary, our Albedo then looked like RRRR RRRR RRPG GGGG GGGG GPBB BBBB BBBB. This allowed us to avoid the problem of the single bit bleeding, as we could use an atomicAdd() to clear the padding bits, but it still required us to “replay” the addition to avoid the rest of the impact of the overflow. In the end, we decided keeping the extra bit of precision in the red and green channels was preferable to protecting ourselves against the overflow.
Below is one of the test scenes I used while stress testing FogVolumes. It contains 96 simple volumes which each inject a little bit of density and color into a small area.
Now for the interesting part. Below is a screen capture of a page from AMD Radeon GPU Profiler showing a zoomed in section of the rendering frame. The top bars represent how much work the GPU is doing and the bottom bars show individual commands that have been sent to the GPU and how long they take.
As you can see, the FogVolumes are mostly rendered at the same time, and even then, they can’t saturate the GPU – of course this changes when using larger or more complex fog shaders. To the right, you can see that the lighting calculations are able to saturate the GPU and keep it busy.
Overall, we’re quite happy with the results and are confident that users will be too.
That was just the tip of the iceberg. In adding FogVolumes, we overcame a few interesting technical challenges and faced a number of tradeoffs in designing a system we hope is fast, flexible, and friendly for users. For more details about the implementation, please see the pull request on Github.
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.
-
+
\ No newline at end of file
diff --git a/article/funding-breakdown-and-hiring-process/index.html b/article/funding-breakdown-and-hiring-process/index.html
index 994bb7ccfb..dc0c92dc12 100644
--- a/article/funding-breakdown-and-hiring-process/index.html
+++ b/article/funding-breakdown-and-hiring-process/index.html
@@ -6,7 +6,7 @@
Godot Foundation11 July 2023
This article aims to shed light on the current status of Godot’s funding, hiring, and our plans for sustainable funding long term.
Current funding and spending
State of Godot’s funding
Godot is sustained completely by donations. To date, those donations have taken the form of Patreon pledges, PayPal transfers, and one-time grants. By nature, only the Patreon donations are recurring (although some choose to make recurring payments through PayPal). Even then, we can’t totally rely on them as the month-to-month amount fluctuates. At the time of writing, it is just under $14,000 USD per month, but the amount we receive after fees is much less.
To account for the temporary nature of donations, we have been cautious about expanding the team. In the past, we waited until we had enough funds on hand to pay for a full year contract for a person before signing a contract with them.
Additionally, when the project was much smaller than it is now, Godot was receiving more funds than it could use due to difficulties in finding suitable candidates for hiring. As a result, we were cautious about expanding the team. This led to Godot carrying funds over year-to-year.
In the past two years, however, the amount of contributors has grown significantly, and more individuals that met the project requirements became available for hire. This, combined with the pressing need to turn the Godot 4.0 development into a stable release, resulted in an increased number of hires and a level of spending greater than our current level of month-to-month donations.
We want to keep the current group of paid contributors, but we need more funding in order to do so.
This amount of hires, at the current level of funding, is not sustainable long term. Thanks to the regular income from Patreon and PayPal, we aren’t going to immediately run out of funds, but we are spending more each month than we take in. Therefore, to keep the current group of paid contributors and to maintain the current development pace, the project needs to increase the amount of funding it receives.
Current and future hires
The foundation currently has 10 contractors (some part-time, some full-time) for a total cost of roughly 40,000 USD per month. These people work in a variety of fields that benefit the engine such as editor UX, rendering, production, fundraising, C# integration, and GDScript development.
At the time of writing, the Godot project (through the SFC and the Foundation) has contracts with the following people:
Bastiaan Olij (BastiaanOlij)
Emilio Coppola (Emi)
George Marques (vnen)
Hugo Locurcio (Calinou)
Ignacio Etcheverry (neikeq)
Juan Linietsky (reduz)
Pāvels Nadtočajevs (bruvzg)
Remi Verschelde (akien-mga)
Tomasz Chabora (KoBeWi)
Yuri Sizov (YuriSizov)
There are some areas where we realize that Godot still needs extra work that isn’t being done by volunteers, and we are hoping to hire some more people in the future to cover these areas. Among them are: expanding rendering features, improving editor usability, improving overall performance and improving the asset I/O pipeline. We identified some people that would be ideal for the roles but we need more donations to make it happen.
Reimbursements and other expenses
Carrying the same policy from Software Freedom Conservancy, a small amount of funding is dedicated to travel reimbursements (Godot contributors meet twice a year during Godot Sprints to discuss engine development).
Additionally, while hardware vendors sometimes donate the hardware needed to develop Godot, the project sometimes needs to help contributors with hardware reimbursements in order for them to test their code on different platforms, GPUs, etc.
Travel reimbursements and hardware costs are a very small proportion of the project’s overall expenses and total less than $1,000 USD most years. The rest of the funding goes directly to paying contractors.
Godot hiring process
We would like to touch on the hiring process for paid Godot contributors.
The hiring process for Godot works differently than it does for traditional software companies. In traditional software companies, job postings are listed and candidates are evaluated until one is eventually hired. New hires need to go through an on-boarding process and it takes time for them to fully understand and get familiar with how the current project works. This process often requires significant assistance from their peers (preventing them from doing their own work) until the new hire feels comfortable and productive. It is possible that this new person will never fully onboard or perform as expected and companies accept this cost.
For Godot, the process works differently. We typically do not make public job postings, we identify individuals who are already knowledgeable about Godot, have experience in areas that need more contributions, and work well with other contributors. As Godot is a highly popular FOSS software project (over 2,000 contributors), it is typically not difficult for us to find such individuals for most areas of the engine.
This way, when enough funding is available, we can ask these contributors if they would like to work full (or part) time for the Godot project so they can continue working on what they are already working on, but dedicate several more hours to Godot as well. This significantly accelerates the pace of Godot development and ensures that donation funds are always used on hires that will maximize the return on investment.
Thanks to this policy, Godot development can happen at a fraction of the cost of larger commercial offerings and get more done dollar-for-dollar (and making the results fully free, Open Source, and available for everyone to use in any way they want).
This approach to hiring has scaled well with the growth of the project and we hope that it continues into the future. As always, we strive to do as much as we can with what we have and we hope that you continue to trust us and believe in the future of the project.
Future of funding
New donation platform
We are launching a Godot Development Fund page, taking inspiration from our friends at Blender and the amazing Blender Development Fund. The Godot Development Fund will operate much the same way allowing users to make recurring or one-time donations from a centralized location.
We decided on offering this new donation platform as it became increasingly clear that using a third-party tool like Patreon was costing too much relative to the service it offers. Due to taxes, payment processing fees and other costs, Godot is receiving substantially less than what is donated through the platform. At the same time, there are few similar services that cater to not-for-profits operating on the scale of Godot. Ultimately, we have decided to follow in the footsteps of our friends at Blender and Krita.
The new donation platform is mostly ready; you can already use it to set up a recurring donation via PayPal if you would like! In the coming weeks, we expect to finalize the donation platform and we will have a big announcement post once it is 100% finished.
We will keep the Patreon operational for the foreseeable future as we heavily rely on the current donations we receive through it. But for future donations, please consider using the Development Fund as it results in more of your donation going towards development.
Diversification of funding sources
With the new Godot Foundation, it is expected that the Godot Project should be able to further diversify its funding, going into areas such as:
Paid asset store (taking a percentage of sales).
Merchandise.
These are still in the early planning phases as our priority until now has been to get the donation platform operational. To be clear, we do not anticipate that we will be able to sustain the project through the asset store and merchandise alone as we will intentionally operate them with very thin margins. We are a not-for-profit project first and foremost and we will not compromise that.
Transparency Reports
During 2023, the transition from Software Freedom Conservancy to the Godot Foundation will take place. Existing contracts with the SFC will end and new contracts with the Godot Foundation will be signed to ensure continuity.
The SFC publishes its own transparency reports at the end of every year with detailed information on funding sources and use of funds, but as they manage several projects, they don’t go into the specifics of each one for every spending category. Godot will be included in the SFC’s annual report for 2022 and 2023, but the Godot Foundation will be responsible for publishing its own annual reports for 2023 onward.
The Godot Foundation will publish its own transparency reports in 2024 covering its inception in 2022 until the end of 2023 based on its own funding and cash flows. This will overlap with the SFC’s 2022 and 2023 reports. As the report will cover Godot exclusively, it can cover more details than what the SFC reports can cover. Particularly, interested readers can expect to find clear breakdowns of sources of funding and categories of expenses.
While it may be desirable to publish this information more often, please understand that these reports have to be audited to comply with local law and can be expensive and time consuming to prepare. We will, however, be able to post up-to-date information about our monthly funding thanks to the new donation platform.
Future
With the strong growth of the Godot Engine project user base and the growing number of contributors, an increased amount of funding will be needed to keep up the expected development pace, so stay tuned for the new Godot Developer Fund or help now by donating here. A big thank you to everyone who has contributed their time or financial support to the project. We wouldn’t be here without you.
-
+
\ No newline at end of file
diff --git a/article/future-patreon-and-donations/index.html b/article/future-patreon-and-donations/index.html
index 3e767f5a51..42bdb726e6 100644
--- a/article/future-patreon-and-donations/index.html
+++ b/article/future-patreon-and-donations/index.html
@@ -5,7 +5,7 @@
Juan Linietsky23 November 2018
This article is from November 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.
It has been a year since we started actively asking for donations on Patreon (and other means). Thanks to that, I could work paid for an entire year so far (which has resulted in dozens of new features and me helping a huge amount of contributors).
Thanks to that, also, Rémi could also work full time since March and help ease the big chaos of our large number of contributors, as well as many of his dedicated project manager tasks which, as you can see, keep growing and growing:
And we could also hire karroffel to work heavily on both GDNative and OpenGL ES 2.0, which allowed us to lift a huge amount of work from our shoulders. The OpenGL ES 2.0 port is now almost complete and will be ready by the time 3.1 comes out.
Thanks to our very generous patrons, Godot 3.1 will be an amazing release, further closing the feature gap with the main commercial game engines and improving enormously on usability.
But it’s time to keep growing, so we have updated the Patreon Goals. Please keep reading to find out more about this!
Managing the money
So far, each time we proposed something, our community has been very generous matching the Patreon goals within weeks. We and everyone using Godot are very thankful. We always tried to be responsible and always ask only for the money we need.
The few times there was excess money, we tried to use it to help contributors cover their travel expenses every time we meet (usually one or two times a year during GodotCons, we mostly live far away from each other). Being able to meet face to face is incredibly productive as we can fix issues together, do improvements, and plan features in a much more efficient way. Many of the features implemented this year were planned during GodotCon 2018 in February. (BTW, the dates of GodotCon 2019 have been announced, check details here.)
As always, we do everything through the Software Freedom Conservancy, to ensure everyone that money is used transparently and for the benefit of the project. There is zero discretionary fund management with our donations.
Making better use of donations
We discussed all this year how we could make better use of donations (as in, besides hiring me and Rémi). We are always careful with asking for more (even though our community keeps growing) because we want to warrant that the money will be used efficiently and fairly.
While doing part-time hires worked well up to now, we don’t feel that this is fair to the community as a regular Patreon goal, as these hires don’t always work in areas that benefit everyone who is donating.
At the same time, we are still short on developers who can work more as generalists, diving into most Godot subsystems to do fixes and improvements. This can be evidenced by the large amount of issues assigned to me. As many of our contributors come and go (as in, for different life reasons they can contribute only for a limited amount of time or at a limited time of the year), we lack more time from veteran developers who can do work as needed in the many different engine areas. This often makes me and the other generalists the bottleneck when fixing issues for stabilizing the engine for new releases.
Added to this, Godot 3.1 will be a release that covers a much wider surface area of what our users expect, so we are not that much in need of new features any longer. The only really big feature planned after 3.1 is porting the rendering to Vulkan, due to the evidenced decay in OpenGL support (deprecated on Apple, constantly worsening driver support, etc.). Other than that, Godot needs mostly polish, smaller features, optimization and improving what is already there the most.
As a result, we believe it will be in the best interest of the project and community to change the focus and instead aim to hire some of our more veteran contributors full-time. Given their industry experience and the fact that they will quit a very well paying job to work for us all day, the cost will be considerably higher. Still, we believe this will be very worthy and should help speed up the project development a lot (especially all the polish and fixing most of the complex issues remaining).
Asking for a raise
Besides the above, both Rémi and I will be asking you, the community, for a small raise. We are currently at USD 3000/month (though you have to consider the high income taxes and cost of living in our respective countries, our families, and that Conservancy -like any charity- takes a 10% cut of the gross donation income too). We included that 10% share in the Patreon goals to clarify the numbers.
On paper, our contract is for 6-hour workdays. In reality, we work close to twice that much.
We work weekdays like any regular job, and we also tend to work on evenings and/or weekends (because this is when most Godot contributors have free time and we need to be there to help them the most), thus, devoting a big part of our life to the project. As soon as funds are available, we will ask Conservancy to raise our work hours on paper from 6 to 8 (so from USD 3000 to 4000/month) and not ask for further raises unless project funds grow considerably and we can hire a good amount of other full-time contributors.
Funding for new features
We will try to make sure that donations go to finance general development, bug fixing and polish. Still, the community may still be interested in funding work on specific features (e.g. support for the latest VR headset, ray-tracing, latest C# version or tool, etc.), which are generaly not of so much priority in our roadmap.
Many Godot features are already financed by third parties directly. Companies like Gamblify, Microsoft or Mozilla continue to hire or fund our contributors to work on them. Following this logic, in case some part of our community really wants to focus on a specific feature and wants to pay for it, we were thinking that separate crowdfunds could be set up if enough interest exists. This could allow hiring a contributor or setting up a bounty and would go via a separate funding channel than the main one.
Help us hire Pedro Estébanez!
We now want to hire Pedro J. Estébanez (RandomShaper), a long time contributor who has worked on everything, from mobile support to rendering and onion skinning. Pedro is an experienced and versatile engineer, so he can maintain and improve areas of Godot that currently lack a dedicated maintainer. We need him to build a bug-free engine on all platforms and across our supported features. Help us reach the next goal to hire him full-time!
Funding demo projects
The Blender project has successfully crowdfunded many open movies, where they use the donations to make an open source high quality movie for everyone to see and learn how it is made. In the same vein (though probably a bit more in the future when Godot’s feature set is more stable and we are focusing even more on polish and usability), we thought it could be really cool to explore this venue.
Seeing the source code and asset workflow of big commercial games is a rarity, so opening up this process more to Godot users (and at the same time, ensuring Godot works as best as possible in these workflows) would definitely be fantastic.
Corporate sponsors
Godot is always open to corporate sponsors, as we believe that high quality, free and open source game technology is a vital asset to the game development world. Otherwise, a handful of companies would control who and how everyone makes games and then, the whole industry would have to pay them a tax in order to create content.
Even if your company does not currently use Godot, or only plans to use it in the future, don’t hesitate to become our sponsor and help make game development a place with more freedom for everyone.
Future
As always, thank you infinitely for your support. If you aren’t yet, and it’s within your possibilities, consider becoming our patron and help make Godot better, faster.
-
+
\ No newline at end of file
diff --git a/article/gamescom-2024/index.html b/article/gamescom-2024/index.html
index 0d5178b24a..740a6fd8b7 100644
--- a/article/gamescom-2024/index.html
+++ b/article/gamescom-2024/index.html
@@ -5,7 +5,7 @@
Nat6 August 2024
How is it already August? Many of you approached the Godot team about our potential presence at gamescom 2024. There won’t be a Godot booth this year, but we are happy to confirm that you still will be able to meet Emi, Juan, Rémi, André, and me in Cologne!
To schedule business meetings with the Godot Foundation, please reach out to emilio@godotengine.org directly ✉️
If you are exhibiting a Godot game and would like to appear on our socials, reach out to nat@godotengine.org to arrange a photo opportunity 📸 (this also applies for the preceding devcom by the way!)
For any attending Godot Engine users who would like to have a chat with us, we planned a more than one way to make that happen:
Thursday Offsite
You may join us at this official Godot Meet-up regardless of whether you have conference passes or not! It will take place in the inner city.
We reserved the upstairs terrace of a traditional German restaurant and thanks to our sponsor W4 Games you needn’t worry about snacks.
Because our capacities are limited, we kindly ask you to sign up in advance. Likewise, if your plans change, please remember to cancel, so someone from the waitlist may take your place.
Friday Onsite
As trade visitors, we tend to avoid the busy weekend. You might spot the crew playtesting some games in the indie area all Friday long, but to ensure you cannot miss us, we promise to be at the IndieArenaBooth at 13:00 local time for a casual Godot gathering. We might even have a shiny sticker for you if you ask nicely.
It might be wise to join either our Discord (#🚌┃godot-on-tour channel) or Forum (Events category) for other onsite communication or to connect with fellow developers attending the event.
-
+
\ No newline at end of file
diff --git a/article/gamescom-latam-2024/index.html b/article/gamescom-latam-2024/index.html
index e3621f8d3a..beb82f4a75 100644
--- a/article/gamescom-latam-2024/index.html
+++ b/article/gamescom-latam-2024/index.html
@@ -6,7 +6,7 @@
George Marques21 June 2024
Last year Godot had a booth at the BIG Festival and it was a great success. This year the event has rebranded as gamescom latam and once again we secured ourselves a booth. It will take place between June 26th and June 30th - make sure to come by if you are attending! We have stickers and pins waiting for you.
The BIG Festival was already the biggest event for game developers in Latin America and therefore a must to attend; with it now carrying the internationally recognizable name of gamescom one can only imagine how much it will continue to grow.
The event features a good amount of booths, with plenty of games to play and many people to meet. It also includes many talks in all areas of game development, all covered by the standard ticket. Not to mention the business area where one can schedule meetings with other companies to negotiate deals or form lasting connections.
The Godot booth is sponsored by a joint effort of W4 Games, anitya, and Vertex Ludi. It is a great place to meet the community and proof that we are here to stay. Looking at last year, we expect to have a busy booth teeming with interesting conversations, as well as some merchandise to take home with you. A short talk titled “Godot and Its Emerging Ecosystem” is also on the program, which will take place on June 27 at 10:00 (local time) on the Quest 2 stage.
If that is not enough, thanks to our sponsors we will be hosting a Godot community gathering for about 100 people. The idea is to meet on a more casual level and get to know the local community better. Networking with likeminded game developers is key! This party is scheduled for the June 27th starting from 19:30 (local time). Make sure to register here!.
While many team members are unfortunately unable to attend due to travel logistics, we made sure to send local correspondents like myself and Michael (Yeldham) to this important event for the Latin American community regardless, to ensure Godot stays represented where it once started.
Staying in touch with the LATAM community is exciting, so we cannot wait for this event to come around. Will we meet you there?
-
+
\ No newline at end of file
diff --git a/article/gdc-2023-godot-games/index.html b/article/gdc-2023-godot-games/index.html
index 5ef378ba64..447cd6e11a 100644
--- a/article/gdc-2023-godot-games/index.html
+++ b/article/gdc-2023-godot-games/index.html
@@ -6,7 +6,7 @@
Emi7 March 2023
This article is from March 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 we announced at the end of the last year, Godot is going to be at the Game Developers Conference (GDC) 2023, which will take place in San Francisco from March 20th to March 24th.
For the first time, Godot is going to have its own booth at GDC where we will be hosting game developers who will be showcasing their latest games made with the engine.
We would love to meet you! Come and chat with the team behind Godot, as well as the developers of some of the most popular games created with the engine. If you don’t have a pass for GDC 2023, our sponsor W4 might be able to get one for you. Read more about it on their blog post.
Godot Meetup
If you are interested in meeting the team behind the engine, as well as other Godot developers, outside of the GDC show floor, there is going to be a less formal event as well! On Wednesday, March 22 from 6:30 PM to 9:30 PM we are holding an event at GitHub HQ open to anyone interested in Godot Engine: AAA, indie, and hobbyist developers of all levels are welcome. Snacks, drinks, talks, and Godot!
We understand that coming to the GDC is not something that everybody can afford, so we would like to give you the opportunity to showcase your game even if you are not able to attend. We prepared a form for you to submit your game and we will select some of those to showcase at our booth.
We are honored to be joined by the games and the developers of:
Dome Keeper
Defend your dome from wave after wave of monsters in this innovative roguelike survival miner, Dome Keeper. Use the time between each attack to dig beneath the surface in search of valuable resources and artifacts – use them carefully to choose powerful upgrades and bonuses.
Usagi Shima
You’ve been tasked as caretaker of an abandoned island — as you decorate it over time, curious (but adorable!) bunny visitors start to appear! Buy toys, plants, and build structures on an abandoned island to entice curious bun tourists to pay your island a visit.
Pingo Adventure
Pingo Adventure is a cute 3D platformer with interesting physics simulation. Follow Pingo to explore the world, solve puzzles, play mini games and even customize your Pingo with the costumes unlocked from the adventures!
Fist of the Forgotten
Fist of the Forgotten is a platformer set in a harsh, dark world, but that doesn't mean you're helpless. Relics passed down from your family allow you to interact with forgotten technology and fight your way forward.
BLASTRONAUT
It is a dangerous but lucrative job. Explore this vast procedurally generated world with your jetpack. Extract the minerals with an explosive gel. Expand your mining platform. But most importantly: stay alive.
Endoparasitic
Three limbs ripped off, infected with a deadly parasite, you must save your research. Drag yourself through the corridors of a secret research lab on a remote asteroid, fight off horribly mutated monsters, inject countless syringes of vaccines, and survive at all costs.
Kamaeru
Kamaeru is a cozy farming sim where you collect and breed frogs, customize your environment, and restore biodiversity in the wetlands.
Brotato
A spaceship from Potato World crashes onto an alien planet. The sole survivor: Brotato, the only potato capable of handling 6 weapons at the same time. Waiting to be rescued by his mates, Brotato must survive in this hostile environment.
Circle of Kerzoven
Circle of Kerzoven is a charming settlement-building strategy game paired with a rich simulation experience. Every animal and plant tries to find their place in nature while you lead your villagers to their future. Expand to different regions and trade with local factions to gain needed resources.
Cassette Beasts
Collect awesome monsters to use during turn-based battles in this open-world RPG. Combine any two monster forms using Cassette Beasts’ Fusion System to create unique and powerful new ones!
Gawr Gura: Quest for Bread
Gawr Gura: Quest for Bread is a time-traveling, action-platforming fan game. Play through a comedic storyline featuring a cast of quirky characters and a blend of fluid platforming with snappy combat. Help Gura reunite with her bread!
Beat Invaders
Beat Invaders is a unique space action roguelite! Blast your way through enemy fleets, unlock skills, items, ships, and upgrade them! Blast away to a pushing soundtrack and neon visuals.
Gourdlets
Gourdlets is a city-building sandbox. Place buildings and scenery, and then watch visiting gourdlets arrive and interact with the world. No objectives, no points, just building.
TailQuest: Defense
Explore a tiny world, defeat hundreds of enemies, experiment with the environment, find all secrets and enjoy the Adventure with a friend or in single player mode.
Until Then
The world hasn't ended yet. Mark is a normal teenage boy doing normal teenage things. But a single meeting flips everything on its head. People are disappearing and memories can't be trusted. An earth-shattering event hides a daunting truth. Mark and his friends traverse the daily lives of teenagers, all while racing to unravel the mystery before it's too late.
-
+
\ No newline at end of file
diff --git a/article/gdc-2023-retrospective/index.html b/article/gdc-2023-retrospective/index.html
index ffd4d76265..03dc706052 100644
--- a/article/gdc-2023-retrospective/index.html
+++ b/article/gdc-2023-retrospective/index.html
@@ -6,7 +6,7 @@
Two things became very clear to us throughout the week. The first is that the industry is ready for an open source game engine to stand shoulder-to-shoulder with the giants in the industry. The second is that people are overwhelmingly rooting for our continued success. A special thank you to everyone who cares about the project and wants us to succeed; we do this for you.
What went well
The booth: The booth was an amazing place to hang out, chat, and play a few games. From the time the expo hall opened until it closed each day, the booth was full of people. We were very pleased to see the number of people interested in Godot and games made with Godot!
The Godot party: Thank you to GitHub for sponsoring the Godot Party at GitHub HQ. They were truly wonderful hosts who went above and beyond. At the party, we had dinner, Godot-themed drinks, and lovely talks from both Nathan (GDQuest) and Juan (reduz). The Godot Party was an excellent opportunity to mingle with other Godot community members and unwind after a busy day.
The community: We had the chance to meet many Godot community members from across areas including users, educators, contributors, and moderators. Many of us have been contributing to the project for years without meeting each other face-to-face. The opportunity to put faces to names alone makes the trip worthwhile.
The pins: We purchased small pins to give away at the booth and they were a huge hit. People loved them and we loved giving them away. We had many people track down the booth after seeing someone else displaying a Godot pin.
What we can improve
More pins: We ordered 1,000 pins to giveaway at the booth and when meeting other folks in the industry. Fortunately for us, Ariel Manzur (through Ramatak) ordered 1,000 more for the booth. The pins went fast and they drew a lot of people to the booth. Next year we would like to seek sponsors in advance specifically to buy pins (and maybe other swag).
T-shirts: We ordered T-shirts for all the volunteers who would be staffing the booth. While not at the booth, many of us were approached by Godot users and fans who noticed the shirt. Next year we would like to have the Godot logo on the front and the back of the shirt to be seen by even more people!
Organization of booth: We had a central round counter in the center of the booth and a set of chairs just behind. Our hope was to simultaneously draw users in to the booth and provide a place to hang out and sit down (there isn’t a lot of seating nearby). However, we found that it was very crowded around the counter from people watching and playing the games. Next year we want to make it a little easier to get to the counter. Similarly, we found that the chairs were really underutilized as the booth was constantly busy (and thus noisy!). For next year, if we do dedicated seating, we would like to separate it a bit from the mayhem.
Business cards: We had pins to give away but we didn’t have anything with the Godot website or information about Godot. Many people wanted a card or pamphlet which would give them something to look up once they got home. We would like to have small business cards with a link to the website and perhaps a QR code to download the engine.
Organize more hangouts: This was a first GDC for most of us and we were pretty overwhelmed organizing things (again thank you to W4 who handled a lot of the organization as well, we couldn’t have done this without you). Once the week ended and the dust settled, we found ourselves wishing we had organized a dinner or hangout with the booth staff and game exhibitors. Despite spending all day within 10 feet of some people, we barely got a chance to talk with everyone at the booth. In the future, we would like to schedule an event to acquaint the booth staff with the exhibitors showing off their games.
Show off the engine more: At the booth we had 8 TVs with playable Godot games as well as 1 big TV with the 2022 showreels on loop. While this made for an impressive display, it didn’t show people what Godot is, many people passing by asked if we were a publisher or a game platform. We would like to utilize the space to show off the editor and the game creation process more, either with live demos or a prerecorded video.
Final thoughts
Overall, GDC was fun, exhausting, and productive. We have been given a lot to think about and discuss as we look forward to the next year of development. In the coming months expect some exciting announcements as well as more detailed plans for development of Godot 3.6 and 4.1.
While Godot is now starting to have a large presence in the industry, we do so on a shoestring budget. The cost to the Godot Foundation for attending GDC was only a few thousand dollars (spent on the pins, t-shirts, and reimbursements for some volunteers and exhibitors). Large events like this aren’t generally possible for us unless a company brings us along (like W4 did this year). Despite the huge amount of support we received to attend GDC, we still rely on donations to fund development.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors in their free time, and a handful of part or full-time developers hired thanks to donations from the Godot community. A big thank you 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.
-
+
\ No newline at end of file
diff --git a/article/gdc-2024-godot-games/index.html b/article/gdc-2024-godot-games/index.html
index 0ccebc30fa..4dd988238d 100644
--- a/article/gdc-2024-godot-games/index.html
+++ b/article/gdc-2024-godot-games/index.html
@@ -5,7 +5,7 @@
Nat1 March 2024
Like we announced a while ago, the team is preparing to head over to the US for this year’s GDC! In case you have not heard about the conference before, you can read more about it here: gdconf.com
We will have a booth on the expo floor, and would love to welcome you there! You can play games (more about those below), chat with our sponsors, meet contributors to the engine and ask your burning questions to the Foundation members staffing the place. There might even be pins to snatch up 👀
Meetup at GitHub HQ
You can meet us in San Francisco even if you don’t hold a GDC ticket. For the third time, our friends at GitHub have lent us their space to host a small after-hours get-together. There will not be talks or a formal program, the focus lies on meeting fellow Godot developers and chatting about your games.
Register for the event here. There are limited spots, so please tell us if you don’t end up making it.
Games made with Godot
Just like last year, we invited Godot developers to join us on our travels and exhibit their games at our booth. Check out the list below, and schedule some time for live playtesting when you are around!
On the 21st of March, we will be joined by a senior class of students from a local public school. As part of their Game Design Academy program - which was started 15 years ago - the teams are currently developing games for their final presentations. At our booth, they will present their current prototypes and aim to gather some feedback from industry veterans.
Halls of Torment
Slay hordes of terrifying monsters in this horde survival roguelite. Descend into the Halls of Torment where the lords of the underworld await you. Treasures, magic trinkets, and a growing cast of heroes will grant you the power to vanquish the horrors from beyond. How long can you survive?
Windowkill
Windowkill is a twin-stick shooter, but the game window itself is constantly closing in on you. Shoot the window edges to push it around your screen as you fight and dodge enemies and bosses in their own windows.
Spring Dash
Catapult yourself to incredible speeds in this first-person precision platformer. Use your command over vegetation to build up momentum and decimate the bugs in your way. Just be careful not to fall!
Warside
Welcome to Warside, the fast-paced turn-based tactics game. With a story campaign, multiplayer support, and a built-in map editor, the fight for victory never ends. Choose your Commander, assemble your forces, and battle your way to victory.
Endoparasitic VR
Three limbs ripped off, infected with a deadly parasite, you must save your research. Drag yourself through the corridors of a secret research lab on a remote asteroid, fight off horribly mutated monsters, inject countless syringes of vaccines, and survive at all costs.
Gourdlets
Gourdlets is a city-building sandbox. Place buildings and scenery, and then watch visiting gourdlets arrive and interact with the world. No objectives, no points, just building.
Stunt Xpress
Become a delivery van driver. The best in the world. Take part in internationally renowned delivery van driving championships. Shoot your parcels (on time) into customer's homes like a marksman while performing gravity-defying stunts and being chased by god knows what.
Kohlrabi Starship
Kohlrabi Starship is a cozy farming game with space travel. Fly your very own greenhouse spacecraft and discover mysterious planets. Put on your gardening gloves, make friends with animals, fall in love, and slowly turn your desert home planet into a thriving ecosystem.
Nonu
Nonu is a fantasy souls-like set in a beautiful hand-drawn world. Face intelligent enemies in true souls-like fashion, with a twist. Draw upon the power of Nonu to forge your own fighting style, and uncover untold truths about the world, and its eclectic inhabitants.
Vultures - Scavengers of Death
Face zombies and fearsome mutants in this turn-based survival-horror roguelike inspired by the Resident Evil Classic Series. Command an expert mercenary to perform extraction missions in a post-apocalyptic city.
Schedule
Wednesday 20th
Games
10:00 AM 1:00 PM
Nonu, Warside, Windowkill, Stunt Xpress, Vultures
2:00 PM 5:30 PM
Kohlrabi Starship, Endoparasitic, Gourdlets, Halls of Torment, Spring Dash
Thursday 21st
10:00 AM 1:00 PM
Kohlrabi Starship, Endoparasitic, Gourdlets, Halls of Torment, Spring Dash, Game Design Academy
2:00 PM 5:30 PM
Nonu, Warside, Windowkill, Stunt Xpress, Game Design Academy, Vultures
Friday 22nd
10:00 AM 11:30 AM
Kohlrabi Starship, Endoparasitic, Gourdlets, Halls of Torment, Spring Dash
-
+
\ No newline at end of file
diff --git a/article/gdc-2024-retrospective/index.html b/article/gdc-2024-retrospective/index.html
index e1d62f6859..92a917becb 100644
--- a/article/gdc-2024-retrospective/index.html
+++ b/article/gdc-2024-retrospective/index.html
@@ -5,7 +5,7 @@
Nat5 April 2024
With the team returning from its GDC adventures, it is once again time to tell those back home about memories made. We hope you didn’t miss us too much!
First of all, we want to thank our sponsors at W4 Games again for providing us with this super-sized booth that allowed us to house not only 11 indie developers, but also so many curious minds from within the community and beyond. Big thanks to everyone who made the time to drop by and fill the space with life. We had an amazing time meeting all of you.
The main difference to last year is rather shocking: barely anyone needed an explanation about what Godot is anymore. Visitors were excited to play the showcased games, and recognized titles — some really surprised to find out their favorites used the engine! Studios and other companies also came by plenty to talk about how they found out about Godot through an excited colleague or the news, and a handful mentioned they started experimenting or even using it in their projects. We took note of people’s wants & needs during these chats, appreciative of being able to forward these first hand accounts of users directly to our engineers.
Notably, we heard from a significant number of people who recently transitioned to Godot that it is working well for them, they love the current feature set, and the engine is not holding them back. However, they are still encountering a few too many pain points requiring workarounds or waiting for updates. For the team, this was a strong indicator that we need to spend more time identifying and resolving these everyday “papercut” issues that add up and impact users’ workflows. Expect to hear more about this soon, as we are back to discuss and adapt our priorities to the feedback we brought with us from the conference.
Of course, you cannot attend a big industry gathering without scheduling a fair share of meetings, so the Foundation did just that. One goal was to secure funding to keep the project running and be able to hire more core developers. Another recurring topic in such conversations were possible integrations and better industry support for Godot developers — we cannot wait to show you what is brewing in that area.
If you or your company had packed schedules already or could not attend GDC, but want to talk to us about similar topics, please reach out to contact@godotengine.org.
Our gathering at GitHub HQ also proved successful, with many Godot users, content creators, and contributors chatting about their personal projects with us. The vegan food seemed to be a hit as well. Afterwards, we were told it was one of the most relaxed evenings of the week for some of our guests. We are grateful to GitHub that we could provide this kind of space to the Godot community, and are looking forward to GodotCon in that regard (TBA).
As for the team itself, this conference allowed the fully remote team to assemble in person again. Between booth duty, team meetings, and extracurricular activities, we are happy to report we all grew a little closer. Even engine developers need to leave their houses sometimes ;)
At the end of the day, we and everyone we met are passionate about this open source project — interacting with the community in person is a really helpful tool to remind everyone of that common ground, and use it to our advantage: to compare feedback and sentiment to what we hear on the internet, and to forge lasting relationships. Which is one of the key reasons why we are now looking into being present at more conferences across the world in the future, aiming to enable more of these important conversations and super helpful learnings. This will come at the expense of a smaller GDC booth next year however, as we have to split budget and personpower accordingly. San Francisco indeed proved as pricey as everybody keeps saying, and we strongly believe there is more to gain from diversifying opposite to always being in one and the same location.
Did you visit the booth? Snapped any pictures you want to share with us? Use the forum post linked here to tell us about your experience at GDC, we would love to hear back from you :)
-
+
\ No newline at end of file
diff --git a/article/gdquest-kickstarter-learn-2d-and-3d-game-creation-godot/index.html b/article/gdquest-kickstarter-learn-2d-and-3d-game-creation-godot/index.html
index 4492f87b62..ef820b207e 100644
--- a/article/gdquest-kickstarter-learn-2d-and-3d-game-creation-godot/index.html
+++ b/article/gdquest-kickstarter-learn-2d-and-3d-game-creation-godot/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest18 January 2019
This article is from January 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.
After a first successful crowdfunding to create a Godot course in 2017, we are back with a new project in collaboration with the Godot team!
We’re going to create:
Two complementary courses about 2d and 3d game creation, based around a platform/adventure game inspired by Metroidvanias
Two beginner-friendly video series for the official documentation about 2d and 3d
In short, we are raising 14,000 € to hire Guilherme, Pigdev, and Razvan, to create great tutorials together. And I will keep working alongside them full-time.
This time, we are releasing all our code as Free Software from day one! Both during and after the campaign.
We are also publishing new free tutorials every day during the Kickstarter! So make sure to subscribe to GDquest’s YoUTube channel.
Our Open RPG engine is available for anyone to study, distribute, and reuse freely.
Questions and answers
Who are you and why should I support you?
We’re a small team and company that teaches, uses, and contributes to Free Software. Our ambition is to bring people together to become better game developers and help the projects that we love to grow.
Thanks to the money from the previous Kickstarter, we:
Contributed long tutorials to the official manual’s Getting Started guide
Released dozens of Free tutorials on our YouTube channel
Open sourced all of our Godot projects in 2018 on GDquest’s GitHub
Organized 7 Write the Docs events to bring Godot’s built-in reference from 30% to 70% complete before the 3.0 release
Created the official demos for pathfinding, grid movement, Finite State Machines
Open RPG, the increase in tutorial releases on GDquest, contributions to the official docs, giving talks, everything we shared was made possible by our last crowdfunding campaigns and the courses’ sales.
Unlike other training companies, we produce equal amounts of free and paid content. As our revenue grows, our contributions to Free Software grow as well. This model allows us to stay consistent.
Then the amount we could hope to raise with donations only is way smaller than what we need. People are a lot more likely to support you financially if they get some exclusive content in return. That’s part of the reason why so many Free Software projects struggle to get a budget and people full-time, even when they have tens or hundreds of thousands of users.
Why crowdfunding?
We need the budget to hire Guilherme to work on the course full-time. With some good budget, we can get Razvan and Henrique involved as well, and produce even better content!
Even if you can’t back us, a successful campaign will allow us to create more content for the official documentation, and more Free resources. So please consider sharing the word! It’s essential for us to keep going.
-
+
\ No newline at end of file
diff --git a/article/gdquest-kickstarter-stretch-goals-free-tutorials-godot-demos/index.html b/article/gdquest-kickstarter-stretch-goals-free-tutorials-godot-demos/index.html
index e24708f77c..eb581ba411 100644
--- a/article/gdquest-kickstarter-stretch-goals-free-tutorials-godot-demos/index.html
+++ b/article/gdquest-kickstarter-stretch-goals-free-tutorials-godot-demos/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest31 January 2019
This article is from January 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.
Our new Godot course Kickstarter campaign was funded in less than four days! Thank you kindly for your support. :)
More on that below. We’re looking to fund three stretch goals to bring more content to everyone. But first, let’s briefly talk about 3d in Godot.
3d tutorials
You’ve asked for them; we promised we’d bring you some quality tutorials about 3d in Godot. There you go! There are seven right now, with more to come, and you can find them all in our 3d tutorials playlist.
Banner and video thumbnail: Littlest Tokyo, CC-By glenatron
The Three Stretch Goals
We have three stretch goals for the project. They’re all about extra contributions to Godot, available for everyone in the community!
On top of everything else, we’re looking to create:
Two detailed Godot learning paths, for beginners and experienced game developers
Great 3d prototyping assets to help you develop games faster
A Free video tutorial series covering the new features in Godot 3.1, for the official docs
If you want to get excellent learning material and help us bring more Free educational resources to the community, you can back us now on Kickstarter!
2 Godot learning guides for beginners and developers
We are going to create two learning paths for Godot. Two curated and polished guides to help you get started and build up solid skills with the engine. One for beginners and hobbyists, and one for developers. Only with free resources! Resources that might be hard to find when you’re just discovering the engine.
This first goal is already funded, with over €21,000 at the time of writing. I think we can get all three of them.
We took inspiration from CGCookie’s Learning Paths.
Professional 3d character and modular level prototyping kit
The second goal, at €24,000 is a set of professional 3d assets to prototype all sorts of games, inspired by the Unreal mannequin and the look of levels made with Pro-Builder for Unity. We’re going to provide you with:
An animated character with its controller, animation tree, and camera set up in Godot. We are
A modular level-design kit to efficiently design and prototype 3d gameplay.
We got in touch with the guys working on Open Mannequin, a similar project. They’re already a team we’re looking to help them if they want us to. Otherwise, we’ll roll our character based on the MIT-licensed Bony (but with modified proportions). We’re working with the film and game animator Luciano Munoz on this one.
Official Godot 3.1 new features tutorials
Lastly, if we reach €28,000 we will contribute an official tutorial series that covers the new features in Godot 3.1.
Visual shader editor, animation tools, changes in the interface, tileset editor, 2d and 3d physics improvements, typed GDscript… we will cover all the main features, and release all the videos and companion demos under a permissive license.
GDScript experiments and Code Guidelines
There’s a request that keeps coming in the community. You’ve been asking us to teach the best practices with the engine.
Godot’s node system is flexible. The engine doesn’t impose a project structure or design patterns on you. It does work best when you have general systems at the top of the tree and specialized nodes at the tip of branches, but you’re not forced to use a specific architecture like Model-View-Controller.
Using powerful features like signals too much can lead to spaghetti code if you’re not careful. That’s why we keep experimenting with new solutions, to avoid issues we’ve faced with our projects until now.
We’re doing much work there, and we’re working on guidelines to help everyone write accessible, clean, and scalable GDScript. As we figure out ways to better decouple our code, we will update them.
Razvan has been rewriting Open RPG to test new ideas, improve the code’s structure, and experiment with a few ways to structure entire projects and assets. Until we add it to the main project, you can look at his work on his fork.
The Work in Progress guidelines are already on the Kickstarter project’s repository, along with ten other open source demos! As usual, feedback is welcome.
However, that said, it’s time to get back to creating more content. Thank you for your time, and see you soon for more!
-
+
\ No newline at end of file
diff --git a/article/gdscript-progress-report-feature-complete-40/index.html b/article/gdscript-progress-report-feature-complete-40/index.html
index 5516da0f81..e95843bbe8 100644
--- a/article/gdscript-progress-report-feature-complete-40/index.html
+++ b/article/gdscript-progress-report-feature-complete-40/index.html
@@ -22,7 +22,7 @@
Note that in 3.x, you already can use this syntax for some cases (such as Color.from_hsv()) but it only works with const functions that return the same type as the base and that is actually constructing a value at runtime. In 4.0, this won’t be valid anymore for these cases, but we can have actual static functions.
Further optimizations
I’ve implemented a couple of things that will help improving GDScript performance (not directly, but we still plan to work on the VM performance before 4.0). Those are internal changes that won’t affect the way you code, but I’ll mention them here for completeness.
One of those is reducing the number of addressing modes, which will help us eventually have instructions with addressing modes baked in. This will reduce branching in the code which is something CPUs enjoy. Having less modes means we can have less permutations of each instruction, reducing the complexity and code size.
The other is using a special stack space for typed temporaries. This means that results of sub-expressions that are typed can be stored on the stack in a Variant without changing its type nor re-initializing it. This is particularly helpful on types that require memory allocation, such as Transform, since the allocation can be done only once per call.
Test suite
To improve the quality of the GDScript code and avoid regressions over time, I’ve added a test runner that verifies if the language code is performing as intended. I’ve had some help from Andrii Doroshenko who ported my suite to use the new doctest integration, effectively making the tests for GDScript part of the general test for the engine.
We don’t have a lot of test cases for now, but the number of tests will increase over time as tests are added together with bug fixes to avoid regressions.
Bug fixing
I’ve now shifted the focus to bringing GDScript to a more usable state even before 4.0-alpha, so more users can test it to verify how it’s working. For now, my focus are in the game-breaking bugs that stops people from even using GDScript. The small things can wait a bit longer to when we reach the bugfixing round after alpha is released.
-
+
\ No newline at end of file
diff --git a/article/gdscript-progress-report-new-gdscript-now-merged/index.html b/article/gdscript-progress-report-new-gdscript-now-merged/index.html
index 2f931d8a47..099bcfb006 100644
--- a/article/gdscript-progress-report-new-gdscript-now-merged/index.html
+++ b/article/gdscript-progress-report-new-gdscript-now-merged/index.html
@@ -5,7 +5,7 @@
George Marques4 August 2020
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.
As some of you might be aware, the refactor that I have been working on lately is now merged into the master branch. This is the work explained in previous progress reports.
See other articles in this Godot 4.0 GDScript series:
While I did already open a pull request to update the documentation, I’ll put here a short description of what have changed.
Annotations
We now have annotation support and that is used to replace a few of the keywords that were introduced along the way. This includes the RPC keywords, such as @master, @puppet, and @remote.
The previous export keyword is now replaced by a list of specialized annotations for each case. For example, if you want a range, you can use the @export_range annotation. There’s no need to set the type as an argument anymore, since it can be retrieved from the variable’s type specifier (e.g. @export var my_number: int).
This has an added benefit because those annotations feature code completion and hints for their arguments, which makes them much easier to use without having to remember all the possible combinations like before.
This also includes an @icon annotation that must be used instead of adding after the class_name like before.
Properties
The previous setget syntax was removed in favor of properties. It is meant to be more tied to the variable declaration and avoid you having to create dedicated functions (though you still can if you prefer). Another change is that, unlike setget properties always call their setter/getter even inside the same class. This gives users a consistent behavior which won’t cause confusion or lead to potential mistakes during a refactor.
await instead of yield
As you might already know, the yield keyword is removed in favor of await. It not only have a more meaningful name but it also takes advantage of first-class signals that were introduced in the master branch of Godot. The syntax is easier to understand and have less boilerplate (you don’t need to write the "completed" signal when waiting coroutines.
It is also more transparent if the function you called doesn’t always work as a coroutine (you don’t need to treat the special case), and it’s type-safe since you can’t receive a function state when you were expecting the return value.
super keyword
Instead of prefixing the function name with a period (.) now you must use the super keyword to call a function defined in the superclass instead of the overridden version. This also applies to constructors, making it more consistent in general and improving the flexibility.
Calling super() on its own will call the same function you are in but using the superclass implementation. If you need to call a different function you can use super.function_name().
Code completion
As mentioned in the previous report, code completion was a working in progress. Now it is essentially complete. I am aware that it could use some quality-of-life improvements, but this will be worked on later. For now it should be the same as it was before. If something is missing feel free to report an issue.
Remove multi-level calls
Another common source of confusion was removed. If you create an override of some lifecycle functions (such as _process or _ready) it still called the superclass implementation implicitly. Worse yet: some functions called the superclass before the subclass, and some went on the other direction.
This behavior is now completely removed. If you need to call the parent implementation, you can use the super keyword as mentioned above. This is common in OOP languages, so it should be more aligned to what user expects (which is evidenced by multiple issues reporting this behavior in the past). It also gives users control of when the super implementation should be called.
Note that methods defined in the C++ code are still called. This is needed to make sure engine behavior is correct (like the button _gui_input which is needed to execute the pressing behavior).
Testing
I spent a good chunk of the time testing GDScript implementation and fixed an amount of bugs and crashes along the way. If you find crashes or issues don’t be afraid to report it (if it wasn’t reported before). Eventually I’ll do a big round of bug fixes to stabilize it for release, but for now I’ll try to keep GDScript in a workable state and especially without crashes.
Future
Currently I’m working on an abstraction for the code generation interface. This will be helpful to create an ability to change the target backend language (which currently is only the GDScript VM itself) without having to change the compiler, eventually paving way to code optimization as well. More details on this will come in the next progress report.
After that I’ll start adding typed instructions to the VM which should increase the speed massively for when you use static typing in the script.
-
+
\ No newline at end of file
diff --git a/article/gdscript-progress-report-type-checking-back/index.html b/article/gdscript-progress-report-type-checking-back/index.html
index 4d70442019..a17f01eb38 100644
--- a/article/gdscript-progress-report-type-checking-back/index.html
+++ b/article/gdscript-progress-report-type-checking-back/index.html
@@ -5,7 +5,7 @@
George Marques6 July 2020
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.
After completing the new tokenizer and parser as mentioned in the previous reports, I started working on the code analyzer, which is responsible for type checking and also for used for other features like warnings and some optimizations.
This was done before as a second pass inside the parser but it was now moved to another class to make it clear that it doesn’t happen at the same pass thus avoiding issues with functions being called out of order (which happened by a few contributions that missed this detail).
See other articles in this Godot 4.0 GDScript series:
One of the main changes in the new type checker is that it always infer the type of expressions and variables. It does not force the variable type unless explicitly stated by the user, as it was before, but it’s now able to catch type errors in these cases, and potentially optimize based on types.
This also means that it’s easier to get safe lines (the ones colored in green) even without adding types to everything and more errors can be detected at the editor.
Enums can be used as types
A long requested feature is that enums should be also possible types. They are considered regular integers in general, but for type checking purposes they are considered a specific type. For example, setting an integer to a variable with an enum type is okay but setting from a different enumeration gives an error.
Warnings are back
The code was moved to a different file to avoid issues with circular includes. It also helps uncluttering the main gdscript.cpp file which is already long enough.
Some warnings were removed since they don’t apply to the new GDScript syntax, such as the one about the possibility of a yield which is not a concern anymore since the keyword is replaced by await. Some were added to cover new ground, like a warning for unused local constants, since those are now added.
Local identifiers are now better checked for usages and shadowing. So the iterator variable from a for loop or the binds in a match statement are treated like local variables and have the checks applied to them as well. This means that if you try to declare a variable with the same name as a match binding, you’ll get an error and if you don’t use the binding you’ll get a warning.
Better constant folding
The process of analyzing constant expressions and processing their result at compile time is commonly called “constant folding”. The old parser did that in the first pass (since it dated from back when GDScript had a single parser pass) but now it is done by the analyzer.
This means that now it’s possible to resolve constant names as well in all cases. For instance, if you type PI * 2 in your code, the analyzer will compute the multiplication at compile time, increasing a bit of performance at runtime. This also applies to user-defined constants, which reduces the burden of using those to replace common values.
GDScript cache singleton for mediating loading of scripts
Last year I’ve come up with an idea to cache scripts in order to fix the problems with cyclic dependencies in GDScript. I’ve made a pull request for the 3.2 branch but unfortunately it’s still lacking in some regards.
The idea is to allow only parsing the scripts without using the Resource Loader from Godot itself. This makes possible for the code to do type checking from dependencies without creating a loading loop. It also creates “shallow scripts” (that is, scripts that still don’t have the code compiled) so they can be referenced before being actually compiled.
I’m now integrating this idea with the new GDScript code to solve the problem from the root. Once it’s working I’ll also port it back to 3.2, as long as we can test it thoroughly to avoid regressions.
Properties syntax
As mentioned in the previous report, my intention is to remove setget and provide a more straightforward property declaration instead. This is now done with the addendum that lets users still use regular functions as setter and getter if so they wish.
Code completion
The code completion relies on the parser code, so the old version was removed. I’m now working on porting it to the new parser while adding extra completion needed in some cases, like enums in type hints, and completion for annotations names and arguments. This is still a work in progress so far.
Future
As mentioned, I still need to finish code completion. After that I’ll make a new PR since the code will be in a usable status, with GDScript having the same level of features as before (or more in some areas). This will allow the users to begin testing and we can fix potential bugs that I missed in my tests.
Afterwards I’ll start working on the interpreter to start doing performance optimizations.
-
+
\ No newline at end of file
diff --git a/article/gdscript-progress-report-typed-instructions/index.html b/article/gdscript-progress-report-typed-instructions/index.html
index 915f0f2894..87fa171206 100644
--- a/article/gdscript-progress-report-typed-instructions/index.html
+++ b/article/gdscript-progress-report-typed-instructions/index.html
@@ -5,7 +5,7 @@
George Marques22 October 2020
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.
It’s been a while since my last report because this particular task took me more time than I anticipated. GDScript now got a much needed optimization.
See other articles in this Godot 4.0 GDScript series:
Between my last report and this one I’ve beenfixingmanybugs in the new GDScript. While not thorough, it should be stable enough to not crash all the time. I am aware that a lot of bugs remain, but I’ll iron them out when the features are complete.
As I said before, if you found a bug not yet reported make sure to open a new issue so I can be aware of it.
Code generation abstraction
Before I delved into the interpreter, I created another class for abstracting the code generation process in the compiler. This allows new targets to be added without messing with the compiler itself by just adding a new implementation of that abstraction.
That should allow us later on to more easily add new targets like compiling to LLVM or C (note that those ideas are not settled, we still need to investigate the best way to do it). It also might simplify how we apply an optimization phase to GDScript code.
This doesn’t yet have a pluggable interface, so it’s hardcoded for the single target that we have for now (the GDScript interpreter itself) but once we have new targets we can easily adapt to our needs.
Typed instructions
I know many of you have been waiting for this. GDScript has had optional typing for quite a while, but so far it had only been for validation in the compilation phase. Now we’re finally getting some performance boost at runtime.
Note that some optimized instructions are applied with type inference but to enjoy the most benefit you have to use static typing for everything (you also get safer code, so it’s a plus).
So what kinds of instructions do we have? Here’s a short list:
Operations (such as +, or, &, etc.), when the type of the operands are known.
Subscript/attribute access (like a[b] and a.b), when the types of both the base and index are known.
Function calls for built-in and native (C++) types, when the base type is known.
Those get special cases when argument types are also known.
Built-in function calls (like sin(), randi()), when the type of the arguments are known.
Note that arguments that require conversion might not get a faster path.
Iteration (use of for loop) when the type of the iterated value is known.
Doesn’t sound like a lot but since those got a lot of variations for the type combinations, the number of instructions got quite a bit larger. Those are the most used and where performance matters more.
Why is this faster?
Having specific instructions for when type is known allows us to take shortcuts in the interpreter. For example, if we know we are adding two integer values, we can take the pointer for the integer values from the Variants and just add them (literally a + in the C++ source code). Before we had to not only look up the types of the operands but also the operation itself at runtime which takes a while.
Function calls for native types are also a very special case since we can take a pointer to the function and call it directly when the arguments are already validated. This is what is used in GDNative and C# for instance, since they have static typing by default.
How faster is it?
I have made a few synthetic benchmarks to test how faster a typed instruction was than a regular untyped one. This consisted in running all in a loop and measuring the time it took. Assuming the loop takes the same amount of time in both cases, the difference in time should be the instruction itself. Typed instructions are consistently faster in all tests.
Subscript/attribute: about 5-7% faster
Operations: about 25-50% faster
Function calls in built-in types (without pre-validated arguments): about 30% faster
Function calls in built-in types (with pre-validated arguments): about 70% faster
Function calls in native classes (without pre-validated arguments): about 70-80% faster
Function calls in native classes (with pre-validated arguments): about 120-150% faster
Built-in function calls: about 25-50% faster
Iteration: about 10-50% faster (dictionaries and strings have a lesser performance gain)
Those were measured with a debug build. It should perform better with release builds.
Can it be more optimized?
Yes, there are still room for further optimization. But since it can get quite complicated we left this for a later review. There are some inner working in the VM that could be better. For instance, we could reduce the type changes in the stack (when they are attributed a new value) which reduce the operations needed to perform the instructions, making them faster. We could also improve type inference to rely less on static typing and allow simpler code to still get a speed boost.
Also, code in GDScript is not yet optimized by the compiler. Once we reach that it’ll certainly improve overall speed of execution of the scripts.
I want to point out GDScript is not as slow as some imagine. Much of what you do is leveraged to the engine internals, which are built in C++ and optimized already. In my tests I had loops of 100,000 iterations and even the function calls (which are generally slower) were hitting about 70ms for running the whole loop (sure I do have a somewhat good CPU, but this is running single-threaded in debug mode). While it might be a bit slower than other languages, it’s definitely up for the task at hand (that is, making game logic).
Future
Now that this first optimization of the VM is complete, I’ll be a bit away from GDScript to focus on GDNative. Since it doesn’t have a dedicated maintainer anymore and it needs many improvements, especially on the usability side. We’ll meet with coredevs familiar with GDNative to decide what needs to be done and start working on it.
-
+
\ No newline at end of file
diff --git a/article/gdscript-progress-report-writing-new-parser/index.html b/article/gdscript-progress-report-writing-new-parser/index.html
index 8faa565834..ae5e9a74a2 100644
--- a/article/gdscript-progress-report-writing-new-parser/index.html
+++ b/article/gdscript-progress-report-writing-new-parser/index.html
@@ -39,7 +39,7 @@
Breaking things to make them anew
I wanted to make this new parser working with the current system sooner rather than later. So I amended the dependencies on the old parser and tokenizer to use the new one. Since this is rather time consuming, a lot of things were disabled in the meantime.
There’s still a long road ahead to make GDScript a better language in general. The next step is to read the type checks so the systems that depend on it can also be reactivated. Hopefully the new type checker will be more precise than the previous one (I learned a lot since then). And it will allow use of some new features like typed arrays.
-
+
\ No newline at end of file
diff --git a/article/gdscript-progress-report-writing-tokenizer/index.html b/article/gdscript-progress-report-writing-tokenizer/index.html
index 3ab0caee2e..47d9abbd87 100644
--- a/article/gdscript-progress-report-writing-tokenizer/index.html
+++ b/article/gdscript-progress-report-writing-tokenizer/index.html
@@ -177,7 +177,7 @@
The question mark can be recognized as an attempt to use the C-style ternary conditional operator, so we can show the user the correct operator for GDScript.
We also recognize conflict markers so you can easily notice that you have a merge conflict in the file.
What comes next
Now that the tokenizer is pretty much done, I’ll start rewriting the parser, which is responsible for reading the sequence of tokens and making sense out of them, deciding if it’s a function, variable, expression, etc. I’ll write more about it when I have something to show.
-
+
\ No newline at end of file
diff --git a/article/george-marques-will-be-working-full-time-project/index.html b/article/george-marques-will-be-working-full-time-project/index.html
index 2675b10da2..2b138ec171 100644
--- a/article/george-marques-will-be-working-full-time-project/index.html
+++ b/article/george-marques-will-be-working-full-time-project/index.html
@@ -5,7 +5,7 @@
Juan Linietsky18 September 2019
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.
Goal Met!
After some months, the project has received enough funding to be able to do a new full time hire! Thanks hugely to everyone who is supporting us, as your help has allowed us reaching this far!
Pedro Estebanez is still on track
Unfortunately, it was difficult for us (and him) to predict when the goal would be met so, due to timing issues, he recently got into a new paid contract with a client (Pedro has been the first of our contributors who became a professional Godot consultant, and works with many companies using the engine). This makes it impossible to for him to work with us for the time being. He still wishes from the bottom of his heart to eventually work full time for the project, so the next Patreon goal is still reserved for him.
George Marques
Some months ago, due to the growing amount of potential sponsors and donations, we had to discuss potential hires. The project is blessed with a large amount of absolutely brilliant contributors and it is our wish that as Godot keeps growing and securing more funding sources, we will be able to have more of them on board working full time. Hope this comes true in the coming years.
George is from Sao Paulo, Brazil. I had the pleasure of meeting him some months ago during the Big Festival (to where I was invited). He is part of the Godot project leadership comitee, along with me, Ariel Manzur, Rémi Verschelde, Julian Murgia and HP van Braam.
He is one of the longest standing and most reliable contributors and an excellent generalist. He is responsible for the UWP port, as well as a lot of improvements and fixes across the engine. He is the main contributor behind the GDScript rewrite for Godot 3.1, which now includes optional typing and a several quality of life improvements (he is the current GDSCript maintainer, along with Bojidar Marinov). Together with Rémi, George has also managed our activities related to Google Summer of Code, and has been present last year during the mentor summit. Thanks to their fantastic work on this area the project has managed to get more student slots granted this year.
Besides continued work on GDScript (on his schedule is the addition of typed instructions, which will massively improve run-time performance, and eventually compilation of scripts to C), he will work together with Rémi, our project manager, doing general bug-fixing and code reviews, helping alleviate our large bottleneck in this area.
On a side note, please remember that for C# support, Ignacio Roldán is already working full time for the project thanks to a generous grant from Microsoft.
Future
The bureaucratic part of the hire (he needs to sign with Software Freedom Conservancy) will take around a month or two, so he will effectively begin working in November. Meanwhile, we hope the level of donations stabilizes over the goal.
Our next Patreon goal is to be able to hire yet another generalist, so we added a new goal for this task, hoping we can finally hire Pedro this time. If you are not yet, please help us reach this goal by becoming a patron!
-
+
\ No newline at end of file
diff --git a/article/get-ready-fosdem-and-godotcon-2018/index.html b/article/get-ready-fosdem-and-godotcon-2018/index.html
index 83289261ab..2ba12aced7 100644
--- a/article/get-ready-fosdem-and-godotcon-2018/index.html
+++ b/article/get-ready-fosdem-and-godotcon-2018/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde11 December 2017
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.
Last year in February, we attended the FOSDEM and organized our very own GodotCon (a.k.a. GDC, the GoDot Convention), and it was a great community time for all who could attend in Brussels, Belgium.
For the coming year, we are lucky to be selected again to have a Godot stand at the FOSDEM 2018 on 3 & 4 February 2018 in Brussels, and we will organize another bigger GodotCon on 5 & 6 February 2018, also in Brussels.
And it gets better: our lead developer Juan “reduz” Linietsky is coming all the way from Buenos Aires to Europe to spend those four days with the community, so it’s a great opportunity to meet one of the minds behind Godot Engine!
TL;DR: Where do I sign up?
Both events are free of charge for everyone, and for the FOSDEM you do not even need to register: just show up and say hi at the Godot stand!
For GodotCon however, registration is mandatory as we need to know how many persons will be there to find an appropriate venue in Brussels. To help us with the organization, we ask that you register as soon as possible, and before 31 December 2017.
You can also indicate on that form if you plan to attend FOSDEM, so that we know who to expect.
FOSDEM 2018
FOSDEM is the major European event focusing on Free and Open Source Software (FOSS). Godot will have a stand there (Building K, level 2) where we will be distributing and selling some goodies (T-Shirts, stickers) and most importantly presenting our favourite engine and some games to the FOSDEM visitors. More than 8,000 visitors are awaited, and we hope that many will be impressed by our Godot 3.0 demos!
There might be some Godot-related talks, but we are still waiting for a confirmation from the FOSDEM organizers (the event is increasingly popular and they have hundreds of talk proposals to choose from).
The FOSDEM is a great opportunity to discover new projects (see the stands) and attend great talks (see the schedule - still in progress) from top-notch free software contributors. It will also be the occasion to meet other Godot users and contributors, at our stand or around a few Belgian beers :)
Practical infos (location, schedule, etc.): See FOSDEM.org and our Events page.
GodotCon 2018
Update 10.01.2018:See this blog post for information about the GodotCon venue as well as our Call for Proposals.
Two days in a crowded event is not enough! To get more time together to actually discuss our projects, learn new things and work together on games and on the engine, we are organizing a 2-day event focused on Godot right after the FOSDEM (on Monday 5 and Tuesday 6).
Registrations are still ongoing, but given the recent growth of the community we expect between 40 and 100 attendees; we’ll size things accordingly so we need you to register as fast as possible to help us with the organization.
There will soon be a Call for Proposals so that everyone can propose a talk, a workshop or any kind of activity that we could do during those two days. Last year was a big success, and we expect the new GodotCon to be even better, both due to the higher number of attendees and the presence of our lead developer Juan!
The exact venue is still to be determined, as soon as we have a good overview about our numbers.
-
+
\ No newline at end of file
diff --git a/article/get-ready-github-gameoff-godot/index.html b/article/get-ready-github-gameoff-godot/index.html
index e1d1a3d9f4..d534665b05 100644
--- a/article/get-ready-github-gameoff-godot/index.html
+++ b/article/get-ready-github-gameoff-godot/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde30 October 2017
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.
GitHub has announced the 5th edition of its Game Off game jam, hosted on itch.io from November 1st to December 1st 2017.
The main feature of Game Off is its focus on free and open source tools for game development, and this is obviously something that we consider highly in the Godot Engine community, as a fully libre 2D and 3D game engine.
We encourage all existing and aspiring game developers to participate in this jam using our current stable release Godot 2.1.4. For newcomers, this blog post lists some of the great learning resources created by the community to help you get started with Godot.
Feel free to experiment with other games engines or frameworks too, such as Phaser, LibGDX or LÖVE, but of course we are hoping to see a high percentage of the Game Off entries made with Godot!
When you share screenshots or videos of your game on social media, please use the #GitHubGameOff hashtag as well as #GodotEngine, to show the community what great projects are being worked on!
Kudos to the first Godot user publishing an open source shader to achieve such an effect on our Asset Library :)
Getting started with Godot
If you’re new to Godot, or started only recently, you might be looking for good resources to learn how to make games with our engine. The following is a short list of recommended resources, but feel free to use different ones from the wealth of video tutorials and demos that have been produced by the Godot community over the years.
It contains many tutorials about the different features of the engine, including a step by step tutorial which should give you a good introduction to the core concepts of the engine such as nodes, scenes, instancing and scripting.
The official documentation also includes the Class Reference, where the API of the various nodes is documented. It’s also included directly in the editor when you press the “Classes” and “Search Help” buttons in the script editor.
Community tutorials
Community members have produced a great number of video tutorials for Godot 2.1, as well as quite a few text-based tutorials for those who prefer that. Some are standalone tutorials about a given feature or concept, while others are series that will lead you through making a simple game from A to Z. Here’s a selection:
KidsCanCode’s Godot 101 is a Godot learner’s favorite and will teach you all the concepts you need to know to get started in about 3 hours of video content. Don’t be fooled by Chris’ tutor name, the series is a great fit for kids but also very suitable for grown-ups… and among game devs, we’re all still children at heart, aren’t we? :)
Angega Studio’s Make a Space Shooter Game is another series that will learn you through the conception of a 2D space shooter from start to finish, in about 2 hours of video content.
GDquest’s 30 Tutorials in 30 Days series offers short and well-edited tutorials that will introduce you to a given feature. It’s perfect for users with some development experience either from Godot or from another engine, and that want to quickly learn how to do something specific.
GameFromScratch’s Godot tutorial series offers both video and text versions of great tutorials covering many aspects of the engine. The earlier ones were for Godot 1.x, but the concept they cover are still the same in today’s 2.1.x, it’s mostly the UI that was enhanced a bit.
Official demos and community projects
There are many official demos included in this archive, such as a simple Pong game, 2D and 3D platformers, a space shooter, and many small demos meant to showcase how to use a given feature, such as particles, screen space shaders, lights, navigation meshes, etc.
Next to those, there are many free and open source community projects that you can learn from, such as those made for our previous Godot community game jams (first, second and third). You can use GitHub’s Explore feature to find repositories tagged with Godot, or GDScript, or search for trending GDScript projects.
Community communication platforms
And of course you are not alone to learn how to use Godot! We have many community platforms where you can discuss with other users and learn from them. You can pick the one(s) you like best and should always find nice users to interact with.
Don’t miss the Godot Questions & Answers, which likely already has answers for some of the questions you might be asking yourselves. If not, don’t hesitate to ask your question, being both concise and specific, and you should quickly get some help.
Finally, if you think that you hit a bug in the engine, please report it on GitHub. Make sure to follow the proposed issue template (filled in automatically) to help us help you.
Can I use Godot 3.0?
Yes and no :)
You might have seen videos about Godot 3.0’s upcoming features, and be eager to test it, but it is not yet released officially. We will soon (a couple days at most) release a development snapshot, Godot 3.0 alpha 2, which you can use if you want, but you should be ready to face bugs and difficulties exporting games (for example exporting games using C# is not possible at this time, and should be fixed in the coming weeks).
If you feel adventurous, don’t hesitate and have fun with the development snapshot, but check beforehand that you’ll be able to distribute your game in a playable manner for the jam. If you are new to Godot, we really recommend to stick to the stable version for which you will find a lot more learning resources.
-
+
\ No newline at end of file
diff --git a/article/github-game-off-and-godot-are-winning-combination/index.html b/article/github-game-off-and-godot-are-winning-combination/index.html
index 91d5a22062..0b94f63234 100644
--- a/article/github-game-off-and-godot-are-winning-combination/index.html
+++ b/article/github-game-off-and-godot-are-winning-combination/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde29 October 2018
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.
And this bold statement is not (only) marketing speak, the winner of GitHub Game Off 2017 was indeed a Godot-made game by Securas, Daemon vs Demon.
The 2018 edition of the month-long jam focusing on free and open source game development tools is about to start again on November 1st. Check the details on itch.io: Game Off 2018.
Edit: The Game Off 2018 theme is HYBRID! Have fun!
This is a great opportunity to discover Godot if you’re not familiar with it yet, get some more experience if you know it already, or get to know some of the other awesome free and open source game engines or frameworks out there such as Phaser, LÖVE or LibGDX.
And make sure to review the tons of available free and open source tools that could be useful for your project, such as Blender, Krita, GIMP, LMMS… and many more! Our contributor Calinou maintains a very useful list of FOSS game development tools and resources, awesome-gamedev.
When you share screenshots or videos of your game on social media, please use the #GitHubGameOff hashtag as well as #GodotEngine, to show the community what great projects are being worked on!
We hope that many Godot users will take part in the jam, and maybe, like in 2017, win it! At the very least we wish you all the best of luck and a lot of fun :)
Getting started with Godot
If you’re new to Godot, or started only recently, you might be looking for good resources to learn how to make games with our engine. The following is a short list of recommended resources, but feel free to use different ones from the wealth of video tutorials and demos that have been produced by the Godot community over the years.
Installing the engine
First of all, head over to the Download page to get the latest stable version of Godot – you can also install it from itch.io or Steam.
For new users, we recommend the “classical” build (as opposed to the “Mono” build with C# support, currently in alpha) and the GDScript language, which you should be able to learn very fast. Experienced C# users are of course welcome to try their hand at the Mono build, just make sure to have the Mono SDK in version 5.12.x installed.
Experienced Godot users may also want to try the nightly builds of the upcoming Godot 3.1, currently at the alpha stage. An official 3.1 alpha 2 build should be published in coming days. Keep in mind that it’s software in development and that bugs could hinder your productivity or capacity to export stable builds to submit to the jam, so proceed with caution :)
It contains many tutorials about the different features of the engine, including a step by step tutorial which should give you a good introduction to the core concepts of the engine such as nodes, scenes, instancing and scripting.
The official documentation also includes the Class Reference, where the API of the various nodes is documented. It’s also included directly in the editor when you press the “Classes” and “Search Help” buttons in the script editor.
Community tutorials
Community members have produced a great number of video tutorials for Godot 3.0, as well as quite a few text-based tutorials for those who prefer that. Some are standalone tutorials about a given feature or concept, while others are series that will lead you through making a simple game from A to Z.
Have a look at this page for a list of recommended resources - but make sure to use the official documentation too, especially as many of these tutorial makers are contributing to the docs.
Official demos and community projects
There are many official demos included in this repository, and also available directly from the Asset Library when you start Godot. There are simple games such as Pong, Dodge the Creeps (from the docs), 2D and 3D platformers, a space shooter, an RPG, etc., as well as many small demos meant to showcase how to use a given feature, such as particles, screen space shaders, lights, navigation meshes, etc.
Next to those, there are many free and open source community projects that you can learn from, such as those made for our previous Godot jam in June 2018. Check also games made for the firsttwo Godot Wild Jams as many come with source included. You can use GitHub’s Explore feature to find repositories tagged with Godot, or GDScript, or search for trending GDScript projects.
Community communication platforms
And of course you are not alone to learn how to use Godot! We have many community platforms where you can discuss with other users and learn from them. You can pick the one(s) you like best and should always find nice users to interact with.
Don’t miss the Godot Questions & Answers, which likely already has answers for some of the questions you might be asking yourselves. If not, don’t hesitate to ask your question, being both concise and specific, and you should quickly get some help.
Finally, if you think that you hit a bug in the engine, please report it on GitHub. Make sure to follow the proposed issue template (filled in automatically) to help us help you.
-
+
\ No newline at end of file
diff --git a/article/gles2-and-gdnative-progress-report-1/index.html b/article/gles2-and-gdnative-progress-report-1/index.html
index 796554c9fc..3e2808ab8f 100644
--- a/article/gles2-and-gdnative-progress-report-1/index.html
+++ b/article/gles2-and-gdnative-progress-report-1/index.html
@@ -8,7 +8,7 @@
karroffel23 January 2018
This article is from January 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.
Introduction
Thanks to our very supporting patrons I have the opportunity to work part-time on Godot! My work will be mostly about implementing an OpenGL ES 2.0 compatible rendering backend for Godot 3.1, as well as maintaining the GDNative system and bindings.
The first month I spent on getting started and familiar with the rendering in Godot.
Since I want to be able to help out with more rendering related tasks in the future, in places where existing code could be re-used, I am rewriting those parts myself to get a better understanding of the code.
Roadmap
Because I am still new to the rendering system in Godot, I might not be experienced enough to make good estimates of what can be achieved, but the rough roadmap looks like this.
Done December 2017
reading the OpenGL ES 2.0 and GLSL ES 2.0 specifications
enable use of OpenGL 2.1 / GLES 2.0 context
create an empty implementation of rasterizer interface
implement basic texture loading
implement render targets
generate C++ classes for GLSL shaders at compile time
show splash screen
basics of 2D item rendering
some GDNative related assistance
Planned for January 2018
implement more 2D items
editor working with GLES 2.0
adapt shader compiler to work with GLSL ES 2.0
2D lightingpostponed
finalize GDNative C API as much as possible
improve GDNative C++ bindings
Planned for February 2018
meet with other developers at FOSDEM and GodotCon
load meshes
render meshes
implement basic PBR
directional lights
Details about work in December 2017
reading the OpenGL ES 2.0 and GLSL ES 2.0 specifications
The first few days I spend reading the GLSL ES 2.0 and OpenGL ES 2.0 specifications to get a more specific idea of what can and cannot be done using that API.
Even thought I didn’t try to learn it like a school textbook, it was worth it since I now know where I can go back to in case of any ambiguities.
enable use of OpenGL 2.1 / GLES 2.0 context
The OS implementations for each platform decide how to create an OpenGL context. For the X11 platform (which I am currently developing on) it is hardcoded to create an OpenGL 3.3 context.
An enum was added that specifies which context to create specifically, but for now it simply points to the “old style” way of creating the context.
After this is done, OpenGL 2.1 functions can be used.
create an empty implementation of rasterizer interface
Juan’s work on the GLES 3.0 renderer a little bit over a year ago contained changes to the class architecture used for the rendering backends. With Godot 2.1 and before, all the rendering related code was contained in one RasterizerGLES2 class.
In 3.0 this architecture has been revisited and split up over multiple classes, as explained in Juan’s first progress report.
Because of that it’s not possible to re-use much of the 2.1 rendering code (although a lot of it is still relevant and helpful as a reference).
The first step towards creating a new rendering backend is to create classes that implement those new interfaces. The goal here was just to make the new code compile properly.
implement basic texture loading
The RasterizerStorage interface has methods for creating and modifying various resources such as textures, shaders, materials, meshes and many more.
The first step towards getting the 2D engine working was to have proper texture loading.
Textures in OpenGL are server-side (so usually a GPU or depending on your hardware also a CPU) chunks of memory that contain image data.
Much of the texture loading code could be taken from the GLES 3.0 code as well as the 2.1 rendering code.
implement render targets
In Godot, render targets are resources that can be used as the destination of draw calls. A very famous Godot Node named Viewport makes use of that.
Render targets are implemented using OpenGL framebuffer objects. The OpenGL specification defines two types of framebuffer objects: window manager created and application created.
The window manager created framebuffer (there only exists one double buffered one) is the one that is used to display things in the associated window. Application created framebuffers can be used to issue render commands that won’t be displayed on the screen.
So the render targets in Godot are implemented using application created framebuffers. The buffers of a framebuffer (for example the color buffer - the pixel colors that can be displayed on screens) can also be used as textures if set up accordingly. This is how ViewportSprites are implemented.
generate C++ classes for GLSL shaders at compile time
Those shaders are written in GLSL, the GL shading language. In Godot, the shaders are in separate files containing the GLSL source code, as well as some special annotations.
Godot’s build system, scons, uses python which we use to create C++ source code generated at compile time. In this specific case, a python function parses the GLSL code and creates C++ classes wrapping the shaders.
The GLES3 backend already uses this with a bit of added functionality, so for the GLES2 backend a few minor modifications had to be made.
show splash screen
After many days of coding in the dark, the sight of this first rectangle was quite relieving.
A few changes in the canvas shader and this lovely face showed up on the screen.
A list of commands describes what, how and where should be drawn on the current render target. These commands can be as simple as “draw a rectangle with this texture at this position”. The shader used when drawing those commands is the previously mentioned canvas shader.
Just rectangles are enough to show text and some other things used in GUIs.
some GDNative related assistance
Apart from the work on the GLES2 backend there were also some changes related to GDNative. I assisted the contributors when working on these features.
Bastiaan Olij submitted a nice GDNative/NativeScript tutorial for the docs. After giving some feedback, the Pull Request was ready to be merged and can now be found in the online docs!
Another great contribution from Geequlim found its way into the Godot editor: an editor plugin for creating GDNativeLibrary resources.
Future
Stay tuned for the next progress report for the month of January. This report was a little bit delayed, so you can expect the next one early February.
Seeing the code
If you are interested in the GLES2 related code, you can see all the commits in my fork on GitHub.
-
+
\ No newline at end of file
diff --git a/article/gles2-and-gdnative-progress-report-2/index.html b/article/gles2-and-gdnative-progress-report-2/index.html
index d4c82a7b0a..6253761ca1 100644
--- a/article/gles2-and-gdnative-progress-report-2/index.html
+++ b/article/gles2-and-gdnative-progress-report-2/index.html
@@ -25,7 +25,7 @@
In the new GLES2 backened I decided to use a vertex + index array buffer instead to reduce the number of draw calls. For each vertex the fitting UVs get calculated before the draw call. Because of some stupid typos I had a hard time getting this right, but at least I got a nice UV-debug screenshot out of it.
Once this was all working, the elements rendered correctly.
A nice consequence of using a element array buffer for rendering instead of different draw calls is that the center rect rendering can be disabled and enabled with very little overhead.
add polygon and GUI primitive rendering
Even with Ninepatch elements rendering the Godot editor didn’t really look like it should yet.
This is because the editor uses Items that use CommandPrimitive commands, which can be used to draw lines, triangles or rectangles with easy to set up custom UVs and colors.
With that done, the editor almost rendered correctly, except for some incorrect clipping. (which got fixed shortly after this screenshot got taken)
start work on shader compiler
As written about in a past dev-blog, the Godot shader language got reworked completely for the 3.0 release, meaning that the new GLES2 renderer needs to support that language as well.
This is done by using the Godot built-in shader parser and compiler which outputs an abstract syntax tree (AST) which can be used for further processing.
To support the Godot shader lanuage, the abstract syntax tree needs to be translated into the appropriate target language, in this case GLSL ES 2.0. This is done in the ShaderCompilerGLES2 class.
The _dump_node_code method is used to output a String for each kind of node in the AST. Recursively, this method is used to generate the GLSL code for the whole shader.
Because GLSL ES 2.0 is more limited than GLSL ES 3.0, some features need workarounds or just won’t be supported.
For example, unsigned integers are not supported in GLSL ES 2.0, so as a workaround they will be converted to signed ints.
Many functions supported by GLSL ES 3.0 can’t be used, such as the inverse() function for matrices, so either they will have to be re-implemented manually in code (without possible hardware support) or be plainly not supported at all, but this is still up for discussion.
Custom shaders are still in an early stage, but they already work inside the editor and in games and support hot-reloading just like with the GLES3 backend.
add circle rendering
One of the last few item command types unimplemented for 2D rendering was the CommandCircle. While the initial implementation had a fatal bug, it helped uncover a more hidden bug that caused problems in the editor UI later on.
Future
The big milestone of basic 3D rendering is still ahead and I’m very excited to get my hands dirty. A few things in the 2D rendering still need to be implemented, but overall the 2D experience should be pretty decent by now.
Seeing the code
If you are interested in the GLES2 related code, you can see all the commits in my fork on GitHub.
-
+
\ No newline at end of file
diff --git a/article/gles2-and-gdnative-progress-report-3/index.html b/article/gles2-and-gdnative-progress-report-3/index.html
index 0066101174..8896a9b78a 100644
--- a/article/gles2-and-gdnative-progress-report-3/index.html
+++ b/article/gles2-and-gdnative-progress-report-3/index.html
@@ -5,7 +5,7 @@
karroffel21 March 2018
This article is from March 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.
Introduction
Another month, another progress report! This time with the early beginnings of 3D rendering in GLES2 and some GDNative ecosystem updates.
Roadmap
Done February 2018
meet with other developers at FOSDEM and GodotCon
2D rendering stabilized
2D engine merged into master branch
NativeScript 1.1 extension
Rust binding guidance
3D viewport drawing
mesh loading
basic mesh drawing
Planned March 2018
NativeScript 1.1 integration for C++
fix material implementation
implement spatial shaders
skeletal animations
Details about work in February 2018
meet with other developers at FOSDEM and GodotCon
As announced in an earlier blog post, the GodotCon took place in Brussels (right after the FOSDEM), where a lot of cool and interesting people showed up. It was a joy to be there and talk with other people about things we love - free and open source software and game development!
As this is a progress report and not an event report I’ll keep this section short, but I had a great time hacking with other people and getting to know more Godot users.
2D rendering stabilized
While a most of the 2D engine was already working, some bugs kept the editor from being fully usable and also caused problems in regular game projects.
The main bug that was keeping me busy for weeks was related to a shader bind that was not descriptive enough when blitting a viewport to the screen. “What does this mean?” you might ask.
Everytime Godot draws something it has to draw that something somewhere. Godot calls these “things” viewports. (That’s why the root node of any SceneTree is always a Viewport!) Internally, viewports are implemented by “framebuffer objects” in OpenGL, which are basically just a set of buffers or images that can be used to draw to.
The root node viewport in Godot is special, because everything that gets drawn into it will be displayed in the actual window. The drawing to the window happens by using a viewport as a texture and then displaying that in the correct position in the window. This act is called “blitting”. The shader code used for blitting is the same as for drawing rectangles with textures - only the texture is the content of another viewport.
OpenGL works by creating a context for the running process/thread, which is a state machine that gets modified by OpenGL function calls. If some state is set then it stays that way until it gets set to a different state.
This was a lot of explanation for this bug fix, but what it boiled down to is that the editor would sometimes become unresponsive if certain actions or popups would be triggered. The error occured when something that is not a rectangle got drawn last before the blitting happened. The blitting didn’t set up its own state completely, so a previous draw call would leave the OpenGL context in a non-working state for blitting.
Once this mistake was spotted it was a fix as easy as adding a few lines, but I didn’t know what was happening for weeks, so I just wrote this much about it to get rid of some frustration :P….. Anyway, 2D is working pretty well now!
2D engine merged into master branch
Because of the previously mentioned fixes it was considered useful to merge the current 2D engine into the master branch, so other contributors can look through the code and can try to make it run on more platforms and uncover bugs and errors (which were found thanks to multiple people!).
Before the pull request could be opened, the selection of the rendering would have to be decidable at runtime (more specifically, engine startup) and not require a compile time change. If you are using a Godot master branch build you can test the 2D (and report bugs later on) by switching the rendering backend in the project settings under rendering/quality.
The (by now merged) pull request can be found here.
Many people helped since to make the renderer work better and on more platforms! Thanks go to Emanuele Fornara, bruvzg, and possibly other people I forgot to mention, I’m sorry :D
NativeScript 1.1 extension
After talking to Juan and Marc at GodotCon I realized, that some part of GDNative can be enhanced - instance binding data!
So far in NativeScript the fact that Godot scripts are making use of delegation instead of actual inheritance (I’m sorry GDScript/C# users that didn’t know) wasn’t hidden from the programmer. When calling methods of a base class some indirection through an owner of the script had to be made. This isn’t too much of a problem in practice, but it isn’t as “programmer friendly” as hiding those things behind inheritance.
GDScript hides the delegation by actually calling the owner in every “self-call”. So it is dealt with in the bytecode to do the correct call.
C# faced the same problems, as inheriting a Godot base class would mean that those are already valid to use, with or without a “script class” inheriting from them. For that matter so called “instance binding data” fields have been added to the core Object class, which can be used to store data for language bindings for each object.
In practice, the most common use case is to create wrapper objects (which contain a field that points to the actualy object) in the langauge binding, then Godot will keep track of the objects lifetime and will notify the scripting language when the Object gets destroyed. This makes for nicer code for the programmer.
The PR implementing the API for this for NativeScript can be found here.
Rust binding guidance
Also at GodotCon I got to talk to Nicolas Silva, a webrender (Firefox rendering engine) programmer and Rust enthusiast!
We were talking about the state of the Rust bindings for Godot’s NativeScript and how the current situation should be best dealt with.
As not many people actually know, Rust bindings were the first attempt to bind any language to “DLScript”. vurpo worked on the first implementation with me at FOSDEM last year. Since then there hasn’t been much time for her to continue working on them.
Even though there has not been much development at the time, there has been a lot of community request for Rust bindings, so much that multiple people started working on bindings.
So now I’m happy that Nicolas tries to bring the community to one place with one “official” language binding, where he tries to do as much work as is possible for him (but because he has a lot of other cool projects he can’t devote too much time to the bindings), so any people interested in using Rust with Godot should definitely check out the language bindings and, if possible, report bugs and contribute :)
3D viewport drawing
Now that most of the 2D rendering is mostly stable, it’s time to move on the 3D to get something showing. For that a new shader has to be used, the scene shader, as it can be found here. This first shader does basically not much but fill the entire draw area with one color - not very interesting.
After some confusion with the proper viewport clearing order this beautiful view was to be seen.
mesh loading
As mentioned previously, all graphics related “resources” are handled in the rasterizer_storage_gles2.cpp file, where the mesh API has to be implemented in order to get the mesh data in a renderable format.
Most of the code could be re-used from the GLES3 implementation (except for things like VAOs).
Pretty much all that gets displayed in the 3D viewport are meshes - the gizmos, the grid, the camera symbol etc.
So with this in place the previous shader will generate images like this
This is the gizmo for an object, but without proper perspective added to it.
basic mesh drawing
The next step was to respect the perspective for each draw call. With the shader taking care of that the pictures start to resemble something more correct.
Unfortunately, the way the drawing was done and the OpenGL state caused not all meshes to render properly, so the view of all elements in the scene rendering properly has to wait for the next progress report :)
Future
3D rendering is quite fun, but there are still many things I need to learn, as well as improving my understanding of the control flow in some more crowded parts of the renderer. Overall I can say that I’m excited to do more of these things that look scary from the outside, but once you find your way in aren’t magic at all.
Seeing the code
If you are interested in the GLES2 related code, you can see all the commits in my fork on GitHub. Other contributions are linked in the sections above.
-
+
\ No newline at end of file
diff --git a/article/gles2-and-gdnative-progress-report-4/index.html b/article/gles2-and-gdnative-progress-report-4/index.html
index d1aab7d7fe..11bdd0f4a0 100644
--- a/article/gles2-and-gdnative-progress-report-4/index.html
+++ b/article/gles2-and-gdnative-progress-report-4/index.html
@@ -42,7 +42,7 @@
To test those things (and some others, work from April is already available), check out the nativescript-1.1 branch of the C++ bindings here, as well as an updated version of the C++ SimpleDemo on the cpp-nativescript-1.1 branch of the GDNative-demos repository here.
WIP godot-rust low level improvements
Steadily gaining more popularity, the godot-rust bindings are getting more attention from new contributors. I tried to check out the new bindings and notices some problems in the workflow for testing the bindings, so I added small complete godot projects to the repository, so things can be reasoned about in context, with all the scenes and environment in place.
Further, the Rust bindings make heavy use of macros for the “script-class” definition, some users said that the heavy use of custom syntax can be distracting and makes things less clear. This is tracked in an issue, but I thought it could be a fun way to get more into the current and new codebase.
Most of my efforts have been focused on being able to define script classes without needing macros, while still offering some useful macros that are completely optional.
Here is a link to a file to show what “low level class registering” might look like in future (this is already working code).
NativeScript classes expose some function pointers with C linkage with a certain signature. To ease the “connecting” of the C-compatible function and the actual Rust function, a macro has been added that generates said C function which will automatically call the Rust code. This is completely optional, the C function can be created manually, but this is generally not a nice thing to spend your dev-time on. The same has been done for constructors and destructors.
The work-in-progress commit can be found here, I plan to open a pull request as soon as I finish up the commits properly.
perspective rendering
Now finally the more visual part of the progress report! Last time I promised more fancy screenshots, here some perspective-correct renderings of some meshes.
No color, no grid on the ground…? Yes, some more invalid OpenGL state was fixed and a first attempt to get spatial shaders working and then this could be seen.
Getting there, slow but steadily :D
material API refactor
This point actually took most of the development time this month, it was a rather frustrating and iterative process to find out how to best handle materials and shaders.
Some background on materials first!
In Godot, a material basically consists of a shader and a list of parameters (name => value pairs) that get passed into the shader. Materials also include other things, like blend modes but the problematic part were the material parameters.
Since OpenGL 3.1, Uniform Buffer Objects, short UBOs, can be used. UBOs are chunks of memory that contain data that is available “globally” and immutably in every shader stage.
The TIME variable in shaders? Part of a UBO. Texture handles? UBO. Camera projection matrix? Also UBO. Those things don’t change in a single draw pass, so they get grouped into a buffer which can then be updated all at once.
In the GLES3 renderer, material parameters get assigned an offset in a UBO, then that UBO can be filled and used for a draw call.
In GLES2 however, UBOs do not exist. Every uniform (a “global” value accessible in all shaders) has to be set individually for each shader.
This is where many iteration and refactoring have been focussed on. Do those values get set when the material changes? No, drawing might happen later in time and the uniform value lost. Do the values get saved in the shader and the shader sets them up when needed? This is rather complex when user-defined shaders come into play, it’s possible, but it doesn’t feel right and caused many bugs.
After all those iterations, I settled for an approach where the shader gets a reference to the material that will be used, and then, only when the shader will be used for drawing, the shader will set all uniform values accordingly.
Some type-system hacks are needed because C++ doesn’t like forward declared inner classes (if someone knows how to do it, please, tell me :D ), and I came up with this code. There is a lot of code that deals with getting and selecting the right uniform type/call, but this way the information from custom shaders can be used more efficiently. With UBOs, this comes natural, and very similar code exists in the GLES3 renderer.
In the end, this approach works pretty well and seems very clear to me, and after all those refactoring I can safely say: UBOs are missed. :D
material passes and renderlist
Up until that point (well, the refactorings and this kind of blend together, but I hope it’s clear what I mean) the drawing was very straighforward.
Get the next available thing to draw
if you can draw it, set the GL state up properly
render.
The code was relatively small and rather simple to understand and get an overview over, because it was so straighforward. But as with many things, this simplicity becomes problematic at some point. In this case no optimization was done at all. Material passes weren’t possible and dealing with shader state became a pain, so it was time to move to a more flexible implementation: the renderlist!
The RenderList is an array of elements and a list of pointers to those elements which need to be drawn.
The cool thing is, that each element can get an index assigned on which they can be sorted. So things in the front will be drawn before things in the back, that helps to reduce overdraw by making use of the depth-buffer. Meshes with similar shaders can be grouped together so that shaders don’t need to be unloaded and loaded again, and many other cool things.
While filling this list, it is very easy to add in a second draw pass for a surface with a different material. This is how the Next Pass in materials is implemented.
The RenderList gives much flexibility while also making simple optimizations very easy to set up.
basics for skeletal animations
Another under-the-hood development was the initial work on Skeleton resources. At that point, a skeleton could not deform a mesh yet and wasn’t very useful, but the basic storage for bone transforms was already in place. Depending on the hardware that Godot is running on, the bone information might be stored in different ways, so the skeleton resource might be handled in different ways.
Because the GLES2 renderer will run on a lot of low-end hardware, I chose a more software-oriented than hardware/GPU-oriented approach to store the bone transforms, but more on that in the next
Future
In the next progress report I will talk about how the new renderer handles skeletal animations differently than the 2.1 renderer, also I will share my then newly-gained knowledge of physically based rendering! Interesting times ahead!
Seeing the code
If you are interested in the GLES2 related code, you can see all the commits in my fork on GitHub. Other contributions are linked in the sections above.
-
+
\ No newline at end of file
diff --git a/article/gles2-and-gdnative-progress-report-5/index.html b/article/gles2-and-gdnative-progress-report-5/index.html
index 0f35e53eba..9b7a1bd1e6 100644
--- a/article/gles2-and-gdnative-progress-report-5/index.html
+++ b/article/gles2-and-gdnative-progress-report-5/index.html
@@ -17,7 +17,7 @@
GDNativeLibrary improvements
A GDNativeLibrary is a resource that contains the needed information about a native library. It is backed by a ConfigFile which is nice for manual editing. Until lately, a GDNativeLibrary could only be properly created by loading it from a file stored on disk, which made programmatically creating them a lot more confusing and not-nice.
Another huge problem that was caused by this behavior is that GDNativeLibrary resources could not properly be embedded in other resources causing many problems with the existing Godot workflow.
This problem was solved by adding proper de-/serialization so that it can be used as a sub-resource, as well as adding a way to set a ConfigFile directly, without having to store it on disk.
The PR for that can be found here, it’s rather small but an immense improvement to the usability of many GDNative applications.
godot-rust low-level registering PR
As mentioned in the last progress report, some work on the godot-rust repository has been prepared but not PR’d to the main repository yet. This is what I did, so here’s the PR which got merged recently! This wasn’t too big of a change, but I hope that the bindings, which are under more active development (but help is still appreciated :P ), will become more transparent.
Future
The C++ bindings are getting to a place where they are more safe to use and resemble code as you would find it in the engine a lot more. As there seems to be a lot of community interest in the Rust bindings, I will try to get more involved with those.
For the graphics side of things, I can’t wait to get roughness working properly, along with other things that I learned more about in the last few weeks. PBR is a pretty interesting topic and it’s awesome to have the opportunity to explore this in depth thanks to all the Patrons <3
Seeing the code
If you are interested in the GLES2 related code, you can see all the commits in my fork on GitHub. Other contributions are linked in the sections above.
-
+
\ No newline at end of file
diff --git a/article/gles2-and-gdnative-progress-report-6/index.html b/article/gles2-and-gdnative-progress-report-6/index.html
index e7828a5be8..be39700d75 100644
--- a/article/gles2-and-gdnative-progress-report-6/index.html
+++ b/article/gles2-and-gdnative-progress-report-6/index.html
@@ -5,7 +5,7 @@
karroffel6 June 2018
This article is from June 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.
Introduction
The GLES2 backend is getting closer and closer to completion, this progress report shows a detailed overview of the steps taken to implement PBR.
Roadmap
Done May 2018
enviroment relections
cubemap filtering
implement BRDF
omni lights
lambert+phong
normal maps
rewrite OAHashMap to use RobinHood hashing
improved C++ bindings compilation workflow
fixed a GDNative binary compatibility bug
Planned June 2018
finish lights
shadow mapping
reflection probes
lightmaps
particles
get NativeScript 1.1 and the C++ bindings release ready
Details about work in May 2018
environment reflections
At the end of last month I was able to load and show a skybox as a background. The next step is to get reflecting materials to show that sky. Or more specifically: the light reflected from a surface should include radiance from the sky.
The first step to getting something like that shown is to know where in the world you actually are. This is a screenshot that displays the object-space position of each pixel as the color.
That’s not really that interesting to look at, so let’s try to use SOME MATH!!! (but mostly just the textureCube() function in GLSL)
Heyyy, this pretty much looks like the sky projected onto the meshes, that’s better!
At that point of development, the sky reflection didn’t respond to the camera position, so it basically looked like the sky was painted ontop of the mesh. That was fixed by reflecting the view-vector with the normal of the current pixel.
The next step is to do proper cubemap filtering.
cubemap filtering
A polished metal-ball doesn’t reflect light in the same way as a rubber-ball or piece of wood does. To implement these different behaviors we could do some complex operations per pixel and possibly index pixels of the skymap and surrounding objects multiple times, but because graphic programmers are very empathic creatures we don’t want the PC to do more work than necessary to achieve a believable effect.
So instead the sky gets blurred with different “intensities” and that’s what will be used for different “roughness” values of the materials.
This blurring is the “cubemap filtering”.
Because blurry images need less detail than non-blurry images it would be handy to store those blurred versions in a mipmap.
A mipmap is a smaller version of the original texture, usually filtered in a special way to make them look nicer when they are viewed from an angle or far away. OpenGL usually generates those for you. It halves the resolution of the image until there’s only one pixel left.
( This is why for pixel-art games you often either change the filtering mode of textures or need to disable mipmaps to make the game look nice and sharp. )
For the sky some custom custom filtering is wanted, in this case a blur. So the lower-resolution images need to be generated manually and OpenGL needs to know that it should use those images instead of using its own method.
Because now the mipmap-level (the amount of “small-ness” of the texture) has a different use case we need to access it manually in the shaders rather than letting OpenGL handle that for us automatically. (This is done using the textureCubeLod() function, where the “level of detail” - so the mipmap level - can be specified explicitly)
So for the beginning I didn’t actually do any blurring, I just gradually made the sky more white to see if it actually works.
…
And of course it didn’t, but here are some screenshots that look cool.
After all this was working properly the actual blurring had to be implemented. This actually turned out to be quite a problem.
The blurring is done by selecting a few mostly-evenly-distributed points on the image. Then those points are mixed in a way that calculates a color that looks cool basically.
The problem I was facing was that the algorithm to distribute points on the texture runs in the fragment shader, and the function used in the GLES3 backend is using a Hammersley distribution. The implementation is based on this post and uses bit-shifting. Bitshifting operations are not supported in GLSL ES 1.0.
I tried to play around a bit to see if I can find a good distribution with some number-crunching. I got interesting and almost okay-ish results.
This was the closest I could get, but it was all very hacky.
For the lack of a better and proven alternative I chose to generate those values on the CPU and writing them into a texture.
The results of that were quite nice (as expected).
(Also having a proper skymap makes a really huge difference on quality, so just as a side tip: search for good environment maps, they shape the perception of graphics quality a lot!)
With all that in place, all meterials where behaving as if they had metallic = 1 but a variable roughness.
There are some great references and materials out there that can go into detail a lot better than I can, so I will just plug someofthem.
So metallic and dielectric materials work now!
(for some reason dielectric materials are darker than they should be, I’ll have to fix that…)
omni lights
With basic materials working and environment mapping in place, the next task on the list is lighting.
The GLES2 backend is a forward renderer, that means each gets shaded once. The counter-part - deferred rendering - renders each of the objects properties into a separate framebuffer. Lights then combine those properties dependeing on their parameters.
Because the GLES2 specification is quite limiting in some parts, the lighting uses a “multi-pass” approach. This means that all the objects that are affected by a light have to be rendered again and the “light difference” will be blended over the “base rendering” of the object.
This happens for all objects for all lights. The GLES3 backend can render all lights for each object in one pass, unfortunately I can’t go down that route :(
The first thing I tackled were OmniLights, which are like points that illuminate the area around them.
The strength of the light depends on the normal of the object and the distance to the light.
lambert+phong
The above pictures where achieved by blindly blending the color of the light over the object. It didn’t take into account the metalness or roughness, as well as the “specular blob”.
So the next step was making sure that the material parameters would be respected properly.
With PBR, light reflection is divided into two categories: specular reflection and diffuse reflection.
The “big” part (diffuse reflection) of a light influence on an object is achieved by “lambert” shading. This only affects rough surfaces.
The specular blob (here through specular reflection) part is done with “phong shading”.
They are both pretty simple to implement, but the lambert model has been modified to be in-line with PBR and energy conservation.
normal maps
Until then I didn’t implement normal maps properly as they require some special care in the shader, but it was about time, and with that in place things are starting to look pretty good!
rewrite OAHashMap to use RobinHood hashing
I was working on a small hashmap implementation in my freetime and read more about RobinHood hashing, which is a pretty nifty addition to regular open adressing hash maps.
A while ago, I implemented a new hashmap type for Godot that should be more cache friendly for situations where high performance is critical (for example CSG).
The main HashMap implementation in Godot uses chaining and many dynamic memory allocations. If a hash collision occurs then the elements will be chained in a linked-list kind of manner. This is pretty bad for cache misses but in most cases it’s not a problem that you need to deal with.
Open adressing uses flat arrays and use the hash as an index into the array. If a collision occurs then the next free spot will be used. This makes lookups more memory local.
One downside to that is that if the hashmap becomes more and more filled, the average time to find the entry you are looking for grows bigger and bigger.
RobinHood hashing enhances that system by “stealing from the rich and giving to the poor”. Basically it shifts elements around to average out the distance of the place where an entry should be and where it actually is. This means that lookups can be aborted a lot faster and in general the lookup times are much faster. Also they can be used with way higher fill factors than regular open adressing.
This is all pretty technical, but if you are interested, the code can be found here.
improved C++ bindings compilation workflow
Until now, compiling the C++ bindings was a multi-step process that required setting up paths correctly and having a Godot tool-binary around.
I added the dependencies as git submodules and files so that the project is now compilable in one command.
This should hopefully lower the entry of barrier to get started with C++ projects and Godot.
fixed a GDNative binary compatibility bug
Recently a compatibility bug was found with the way the Godot API struct was constructed. This has been unnoticed for a while and caused problems when cross compiling libraries. This has been resolved now and shouldn’t cause any issues from now on.
Future
The GLES2 backend is getting closer to completion and the major things missing are shadows, reflection probes and light mapping. The 3.1 alpha is planned to be soon, so those features will hopefully be ready to test by then.
As always, thanks for the support on Patreon and also thanks to all the people that are interested in Godot and spread the word around!
Seeing the code
If you are interested in the GLES2 related code, you can see all the commits in my fork on GitHub. Other contributions are linked in the sections above.
-
+
\ No newline at end of file
diff --git a/article/gles2-and-gdnative-progress-report-7/index.html b/article/gles2-and-gdnative-progress-report-7/index.html
index d090685598..2a4bbdb084 100644
--- a/article/gles2-and-gdnative-progress-report-7/index.html
+++ b/article/gles2-and-gdnative-progress-report-7/index.html
@@ -7,7 +7,7 @@
One of those things was support for “billboard modes” and for the vertex shader to skip the vertex transform so the user can do it manually.
This made many more gizmos in the editor show up, so now it is almost as complete as the GLES3 version of the editor, with the exception for things that use ImmediateGeometry, like some handles on light gizmos. Implementing this is planned for next month :)
BlendSpace1D
To catch some breath after all this debugging madness, I took a shot at implementing BlendSpace1D for the new animation system since I needed that in one of my side-projects.
You can read more about the new animation system here!
The way the lighting is done currently is very bad for the i-cache of the GPU, so some refactoring will be needed to increase performance.
Also the branch will soon be merged into the Godot master branch, so some cleanup will be done for that as well.
Seeing the code
If you are interested in the GLES2 related code, you can see all the commits in my fork on GitHub. Other contributions are linked in the sections above.
-
+
\ No newline at end of file
diff --git a/article/gles2-renderer-optimization-2d-batching/index.html b/article/gles2-renderer-optimization-2d-batching/index.html
index 4c8ad3e20c..5527812a5a 100644
--- a/article/gles2-renderer-optimization-2d-batching/index.html
+++ b/article/gles2-renderer-optimization-2d-batching/index.html
@@ -6,7 +6,7 @@
Bottom: 8 layers of a screen full of “A”s with two Sprites intermixed.
Let the above example images teach you all a lesson that us graphics programmers don’t stare at beautiful images all day, often times we work with images like these.
How to try out the new build
Rémi (Akien) has kindly been making a series of test builds which we are trying to test as widely as possible before we merge into the main 3.2.x branch.
Please try these changes out yourself, they are linked from the PR with many more details:
Let us know if it worked okay for your project, and also let us know if you discover any problems so we get onto fixing them. :)
The banner image is using the Godot bunnymark bunny from godot3-bunnymark. Thank you to cart for making such a great profiling tool. Consider this a warning that all your bunnymark scores have become outdated.
-
+
\ No newline at end of file
diff --git a/article/godot-1-1-beta1-out/index.html b/article/godot-1-1-beta1-out/index.html
index afc9412208..7416894162 100644
--- a/article/godot-1-1-beta1-out/index.html
+++ b/article/godot-1-1-beta1-out/index.html
@@ -5,7 +5,7 @@
Juan Linietsky2 April 2015
After three months of hard work, our first new release is out! This beta prepares the road for the 1.1 release, expected sometime in late April.
New features include:
Rewritten Auto-Completion in the Code-Editor. Supports a lot of scenarios and perform smart-completion of node types if a scene where the script is being used is open.
New API in OS for managing the screens and window, with multi-monitor support.
Largely rewritten 2D engine, with support for:
Shaders (Visual and Code)
2D Materials
2D Independent Z ordering per-node.
2D Lights
2D Shadows with Polygonal Occluders
2D Normal Mapping
Back-Buffer compositing for shaders that read from screen (allows all sorts of post-processing effects).
Improved Isometric TileMap Support (proper Z ordering of tiles and children nodes).
Distance-Field font support.
New 2D Navigation Polygon support, for efficient 2D pathfinding. Navigation Polygons can be edited visually and combined, disabled, etc.
Improved Usability in 2D Physics API:
Area2D and RigidBody2D can receive input events
Area2D can detect overlap with another Area2D
New Dark Theme
Large amount of bug fixes and smaller improvements.
Please remember that this new version is BETA, so this is your time to report everything that doesn’t work to GitHub as Issues, contribute PRs with fixes or annoy Juan and Ariel to fix what is not working for you.
Godot 1.1 Beta1 can be obtained in the Download section, or source cloned at GitHub.
-
+
\ No newline at end of file
diff --git a/article/godot-1-1-out/index.html b/article/godot-1-1-out/index.html
index 8d9df79340..f97fb5d9f7 100644
--- a/article/godot-1-1-out/index.html
+++ b/article/godot-1-1-out/index.html
@@ -5,7 +5,7 @@
Juan Linietsky21 May 2015
After many months of hard work (and many more of bug fixing), Godot 1.1 is out!! This release brings a completely new 2D engine and more features (feature list below). At this point Godot is one of the most advanced 2D engines out there. Check out (and share!) this video with the new feature showcase!
Full list of features
Rewritten Auto-Completion in the Code-Editor. Supports a lot of scenarios and perform smart-completion of node types if a scene where the script is being used is open.
Godot 1.1 can be obtained at the Download section.
Future
With this release, Godot becomes one of the best options out there to develop modern 2D games. While the community is eagerly waiting for the same work on modernizing the 3D side of engine, the developers are waiting for more news on the newly announced Vulkan API, as it would be ideal to adopt it instead of OpenGL3/4 or OpenGL ES3. Meanwhile, the focus for 1.2 will be on modernizing the editor UI for better usability. There is a long list the community has put together on this and we are still welcoming feedback. As always, Godot is developed with the community and for the community.
There will also soon be:
A new website, more community oriented, developed by Theo Hallenius, where everyone will be able to create documentation and content.
An asset sharing section, so the community can better share the content it creates and help each other.
A diffusion section, where you will be able to find material, talks, etc that you can use to help spread the world and teach others about Godot.
Make Noise!!
Godot does not have millions of dollars in investment for PR, so it relies on you in order for the rest of the world to find out about it. Talk about it, tweet about it, write articles, organize talks, and share this news!!
-
+
\ No newline at end of file
diff --git a/article/godot-1-1-rc1/index.html b/article/godot-1-1-rc1/index.html
index e45d271a40..704a9c28a2 100644
--- a/article/godot-1-1-rc1/index.html
+++ b/article/godot-1-1-rc1/index.html
@@ -5,7 +5,7 @@
Juan Linietsky1 May 2015
After 1.1 Beta a month ago, our first release candidate is here. A huge amount of issues were fixed (full changelog).
If you didn’t report your favorite bugs, this is the time before it’s too late! If you reported them and they were not fixed yet, it’s your chance to pester the developers (just add comments to the issues you want fixed reminding them). If nothing comes up, this will become 1.1 stable.
-
+
\ No newline at end of file
diff --git a/article/godot-1-1-rc2/index.html b/article/godot-1-1-rc2/index.html
index 6f8c508bf4..b286b2cb1a 100644
--- a/article/godot-1-1-rc2/index.html
+++ b/article/godot-1-1-rc2/index.html
@@ -5,7 +5,7 @@
Juan Linietsky5 May 2015
The second release candidate is out, with a large amount of fixes. Let’s hope this is the last one and becomes stable!
It is recommended to migrate to this version if you are using RC1, because a serious bug was fixed when saving animations in xml format that can end up in a corrupted scene.
-
+
\ No newline at end of file
diff --git a/article/godot-1-1-rc3/index.html b/article/godot-1-1-rc3/index.html
index 7bb0fe8493..0ad217a0ed 100644
--- a/article/godot-1-1-rc3/index.html
+++ b/article/godot-1-1-rc3/index.html
@@ -5,7 +5,7 @@
Juan Linietsky17 May 2015
Many more issues were reported issues after RC2 (changelog), so we’ll be releasing one more candidate. This time, we’ll raise the bar so if nothing really serious is reported, this should go as 1.1 Stable!
-
+
\ No newline at end of file
diff --git a/article/godot-10-rc1-here/index.html b/article/godot-10-rc1-here/index.html
index 631c8b6ffe..1cf2d89491 100644
--- a/article/godot-10-rc1-here/index.html
+++ b/article/godot-10-rc1-here/index.html
@@ -5,7 +5,7 @@
Juan Linietsky2 December 2014
A long time in the baking, but the first release candidate is here. This does not mean Godot is now without bugs, but that nothing should be too serious to affect your productivity. After stable release, we’ll keep fixing issues and then head over to 1.1 (see roadmap!).
If nothing too serious is found in this build this week, it will become 1.0 stable, so make sure to test well with your projects!
-
+
\ No newline at end of file
diff --git a/article/godot-2-0-now-beta/index.html b/article/godot-2-0-now-beta/index.html
index 1f1146f468..2cb10ed0f9 100644
--- a/article/godot-2-0-now-beta/index.html
+++ b/article/godot-2-0-now-beta/index.html
@@ -5,7 +5,7 @@
Juan Linietsky26 January 2016
After a long, long time in development Godot 2.0 is now in beta!
Godot 2.0 Beta features a new interface, and a huge amount of usability improvements. It is also more stable than ever, with hundreds of bug fixes and small enhacements.
Please test this version out heavily and report any bugs you find! If your favorite bug has not been fixed, please post it to GitHub or (if already there) update it expressing your desire for it getting fixed for 2.0 stable.
-
+
\ No newline at end of file
diff --git a/article/godot-2-0-rc1-released/index.html b/article/godot-2-0-rc1-released/index.html
index f45f15a7ca..f2fe7497d4 100644
--- a/article/godot-2-0-rc1-released/index.html
+++ b/article/godot-2-0-rc1-released/index.html
@@ -5,7 +5,7 @@
Juan Linietsky9 February 2016
Finally, a couple of weeks (and hundreds of fixes) after the Beta, we are proud to present our first Release Candidate! This engine version should be much more stable and, if no serious bugs are found, will become 2.0 stable.
-
+
\ No newline at end of file
diff --git a/article/godot-2-1-rc1-out/index.html b/article/godot-2-1-rc1-out/index.html
index 87c8dbb336..f10b7ca619 100644
--- a/article/godot-2-1-rc1-out/index.html
+++ b/article/godot-2-1-rc1-out/index.html
@@ -5,7 +5,7 @@
Juan Linietsky24 July 2016
Our first release candidate is out! This means, if nothing important changes, that this build will become Godot 2.1.
Godot 2.1 continues to improve on the usability trend, taking care of several aspects that were left out of 2.0 due to time constraints. Grab it now while you read on the list of new features below (short version!).
Same as in Beta, a quick and incomplete list of new features follows (a proper post will be written for the stable release):
New asset sharing platform: Godot has a new platform for sharing assets between users. It’s still rough, but it will improve with time. As of now there is almost no content to test it with, but we will upload some plugins and the demos there in the coming days.
New plugin API: Downloaded assets can be used as plugins to extend the editor functionalities. Our first attempt at offering an API for this is still probably incomplete, so help us improve it with your feedback.
Support for dynamic fonts: Load TTF and OTF font files directly into your projects. This aids enormously with internationalization.
Fully internationalized editor UI: Godot can now be used in several languages and displays all unicode characters properly (including CJK). Right-to-left language support is still unimplemented though.
Editor visual customization: Change font sizes or set custom fonts, set custom themes, etc.
Customizable keybindings: Most keybindings can now be customized and there is a new binding editor in the editor settings.
Live script reloading: Saved scripts in the editor will be reloaded in the running game automatically, and tool scripts will also be automatically reloaded.
Profiler & frame profiler: Godot has a fully featured profiler (with graph plotting), which allows going back in time and see the performance numbers and most used functions frame by frame.
Remote scene inspector: Inspect the scene tree of the running game live, including nodes and resources.
HiDPI/Retina support: Godot detects high resolution monitors and offers the editor UI with native resolution. All Godot icons were redone in vector graphics for the occasion, thanks a lot to @drjm who did almost all of them!
Drag & drop support: Godot now supports drag & drop editor-wide. Dragging assets from filesystem explorer to Godot will also open the relevant import dialogs.
Contextual menus: Godot now also supports contextual menus where relevant.
Script editor usability improvements: Incremental search, better highlighting, smart function matching in code-completion, etc.
Improved asset pipeline: Automatic re-import and reload of assets and scenes when changed.
Improved thumbnailer: Previews are updated in real-time, and thumbnails of resources will appear in the inspector.
New AnimatedSprite features: Labelled animations, and the ability to play animations without an AnimationPlayer.
With these changes, Godot has become a true joy to use. Please help us with testing so we can make sure 2.1 is a solid release! This is the time to report your favorite bugs, or add a comment to existing ones so we give them more priority.
For the most adventurous, you can check the complete git changelog of the more than 1,200 commits (excluding merge commits) that were done so far for this new release! If you’ve tried the betas already, you can also consult the (much shorter) git changelog since the previous beta build.
-
+
\ No newline at end of file
diff --git a/article/godot-2-1-reaches-beta-ready-for-testing/index.html b/article/godot-2-1-reaches-beta-ready-for-testing/index.html
index 410de04471..e4a79e588e 100644
--- a/article/godot-2-1-reaches-beta-ready-for-testing/index.html
+++ b/article/godot-2-1-reaches-beta-ready-for-testing/index.html
@@ -5,7 +5,7 @@
Juan Linietsky12 July 2016
Edit: A new beta build has been published, dated 2016-07-21. See the changelog since the 2016-07-12 build.
Today, after several months of hard work, we have reached a new milestone in the development of the upcoming version 2.1! We are now pretty happy with the feature set and the overall stability, and therefore provide beta binaries for you to test and report issues/suggest improvements.
Godot 2.1 continues to improve on the usability trend, taking care of several aspects that were left out of 2.0 due to time constraints. Grab it now while you read on the list of new features below (short version!).
A quick and incomplete list of new features follows (a proper post will be written for the stable release):
New asset sharing platform: Godot has a new platform for sharing assets between users. It’s still rough, but it will improve with time. As of now there is almost no content to test it with, but we will upload some plugins and the demos there in the coming days.
New plugin API: Downloaded assets can be used as plugins to extend the editor functionalities. Our first attempt at offering an API for this is still probably incomplete, so help us improve it with your feedback.
Support for dynamic fonts: Load TTF and OTF font files directly into your projects. This aids enormously with internationalization.
Fully internationalized editor UI: Godot can now be used in several languages and displays all unicode characters properly (including CJK). Right-to-left language support is still unimplemented though.
Editor visual customization: Change font sizes or set custom fonts, set custom themes, etc.
Customizable keybindings: Most keybindings can now be customized and there is a new binding editor in the editor settings.
Live script reloading: Saved scripts in the editor will be reloaded in the running game automatically, and tool scripts will also be automatically reloaded.
Profiler & frame profiler: Godot has a fully featured profiler (with graph plotting), which allows going back in time and see the performance numbers and most used functions frame by frame.
Remote scene inspector: Inspect the scene tree of the running game live, including nodes and resources.
HiDPI/Retina support: Godot detects high resolution monitors and offers the editor UI with native resolution. All Godot icons were redone in vector graphics for the occasion, thanks a lot to @drjm who did almost all of them!
Drag & drop support: Godot now supports drag & drop editor-wide. Dragging assets from filesystem explorer to Godot will also open the relevant import dialogs.
Contextual menus: Godot now also supports contextual menus where relevant.
Script editor usability improvements: Incremental search, better highlighting, smart function matching in code-completion, etc.
Improved asset pipeline: Automatic re-import and reload of assets and scenes when changed.
Improved thumbnailer: Previews are updated in real-time, and thumbnails of resources will appear in the inspector.
New AnimatedSprite features: Labelled animations, and the ability to play animations without an AnimationPlayer.
With these changes, Godot has become a true joy to use. Please help us with testing so we can make sure 2.1 is a solid release! This is the time to report your favorite bugs, or add a comment to existing ones so we give them more priority.
For the most adventurous, you can check the complete git changelog of the more than 1,600 commits that were done so far for this new release!
-
+
\ No newline at end of file
diff --git a/article/godot-2019-showreel/index.html b/article/godot-2019-showreel/index.html
index e7f78f9978..899dd20f2b 100644
--- a/article/godot-2019-showreel/index.html
+++ b/article/godot-2019-showreel/index.html
@@ -5,7 +5,7 @@
Juan Linietsky16 April 2019
Another year, another showreel. As every year, the amount of quality games being created by Godot has increased significantly (as did the amount of submissions).
Submissions
The idea of the reel is to include games both published and in development.
We got well over a hundred submissions this year, 3 or 4 more times than last year. Most of them are fantastic, but it became impossible to put all of them in the official reel, not even in the extended one.
After discussing, we decided to split into two, one for Mobile and one for Desktop/Console games, so have a seat, grab a drink and enjoy the 2019 showreels!
Desktop / Console showreel
Mobile showreel
Future
In some days we will also put up the extended showreel, including significantly more games.
Remember that, as always, Godot is Open Source and community developed. The core contributors have decided to dedicate their lives to this project, rejecting very juicy offers by the biggest companies in the world. But this can only happen thanks to donations so, if you are not yet, please consider becoming our patron, and help Godot development remain free and open. Even a small donation is enormously helpful.
-
+
\ No newline at end of file
diff --git a/article/godot-2020-year-in-review-video/index.html b/article/godot-2020-year-in-review-video/index.html
index e9d1fedfd5..b584ac3b39 100644
--- a/article/godot-2020-year-in-review-video/index.html
+++ b/article/godot-2020-year-in-review-video/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio31 December 2020
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.
While 2020 was a difficult year for most of us, it’s been a great year for Godot development! A lot of new features were implemented for both 4.0 and 3.2.x, from Vulkan rendering to HTML5 export improvements. Many long-requested features are now available in the master branch, such as support for right-to-left typesetting and complex scripts (which are required to display text in Arabic, Hebrew, …). On top of that, GDScript has been rewritten from scratch and C# has received continuous improvements and fixes throughout the year.
We would like to thank the Godot contributors for their tireless work on the engine. Also, thanks to the Godot community for supporting development, Hugo Locurcio for editing, and thanks to Hubert Lamontagne for providing their music!
-
+
\ No newline at end of file
diff --git a/article/godot-3-0-released/index.html b/article/godot-3-0-released/index.html
index 17ae876f52..e42973f2b0 100644
--- a/article/godot-3-0-released/index.html
+++ b/article/godot-3-0-released/index.html
@@ -7,7 +7,7 @@
Improved flat style box
The vector-based style box (StyleBoxFlat) has been greatly improved by Timo (toger5), adding support for rounded corners. Customize your game UI components with slick vector looks and soft drop shadows (which are also resolution-independent), without having to create any image!
Font oversampling
To continue on the resolution-independent trend, Godot also now supports font oversampling. This makes sure your fonts always use the native resolution even if your UI is scaled.
Custom hardware cursor
Thanks to Xavier Sellier (xsellier) and Guilherme Felipe de C. G. da Silva (guilhermefelipecgs), it is finally possible to change the hardware mouse cursor on desktop platforms. Set any image as cursor and it will work, with reduced latency compared to a software cursor.
Greatly improved 3D editor viewport
Support for free look and fly mode, thanks to Marc Gilleron (Zylann)
Improved 3D manipulation gizmos (multiple-axis editing and scale), thanks to the work of Przemysław Gołąb (n-pigeon)
Interpolation on motion and view change
Improved selection support on instanced scenes
Exposed grid snap and local axis transform in toolbar
Information display on rendered geometry
Half-resolution viewport rendering for better performance on HiDPI displays
Console support
While, due to legal and practical reasons, we can’t provide ports to consoles (save for XBox One via UWP), this does not mean that separate private companies can’t. Godot’s open license allows any company to port the engine to consoles and offer it as a product.
This is the case of Lone Wolf Technology, a company created by original Godot co-author Ariel Manzur, who offers to get your game running on any console. A Nintendo Switch port has been recently completed, allowing Godot to run on their latest console.
This post is already too long and it’s impossible to list all the hundreds of features and bug fixes that have been implemented by Godot contributors over the last year and a half.
Contributors are working on a human-readable changelog which should give you some more details. You can also browse and filter the list of GitHub pull requests of almost 3000 contributions (and the corresponding list for GitHub issues), as well as review the raw Git changelogs since Godot 2.1 (sorted chronogically or by author).
Future
Godot 3.0 lays the foundation of a fantastic engine. Over the course of the next months, the plan is to keep adding the missing features and fix known issues, as well as further improving documentation and tutorials.
Godot 3.1 will bring a new and more powerful animation tree, modern occlusion culling, improved rendering and a GLES 2.0 backend (for mobile and low-end desktop compatibility), as well as many other pending features.
Help make Godot better!
You can greatly help us improve Godot, as well as make it faster and better. Besides contributing code (if you are a programmer), you can help us a lot by becoming our patron. Additionally, spreading the word will always benefit us, as most game developers still have never tried (or even heard of) Godot. Finally, the best contribution might be to use Godot to develop and publish awesome games!
See our community documentation for a description of all the ways you can contribute to Godot and how.
Have fun with this long-awaited release!
Trivia: Today’s also the anniversary date of the writing of our namesake play by Samuel Beckett, Waiting for Godot, whose French text was completed on 29 January 1949.
The illustration picture is courtesy of James Redmond (@fracteed) who helped a lot during the development of 3.0 by stress-testing the engine with great PBR assets and reporting the issues he found doing so.
-
+
\ No newline at end of file
diff --git a/article/godot-3-1-released/index.html b/article/godot-3-1-released/index.html
index 39ab6f3a38..dc49f70c39 100644
--- a/article/godot-3-1-released/index.html
+++ b/article/godot-3-1-released/index.html
@@ -5,7 +5,7 @@
Juan Linietsky13 March 2019
After a bit more than one year of work, the Godot developers and contributors are delighted to get their new release out the door, Godot 3.1! It brings much-requested improvements to usability and many important features.
Godot 3.0 was a massive release, which required large rewrites of the engine codebase and breaking backwards compatibility significantly. This new version builds upon it by improving it and finishing the pending work.
As a result, Godot 3.1 feels more mature and easy to use, and it does away with many hurdles introduced in the previous versions.
Download Godot 3.1 now and keep on reading about the great features added in this version.
Patreon
As always, please remember that we are a not-for-profit organization dedicated to providing the world with the best possible free and open source game technology. Donations have played a vital role in enabling us to develop Godot at this sustained pace. Thanks to all of you patrons from the bottom of our hearts!
If you use and enjoy Godot, plan to use it, or want support the cause of having a mature, high quality free and open source game engine, then please consider becoming our patron. If you represent a company and want to let our vast community know that you support our cause, then please consider becoming our sponsor. Additional funding will enable us to hire more core developers to work full-time on the engine, and thus further improve its development pace and stability.
Documentation
While this article focuses mostly on the new features of the engine, it’s worth mentioning that Godot’s documentation has seen a lot of work from dozens of contributors. A detailed changelog is being worked on, you can see the current draft on GitHub.
New features
Release trailer by Nathan Lovato (GDquest) showcasing the outstanding new features of Godot 3.1.
Here’s an index of the outstanding features described in this post:
The Godot 2.x branch used OpenGL ES 2.0 / OpenGL 2.1 (GLES2) as its rendering API. This worked well, but had many limitations preventing us to use more modern rendering techniques.
In Godot 3.0, all rendering code was rewritten to use the more modern OpenGL ES 3.0 / OpenGL 3.3 specifications (GLES3) and the OpenGL ES 2.0 renderer was removed. This seemed like a great idea at the beginning, but ended up giving us many problems, such as:
Bad performance on old mobile/desktop hardware which wasn’t designed for the more modern rendering techniques being used.
Incompatibility with older mobile devices which do not support OpenGL ES 3.0.
Incompatibilities in the HTML5 platform, as not all browsers support WebGL 2.0 (the equivalent specification for OpenGL ES 3.0).
Lots and lots of driver bugs in mobile and desktop. On desktop, it seems that modern OpenGL is not well supported by various driver vendors, and regressions keep coming up in new drivers on macOS and Windows. On mobile, as OpenGL ES 3.0 is comparatively new, there is a range of many years where devices with very buggy drivers came out. Even modern flagship devices still ship with crippling driver bugs.
Due to this, we were forced to bring back the OpenGL ES 2.0 / OpenGL 2.1 renderer. This work was done by karroffel and I (reduz).
On the 2D side, this new renderer is feature complete. On the 3D side, a simpler approach to rendering was done that is intended to be more limited, but more compatible. It has the following features and limitations:
Rendering is done entirely on sRGB color space (the GLES3 renderer uses linear color space). This is much more efficient and compatible, but it means that HDR will not be supported. Lighting looks a bit different too.
Some advanced PBR features are not supported, such as subsurface scattering. Unsupported features will not be visible when editing materials.
Some shader features will not work and throw an error when used (which is to be expected when using an older OpenGL version).
Some post processing effects are not present either. Unsupported features will not be visible when editing environments.
As this back-end is intended to run on the lowest end hardware possible, shaders need to be kept very small. As such all lighting is done by using a forward multi-pass approach.
GIProbes of course don’t work. Use baked lightmaps instead.
GPU-based Particles will not work as there is no transform feedback support. Use the new CPUParticles node instead (more on this later).
From the points above, it must be clear that OpenGL ES 2.0 is not a fallback but a different platform you should target your game for. It looks different and has different limitations. If your game aims for absolute maximum compatibility, use this backend instead of the GLES3 one. If you aim for modern features at the cost of compatibility, don’t use it.
Optional typing in GDScript
This has been one of the most requested Godot features from day one. GDScript allows to write code in a quick way within a controlled environment. As any dynamically typed language, it allows churning out large amount of code at a high speed.
However, dynamically typed languages have some limitations that can be a hassle:
Code completion is not always possible.
Performance is constrained to the interpreter.
Does not always catch errors during compile (or write) time.
Code can be less readable and difficult to refactor.
Our contributor George Marques (vnen) did a fantastic job implementing optional typing in GDScript to tackle these problems. For Godot 3.1, optional typing is a parser-only feature. The plan is, afterwards, to include typed instructions in the state machine to greatly optimize performance.
One nice implementation detail is that the code editor will now show which lines are safe with a slight highlight of the line number. This will be vital in the future to optimize small pieces of code which may require more performance.
This work also enabled GDScript warnings, which will now be raised by the parser. You can toggle which warnings you want to see in the Project Settings.
Revamped inspector
The Godot inspector has been rewritten from scratch. It is now a lot more comfortable to use. Among some of the nice new features are proper vector field editing, sub-inspectors for resource editing (no longer needed to switch to a separate one when editing resources), better custom visual editors for many types of objects, very comfortable to use spin-slider controls, better array and dictionary editing and many many more features.
Revamped 2D editor
The Godot 2D editor has seen a serious rewrite by Gilles Roudiere (Groud). There is a much better use of gizmos, as well as showing small crosses where generic nodes exist. In particular, it solves a major pain point for new Godot users by no longer offering scaling handles for collision shapes, but letting you directly change their size instead.
New TileSet editor
The tileset creation workflow in Godot had always been a major pain point for users due to its tediousness. Mariano Suligoy (MarianoGnu) wrote a whole new TileSet editor with many features familiar from other tileset creation software, and a much better support for the autotile feature added in 3.0.
Revamped filesystem dock
Another fine piece of work by contributor Gilles Roudiere (Groud) and sponsored by Gamblify. The new filesystem dock has been rewritten and now supports a single tree + files view by default, with thumbnails for the files. It makes it easy to navigate projects and understand where everything is.
KinematicBody2D (and 3D) improvements
Kinematic bodies are among Godot’s most useful nodes. They allow creating very game-like character motion with little effort. For Godot 3.1 they have been considerably improved:
Support for snapping the body to the floor.
Support for RayCast shapes in kinematic bodies.
Support for synchronizing kinematic movement to physics, avoiding a one-frame delay.
Revamped animation editor
The animation editor has also been completely rewritten to ensure a much better experience. Some of the more outstanding features are:
Friendlier layout, with less clutter.
Key previews for most types of keys allow seeing the key values within the track.
Ability to group tracks by node.
Key editing in inspector.
Copying and pasting tracks.
Capture tracks, which interpolate from existing values.
Ability to create custom track editor plugins.
New track type: Bezier.
New track type: Animation (play animations of sub-animation player, allowing complex cinematics).
New track type: Audio (play audio on StreamPlayers, including 2D and 3D).
Revamped AnimationTree
The old AnimationTreePlayer has been deprecated in favor of the new AnimationTree node. Besides improving the blend tree, it also supports blend spaces (1D and 2D), a state machine, and a modular approach that allows you to combine all modes hierarchially to better reflect your gameplay.
Support for root motion as well as the ability to write your own custom blend nodes has also been added.
New axis handling system
After several months of deliberation and prototypes, we settled on a really good approach to axis mapping, courtesy of Gilles Roudiere (Groud). Instead of going the way other game engines do it with axis definitions, Godot 3.1 uses the novel concept of “action strength”.
While it may take a bit of time to sink in, this approach allows using actions for all use cases and it makes it very easy to create in-game customizable mappings and customization screens.
Visual shader editor
The visual shader editor has made a comeback. This was a pending feature to re-implement in Godot 3.0, but it couldn’t be done in time back then. The new version has a lot of niceties, such as PBR outputs, port previews, and easier to use mapping to inputs.
2D skeletons
It is now possible to create 2D skeletons with the new Skeleton2D and Bone2D nodes. Additionally Polygon2D vertices can be assigned bones and weight painted. Adding internal vertices for better deformation is also supported.
2D meshes
Godot now supports 2D meshes, which can be used from code or converted from sprites to avoid drawing large transparent areas.
Improved 3D editor
Just like the 2D editor, the 3D editor has also been considerably improved. Joan Fons Sanchez (JFons) did a magnificent job by improving how selection works and entirely rewriting the gizmo system.
3D softbody support
Andrea Catania (Odino), who integrated Bullet to Godot 3.0, has added support for soft bodies in Godot 3.1. This is a very easy to use implementation supporting many nice features.
Ragdolls and Skeleton IK
Also by Andrea Catania (Odino), there is a new PhysicalBone node used for easy ragdoll setups, as well as a SkeletonIK system which allows creating simple Inverse Kinematics (IK) chains for existing skeletons and toggling bones from regular to IK mode.
Constructive Solid Geometry (CSG)
CSG tools have been added for fast level prototyping, allowing generic primitives and custom meshes to be combined via boolean operations to generate more complex shapes. They can also become colliders to test together with physics.
OpenSimplex and NoiseTexture
Support has been added for OpenSimplex (another very requested feature from users) by Joan Fons Sanchez (JFonS). Additionally, a noise texture can now be used as a resource, which generates noise on the fly.
CPU-based particle system
Godot 3.0 integrated a GPU-based particle system, which allows emitting millions of particles at little performance cost. As OpenGL ES 2.0 support was added, this feature could not be supported there, so we added alternative CPUParticles and CPUParticles2D nodes.
These nodes do particle processing using the CPU (and draw using the MultiMesh API). They are quite efficient for lesser amounts of particles and work on all hardware. Additionally, these nodes open the window for adding features such as physics interaction, sub-emitters or manual emission… which are not possible using the GPU.
Greatly improved C# support
Ignacio Etcheverry (neikeq) and other contributors have done a tremendous work since Godot 3.0 to improve the C# integration in Godot. As of 3.1, C# projects can be exported to Linux, macOS and Windows. Support for Android, iOS and HTML5 will come further down the road, with Android being the current priority.
Both Ignacio and HP van Braam (hpvb) did great work to improve our Mono builds and remove some of its previous hurdles, such as being tied to a specific Mono version. The relevant bits from the Mono SDK are now included directly with the editor binary, and you only need to install MSBuild to build and ship C# games.
Networking improvements
Fabio Alessandrelli (Fales) did a number of improvements to Godot’s low-level networking APIs and high-level multiplayer API. He also implemented support for WebSockets, and Max Hilbrunner (mhilbrunner) helped him with various fixes and adding support for UPnP.
Custom classes registration
Will Nations (willnationsdev) implemented a way to register GDScript classes (and thus scenes/nodes) as custom classes that can be added directly from the “Add Node” dialog as if they were built-in nodes. This is done with the class_name keyword, which also allows defining a custom icon for the node.
MIDI and microphone input
Marcelo Fernandez (marcelofg55) added support for using MIDI devices as input devices. Together with SaracenOne, they also added support for capture microphone audio.
More VCS friendliness
Godot is already unrivalled with regards to being friendly to version control systems (VCS). The new 3.1 version includes some very requested enhancements such as:
Folded properties are no longer saved in scenes, avoiding unnecesary history pollution.
Non-modified properties are no longer saved. This worked up to some extent before with properties that were not zero but it now applies universally. This reduces text files considerably and makes history even more readable.
Many more changes
The above are only the most outstanding features. Hundreds of other changes have been made since Godot 3.0. You can read about them in the release changelog.
A heartfelt Thank You to all the contributors who worked on Godot 3.1!
Compatibility with 3.0
Godot 3.1 strives to maintain compatibility with Godot 3.0.x, so your projects should be easy to port over to the new version. There have been some compatibility changes though, especially in GDScript due to the new optional typing changes, but they should be easy to adapt to in a couple of hours at most. Refer to the changelog for details on what changed exactly.
Future
After so much work on improving usability and compatibility, the main focus will move into further improving rendering. The current GLES3 renderer will be deprecated in favor of a Vulkan-based one and 3D rendering will once again become the priority. The goal is to release Godot 4.0 one year from now (or less, I hope) with a top notch modern renderer capable of everything the other big engines can do.
In parallel, other contributors will continue working on other areas and usability will keep improving. We plan to release Godot 3.2 in the second half of 2019 with those improvements (the Vulkan work towards Godot 4.0 will be done in a separate feature branch). Some of the areas we want to focus on are:
Adding typed instructions to GDScript to improve performance of typed code.
Adding FBX support, either via Assimp or OpenFBX (the official Autodesk library cannot be used due to their restrictive licensing terms).
Improve the Android and iOS export workflow, in particular adding a simpler way to integrate mobile SDKs such as AdMob, without having to recompile the whole engine.
Getting the Godot editor to run on a web browser (ideal for public teaching institutions).
Improving networking to better support dedicated servers and modern protocols.
And many, many more features. Of course, always keeping priority on stability and usability.
Finally, we will also have patch releases for Godot 3.1.x to fix some more bugs and improve usability in a backward compatible way. In particular, some of the new features in 3.1 might still have issues preventing their use in some scenarios. We know for example of yet-unresolved OpenGL ES 2.0 issues on some lower end mobile devices, which will be addressed soon in 3.1.x maintenance releases.
Help us reach our next funding goal and speed up Godot development!
We are looking to get enough funding to hire a dedicated generalist. This will significantly reduce the time between adding features and new releases, which is currently our biggest bottleneck. Having a dedicated generalist will help us work constantly on fixing issues and improving usability even while new features are being added, reducing the time required to wrap up a new release.
Again, if you use and enjoy Godot, plan to use it, or want support the cause of having a mature, high quality free and open source game engine, then please consider becoming our patron. If you represent a company and want to let our vast community that you support our cause, then please consider becoming our sponsor.
-
+
\ No newline at end of file
diff --git a/article/godot-3-2-adds-support-convex-decomposition/index.html b/article/godot-3-2-adds-support-convex-decomposition/index.html
index 8d9f36b815..e6f5e4fb9e 100644
--- a/article/godot-3-2-adds-support-convex-decomposition/index.html
+++ b/article/godot-3-2-adds-support-convex-decomposition/index.html
@@ -5,7 +5,7 @@
Juan Linietsky10 April 2019
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.
Another long awaited feature makes it for Godot 3.2. This makes the workflow for 3D games considerably easier, by allowing conversion of concave meshes of any form into a set of convex shapes.
The convex problem
To explain as simple as possible, this feature does not add anything new, but improves the existing workflow.
Triangle mesh shapes (ConcavePolygonShape) work very well as static colliders, but they are useless for rigid bodies or areas, as they have no internal volume. To work around this limitation, convex shapes must be used.
The obvious problem with them is that they only really work well for convex geometry. When geometry is not convex, the usual workflow is to create more than one shape to cover the desired concave area. Doing this is tedious and the results are often not great (specially for complex geometry).
Here is an example of adding collision shapes to Suzanne by using standard shapes (two capsules, a sphere and a box):
It works and it will collide more or less OK, but it’s tedious to build and far from perfect.
Convex Decomposition
So, what if this process could be automatic? Imagine that, with the press of a button, any mesh is divided into N number of convex shapes that cover the surface of the geometry as best as possible.
This is pretty much what convex decomposition is. It’s now available via the MeshInstance menu:
Using this option makes the most sense when the edited MeshInstance is child of a RigidBody, KinematicBody or Area (as we mentioned before, for static bodies, triangle mesh works fine and is the recommended workflow). For anything dynamic, based on actual geometry, convex decomposition is the way to go.
This option existed before, but it only generated a single convex shape based on QuickHull. This was imprecise and inefficient. The new version uses de VHACD algorithm, and generates very precise (and simplified) convex geometry:
Thanks to this, it’s possible to effortlessly add collision to any concave shape and increase the physics realism of games:
Generating convex shapes on import
When importing data from 3D content creation tools such as Blender or Maya, Godot already supports generating collision objects or rigid bodies from the scene via the special hints added to the names of objects.
From now on, existing hints (such as -convcol,-convcolonly and -rigid) will generate convex shapes via decomposition (instead of the old QuickHull-based approach). This will finally allow creating rigid bodies directly in the 3D scene.
Future
Please give us feedback and test well, to ensure this feature works as best as possible in upcoming Godot 3.2!
And as always, if you are not yet, consider becoming our patron. This ensures that Godot development remains free from the control of any company and we can keep working like now, with the freedom to listen to everyone equally.
-
+
\ No newline at end of file
diff --git a/article/godot-3-2-arvr-update/index.html b/article/godot-3-2-arvr-update/index.html
index 4e891acdff..70085cb93b 100644
--- a/article/godot-3-2-arvr-update/index.html
+++ b/article/godot-3-2-arvr-update/index.html
@@ -7,7 +7,7 @@
Work will continue on expanding the capability of this logic.
Gear VR/Oculus Go/Quest
I suspect many will have been waiting for this news. Yes Gear VR/Oculus Go/Oculus Quest support is going to be part of the Godot 3.2 release. All the enhancements in the core have already been merged. Support for this, as with other headsets, comes in the form of a plugin that will eventually be made available through the asset library. You can compile the latest version of the driver here: GodotVR Oculus mobile plugin.
Performance is still being worked on and a full-featured game will likely require the new Vulkan renderer to get the most out of the platform but games with less demanding graphics are definitely possible already.
Godot user Christoph made a cool video of the plugin in action:
Not to leave out Android developers for AR support, ARCore is nearly working as well. There are a few more things to resolve before it is on par with the ARKit 1.0 implementation and in a mergeable state. We’re putting the final touches on the export functionality and on plane detection. Everything else is working.
Valve Index
HTC Vive support through OpenVR was one of the first platforms Godot supported and it will come as no surprise that the Valve Index works fine with the current drivers.
What is missing is support for the new Index controllers, formally known as knuckles controllers. These controllers have full finger tracking support and this will require enhancements to both the Godot core and the OpenVR driver to fully support this new feature. For now they only support the standard controller functions.
Valve has reached out to the Godot team and offered help so this will likely be our next big addition.
How to get my hands on this
Just to re-iterate, ARKit and GearVR/Oculus Go/Oculus Quest support will be available in Godot 3.2. If you want to play around with any of this already you will need to compile Godot from source.
-
+
\ No newline at end of file
diff --git a/article/godot-3-2-docs-sprint/index.html b/article/godot-3-2-docs-sprint/index.html
index 8b9caf172b..8f248c5361 100644
--- a/article/godot-3-2-docs-sprint/index.html
+++ b/article/godot-3-2-docs-sprint/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest7 June 2019
This article is from June 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’re starting a series of docs sprints once again to make Godot’s reference and documentation as good as they can be! Together, we can improve everyone’s experience using the engine.
Godot keeps growing at a fast pace. With over 900 contributors at the time of writing, new features and improvements come to the engine every week.
We have to keep up with the documentation so that beginners have the best experience possible learning the program, and so that people keep finding the information they need.
That’s why we are running new documentation sprints! Let’s make the docs even better once again!
Our priorities are to:
Complete the built-in code reference
Find outdated explanations in the reference and in the manual
Edit the reference and the manual to make them clearer and more accessible
The code reference is down to 73% complete at the time of writing. We want to get it as close as possible to 100%.
We can do this together. Back in 2017, in the months leading to the release of Godot 3.0 and with the help of dedicated contributors, we took the reference from 30% to 70% complete in just a few weeks! The manual got its great Getting Started section at that time, with a lot of work from KidsCanCode, among others.
Let’s get started together
Join me for a 4 hours livestream starting on Sunday, June 9, 11PM UTC. The video replay is available below.
How can I participate?
If you want to contribute to the code reference, starting by reading the Contribute to the Class Reference page to learn about the workflow.
I made a complete video tutorial to show you the entire workflow, explain the best practices, and my techniques to be as productive as possible:
Use this shared document to let everyone know what you’re working on: https://hackmd.io/@gdquest/godot-docs-sprint
If you don’t feel like you can write, you can also create issues with your feedback about parts of the reference that are not clear, so that other writers can fix them. No need to point out empty classes though as we have a tool to find them in the Godot repository.
Hop on the #documentation channel on Discord to get in touch with fellow contributors.
-
+
\ No newline at end of file
diff --git a/article/godot-3-2-will-get-new-android-plugin-system/index.html b/article/godot-3-2-will-get-new-android-plugin-system/index.html
index fcb91619bb..17a1e02943 100644
--- a/article/godot-3-2-will-get-new-android-plugin-system/index.html
+++ b/article/godot-3-2-will-get-new-android-plugin-system/index.html
@@ -5,7 +5,7 @@
Juan Linietsky24 April 2019
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.
Godot has a simple and efficient Android deploy system. With a single click, your project is running on your phone. With a single option (network filesystem deployment) your gigabyte-sized project is running and updating on your device in seconds. You can use the editor to debug your running game while playing on your device and you can make changes in the scenes or scripts and they will reflect in real-time on your phone or tablet. The big drawback until now, however, was that adding plugins was a pain in the butt.
Beginnig with Godot 3.2, the Android plugins system has been overhauled. It is no longer required to recompile the engine to add a new plugin.
New custom build system
Godot export templates for Android projects are just two .apk files, one for debug and one for release. On export, Godot fills them with the project files and tweaks some internal variables of the format. This works well in general, but many times the Android project needs to be actually modified and the current approach is not flexible enough.
Instead of going the way of other engines, which just export an Android project, it was decided to keep the current, easy-to-use approach, but to make it easier to generate the base templates from source.
To do this, there is a very simple option in the Project menu to install the build template:
When used, the Godot Android project that is used to build Godot for Android is installed in “res://android/build”, including full Java source code (a proper .gdignore file is added in “res://android” to avoid Godot filesystem dock from entering this folder).
When the build template is installed, the following option can be turned on in the Android export presets:
And from now on, every time the project is exported, gradle will be executed to produce fresh export templates from the Android source. The output (as well as potential errors) is displayed in the editor UI:
The generated templates are used automatically without any user intervention.
Setting this system up still requires installing the Java and Android SDK in order for Godot to build, but detailed instructions can be found in this new tutorial.
New plugin system
Having the Godot Android project source built automatically allows doing modifications to it, in a way more similar to how it works in other engines. This way you can keep modifying your Android project and bypass the rigidity of the export system as desired.
Still, however, the problem persists where, if a new Godot version is released, the Android build template will need to be erased and updated, discarding any changes you may have done to it.
To avoid this situation, a new plugin system was also added. This allows adding plugins inside the “res://android” directory (with any name other than “build”, of course). When Godot exports using the custom build option, the plugins are be compiled-in automatically.
Plugins allow extending the existing base build template by adding extra files and resources to it in outside directories. They also support blitting chunks of text into AndroidManifest.xml and build.gradle, so these files can be modified without risking to lose these changes as soon as the build template is updated.
The code part (Java) for creating plugins remains unmodified so existing plugins should be easy to port to the new system. For more details on how to create them, see this new tutorial.
As plugins are just extra files that are added to the project, you can now also distribute them via our asset library. This was not possible before.
Future
With upcoming Godot 3.2, it will be very easy for both our community and third party vendors to create and distribute Android add-ons (such as Ad-Mob, Firebase, Facebook, etc) for others to use. Here’s towards a flourishing ecosystem!
And as always, remember that this is done with love from us. This was a highly requested feature that we’re glad to finally be able to provide. If you aren’t already, please consider becoming our Patron and help Godot’s main developers work full time on the project, so the world can have a free and open source tool that lets you create games without any restrictions. Even a small donation is a huge help!
-
+
\ No newline at end of file
diff --git a/article/godot-3-3-has-arrived/index.html b/article/godot-3-3-has-arrived/index.html
index 9170eec849..179d4f335b 100644
--- a/article/godot-3-3-has-arrived/index.html
+++ b/article/godot-3-3-has-arrived/index.html
@@ -12,7 +12,7 @@
Moreover a 3.2.2 regression was fixed for System.Collections.Generic.List marshalling, and Unicode identifiers are now properly supported.
There’s also been extensivework on Mono compatibility with WebAssembly.
Other areas
Improved FBX importer
Gordon MacPherson (RevoluPowered) rewrote the prototypical Assimp-based FBX importer that we had in Godot 3.2 to support a lot of the more advanced features used in professional FBX-based workflows. You can read his devblog about it for details.
In the current state, the new importer works quite well for FBX assets authored in Autodesk Maya. There are known issues with some other types of FBX models which are currently being addressed, and should be fixed in upcoming 3.x (and possibly 3.3.x) releases. If you have models that fail to import properly, please file a bug report so that we can investigate and solve it.
WebXR support for VR games
VR developers got a nice surprise back in September when David Snopek (dsnopek) landed a pull request to implement WebXR support in Godot’s HTML5 port. Since it was merged earlier this year, we’ve seen a number of prototypes being developed with 3.3 RC builds’ WebXR support, and we’re eager to see what the community will create now that it’s available in a stable release!
David’s talk about WebXR support at Online GodotCon in January 2021.
OpenXR plugin
As one of his first tasks as a new full-time developer, Bastiaan Olij (BastiaanOlij) worked on an OpenXR plugin for Godot 3.3, before focusing on rendering optimization for mobile Vulkan in the 4.0 branch. He built on the pre-existing effort by Christoph Haag (ChristophHaag), porting the Linux-only plugin to Windows, and implementing a first version of the the OpenXR action system. You can read more in this devblog.
We initially avoided the ubiquitous MP3 audio format for two reasons: it was patent encumbered, and less performant than alternatives like OGG Vorbis. Since the patents expired, and a good minimal open source implementation is available (minimp3), we finally decided to include MP3 support in the engine. This was implemented by DeleteSystem32.
It is still not recommended for audio streams as OGG Vorbis is typically better, but it enables Godot projects to load pre-existing MP3 assets that they can’t convert beforehand: assets streamed from the Internet, or loaded by the users from their system. So supporting the ubiquitous MP3 format with a tiny library ends up being quite useful.
New AspectRatioContainer Control node
Making dynamic UI with containers while keeping control of aspect ratio has been made very easy thanks to the new AspectRatioContainer Control node, implemented by Uģis Brēķis (UgisBrekis) and finalized by Andrii Doroshenko (Xrayez).
This container resizes its child Control nodes based on two parameters: aspect ratio and stretch mode.
Uģis’ original proposal. The merged implementation is slightly different but the features are the same.
Minimap support in GraphEdit
Users of Visual Script and Visual Shaders, as well as developers relying on graphs in their game projects and editor plugins, will find this little UX improvement in Godot 3.3. At the end of the last year Yuri Sizov (pycbouh) added an often requested minimap to the GraphEdit control node. Located at the bottom right corner of the graph minimap allows to quickly find your way around even a very complex node structure.
And many more changes!
There’s a lot more that would be worth showcasing in this blog post, but it’s already extremely long and to be honest I’m running out of time :D
Godot 3.3 is ready to use now and we want you to have it without further ado.
We would like to take the opportunity to thank all of our amazing contributors for all the other great features merged since 3.2.3, and the hundreds of bugfixes and usability improvements done in this release. Even if not listed here, every contribution makes Godot better, and this release is truly the work of hundreds of individuals working together towards a common goal and passion.
For more details on other changes in Godot 3.3, please consult our curated changelog, as well as the raw changelog from Git (chronological, or sorted by authors).
Reporting issues
Godot is a complex piece of software and is not bug-free. Our contributors do their best to fix issues as they are being reported, but there’s a lot of surface to cover and you might encounter situations which we aren’t aware of yet, or couldn’t fix in time for this release. There will be 3.3.x maintenance releases focused on fixing bugs in coming weeks and months, so make sure to report any issue you encounter on GitHub, so that we can make sure to fix it for our future releases.
Giving back
As a community effort, Godot relies on individual contributors to improve. In addition to becoming a Patron, please consider giving back by: writing high-quality bug reports, contributing to the code base, writing documentation, writing tutorials (for the docs or on your own space), and supporting others on the various community platforms by answering questions and providing helpful tips.
Last but not least, making games with Godot and crediting the engine goes a long way to help raise its popularity, and thus the number of active contributors who make it better on a daily basis. Remember, we are all in this together and Godot requires community support in every area in order to thrive.
-
+
\ No newline at end of file
diff --git a/article/godot-3-4-is-released/index.html b/article/godot-3-4-is-released/index.html
index 4d53f6ac32..765d560342 100644
--- a/article/godot-3-4-is-released/index.html
+++ b/article/godot-3-4-is-released/index.html
@@ -30,7 +30,7 @@
And many more changes!
There’s a lot more that would be worth showcasing in this blog post, but it’s already fairly long and we’re eager to get it published :D
Godot 3.4 is ready to use now and we want you to have it without further ado.
We would like to take the opportunity to thank all of our amazing contributors for all the other great features merged since 3.3, and the hundreds of bugfixes and usability improvements done in this release. Even if not listed here, every contribution makes Godot better, and this release is truly the work of hundreds of individuals working together towards a common goal and passion.
For more details on other changes in Godot 3.4, please consult our curated changelog, as well as the raw changelog from Git (chronological, or sorted by authors).
Reporting issues
Godot is a complex piece of software and is not bug-free. Our contributors do their best to fix issues as they are being reported, but there’s a lot of surface to cover and you might encounter situations which we aren’t aware of yet, or couldn’t fix in time for this release. There will be 3.4.x maintenance releases focused on fixing bugs in coming weeks and months, so make sure to report any issue you encounter on GitHub, so that we can make sure to fix it for our future releases.
Giving back
As a community effort, Godot relies on individual contributors to improve. In addition to becoming a Patron, please consider giving back by: writing high-quality bug reports, contributing to the code base, writing documentation, writing tutorials (for the docs or on your own space), and supporting others on the various community platforms by answering questions and providing helpful tips.
Last but not least, making games with Godot and crediting the engine goes a long way to help raise its popularity, and thus the number of active contributors who make it better on a daily basis. Remember, we are all in this together and Godot requires community support in every area in order to thrive.
-
+
\ No newline at end of file
diff --git a/article/godot-3-5-cant-stop-wont-stop/index.html b/article/godot-3-5-cant-stop-wont-stop/index.html
index 8cc4fd01f9..9cd0651bf4 100644
--- a/article/godot-3-5-cant-stop-wont-stop/index.html
+++ b/article/godot-3-5-cant-stop-wont-stop/index.html
@@ -11,7 +11,7 @@
Note that builds are currently not signed, so you will get a warning on install.
This first release is experimental. There are a number of known issues with the port currently, and it isn’t optimized for use with touch input or virtual keyboards (as such it’s recommended to try it with a mouse and physical keyboard). We plan to refine the experience further for Godot 3.6 to make it more usable.
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
Material Overlay
fbcosentino has worked hard to add the new material_overlay property to MeshInstances in both 3.5 and 4.0 simultaneously. The material_overlay property allows you to assign a material that will be used to render all surfaces of the mesh again with that material. It functions the same as the next_pass material in a SpatialMaterial, but it applies to all surfaces of a mesh instead of only the surface to which the SpatialMaterial is applied.
To illustrate, here is the same material applied to our dear enemy with the three different locations:
Using next_pass to apply an effect only applies to one surface at a time.
Using material_override replaces the base material with the new one.
Using material_overlay correctly adds the effect over top of the base material for all surfaces.
Early adopters of 3.5 and 4.0 have found that this is a very helpful tool and we hope you think so as well!
Other rendering changes
As usual, many new features and bug fixes have been added to the renderer, many of which are backports of features originally planned for 4.0. Among them are:
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5.
Hundreds of other improvements
A ton of other improvements are also included in Godot 3.5 such as a 2D gradient texture you can use for lights, particle placeholders, and masking. The ability to align icons on buttons, the use of property pinning on inherited scenes, theme type variations that allow you to use your global project theme and make variations of anything. We advise interested users to also dive into the detailed changelog to know more.
Known issues
We currently have 2 outstanding regressions found in 3.5 RC builds which couldn’t be fixed in time for this release:
Flicker on some materials when Shader Compilation Mode = Asynchronous + Cache (GH-63346).
Bullet KinematicBody (3D) move_and_collide fails to return KinematicCollision with small velocity (GH-62153).
There is also a slight compatibility breakage with text-based shaders. Visual shaders are not affected unless they use expression nodes:
Shaders can no longer use the 1f/0f float literal syntax as it’s not valid GLSL (GH-59316). This change was intentional and will be kept in 4.0 for GLSL compliance.
We’ll update this list with any further regression that the first users of 3.5-stable may report.
Reporting issues
Godot is a complex piece of software and is not bug-free. Our contributors do their best to fix issues as they are being reported, but there’s a lot of surface to cover and you might encounter situations which we aren’t aware of yet, or couldn’t fix in time for this release. There will be 3.5.x maintenance releases focused on fixing bugs in coming weeks and months, so make sure to report any issue you encounter on GitHub, so that we can make sure to fix it for our future releases.
Future
This is not the end of the 3.x branch. A new 3.6 milestone already exists so you can expect some more backports coming from Godot 4.0, and continuous support for your 3.5 projects.
As Godot 4.0 is getting close to beta, most contributors are now focusing on that branch, and rightly so. So expect less feature work and backports for the 3.x branch in the future. The planned 3.6 milestone will mostly serve to wrap up current developments and prepare a Long Term Support 3.x branch that will live in parallel to 4.x stable releases, and mostly receive bugfixes.
Giving back
As a community effort, Godot relies on individual contributors to improve. In addition to becoming a Patron, please consider giving back by: writing high-quality bug reports, contributing to the code base, writing documentation, writing tutorials (for the docs or on your own space), and supporting others on the various community platforms by answering questions and providing helpful tips.
Last but not least, making games with Godot and crediting the engine goes a long way to help raise its popularity, and thus the number of active contributors who make it better on a daily basis. Remember, we are all in this together and Godot requires community support in every area in order to thrive.
-
+
\ No newline at end of file
diff --git a/article/godot-3-6-finally-released/index.html b/article/godot-3-6-finally-released/index.html
index 8a2e180a2a..8d47f5b7af 100644
--- a/article/godot-3-6-finally-released/index.html
+++ b/article/godot-3-6-finally-released/index.html
@@ -10,7 +10,7 @@
This notably gives us the following toolchains:
Base image: Fedora 39
Mono version: 6.12.0.198
SCons: 4.5.2
Linux: GCC 13.2.0 built against glibc 2.28, binutils 2.40, from our own Linux SDK
macOS: Xcode 15.0 with Apple Clang (LLVM 16.0.0), MacOSX SDK 14.0
iOS: Xcode 15.0 with Apple Clang (LLVM 16.0.0), iPhoneOS SDK 17.0
UWP: Visual Studio 2017 (unchanged)
In practice this shouldn’t change much, aside from getting some better compile and linking-time optimizations thanks to newer toolchain versions, leading to potential size or performance improvements. And some bug fixes which may or may not affect our builds.
Official Linux ARM builds
Just like added in Godot 4.2, we now have official Linux ARM builds (arm32 and arm64) of Godot 3.6. This should allow both running the Godot editor on ARM devices (such as Raspberry Pi) and Chromebooks with the Linux subsystem, and exporting Godot projects to them. The Linux export template now lets you select the architecture at export time among the four options supported in 3.6: x86_64 (default), x86_32, arm64, arm32.
Update supported versions for Android, iOS, and macOS
The target version for Android was updated to SDK 34 (Android 14). This also implied changing the Java version used for exporting to Java 17 (versus 11 previously). The path to the Java SDK can be configured in the Editor Settings.
To ensure compatibility with current Apple SDKs, we had to increase the minimal supported version from iOS 10 to iOS 12 (GH-87359), and from macOS 10.12 to macOS 10.13 for x86_64 (GH-76394).
Other notable changes
2D
Make autotiles fall back to the most similar bitmask (GH-71533).
XR: Disable blending before blitting to framebuffer from WebXR (GH-76072).
Documentation and translation updates.
Thirdparty library updates
As usual, we’re keeping thirdparty libraries updated, especially the ones which may be subject to security vulnerabilities.
This dev snapshot includes updates to:
Mozilla CA certificates from March 2024
SDL GameControllerDB from April 2024
brotli 1.1.0
bullet 3.25
embree 3.13.5
enet c44b7d0f7
libpng 1.6.43
libwebp 1.3.2
mbedtls 2.28.8
miniupnpc 2.2.7
minizip 1.3.1
pcre2 10.42
recast 1.6.0
tinyexr 1.0.8
wslay 0e7d106ff
zstd 1.5.5
Hundreds of other improvements
A ton of other improvements are also included in Godot 3.6. We advise interested users to dive into the curated changelog to know more, or the interactive changelog for an overview of all changes in 3.6.
Reporting issues
Godot is a complex piece of software and is not bug-free. Our contributors do their best to fix issues as they are being reported, but there’s a lot of surface to cover and you might encounter situations which we aren’t aware of yet, or couldn’t fix in time for this release. There will be 3.6.x maintenance releases focused on fixing bugs in coming weeks and months, so make sure to report any issue you encounter on GitHub, so that we can make sure to fix it for our future releases.
-
+
\ No newline at end of file
diff --git a/article/godot-3-capitole-du-libre-2017/index.html b/article/godot-3-capitole-du-libre-2017/index.html
index 91e6bfbef4..2e9ff1f7d1 100644
--- a/article/godot-3-capitole-du-libre-2017/index.html
+++ b/article/godot-3-capitole-du-libre-2017/index.html
@@ -6,7 +6,7 @@
In the meantime, have a pleasant day.
-
+
\ No newline at end of file
diff --git a/article/godot-3-capitole-du-libre/index.html b/article/godot-3-capitole-du-libre/index.html
index 8aa4ea30d5..e04139808c 100644
--- a/article/godot-3-capitole-du-libre/index.html
+++ b/article/godot-3-capitole-du-libre/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest5 December 2017
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.
We gathered with Julian and Gilles at the Capitole du Libre 2017 in Toulouse. It’s one of the largest French events dedicated to Free Software. We went there to showcase Godot 3 and try to introduce new users to it. Here’s our event report.
Passing the word to Gilles Roudière himself.
Gilles’ perspective
Julian (StraToN) and I (Gilles a.k.a. Groud) spent most of our time at the Godot stand. We used Fracteed’s demo to showcase the engine, along with Zylann’s Wallrider.
We met a lot of friendly people interested in Godot. Enthusiasts, hobbyists, and even some Unity users looking for an alterative to their game engine!
More importantly, we met people who are deeply involved into the game developpment community. Especially those from the Toulouse Game Dev association, which regroups both hobbyists and professional game developers in Toulouse. They even asked us to organize a presentation of the engine. Besides, we managed to sell some shirts, bringing 152€ to the project.Picture courtesy of Photo N7
We held a workshop based on KidsCanCode’s tutorial. We’re very happy about the interest it brought. 25 persons came so the room was almost full. Even if we did not manage to finish the tutorial in two hours, all participants left with a serious playable prototype, with a moving player and enemies. It seems that nobody got lost in the process, which shows that Godot is accessible to beginners.Picture courtesy of Photo N7
We would like to thank everyone involved in the event. It was very good, well-organized and welcoming. Big thanks to Fracteed and Zylann for their demos. All presentations at the event should be available soon on the Capitole Du Libre 2017, in French. The presentation from GDQuest is available in English below.
Giving a talk about Godot
I prepared a complete Open Source presentation ( sources on GitHub ) for everyone to use. It covers some of Godot 3’s new features and talks about what sets Godot apart from other engines: its design principles and its health as an open source project. A good presentation takes long hours of prep work: now you don’t have to start from scratch anymore.
The goal was to answer some of the most common questions creators may have about the engine:
What is Godot?
What can it do?
Can I trust it?
How does it work?
How do I get started?
The first idea was to use reveal.js, an open source, web-based presentation framework. This would make the presentation easy enough to edit and available to everyone: it allows you to write slides as JSON.
In the end I picked a riskier, but a more interesting option: the presentation runs in Godot 3. It’s a more playful way to introduce people to the engine: you can include a real-time game demos, use the particle engine… hopefully other Godot contributors can help to enrich it up in the future too.
You can watch the presentation right here:
The engine being in alpha, it was still a bit buggy and took some workarounds to make it work. The developers had to merge a fix for the VideoPlayer to work only a few days before the event.
The presentation was met with relative success. It’s available in French and English thanks to Daniel Marais, and it’s completely open source. The code is under the MIT license, you can do whatever you want with the assets, and there are some videos and pictures that Godot users kindly accepted to let us use. You’ll find a slide at the very end of the slideshow with credits and links.
You’re welcome to use, customize, or even to re-distribute it to your heart’s content. You’re also more than welcome to make it available in more languages! Luiz Gustavo is already at work on a Portuguese version.
-
+
\ No newline at end of file
diff --git a/article/godot-3-renderer-design-explained/index.html b/article/godot-3-renderer-design-explained/index.html
index ece34828ea..745a3f0b73 100644
--- a/article/godot-3-renderer-design-explained/index.html
+++ b/article/godot-3-renderer-design-explained/index.html
@@ -14,7 +14,7 @@
If more than one directional light is used per scene, less space is available for each light.
Reflection atlas
Godot uses a simple reflection atlas supporting 64 reflections of equal size. Reflections can be computed on load, or on every frame (slower). Reflections are stored as dual paraboloid.
Decal & projector atlas
Decal images and projectors are stored into a single atlas. If images are too big to fit the atlas they will be shrunk and appear with less quality.
Closing words
For Godot, we aimed to have a really simple 3D renderer (all the above, shaders included, amount to only around 10k lines of code) that is powerful, yet very easy to maintain (we don’t have millions of dollars to pour into development, so we are forced to understand our priorities well).
If you are a render engineer, feel free to take any ideas you have read from here for your own renderers (in fact, feel free to take any code, as Godot is MIT licensed).
Thanks for reading, and any feedback is very welcome!
-
+
\ No newline at end of file
diff --git a/article/godot-3-vr-and-ar-support/index.html b/article/godot-3-vr-and-ar-support/index.html
index 7724dc9db2..bf4f04c6c4 100644
--- a/article/godot-3-vr-and-ar-support/index.html
+++ b/article/godot-3-vr-and-ar-support/index.html
@@ -14,7 +14,7 @@
This download also contains a very simple boilerplate demo to get you up and running.
The module has been successfully tested on Windows and Linux but as I only have access to a Windows machine I’m not able to provide Linux builds at this time. I do not know anyone with capable Mac hardware and an HTC Vive, so it is unknown at this time if the module will work on Mac OS X.
It has been successfully tested on both Oculus and HTC hardware and should in theory work with any hardware supported by the Steam VR platform.
OpenHMD
OpenHMD is a great open source project that enables cross platform support for a number of major headset without relying on pre-installed SDKs. Especialy on Linux this project shines as it allows you to use hardware that isn’t supported on Linux by their hardware vendors. But equally on Windows it brings in native support for devices such as the NOLO VR controllers and even the PSVR headset!
The module we are building for Godot is still very experimental and incomplete but I’m putting it in the mix here as it would be good to have people offering a helping hand to further complete it. It may change drastically before we’re done with it. You can find the current version of the OpenHMD GDNative module in the godot_openhmd repository.
ARKit
Godot fully supports ARKit but it is unlikely to be added into the core any time soon. The biggest issue holding us back with ARKit is Apple’s requirement to compile the source code against iOS 11 and that means dropping support for the iPhone 5. Also Apple does not allow dynamic libraries being deployed over the AppStore, removing GDNative as an option (though potential workarounds for this are being discussed).
If you want to give ARKit a try the only option is to compile Godot yourself. You can locally merge the pull request with the ARKit implementation, or simply clone the ARKit branch on my GitHub fork.
Future interfaces
The interfaces discussed above are the ones in development or finished at this time. Other interfaces are being discussed but for the most part it is a function of availability of hardware and time. My time is currently consumed by bugfixing what we already have :)
Anyone wanting to give us a hand testing or developing interfaces can find us on the IRC channel #godotengine-vr on Freenode (#vr:godotengine.org on Matrix). I can usually be found there a few days a week at night or in the weekend, but do note I’m in Australia.
Finally, I have taken the lead on this project but the list of people who have helped out by testing, bugfixing, lending out hardware, discussing code, etc. is long. So thanks, loads of thanks, to all involved!
-
+
\ No newline at end of file
diff --git a/article/godot-30-new-internals-progress-report-4/index.html b/article/godot-30-new-internals-progress-report-4/index.html
index f9b14e968f..9bf13adc1e 100644
--- a/article/godot-30-new-internals-progress-report-4/index.html
+++ b/article/godot-30-new-internals-progress-report-4/index.html
@@ -5,7 +5,7 @@
Juan Linietsky4 February 2017
This article is from February 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.
First of all, apologies for not being able to show flashy stuff this month! January was spent mostly updating Godot internals and breaking compatibility, now that we have the chance.
Most of the internal code in Godot was written over a decade ago, and many design decisions that were taken back then, did not stand the test of time. Nothing serious in general, just stuff that was either incorrect or overdesigned.
The result of this work has been mostly a lot of simplification in the internals, resulting in more performance and more readable code.
We also took the chance to rewrite key parts of Godot, which were considerably overdesigned (and dated), such as the audio engine, and the import framework.
Big merge
While the 3.0 work was carried in the gles3 branch, Rémi Verschelde and other main devs kept working on the master branch, cleaning up the repo and reorganizing third party libraries into a more maintainable form.
At the begining of January, the gles3 branch was merged to master, which resulted in a pretty unusable repository.
This signalled the start of the process where all features that could not be implemented in previous versions, due to requiring breaking compatibility, could finally be implemented.
Internal changes
New memory management architecture
All the internal memory management code in Godot was rewritten. This resulted in much simpler code and hopefully more performance.
Better locking
Godot now implements readers-writers locks in many places, improving locking times when accessing some global data from multiple threads.
Local resources
Resources can now be marked as local to the scene. This allows for simplifying some behaviors, such as using a Viewport directly as a texture in a Sprite, or creating button groups without a special control.
Fixed rotation angles
Godot used rotations in XY instead of YX. Thanks to the great work of Fernc Arn/tagcup, all Godot math classes and functions should now be mathematically correct.
Made signal names more consistent
Signals are now always in past tense (e.g.mouse_exited) to indicate an event just happened, or as verbs when an action is expected (e.g._draw).
GDScript
Scalars are 64-bits.
This means that doing scalar integer math in GDScript, as well as storing these values to files, is fully 64 bits. Both integer and float types.
Support is also in progress (by Ferenc Arn/tagcup) to compile Godot using doubles for all math datatypes and functions. This is useful in case of desiring to create very large world without resorting to hacks such as moving the origin (at the cost of some performance).
Arrays are now always shareable
It was previously possible to declare arrays as atomic in GDScript, as in, copies did not keep the data shared. This resulted in several difficult to trace bugs. As a result, this functionality was removed.
Pool arrays
Godot always supported these types, but their use was confusing due to their name (ByteArray, IntArray, etc)..
These are now called “Pool Arrays”. It means they use memory from the memory pool, which makes them safer to allocate large amounts of memory without causing fragmentation.
Renamed many math types
Many math types were also renamed to have more consistent naming.
Dictionary keeps insertion order
Dictionaries now remember the insertion order. When the list of keys is requested, or dictionaries are iterated, the order should always be the same. This helps make code more deterministic and avoids VCS inconsistencies in saved files.
Automatically enabled callbacks
Common Godot callbacks such as _process, _input, etc. required a funtion to enable them.
From Godot 3.0, if a callback is detected in the code, it is enabled automatically. Disabling it manually is still possible.
Additionally, some of the callbacks were renamed (e.g._input_event became _gui_input).
Property access as default
Most of Godot’s API was exposed to GDScript as functions. This made browsing the doc and using some data somewhat cumbersome.
In Godot 3.0, most API access is done via properties:
This simplifies code a lot, as well as making the documentation easier to read.
Syntax sugar for get_node()
A simple syntax sugar was added for get_node(), a very commonly used function in Godot. This is done via the $ operator:
Together with the property accessor, makes GDScript look pretty different now…
_ready() is called only once.
A common complaint from users is that _ready() was called again when a node is re-inserted into the scene after being removed.
By default, this callback is called only the first time. If you need it again, it can be requested with request_ready().
File formats
Filetype deprecation
XML file format was removed in Godot 3.0. The TRES/TSCN formats are faster, more readable and more VCS friendly.
The venerable engine.cfg was renamed to godot.cfg. This new configuration file uses the same text serialization as .tres/.tscn, and is also versioned (so we can break compatibility more easily in future versions).
Better JSON parsing in GDScript
A very requested feature, now JSON supports parsing into any datatype (not just dictionaries), as new built-in functions were added to GDScript to handle it.
GUI
Ratio anchoring removed
Ratio anchoring was removed in controls. It was deprecated a long time ago since Godot added container support, but it could not be removed due to fear of breaking compatibility.
Better handling of Stop/Ignore mouse in controls
This area was pretty confusing in Godot 2.x, so the whole amount of options was moved to a single enum. Additionally, Drag&Drop now support these too.
Opacity / self opacity removed
Controls (and 2D nodes) now have modulate and self_modulate properties, which both change the opacity and the color of control and branch.
Editor
Settings are better categorized
This is another area where breaking compatibility helped a lot. Both Editor and Project settings are now cleaner and better organized:
Named layers
Physics, 2D and 3D layers can now be assigned names.
Better project settings editing
Project settings window was confusing because of the double checkboxes (one for persist and another for option value). This was removed in favor of a “revert” button.
New audio engine
As 3.0 is the compatibility breaking release, we took the chance to rewrite the audio engine too.
Only streams
Godot 2.x used a separate concept for Samples and Streams. Godot 3.0 simplifies the audio engine enormously by just supporting streams. Streams can be either .ogg or .wav depending on your needs, which are usually:
.ogg files are small in both disk and memory, but expensive to reproduce and very expensive to resample (change pitch).
.wav files as PCM take up a lot of disk and RAM, but are cheap to reproduce (in the hundreds simuntaneous streams), can be seeked and played in reverse.
.wav files as IMA-ADPCM are in the middle of .ogg and PCM: they take up to 4 times less space than PCM, are also cheap to reproduce, but cannot be seeked.
Playback
Only 3 nodes are needed to play back audio:
AudioPlayer, which is a generic player.
AudioSource, which works for 3D positional audio.
AudioSource2D, which is the same but for 2D.
Buses
The new audio engine has buses. Nodes that play back audio can choose which buses to send audio to.
Built-in effects
Godot 3.0 also comes with a large library of built-in effects which can be assigned to each bus. As there is not much open source audio code with a MIT compatible license we could re-use, these were written specially for Godot (and sounds great!).
New import system
One common complaint from Godot users is that many asset types need to be imported in order to be used, or in order to change certain types of flags.
For this, they have to be kept outside the project folder, but close enough to be referenced by the import versions.
Automatic import
Godot 3.0 simplifies this process a lot, by performing automatic import. Original assets are placed directly in the project folder (e.g. .dae scenes, images, etc.), and Godot will perform an internal and automatic import.
Users, then, can still refer to the original assets as if they were the actual resources (while the generated, imported resources are placed in a res://.import shadow dir). At export time, the original assets are removed and replaced by the imported versions.
Import dock
Even though import is automatic, it’s still possible to specify large amount of options per asset, and re-import. This is done via the new Import dock.
Future
With this, the large bulk of changes required for breaking compatibility are mostly complete. Next months will be focused in closing the remaining renderer features and stabilizing Godot for an alpha release.
Seeing the code
If you are interested in seeing what each feature looks like in the code, you can check the master branch on GitHub.
-
+
\ No newline at end of file
diff --git a/article/godot-30-new-progress-report-and-gdc/index.html b/article/godot-30-new-progress-report-and-gdc/index.html
index 7f82acc1f5..909471bbb0 100644
--- a/article/godot-30-new-progress-report-and-gdc/index.html
+++ b/article/godot-30-new-progress-report-and-gdc/index.html
@@ -5,7 +5,7 @@
Juan Linietsky12 March 2017
This article is from March 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.
February was spent mostly rewriting the import and export workflow of Godot, so not many pretty visual features were added. At the end of the month, I also went to San Francisco for GDC.
Import workflow
The import workflow is mostly complete. Beginning with Godot 3.0, Godot will attempt to import files transparently (no more import -> menu), more in the vein of how Unity works. This was a necessary change for many reasons:
It’s much, much simpler to write import/export code this way. Godot import/export code was most likely simplified tenfold.
Export options (convert textures, etc.) are removed, as they are no longer needed. Any PNG, JPG, etc. file in the project can be tweaked in the import options to become the desired format.
Automatic detection and reimport of many use cases for textures. If an image is detected as being used for 3D, it will change its flags (e.g. mipmaps enabled, repeat enabled). If an image is used for an albedo channel, it will automatically be converted and reimported from SRGB to Linear. Of course, all these settings can be forced manually too.
Multiple editing of imported files is possible, so settings for several files can be changed at once by selecting them on the filesystem dock. This gets rid of image groups and the hassle of changing settings for many files.
In general, much greater ease of use as files don’t need to be in a separate folder outside the project for them to be imported.
Scene importing
Importing of scenes is now operational. DAE (and hopefully FBX in the future) files are treated as if they were actual scenes (you load them directly from code). Trying to open a DAE file as a scene, however, will display this message:
Of course, as these .dae files are read-only (godot can’t save them), it brings the question of how to modify these scenes. There are a couple different ways to do this:
Using scene inhhttps://godotengine.org/backend/backenderitance is the simplest and most common way. Just inherit from the imported scene and do all the desired changes.
If you only care about materials, it is possible to tell Godot to save them as separate files. This is more akin to how Unity works. Reimports will not overwrite the saved materials.
If you care about using meshes separately, it is also possible to tell Godot to save them as files. Reimports will overwrite those meshes, though.
If you seriously don’t care about reusing the .dae file ever again, you can choose “Open Anyway”, save as another file and modify the scene to your heart’s content.
Export
The export system in Godot has been greatly simplified, but at the same time it became more flexible. There is a new export dialog:
The idea is that, instead of choosing a platform and hitting export, “Export Presets” can be created.
Many presets per same platform can be created with different export options. This allows exporting different versions (e.g. debug settings, different bit depth, demo version of a game with less files, etc.). It also makes automating exports from command line easier.
One of the presets has to be the “runnable” one for the platform, which will be used in the one click deploy for many platforms.
Resources
A new export mode for exportable resources (“Selected Scenes”) is available, which makes it easy to choose which scenes will be exported. All dependencies are tracked and exported.
The previous modes (all resources and selected resources) are still there. The “All files” mode is gone, as it’s not very useful.
Patching
Godot always supported loading patches as extra .pck files, but tools to create them were not readily available. Godot 3.0 will bring a simple tool to create patches based on previous releases and previous patches.
This should make it really easy to create patch files, DLCs, etc.
Exporting to the Web
A new exporter to WebAssembly + WebGL2 is in the works, should be working soon. This will hopefully revolutionize games on the web!
GDC 2017
I had the pleasure of going to GDC 2017, San Francisco this year. Initially I wanted to showcase Godot 3.0, but we couldn’t progress as fast as desired so this will have to wait for next year :(. By then the stable version will be out and we will have a lot of awesome demo content.
Compared to last year, some more people had heard of Godot, but it’s still very largely unknown. We seriously need to consider ways to improve on this!
Other than that, some people from key companies were pretty amazed about the new renderer features we have and will be following our progress more closely!
Will be writing a post with more details about this shortly.
Future
All that remains now is to complete and fix the remaining and existing features and we will be releasing an alpha of 3.0. Hope that happens soon!
Seeing the code
If you are interested in seeing what each feature looks like in the code, you can check the master branch on GitHub.
-
+
\ No newline at end of file
diff --git a/article/godot-30-progress-report-6/index.html b/article/godot-30-progress-report-6/index.html
index ed32c4352f..66cd636d89 100644
--- a/article/godot-30-progress-report-6/index.html
+++ b/article/godot-30-progress-report-6/index.html
@@ -5,7 +5,7 @@
Juan Linietsky9 April 2017
This article is from April 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.
Another month of work, another progress report. This month’s work was divided into completing the exporters, GDNative and the new particle system.
Web Export
Godot has now an experimental exporter to WebAssembly and WebGL2, thanks to eska’s work. You need latest Chrome or Firefox to test it, but it works really well. It even runs games flawlessly on mobile web!
Here’s a small platformer demo you can try! (again, remember, latest versions of Chrome or Firefox only!).
GDNative
We recently wrote an article about GDNative (initially named DLScript but renamed to avoid confusion). Let me tell you that this amazing new feature by karroffel and Bojidar Marinov (bojidar-bg) is the real deal. It allows way too many amazing things:
Add Godot objects made in C++, without recompiling Godot or the editor. Before this, a module had to be created, which implies recompiling everything.
Optimize any part of your game by rewriting it transparently in C++, or any language that can compiled to native code for the target platform, wihout recompiling the engine or templates.
Bind to any external libraries (e.g. SQLite, Steam, etc.) without any recompiling. Even downloading the bindings from our asset sharing would be possible.
Add import/export formats using official libraries from outside Godot. For example, you could download an FBX import module from the asset sharing. Same as direct support for stuff such as Spine using their own library.
Add external scripting languages, such as Lua, Python, etc. Of course, without the nice integration GDScript benefits from, and you’ll have to be aware of the limitations.
This will be one of the new amazing additions of Godot 3.0.
New Particle System
Godot 3.0 will come with a new particle system. As times change, the main difference is that this one processes particles entirely on the GPU. What does this mean?
Speed!
You can have hundreds of thousands of particles on legacy CPUs or mobile.. or several million particles on modern desktop GPUs.
Customization
While we offer a default particles material (which is very powerful and customizable), it is possible to write your own particle logic entirely in a shader. It is also possible to convert a particle system to a shader and do further modifications to it by yourself, manually.
More power
The default particle material allows tweaking all parameters by using curves over time:
Also, it is no longer limited to billboards only. The new particle system uses meshes by default (to work with impostor quads, just create a QuadMesh and assign a material with billboard set to enabled).
The fact that so many particles can be used thanks to GPU processing allows for really nice effects such as brute-forced trails:
And finally, more powerful emission volumes can be provided such as box, sphere and mesh surface or volume. Mesh surfaces can also emit directed by normals:
We wanted to include skeletal transform support to emission meshes, as it’s not a lot more complex, but this will have to wait for 3.1 :(
Godot 3.0 alpha
With this, all major funtionalities planned for 3.0 are implemented. We will be releasing an alpha build soon for everyone to start playing with them and finding bugs. Stay tuned!
Seeing the code
If you are interested in seeing what each feature looks like in the code, you can check the master branch on GitHub.
-
+
\ No newline at end of file
diff --git a/article/godot-30-switches-bullet-3-physics/index.html b/article/godot-30-switches-bullet-3-physics/index.html
index 3711ec1d55..520b68142d 100644
--- a/article/godot-30-switches-bullet-3-physics/index.html
+++ b/article/godot-30-switches-bullet-3-physics/index.html
@@ -7,7 +7,7 @@
This will be added after 3.0 is out, likely for 3.1.
Will it work for 2D physics?
No. Godot 2D and 3D physics engines are separated. Our 2D physics also has considerably more customization code, such as one way collisions for both kinematic and rigid bodies. The 2D physics engine will likely remain custom and be improved after 3.0 is out.
-
+
\ No newline at end of file
diff --git a/article/godot-31-will-get-many-improvements-kinematicbody/index.html b/article/godot-31-will-get-many-improvements-kinematicbody/index.html
index 388dd48617..9f1af26613 100644
--- a/article/godot-31-will-get-many-improvements-kinematicbody/index.html
+++ b/article/godot-31-will-get-many-improvements-kinematicbody/index.html
@@ -29,7 +29,7 @@
RayCast Shapes
Another common situation (when using move_and_slide()) is that the character incurs more effort going up slopes than it does going down.
This is physically correct, but some types of game expect velocity to be constant when moving up and down in slopes.
The solution for this is now the same as when creating a dynamic character controller (physics-based), which is using RayCast shapes. They work now with KinematicBody.
RayCast shapes separate the body in the direction they are pointed to, and will always return a collision normal along their ray, instead of the one provided by the floor (because, again, their goal is to separate). Yes, the name is confusing, maybe they should be renamed to SeparationRayShape in Godot 4.0 :)
In any case, change the collision shape in your body to include a ray pointing down:
And now, when moving around the stage, the speed will remain constant:
Keep in mind that the maximum slope angle where this will work will be geometrically determined by the length of the ray, so make sure to adjust the ray length according to the approximate slope you want to support:
As you can see in the picture above, the right slope is so steep that it hits the capsule before the ray, so this effectively disables the ray effect and makes the character incur a lot more effort. It happens naturally, without a single line of code needing to be written.
Sync to Physics
When a KinematicBody is moved around (be it using move_and_slide, or just moved around by modifying the position, rotation, etc. properties), it automatically computes its linear and angular velocity. This means that if either a box with physics (RigidBody) or a KinematicBody (that moves with move_and_slide) are standing over it, they will be moved along together.
This makes KinematicBody also very useful for moving platforms, elevators, scripted doors, etc.
The main limitation until now is that, when used as moving platform, its motion was always a frame ahead than the physics, so the character appears to slowly slide over it:
To compensate with this, a new option “Sync to Physics” was added. This option is useful when animating via AnimationPlayer or tweaking the position/rotation properties manually in the object:
When enabled, objects will appear in sync with the KinematicBody:
Future
After these functions are well tested, they will be ported to the 3D engine, where they should work in the exact same way.
Once again, please remember that all this done with love for everyone. Our aim is to make a 100% free and open source game engine where the games you make with it are truly yours.
This progress is made possible thanks to the infinite generosity of our patrons. If you are not one yet, please consider becoming our Patron. This way, you don’t need to be an expert engine programmer to aid with Godot development :)
-
+
\ No newline at end of file
diff --git a/article/godot-32-will-allow-disabling-editor-features/index.html b/article/godot-32-will-allow-disabling-editor-features/index.html
index 29855f1ad9..ae82e864d0 100644
--- a/article/godot-32-will-allow-disabling-editor-features/index.html
+++ b/article/godot-32-will-allow-disabling-editor-features/index.html
@@ -5,7 +5,7 @@
Juan Linietsky8 April 2019
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.
It sounds like an odd feature to have (and never crossed our minds at the beginning). Yet, more and more users requested it, and in their context it made a lot of sense. In the end, we now believe this functionality is of vital importance to strengthen Godot’s adoption in the future.
Disabling / enabling features
So, what is this exactly? To make it short, it allows enabling or disabling editor features. Using it, the editor can be reduced to a much simpler version of itself.
Short tutorial
This feature can be found in the Editor menu:
Selecting this option brings a new dialog. This dialog lets you enable or disable many areas of the editor:
As you can appreciate on the image above, there are many things that can be enabled or disabled:
General features, such as the 3D editor, script editing, or asset library.
Some docks, such as Import, Node or Filesystem.
Scene Tree editing. It can be blocked to avoid the modification of scenes.
Nodes can be disabled, and they won’t appear in the Create dialog. Existing ones in scenes will remain visible, but their editors and properties will not appear.
Resources can also be disabled. They won’t appear in the Create dialog of the Inspector. Additionally, files of that type will be absent in the Filesystem dock.
Properties for any enabled class can be hidden (for disabled classes all properties are hidden by default).
Finally, it’s also possible to disable contextual editors for any enabled class (animation editor, etc.).
Additionally, these profiles can easily be changed, imported or exported.
What’s the main use case for this?
There are two main use cases for this feature:
Education
Besides being proposed by tutorial makers, this feature was suggested several times by professionals in education, who teach Godot at schools and universities.
It allows students to use a simplified version of the editor which helps reduce confusion by focusing only on what needs to be taught.
The profile system for this feature can be used to set the progress of the course, by gradually enabling more functions as they are learned.
Companies
Godot has very powerful tools for lighting, animating, level design, etc. This means that specialized professionals (which are not necessarily programmers) can efficiently use it to create content.
For real-life use cases in medium to large companies, we got requests for restricting what non-programmers can do to only what is needed for their job. This helps avoiding accidental mistakes, especially when they are undergoing training or they work in a very contained area of the project.
Indies and general purpose
We got requests from single developers working on 2D games that they would like to disable the 3D editor and nodes from the Create dialog. The reasoning is that, if not in use, they just add clutter.
With this feature, they can be simply disabled, adding a small usability boost.
Future
A comprehensive set of options is provided for this first version, but I’m sure that more (or more fine-grained) toggles will be requested at some point in time. The plan is to make this feature as useful as possible for the use cases mentioned above.
For the rest of this month, my personal focus will be to add simple (yet very requested) features for Godot 3.2. At the beginning of May, my full focus will switch to Vulkan support. As always, if you are not, please consider becoming our patron to help speed up Godot development. Even a small amount helps us enormously :)
-
+
\ No newline at end of file
diff --git a/article/godot-32-will-get-new-audio-features/index.html b/article/godot-32-will-get-new-audio-features/index.html
index 00c5acf591..f3dbef4c41 100644
--- a/article/godot-32-will-get-new-audio-features/index.html
+++ b/article/godot-32-will-get-new-audio-features/index.html
@@ -31,7 +31,7 @@
And a video of this code in action:
Examples
Example code for both projects can be found in the demo repository.
Future
I wanted to add a BPM detector for rhythm games, but all the open source code I found is GPL (incompatible with Godot MIT), so we will probably need to roll our own. I am too busy for this at the time, but if you want to help contribute to one, let me know (I can lend a hand explaining how it’s done).
As mentioned before, this month I will be working in adding missing features for Godot 3.2. Next month I will start the Vulkan port. If you are not yet, please consider becoming our patron. It’s easy, and you help the project enormously, even if just a small donation.
-
+
\ No newline at end of file
diff --git a/article/godot-32-will-get-pseudo-3d-support-2d-engine/index.html b/article/godot-32-will-get-pseudo-3d-support-2d-engine/index.html
index 4ab1bdb48c..ee08edb218 100644
--- a/article/godot-32-will-get-pseudo-3d-support-2d-engine/index.html
+++ b/article/godot-32-will-get-pseudo-3d-support-2d-engine/index.html
@@ -5,7 +5,7 @@
Juan Linietsky5 April 2019
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.
Pseudo 3D support
Godot support for 2D is already mature and most of our users enjoy working with it. There is, however a growing trend of adding 3D layers to 2D games, which can be seen in successful titles such as Hollow Knight or Rayman Origins.
This is possible because the engines in which such games are made are actual 3D engines using 2D planes. In the end, doing this is possible but it requires understanding and being familiar with how 3D engines work.
Same technique in Godot
This is also possible in Godot using the 3D engine, via nodes such as Sprite3D, but truth is that this technique requires user to do more work and understand more about how 3D space functions.
Parallax (via ParralaxBackground) works to some extent, but it’s more aimed to be used as a far away background rather than adding depth to the game play area.
Because of this, a new way to implement pseudo 3D was added to the 2D engine, so the same results can be obtained with pure 2D programming, making it much easier to develop this type of games while using all the existing 2D tools (and assets) Godot provides.
Canvas layers
Godot 2D engine already has a node named CanvasLayer. Everything that is a child or grandchild of it will render on this layer. The layer index can be specified as a number (and it´s also tree-ordered) to control depth placement, so no real Z positioning is required.
Using this node is a common practice to make user interfaces, because they won´t scroll together with the rest of the Viewport, as layers can move independently.
Yet, moving together with the viewport may actually be desired, so a new option was added: “Follow Viewport”. Toggling it on will ensure that this layer will move together with the actual viewport when using a Camera2D.
Adding depth
Together with Follow Viewport, there is a new “Scale” property. This value allows scaling the canvas while following the viewport. It’s a simple setting but it can be used to do “Pseudo 3D” with ease:
In practice, just create your level using several CanvasLayer nodes. Edit them together as if you were using an Orthogonal view in 3D:
In the above screenshots, a few CanvasLayer nodes were created. Aftwerwards, the TileMap from the 2D Platformer demo was brute-duplicated and put in every single of them.
Finally, the “Follow Viewport” option was enabled together with a a scale value. This enables the pseudo 3D effect in each layer.
Previewing without running the game
Previewing the effect in the editor is very easy, just use the new “Preview Canvas Scale” option in the 2D view menu:
Limitations
The main limitation of this technique is that it’s not possible to move a single object in multiple layers, as they will definitely need to be separate ones (none of the games mentioned above use this, though). This can still be worked around with a RemoteTransform2D node, though requires a bit more work.
Future
This is an experimental feature, so don’t forget to give feedback! Also, if you are not one, please consider becoming our patron, to help accelerate Godot development.
-
+
\ No newline at end of file
diff --git a/article/godot-4-0-development-enters-feature-freeze/index.html b/article/godot-4-0-development-enters-feature-freeze/index.html
index 45e6052e4c..bb31273286 100644
--- a/article/godot-4-0-development-enters-feature-freeze/index.html
+++ b/article/godot-4-0-development-enters-feature-freeze/index.html
@@ -5,7 +5,7 @@
Yuri Sizov28 July 2022
This article is from July 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.
We’re determined to deliver a stable release of Godot 4.0 as soon as possible. To achieve this, we need to shift the focus from implementing new and exciting features towards stabilizing the existing functionality and fixing bugs.
The road to Beta 1
With that in mind, effective August 3rd we’re entering a feature freeze stage, and no changes to the roadmap for Godot 4.0 will be expected. If you have pending work that you absolutely want to see in Godot 4.0, submit it before August 3rd. You can either open a pull request or contact the Production team directly for your work to be considered.
Please, do not exhaust yourself and avoid crunching. There are always future releases, especially if your enhancement doesn’t break compability. Once 4.0 is released, we aim to have much shorter development cycles for 4.x releases so the wait for new features shouldn’t be long.
In the meantime we have begun reassessing every submitted PR marked for the 4.0 milestone. We want to evaluate if the proposed fix or feature is absolutely necessary for the project going into the next big stable release. Features that demonstrate no urgency will be pushed to future releases. This helps us narrow the scope and make sure we can finish this development cycle.
By August 17th, we want to have a good understanding of what features are going into beta 1. Which is why it is important that you submit your pending work long before that. If all goes according to our plan, we should have the first Godot 4.0 beta release within the next 5-6 weeks.
To reiterate the plan:
August 3rd — the roadmap for 4.0 enters feature freeze; submit your work before that.
August 17th — the scope of beta 1 is determined; reviews and assessment of PRs continues.
Early September — beta 1 is released.
Beta phase considerations
Please note that the beta phase does not mean that the engine is stable and ready for production use. We cannot guarantee that Godot 4 betas won’t have compatibility breaking changes or critical bugs. If you want to make a commercial project with the engine, please wait for at least the first release candidate. Until then, we will continue fixing bugs and improving existing features, breaking compatibility if absolutely needed so that the friction is low and effectiveness is high.
Some work can still be permitted during the beta phase. Bigger features can still be merged, if they have been approved before the release of beta 1. Smaller enhancements can also be approved, given that they have reasonably high support. Compatibility breakage at this point should be minimal or better yet avoided at all. The beta phase would be very similar to our policies for the current development of the 3.x branch, so you can refer to your experience with that.
If you want to contribute to the engine, now is a great time to do so! The faster we can fix the outstanding issues, the sooner everyone can enjoy a brand new iteration of Godot. You can start by reading our guidelines for contributors. Then look on GitHub for issues that may be interesting to you, try to reproduce them, and figure out a fix.
-
+
\ No newline at end of file
diff --git a/article/godot-4-0-docs-sprint/index.html b/article/godot-4-0-docs-sprint/index.html
index 3ebc339106..b155d2a0eb 100644
--- a/article/godot-4-0-docs-sprint/index.html
+++ b/article/godot-4-0-docs-sprint/index.html
@@ -5,7 +5,7 @@
Max Hilbrunner11 January 2023
This article is from January 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.
With the release candidate for Godot Engine 4.0 being just around the corner, we want to make sure that the community is fully prepared and can dive right into it as soon as the new version is available. To that end, this is a call to action — to help in completing the documentation for Godot 4.
Everyone is welcome! New contributors, we’re happy to help you get started. Seasoned participants, please take this chance to document all the awesome work you and your teammates have been doing on Godot. Helping each other is highly encouraged, filling the gaps and reviewing contributions to make sure they are factual and well written.
We have many new features, and documentation is going to be the first place people look at to figure them out. If you don’t have a lot of time or lack writing skills, don’t worry! The documentation team is happy to help out, just give us something to work with be it a class reference addition or a new tutorial for the manual.
How to participate in the docs sprint
What? Calling on all members of the Godot community to help complete the docs for the next major release. We’re happy to help, give tips, onboard new documentation contributors, and to get pull requests reviewed and merged! Let’s get stuff done.
When? Starting right now up until the end of this month, January 31st.
Who? Everyone is welcome. Whether you’re new to contributing, or returning to the project, there’s enough to do for everyone.
How to start? The writing documentation page in the documentation is a good start. If you have any questions, get in touch with the maintainers in the #documentation channel on the Contributors Chat. You can see the whole documentation team on the Teams page. If in doubt, ping Max (@mhilbrunner).
Where to start? Have a look at open issues in the documentation repository, as well as the main repository. You can also check the areas of the engine you’re most familiar with. See if the class reference is updated and complete for that area, whether the tutorials need to be updated, and so on.
Gotchas. The Class Reference is maintained in the main repository and needs to be edited there. See this article for more information.
Thanks to everyone who contributes and helps make this project better for everyone. Let’s end this announcement with a video by Nathan of GDQuest fame on how to start contributing to Godot’s docs! Watch it here.
-
+
\ No newline at end of file
diff --git a/article/godot-4-0-sets-sail/index.html b/article/godot-4-0-sets-sail/index.html
index 056409b5d5..700afc3f95 100644
--- a/article/godot-4-0-sets-sail/index.html
+++ b/article/godot-4-0-sets-sail/index.html
@@ -15,7 +15,7 @@
Platform Support
Android & Web Support
As always, inclusiveness is a pillar of Godot. With Godot 4, we continue to strive to enable and empower the widest possible pool of game and app developers all over the world. Your hardware preferences and even the state of the devices available to you should not constitute a barrier to creating your projects. In line with this, we’re pleased to announce that Godot 4.0 runs on Android devices and in the web browser, in addition to Windows, macOS, and Linux.
More Exporting Options
Of course, you want your games or apps to be accessible to everyone too. To this end, Godot 4 presents you with new first-class build system support for multiple CPU architectures. If you have the builds compiled, you can now target devices such as Raspberry Pi, Microsoft Volterra, Surface Pro X, Pine Phone, VisionFive, ARM Chromebooks, and Asahi Linux without much manual hassle. This is in addition to the existing support Godot has for x86 Windows & Linux, and various architectures on Android, iOS, and macOS.
We haven’t forgotten web-based games. Among many other improvements to the web platform, Fabio has added the necessary tooling to allow remote profiling of HTML5 exports. This means you can run the debugger/profiler on web exports as you would on the desktop platform making it much easier to polish and optimize your web-based games.
One limitation of our philosophy of inclusiveness is that it works best when everyone practices it. That is not the case with console manufacturers, who typically do not open-source their SDKs.
You can of course create games in Godot 3 for Xbox, PlayStation, Nintendo Switch, and more with the help of third parties. Several teams are already working on console support for Godot 4, hoping to make it more accessible to everyone.
This said, if your project is destined for consoles, regardless of the engine you use, you will ultimately have to register with console manufacturers and do the difficult work of adapting your game to follow their many guidelines and pass their strict QA.
Future
Did we mention Godot 4.0 is only the beginning? We kept reiterating this because we’re sharply aware that after 3 years of development, a major release feels like the end of a long wait. The reality is that Godot 4 starts now and we’re eager to polish it with a fast paced release cycle. We’ll iterate quickly on the more modern and flexible architecture that we’ve built for this major branch. Godot 4.0 is by no means a silver bullet - it’s a stable base for us to build upon, and for you to start developing new projects which will mature alongside Godot 4.x.
We’re working on a precise roadmap that we’ll publish at a later date.
This is not the end of the 3.x branch either. Godot 3.6 is on the way to wrap up current developments. You can expect some more backports coming from Godot 4.0 and the beginning of a Long Term Support 3.x branch that will live in parallel to 4.x stable releases, and mostly receive bugfixes.
-
+
\ No newline at end of file
diff --git a/article/godot-4-1-is-here/index.html b/article/godot-4-1-is-here/index.html
index f0a0737609..7c09cbfc7a 100644
--- a/article/godot-4-1-is-here/index.html
+++ b/article/godot-4-1-is-here/index.html
@@ -6,7 +6,7 @@
C#/.NET
The focus in this release was on bringing feature parity between C# and GDScript.
When using GDScript, you can define a new node type to use in the editor by adding a global class name to your script.
Starting from Godot 4.1, this is also possible in C# by adding the [GlobalClass] attribute to your file, thanks to Raul Santos and Will Nations. You can also use the [Icon] attribute to give your global class a unique icon.
Note that as of this release projects made with C# still cannot be exported to mobile and web platforms. We are working on providing the support as soon as possible, but the resolution of this limitation will likely depend on the release of .NET 8 at the end of 2023. This means that the work on enabling mobile and web platforms can only truly start later this year.
GDExtension
Godot comes with a unique technology to use low-level languages like C++ as a game scripting language, without having to recompile the engine.
While the technology is still in beta for this release, GDExtension is now even closer to GDScript and C# in terms of scripting capabilities. You can now implement new visual shader nodes and create editor plugins with GDExtension.
The team also implemented a backward compatibility system to help ensure that code written for Godot 4.1 keeps working even if the API changes in future releases. However, a significant compatibility breakage was necessary to do in 4.1 to fix critical issues in GDExtension, so existing Godot 4.0 extensions will need to be ported and recompiled for 4.1.
Finally, a lot of work was done on the architecture once again to make the GDExtension API extensible in the future.
Godot 4 has support for multiple windows which we use for the project and editor settings and various pop-ups. Starting with this version, you can now also detach docs into floating windows and detach script editors, including the shader editor, and place them on a separate monitor.
In addition to that, the editor will now keep track of your window layout so that when you close and reopen the editor, you should often find yourself exactly where you left off.
Godot 4.0 introduced the option to define and export typed arrays, and to export individual nodes to the inspector, but it was not possible to combine the two. From Godot 4.1 onwards, you can export arrays of nodes to the inspector, which is great to link game objects together.
The project manager now allows you to assign tags to individual projects and filter projects by tags. It makes it much easier to search through dozens, if not hundreds of Godot projects.
Rendering
Particle turbulence got reworked in this version based on artists’ feedback to offer greater creative control. Turbulence is used extensively to create these rich sprawling effects seen in many modern games. Big thanks to KdotJPG and Raffaele Picca for this contribution.
Using the new 3D noise textures you can control the density of volumetric fog easily, and make it thinner in certain areas. NoiseTexture3D can also be used to create particle attractor vector fields, which is useful to simulate wind that affects particles. Lasuch and Clay John implemented this feature.
While there are still many planned improvements to Godot’s renderers, most will be present in future releases. The rendering team (and all rendering contributors) prioritized bug fixing and stability over new features. Notably, the 3D GLES3 renderer is not yet complete, but will see substantial work over the coming months.
Navigation
Godot 4.0 introduced real-time avoidance for AI navigation, but it was limited to a single plane.
This release includes completely rewritten avoidance algorithms by smix8 to give you much better behaviors and greater control. Avoidance can now happen in 2D or 3D, allowing flying agents to move over those walking on the ground.
On top of that, you can now use layers to control which agents avoid which and assign priorities to have some agents push others away.
Check out the updated documentation to learn more about how the improved navigation works.
Platform support
We are as committed as ever to have Godot games on all popular platforms, and 4.1 still offers the same capabilities as did Godot 4.0. You can export to all desktop platforms with both standard and .NET version of the engine, and you can export to mobile and web if you don’t use C# in your projects.
As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.
Known issues
With every release we acknowledge that there are going to be problems which we couldn’t resolve in time. Some of these problems have been identified and fixes are being worked on as we speak, while others remain unknown until someone runs into the issue. You can follow our bug tracker to learn if the problem that you’re experiencing has been reported. We appreciate new reports and confirmations of existing reports, as that helps us prioritize fixing specific issues.
Here are notable issues that have already been identified that you might experience in Godot 4.1:
The newly added API for defining custom configuration properties for export presets does not persist user configurations. Configuration options get reset and lost on editor restarts. The fix is going to be available in 4.1.1 (see GH-79025).
On to the next release!
We already started work on Godot 4.2, which will come out in four months. We are dedicated to keeping up the pace and sticking to this reliable release cycle, so you never have to wait long for the next batch of improvements and new features.
-
+
\ No newline at end of file
diff --git a/article/godot-4-2-arrives-in-style/index.html b/article/godot-4-2-arrives-in-style/index.html
index e873a2fd64..c44e20e413 100644
--- a/article/godot-4-2-arrives-in-style/index.html
+++ b/article/godot-4-2-arrives-in-style/index.html
@@ -23,7 +23,7 @@
(GH-79990).
Regular and documentation comments are seeing some upgrades as well. Special TODO markers (such as TODO, FIXME, etc.) are now highlighted in the code editor to better grab your attention (GH-79761). You can configure both keywords and colors that are given to them in the editor settings. Documentation comments now support @deprecated and @experimental tags to mark class members accordingly in the generated documentation (GH-78941). Documentation generation itself has also been improved (GH-80745). All these changes were submitted by, once again, Danil Alexeev.
To close things off for GDScript, a contribution to the language server from Ryan Brue improves hovered symbol resolution, fixes various bugs related to renaming, and implements reference lookup, all in one go (GH-80973). These changes should make your experience coding in GDScript with an external editor significantly better. Ryan also added a new command line argument, --lsp-port, which is useful for authors of LSP plugins to support both Godot 3.x and 4.x, as well as multiple editor instances (GH-81844).
XR
Godot’s lead XR maintainer Bastiaan Olij recently published a progress report on new and upcoming XR features, which you should definitely read! Some highlights from the list of changes, implemented by Bastiaan himself, include foveated rendering support, ported from Godot 3.x (GH-80881), and access to raw hand-tracking data (GH-78032).
On top of that, a significant contribution by konczg from Migeran opens up the OpenXR module to be extended and interacted with from the GDExtension API (GH-68259). We can’t wait for your projects utilizing this capability to its fullest!
Known issues
With every release we acknowledge that there are going to be problems which we couldn’t resolve in time. Some of these problems have been identified and fixes are being worked on as we speak, while others remain unknown until someone runs into the issue.
You can follow our bug tracker to learn if the problem that you’re experiencing has been reported. We appreciate new reports and confirmations of existing reports, as that helps us prioritize fixing specific issues.
Acknowledgements
Announcements such as this are as much of a team effort as the development of the engine itself. We look to our community for help with illustrating the changes and improvements that go into each release.
This article features screenshots and clips provided or based on the work of GDQuest, passivestar, Minions Art, Icterus Games and Todogodot, as well as various engine contributors who provided illustrations with their pull requests.
Make sure to support these creators and follow them for more amazing stuff!
On to the next release!
We already started work on Godot 4.3, which will come out early next year. We are dedicated to keeping up the pace and sticking to this reliable release cycle, so you never have to wait long for the next batch of improvements and new features.
-
+
\ No newline at end of file
diff --git a/article/godot-4-will-discontinue-visual-scripting/index.html b/article/godot-4-will-discontinue-visual-scripting/index.html
index 270568d60d..db1ba9b389 100644
--- a/article/godot-4-will-discontinue-visual-scripting/index.html
+++ b/article/godot-4-will-discontinue-visual-scripting/index.html
@@ -6,7 +6,7 @@
With this information, VisualScript was created and published for Godot 3.0.
It was not perfect, but it contained most of what we believed was needed to use it. Using it was similar to GDScript but in a graphical, node-based way.
Unable to meet expectations
Unfortunately, VisualScript did not catch on. When trying to ask users why they did not use it, we got two main answers:
For a lot of potential users that wanted this feature, they found out GDScript was a great fit and they pretty much ended up preferring it over VisualScript. They did not expect to find GDScript to be so easy to learn and use (even if they did not have prior programming knowledge), given none of the popular engines of the time offered this type of high level scripting. For many of these users, Godot ended up being a tool to learn programming instead.
Even though the visual scripting base functionality was there, Godot lacked high level components to make use of it. Engines like Unreal, Game Maker or Construct offer high level game features packaged together with the visual scripting solution. This is what makes it useful. Godot is an extremely general purpose game engine where it’s easy to make those features yourself, but they don’t come packaged out of the box. As such, VisualScript by itself was of little use.
Another likely reason for VisualScript’s low popularity is that we failed to provide good documentation for using it. The official documentation has examples in GDScript and C#, but we never succeeded in including VisualScript examples due to technical reasons (we’d have to make screenshots of VS graphs for each example and maintaining them would prove very difficult). We had some demo projects, but that’s not enough to let users become proficient with a language, even a visual one – and to learn Godot’s API, they’d need to become familiar with GDScript or C# to understand the examples.
According to our most recent poll (with more than 5000 respondents), only 0.5% of the user base has used VisualScript as their main engine language.
No path forward
The contributor community did improvements to it, but for the most part these were mostly based on assumptions of what could be improved since, for pretty much all features we implement in Godot, we always get user feedback indicating us what needs to change, via issues or proposals.
VisualScript was the exception, we struggled to get enough feedback to improve it meaningfully. The conclusion we can draw from this is that there simply wasn’t any path forward: the approach we took to visual scripting was simply not the right one.
Removing and maybe moving to extension
VisualScript will be removed from the codebase in Godot 4.0 (it will remain supported in Godot’s 3.x branch).
As VisualScript was implemented as an optional module, the relevant code was moved to a dedicated repository so that interested users could still compile it in, if there is interested in keeping it up to date: https://github.com/godotengine/godot-visual-script
One possibility is to convert it to an official GDExtension using GodotCPP, which is very mature now and should support everything required to do this. As an extension, it may work better as a ground for experimentation and improvement. For this to happen, however, there have to be volunteers wanting to make this happen and spend the time required to research a path forward. If you are interested, get in contact with us on the #scripting channel on the Godot Contributors Chat.
Retrospective
Godot development philosophy has shaped very strongly to focus on finding solutions for user problems and real-life use cases. VisualScript was not developed this way, and hence we were unable to implement something useful, costing us significant development time. This has been a great learning experience and it reinforces our belief that Godot must always be developed user-facing first.
Future
There are some ideas floating around by contributors on implementing alternatives to do visual scripting, more similar to tools like Game Maker or GDevelop. Anything that is done will most likely still be an extension, as this provides more flexibility to experiment with quick feedback from users, and to provide lots of high level and even game-specific components without adding a significant maintainance burden on the core engine.
The VisualScript removal from the core engine will happen before Beta (which is now very close!). Even though it’s gone, we are still thankful to all the effort that many contributors put on it over the past years to try to keep it alive, even if ultimately we were unable to make it user-friendly enough to attract user interest!
-
+
\ No newline at end of file
diff --git a/article/godot-40-gets-global-and-instance-shader-uniforms/index.html b/article/godot-40-gets-global-and-instance-shader-uniforms/index.html
index a8cd8688dc..2877ee5a90 100644
--- a/article/godot-40-gets-global-and-instance-shader-uniforms/index.html
+++ b/article/godot-40-gets-global-and-instance-shader-uniforms/index.html
@@ -36,7 +36,7 @@
For global uniforms there is no limit though, you can have as many as you want.
Future
Hard work and lots of love continues being poured into the master branch by the project contributors to make Godot 4.0 our best release ever. If you are not yet, please consider becoming our patron, and helping the project achieve its goals faster and better!
-
+
\ No newline at end of file
diff --git a/article/godot-40-gets-sdf-based-real-time-global-illumination/index.html b/article/godot-40-gets-sdf-based-real-time-global-illumination/index.html
index 3fb3898aef..ebd5627a30 100644
--- a/article/godot-40-gets-sdf-based-real-time-global-illumination/index.html
+++ b/article/godot-40-gets-sdf-based-real-time-global-illumination/index.html
@@ -7,7 +7,7 @@
How do you use it?
Ensure your meshes are marked as “Static Bake”, then enable SDFGI in the Environment settings. That’s it.
There are some options to customize SDFGI:
Cell size: Shows the base cell size of the nearest cascade. Each further away cascade duplicates the size, allowing very large view distances that support global illumination.
Multiple Bounces: Enable a feedback loop, which simulates multiple bounce lighting.
Occlusion: Generates occlusion information between the probes, to avoid light leaks in walls. Occlusion generally works well, but you must ensure that walls are thicker than a voxel at the cascade they are rendering to in order to avoid light leaks. It has a small cost when enabled.
Read Skylight: Allow sky to contribute to lighting/
Y Scale: Trades horizontal detail for horizontal range. This is very useful for scenes with interiors.
There are also some new debug modes to visualize how SDFGI is working:
SDFGI Cascades: Show the world as SDF, helps you understand what voxel sizes are, so you adjust your geometry to work better with those voxel sizes.
SDFGI Probes: Shows where probes are (only near cascade for now), helps you understand where your geometry is reading lighting from. If an areas has less probe density, it may get wrong occlusion.
How does it work?
Will write an article about this soon.
Videos
Introduction Video:
Very large, open world scene with real-time GI:
Future
Godot 4.0 keeps improving and we are fully commited to create an amazing game engine, that you can use with the same freedom as as if it was your own in-house tech. If you are not yet, please become our patron and help us improve Godot faster!
-
+
\ No newline at end of file
diff --git a/article/godot-40-optimization-progress-report/index.html b/article/godot-40-optimization-progress-report/index.html
index 078a6f41b5..d2fc70c118 100644
--- a/article/godot-40-optimization-progress-report/index.html
+++ b/article/godot-40-optimization-progress-report/index.html
@@ -7,7 +7,7 @@
have been pretty dramatic, between 3-4x in most tests. The sole exception is the Dynamic Cull one, which tests 10k moving objects paired to lights. Unfortunately the Dynamic BVH implementation I used is not very good, and it will be replaced by something else in the coming weeks.
GPU Optimization
A lot of optimization was done on the GPU side:
Implemented automatic LOD, to reduce on vertex load.
Skeletons and blend shapes are now processed using Compute, and run all together.
There are special versions of meshes to render when doing shadow maps or depth pre-pass. This reduces the amount of vertices processed as well as bandwidth.
Re-written most shaders to reduce VGPR usage, thus improve occupancy. This allows the GPU to better parallelize them.
Re-written the light clustering. Clustering is now entirely done on GPU. The new approach is much faster, allowing hundreds of lights with shadows at extremely good performance.
Optimized texture formats. For many algorithms, used smaller texture formats to reduce bandwidth.
Did general optimization in most shaders to improve performance.
Added more quality settings to GI, allowing it to run on lower end devices.
Improved parallelism with more clever use of barriers. Most shaders (both compute and raster) will run in parallel as much as possible. This gives massive performance improvements on AMD hardware (more modest on Nvidia).
Here is a full frame of Godot running a scene at 1080, 8xMSAA with all effects, GI, etc. turned on. Note that many tasks are now overlapped.
On my test hardware (Vega64) frame time improved from 10 to 4.5ms. On NVidia 1650 I saw improvements from 15 to 10ms. With the scalable quality settings, it is now possible to target a very wide range of hardware.
Future
Some tasks (not many) are remaining regarding optimization, then will move to other areas. Pending are visibility dependencies, portals and occlusion culling, which will be done later. Additionally, a tool to do automatic quality adjustment based on performance is still being planned, so you can ship your game and ensure it will work on as much hardware as possible without the user intervention.
As we are approaching an Alpha release, Godot 4.0 is finally shaping up to be a very performant engine for 3D. And, as always, remember all this is done out of love for you and the community. If you are not yet, please consider becoming our patron!
-
+
\ No newline at end of file
diff --git a/article/godot-40-will-get-new-modernized-lightmapper/index.html b/article/godot-40-will-get-new-modernized-lightmapper/index.html
index 0f6393e5e1..56709a2023 100644
--- a/article/godot-40-will-get-new-modernized-lightmapper/index.html
+++ b/article/godot-40-will-get-new-modernized-lightmapper/index.html
@@ -5,7 +5,7 @@
Juan Linietsky9 May 2020
This article is from May 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.
After 3 hard weeks of work, the new lightmapper for Godot 4.0 is ready to go!
Wait, why a lightmapper, didn’t we get real-time GI?
Yes, indeed. Godot 4.0 will also have a very cool Voxel based real-time GI:
Still, that is a different technique aimed at different use cases. Lightmaps offer significant advantages over any other technique when the following requirements are met:
Performance above anything else (for mobile, lightmaps are still a must-have)
Quality above anything else (no light leaking, ideal for architecture)
Lighting will not change (lights won’t move)
If these requirements are met, then lightmapping is probably the best for you.
Didn’t we have a lightmapper in Godot 3.2?
The lightmapper in Godot 3.2 was a very simple voxel-based lightmapper that used the same code as GIProbe. It was extremely limited and had serious performance and quality problems, so it was seldom used. In fact, the plan is to back-port this new lightmapper to Godot 3.2 too.
Are there no good lightmappers available you can use for Godot?
Unfortunately no. While the theory behind lightmappers is relatively simple, implementation is actually very complex due to several corner cases that need to be resolved in order to produce a decent quality. While there are some simple libraries around, there is nothing close to a complete implementation of a lightmapper published with source code and a friendly license.
Let’s hope this implementation will also be of use to others making their own technology or engines, so they can use it as reference or just copy it.
Features of the new Godot 4.0 lightmapper
GPU based by default
The new lightmapper is GPU based written mostly on Compute shaders (meaning it does most of the heavy lifting using the GPU, via Vulkan). Most scenes bake in seconds instead of minutes or hours. If your device does not support it, an option to use a CPU based one will be present, which will be slower but more compatible.
Quality as priority
Despite lightmappers being pretty old technology, the new one that was implemented in Godot 4.0 branch uses state of the art algorithms to ensure the maximum possible quality:
Bakes geometry to lightmap coordinates using the actual rendering code, so any existing shader or material works.
Supports emissive materials, so it is possible to use it for emissive lighting.
Uses an efficient conservative rendering approximation to ensure thin polygons are not lost, but also avoids growing geometry too much (which reduces bake performance).
Efficiently packs all texture objects in the lightmap to a texture array, to avoid state or material changes during rendering.
Allows baking dynamic and static lights.
Allows multiple bounce support, from 0 to 16 light bounces.
Performs proper seam-blending, to remove discontinuities in the geometry.
Performs AI-based denoiser on the final bake, to ensure lightmaps are as smooth as possible.
Supports L2 Spherical Harmonic based lightmaps for normal-aware lighting.
Easy to use
Lightmappers normally require a lot of tweaking to achieve the best possible quality. This one instead, had a lot of work put into it so you can get the most quality out of it from only a set of parameters used to configure it.
There are more advanced configuration options in the project settings, but the ones exposed to the inspector should be enough for far most use cases.
Lightmaps work “the Godot way”
In most game engines, a lightmap is baked for a whole scene and only one can be used at the same time. In Godot, different scenes can have their own ligthmaps and you can mix and match them however you like.
It is also possible to toggle lightmaps as “interior”, which allows mixing them with “exterior” lightmaps (as an example, a large field and a castle on that field, going inside the castle will make it have priority over the exterior because it’s marked as “interior”). For lightmaps of the same type, Godot will perform blending between them for dynamic objects.
This allows creating very complex scenarios by mixing pre-lit scenes transparently.
Lightprobes
The old lightmapper in Godot 3.x used a light octree to give dynamic objects the ability to receive indirect light. This technique had good quality, but suffered from performance and memory problems. Very large maps lacked detail or required huge amounts of memory.
The version in Godot 4.0 will use more standard lightprobes that you can manually place in your scene, but it also supports automatic lightprobe placement (configurable via different resolutions), for getting things working quickly. Adding extra lightprobes to the automatic generator works fine, so you can still increase capture quality at certain map regions.
As a result, dynamic objects just work, look great and only use very minimum CPU time to compute their lighting.
Automatic UV unwrapping
Similar to Godot 3.x, you need to set objects to generate lightmaps on import, but this process works much better now and it will cache the lightmap UV2 coordinates in objects that did not change across re-imports.
Future
With these new features, Godot 4.0 is shaping up to be an excellent choice for high end graphics development. Stay tuned for the next cool updates in rendering tech! And as always, remember we do all this with love for you and everybody who likes making games. We want to create the best and most accessible technology for you, and make it free and open source so your games are entirely yours. If you are not yet, please consider becoming our patron and help us reach this goal sooner!
-
+
\ No newline at end of file
diff --git a/article/godot-aims-mainstream/index.html b/article/godot-aims-mainstream/index.html
index acc1d3c7e1..d3a3bec57e 100644
--- a/article/godot-aims-mainstream/index.html
+++ b/article/godot-aims-mainstream/index.html
@@ -6,7 +6,7 @@
This is obviously wrong and against the trend in modern game engines. As an example, Lumberyard, the new amazing Amazon game engine, uncompresses to 40 GB after download.
It’s a basic rule in marketing that public visibility depends on how big you are. So starting from Godot 2.1, users will finally be able to download an installer that takes up 2.7 GB of your hard drive. This increase size should hopefully help increase our visibility and give our users the feeling that they are installing a feature-packed engine. Of course this won’t just be bloat, the additional size will be due to many important new features: for example, the internal PI constant will provide the first 231 decimals of π (Pi), as we know that mathematical precision is an important concern in the gaming industry.
Asset Store
It is clear that our current approach to offering an editor with the most common tools and aiming at improving the built-in tools in each new Godot release is wrong and against the trends too. Users have a hard time finding their way through the tons of features that Godot supports right now, so we need to remedy that to become more mainstream.
From Godot 2.1 onward, we want to do away with this monolithic approach and provide an editor with a limited set of tools. This will make it easier to learn the engine at first as there won’t be much to do, and most actual features will have to be downloaded and purchased from the new Godot Asset Store.
We will stop merging pull requests on the core engine and editing tools. Instead, contributors will be asked to sell their improvements via the Godot Asset Store, thus making it more enticing to contribute features to the engine ecosystem, and thus benefiting the users as a whole.
Built-in monetization
Everyone wants to use ads systems from Google, Microsoft, etc. within Godot, but so far we had refused to include such modules in the core tree. Since we know users only care about making mobile apps to make money together with advertising companies, we will provide support for such APIs out of the box.
More than that, Godot will keep being free but you will only be able to use Google services for ads and server services. Games shipped will also send analytics to us the developers so we can better make money by selling your information.
We will soon publish an updated EULA dated April 1st 2016, to ensure that every Godot user starting with version 2.1 knows and accepts these new usage conditions.
-
+
\ No newline at end of file
diff --git a/article/godot-and-openhmd-kiel-open-source-and-linux-days/index.html b/article/godot-and-openhmd-kiel-open-source-and-linux-days/index.html
index fd701701df..fde94a00ce 100644
--- a/article/godot-and-openhmd-kiel-open-source-and-linux-days/index.html
+++ b/article/godot-and-openhmd-kiel-open-source-and-linux-days/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde25 August 2017
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.
This is mainly of interest to the German members of our community, but maybe also German-speaking users of the neighbouring countries: Godot will be present as the Kiel Open Source and Linux Days (Kieler Open Source und Linux Tage, alias Kilux) in Kiel, Germany, on Friday 15 and Saturday 16 September 2017.
Godot and OpenHMD (VR) stands
Several core Godot developers will be there (Andreas alias Hinsbart, karroffel and myself), and we hope to see many other members of the community at our booth. If you plan to come to the event, don’t hesitate to add yourself to our Framadate so that we know whom to expect :)
We should also have some cool Godot T-Shirts on sale for a fair price!
But that’s not all - we are teaming up with the OpenHMD developers who will have their booth right next to ours. OpenHMD is a free and open source API and set of drivers for Virtual Reality (VR) devices, and they have been working with our main VR contributor Bastiaan to implement their API in Godot 3.0.
This means that they will bring the VR devices, we will bring the (work-in-progress) VR capable game engine, and together we will showcase demos of fully free and open source Virtual Reality! So by all means, come to our stands and give it a try!
Godot talk and workshop
On Saturday 16, we will we have two organized events:
A general presentation of Godot from 11:00 to 12:00 in Room R114, intended mainly for people who haven’t heard or read much about our engine yet. We will present features of both the current stable and the upcoming 3.0 versions, showcase some games, discuss the roadmap and answer all kinds of questions from the public.
A 2-hour workshop to get started with Godot by making simple games together. At the time of this writing, there are only two places left, so be quick to secure yours! For those who may miss it, don’t worry, we can spend plenty of time kickstarting your Godot journey directly at our stand :)
Practical infos
The event takes place at the Kieler Innovations- und Technologiezentrum in Kiel, Germany, from 10:00 to 18:00 both days. See the visitor infos for more details, as well as the programme to plan ahead which talks and workshops you would like to attend. There is no entrance fee, as usual in such free software community events.
The event is mainly German-speaking, so all of us Godot developers are of course also English-speaking (some of us even being Dutch and French), so if you’re in the geographical area, don’t let the language barrier put you off. Our Godot presentation and workshop are planned in German for now, but if we see that the attendants would be like them in English, we can easily switch :)
-
+
\ No newline at end of file
diff --git a/article/godot-apk-fixer-tool/index.html b/article/godot-apk-fixer-tool/index.html
index 11c2c9a064..6ba82b6128 100644
--- a/article/godot-apk-fixer-tool/index.html
+++ b/article/godot-apk-fixer-tool/index.html
@@ -7,7 +7,7 @@
When using jarsigner from the JDK for instance.
After the program has finished you will find an apkname_fixed.apk in the same directory as the original APK. This APK should now be good to upload back onto the Play store.
For those who are interested the source code to this tool can be found on notabug.
-
+
\ No newline at end of file
diff --git a/article/godot-arrives-in-the-epic-games-store/index.html b/article/godot-arrives-in-the-epic-games-store/index.html
index f767a17503..6ff8a59972 100644
--- a/article/godot-arrives-in-the-epic-games-store/index.html
+++ b/article/godot-arrives-in-the-epic-games-store/index.html
@@ -5,7 +5,7 @@
Emi17 March 2023
This article is from March 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 honored to announce that Epic Games is offering Godot Engine a place on the Epic Games Store. Starting today, you can choose to use EGS to download the engine and keep it up to date with every release.
Epic Games is a long-time supporter of Godot, and thanks to their contributions we have been able to improve our rendering pipeline as well as our built-in scripting language, GDScript – the fruits of that work are now visible in the newly released Godot 4.0!
The Godot build you can download from EGS is the exact same open source release as on other platforms. Being present on more storefronts opens a new convenient avenue for more users to find the engine and begin their game development journey. You can of course still download Godot Engine from other platforms, or clone its source code from the Git repository and build it yourself. And if you do, you are more than welcome to contribute to Godot’s development too!
We are excited to continue our friendship with Epic Games and to be published on the Epic Games Store. We believe this will bring new opportunities for growth and development for Godot and its community. Thank you for your continued support and we look forward to seeing what you create!
-
+
\ No newline at end of file
diff --git a/article/godot-at-big-festival-2023/index.html b/article/godot-at-big-festival-2023/index.html
index 0aabd0fcb5..d0b1498c95 100644
--- a/article/godot-at-big-festival-2023/index.html
+++ b/article/godot-at-big-festival-2023/index.html
@@ -2,10 +2,10 @@
Following our success at the GDC earlier this year, Godot will have a booth at the BIG Festival for the first time. BIG will happen between June 28th and July 2nd, so it is right around the corner.
BIG Festival is a huge event for indie game developers that happens yearly in Brazil since 2012. It is one of the biggest in Latin America and gathers out many big players in the industry, not only from Brazil but also from the rest of the world. It has a good amount space for showcasing games, an awards ceremony, and industry-related talks.
During GDC we met some of the organizers of the BIG Festival which started a conversation that ended up with our presence being confirmed at the event. Our booth is being kindly sponsored by W4 Games. Without the support of sponsors like them, our presence at the event would not have been possible.
We will also have a talk about the current state and plans for Godot’s growth, presented by one of the project’s co-founders: Ariel Manzur. It is scheduled to happen on Thursday, June 29th at 18:35 (local time), in Stage 1. You can see the details on the official program page.
While most Godot maintainers won’t be able attend — due to the difficulties of traveling and costs — you’ll find me at the booth together with volunteers and contributors interested in the project, and Lisandro Lorea from W4 Games. So if you’re in São Paulo for the event, make sure to come to say hi and talk about the project. See you there!
This article is from June 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.
Following our success at the GDC earlier this year, Godot will have a booth at the BIG Festival for the first time. BIG will happen between June 28th and July 2nd, so it is right around the corner.
BIG Festival is a huge event for indie game developers that happens yearly in Brazil since 2012. It is one of the biggest in Latin America and gathers out many big players in the industry, not only from Brazil but also from the rest of the world. It has a good amount space for showcasing games, an awards ceremony, and industry-related talks.
During GDC we met some of the organizers of the BIG Festival which started a conversation that ended up with our presence being confirmed at the event. Our booth is being kindly sponsored by W4 Games. Without the support of sponsors like them, our presence at the event would not have been possible.
We will also have a talk about the current state and plans for Godot’s growth, presented by one of the project’s co-founders: Ariel Manzur. It is scheduled to happen on Thursday, June 29th at 18:35 (local time), in Stage 1. You can see the details on the official program page.
While most Godot maintainers won’t be able attend — due to the difficulties of traveling and costs — you’ll find me at the booth together with volunteers and contributors interested in the project, and Lisandro Lorea from W4 Games. So if you’re in São Paulo for the event, make sure to come to say hi and talk about the project. See you there!
-
+
\ No newline at end of file
diff --git a/article/godot-at-gamescom-2023/index.html b/article/godot-at-gamescom-2023/index.html
index 1dd70c9113..d2a583380f 100644
--- a/article/godot-at-gamescom-2023/index.html
+++ b/article/godot-at-gamescom-2023/index.html
@@ -6,7 +6,7 @@
-
+
\ No newline at end of file
diff --git a/article/godot-at-gdc-2023/index.html b/article/godot-at-gdc-2023/index.html
index ca314e3bc8..115c3d926c 100644
--- a/article/godot-at-gdc-2023/index.html
+++ b/article/godot-at-gdc-2023/index.html
@@ -5,7 +5,7 @@
Emi21 November 2022
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.
We are excited to announce that the Godot Engine will attend the 2023 Game Developers Conference (GDC), on March 20-24.
The Game Developer Conference is a yearly event in San Francisco, California. It is the world’s largest professional game industry event, with over 26,000 attendees. The conference features over 700 lectures, panels, and workshops on a variety of game development topics, as well as a large expo floor with over 500 exhibitors.
Thanks to W4 Games who are donating it, the Godot Engine will have its own booth for the first time. We got in touch and teamed up with a selection of Godot developers from all over the world to present their high-profile games at our booth, and share their Godot experience with visitors. This is an excellent opportunity if you want to meet the people behind the engine, or other like-minded folks, so come to hang out and play some of the fantastic games. You might even get some free swag ;)
We’ll give more details in coming months as we get closer to the event, so stay tuned!
-
+
\ No newline at end of file
diff --git a/article/godot-at-gdc-2024/index.html b/article/godot-at-gdc-2024/index.html
index 95314a0f08..ee0874396c 100644
--- a/article/godot-at-gdc-2024/index.html
+++ b/article/godot-at-gdc-2024/index.html
@@ -5,7 +5,7 @@
Godot Foundation13 February 2024
Since we had a great & productive time last year, and 2,000 pins dispersed around the world to prove it, we are attending the Game Developer Conference (GDC) again. It is taking place March 18-22 in San Francisco, California.
What can you expect?
This year, W4 Games is organizing a Godot Pavilion and the Godot Foundation will be there hosting a selection of developers who could not be more stoked to let you play their Godot Engine games on the expo floor. Keep an eye on this space to not miss the line-up announcement!
We are also bringing along Godot Foundation members (like Adam, Emi, George, Nat, Rémi, Winston & more) for in person chats, as well as inviting any maintainer/contributor present for work reasons to come join us any time :)
You will find us at: booth S763, North & South Halls, Moscone Center.
If you would like to schedule a meeting with the Godot Foundation, you can write an email to Emilio with “GDC” in the subject.
Other than that, we are also planning a Godot get-together at GitHub HQ on March 20th, more info on that as soon as we can share it.
Where can I stay up to date?
This blog is the right place. In addition, we put out a forum post asking the community who plans to attend, to give you the chance to connect and make plans together. Lastly, don’t forget to follow our socials, where we are sure to post some pictures during the event as well.
I can’t come…
We are aware that traveling to the US for a conference is not an option for all of you.
If you want to meet us in person, you can also do so at gamescom (August 21-25, Cologne) or even later this year at GodotCon (date and location TBD). Parts of the team will be present at the newly merged Gamescom Latam/BIG Festival (June 26-30, São Paulo) too.
In case you are looking for networking opportunities concurrent to GDC, there are online alternatives like https://notgdc.io/ worth checking out.
-
+
\ No newline at end of file
diff --git a/article/godot-community-poll-2020/index.html b/article/godot-community-poll-2020/index.html
index 67ecae824e..59b88dd8b9 100644
--- a/article/godot-community-poll-2020/index.html
+++ b/article/godot-community-poll-2020/index.html
@@ -5,7 +5,7 @@
Juan Linietsky13 July 2020
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.
It’s this time of the year again! Help us better understand who is using Godot, what are your needs and towards where Godot usage is trending by completing the anonymous community poll! This is a short poll that should take a few minutes to complete.
-
+
\ No newline at end of file
diff --git a/article/godot-community-poll-2021/index.html b/article/godot-community-poll-2021/index.html
index 6f003a27fa..238f944cc5 100644
--- a/article/godot-community-poll-2021/index.html
+++ b/article/godot-community-poll-2021/index.html
@@ -6,7 +6,7 @@
Let us know what your relationship with Godot is in this brief list of questions!
The poll is completely anonymous, and you can see the results after filling it. It will remain open for a week. Completing the poll should take less than 5 minutes.
-
+
\ No newline at end of file
diff --git a/article/godot-community-poll-2022/index.html b/article/godot-community-poll-2022/index.html
index 1ada280ee9..4e467802ce 100644
--- a/article/godot-community-poll-2022/index.html
+++ b/article/godot-community-poll-2022/index.html
@@ -6,7 +6,7 @@
Let us know what your relationship with Godot is in this brief list of questions!
The poll is completely anonymous, and you can see the results after filling it. It will remain open for a week. Completing the poll should take less than 5 minutes.
-
+
\ No newline at end of file
diff --git a/article/godot-community-poll-2023/index.html b/article/godot-community-poll-2023/index.html
index 7cc6b9dcb6..0d66e5639c 100644
--- a/article/godot-community-poll-2023/index.html
+++ b/article/godot-community-poll-2023/index.html
@@ -6,7 +6,7 @@
Clay John23 June 2023
As we do every year, we would like to take a short poll to gather some basic information about the Godot community. We have a short list of questions and we hope you will take the time to fill them out!
The poll is completely anonymous, and you can see the results after submitting your answers (we will also post a link to the results directly once the poll has closed). It will remain open for a week. Completing the poll should only take a few minutes.
-
+
\ No newline at end of file
diff --git a/article/godot-community-poll-2024/index.html b/article/godot-community-poll-2024/index.html
index 7e1ba02fe1..83cd7a21a6 100644
--- a/article/godot-community-poll-2024/index.html
+++ b/article/godot-community-poll-2024/index.html
@@ -8,7 +8,7 @@
2022, 2021, and 2020.
-
+
\ No newline at end of file
diff --git a/article/godot-consoles-all-you-need-know/index.html b/article/godot-consoles-all-you-need-know/index.html
index 27bb233a40..174b143355 100644
--- a/article/godot-consoles-all-you-need-know/index.html
+++ b/article/godot-consoles-all-you-need-know/index.html
@@ -5,7 +5,7 @@
Juan Linietsky15 July 2022
This article is from July 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 subject of running Godot games on consoles pops up very often. In this article you will find information about the following topics:
How console development works.
The challenges that Godot faces for supporting those platforms.
Which alternatives exist to publish your Godot games for consoles.
What is the consoles market like?
While platforms like Steam are very easy to publish for, the reality is that most of the revenue from independent developers generally comes from consoles (this, of course, speaking of devs not focusing on mobile).
Consoles are cheap, easy to get access to, and have a wide catalog of first and third party titles, making them ideal devices for players wanting to spend their time and money on games.
How does one develop for consoles?
Unfortunately, consoles are entirely closed ecosystems. This means that there is a very simple rule that must be followed in order to develop for them: Unless you sign an NDA (Non Disclosure Agreement) and the manufacturer approves you, it is impossible for you to obtain any kind of information in regards to how they work (and much less publish games).
This means that, on the whole public Internet, you will not be able to find (legally, at least):
Any detailed public documentation on how consoles work (that was not reverse engineered).
Any official tools or libraries that let you develop or run your game on consoles.
Any downloadable game engines that, out of the box, include support for developing or exporting to consoles.
This includes game engines such as Unity or Unreal. To obtain the console versions of those, you must get licensed, sign the NDA, get approved and then download the version that lets you develop on consoles from a secret console development portal. It is a common misconception that you can download a game engine and start using it to develop for consoles without previously being approved by the console manufacturer.
The only exception at some point was exporting to the UWP platform which could run on XBox, but it had limited access to the console internals and was eventually deprecated by Microsoft.
Where does Godot fit is in all this?
Godot is a free and open source (FOSS) game engine, published under the MIT license. Development is made entirely in the open. Because of this, it is impossible for Godot to include first-party console support out of the box. Even if someone would contribute it, we simply could not host this code legally in our Git repository for anyone to use.
Additionally, it would not be possible to distribute this code under the same license that Godot uses (MIT) because this is in direct conflict with the proprietary licenses and non-disclosure terms that console manufacturers require to have access to the knowledge needed to write this code.
To make it simple, it is not possible for Godot to support consoles as an open source project.
Can it be done in secrecy?
Some projects such as LibSDL, Haxe, Monogame, Cocos or Defold developed console ports behind closed doors and offer them to licensed developers for free, so the question arises often about whether Godot can do this too.
The answer is that, Godot is not in the same situation, because:
Godot is orders of magnitude more complex than any of those projects. Porting the platform layer can be relatively simple, but porting the rendering engine and making sure it works well is extremely laborious. Hiring talent that can do this properly can be in the order of hundred thousands of US dollars. Given consoles are exclusively a commercial market, It is very unlikely that anyone would do this for free if it can’t be made open source afterwards.
Additionally, save for SDL (which is the simplest of them all given its just a platform layer), all the other projects are actually developed by companies with an actual business model, such as the Haxe Foundation (which is actually a company), Microsoft, Cocos China, or King for Defold (then Refold).
Godot is not developed by a company. It is a pure open source project developed by individuals entirely in the open, so it has no alternate business model to sustain the cost of developing console ports at loss.
Additionally, the difficulties do not end there. Obtaining the source code for console development can be useful for some independent developers, mainly those who are strong in technology, but this is not how console manufacturers prefer to work.
In consoles, any technology that is offered to develop titles for them must be an official, licensed middleware. This means that, for companies to use them, they require that:
It must support the platform efficiently (the port must be optimized for it).
It must support the platform APIs, such as save files, online APIs, peripherals, dedicated hardware, etc as best as possible.
There must be some level of technical support for companies using the technology in the platform.
Unless the above points are met, obtaining official middleware category is not possible, which means that most companies will still not be able to port their Godot games to consoles, even if they can get the source code.
In all, supporting consoles properly is very costly and beyond the possibilities of Godot as a project to do so.
So, how do I get my Godot game into consoles anyway?
The best way to do this right now is to work with companies that will port and publish your Godot game to consoles. Because these companies act as the publishers, they are not required to license the technology to you (and thus avoid the costly process of becoming middleware providers). For most independent developers also, porting to consoles is not easy because they need to meet a lot of technical requirements, so working with a company that does for them is generally still desired.
Links to companies that do console porting for Godot titles:
Most smaller studios working on games with Unity and Unreal also rely on third party companies to ensure that their ports are done properly and pass all the console comformance requirements.
The last alternative is to do the console ports yourself. This is what Sega did for Sonic Colors Ultimate, but only large studios with a strong technical background are assumed to be able to do it.
Future
One can only wish that, as consoles nowadays are almost nothing more than openly documented stock hardware (very distant from the specialized hardware that we saw until the PS3/Wii era), the secrecy requirements are going to be eased at some point in the future. Efforts can be seen from Nintendo and Microsoft in this direction already.
Still, until (if) this happens, it is possible that some of the existing (or new) companies that specialize in Godot for consoles may become licensed Godot middleware providers, but it must be clear that this is a very costly process so they will need to make revenue somehow and adoption will depend on the strategy they take towards independent and corporate entities.
Hoping that this dissipates most of the doubts regarding to Godot on consoles. If you have further questions, let us know!
-
+
\ No newline at end of file
diff --git a/article/godot-core-budget-meeting-report-1/index.html b/article/godot-core-budget-meeting-report-1/index.html
index 24f9cd990f..f653208293 100644
--- a/article/godot-core-budget-meeting-report-1/index.html
+++ b/article/godot-core-budget-meeting-report-1/index.html
@@ -5,7 +5,7 @@
Juan Linietsky11 June 2020
This article is from June 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.
The funding situation of Godot has been evolving in the past months, as we received more grants and donations, and reorganizing where the funding is going, deciding hires, etc., takes considerable time as well as requires the right timing.
Because of this, we have started organizing meetings with the core Godot contributors to discuss and decide how to best allocate our available budget in the best interest of the project. To these meetings we invite long standing Godot contributors who we know and trust and who have made significant contributions to the project over the years.
Based on the outcome of these meetings, the PLC (which still has the final say regarding the use of Godot funds) will set things in motion with our legal and fiscal home Software Freedom Conservancy to apply these decisions. The idea is to publish a brief of what was discussed in the meeting, so that the community and those donating can have more transparency on what funds are being used for (although remember that, in the end and whatever we decide, Software Freedom Conservancy’s charitable mission ensures that our funds are solely used for the benefit of the project).
Keep in mind that, as a main rule, Godot is a free and open source project where most of the development and contribution is done by volunteers donating their free time, so we only use funds for critical tasks of utmost importance, where we are having difficulties finding enough volunteer time to work on them, and for which the PLC and core contributors decide that we must move forward.
The following is the list of topics discussed at our first meeting in late May 2020 and what was decided:
RTL + font shaping
There is a high demand from Godot users in countries and cultures where right-to-left writing systems are used to have proper support for it in Godot (such as Arabic, Hebrew, etc.). Additionally, many languages require advanced font shaping features to handle diacritics and letter combinations, which are often fundamental for any accurate rendering of these languages (see e.g. Is this Arabic? for a light-hearted crash course). Unfortunately, most of the project contributors are from countries where these language systems are not common (plus the task complexity is high, as it involves refactoring the way Godot handles text controls like Label, RichTextLabel or Button) and creating this support without actually being able to understanding it is very difficult.
As this is a task of high interest, we were offered donations specifically to do this task. As such, we will start accepting budgets to do this from developers or companies that might be interested in implementing it. The proposal of what exactly needs to be done will be cleaned up in the coming days so we will make an announcement and start accepting budgets proposals to do it. If you have significant experience with Godot and/or with implementing RTL and font shaping support and you are interested, please wait until then.
Documentation budget
We have received a 10k USD directed donation to improve documentation. We discussed with the core developers about hiring GDQuest (who have plenty of experience working with the engine documentation, with Nathan being one of our main docs contributors) to work on this task. We also discussed a proposal to further clean up the documentation and clearly separate more game-specific tutorials, as well as having a clearer way to link to content generated by our community.
Hiring a generalist contributor for editor UX and web dev
On planning our next full-time hire, we discussed the possibility of hiring one of our core contributors to work, among other things, on improving the general usability of the Godot editor, which we believe to be an area where a lot of work is pending. They would also help with the management of contributions and bug fixing in various areas.
The contributor we have in mind also has experience in web development, so they could help us improve the Godot website and infrastructure, which have been needing more work in many areas, like a proper showcase, up to date content, a proper system to show our combined funding status and goals, etc.
As always, our goal with hires is that they need to be cash-flow positive. Meaning that we will not do permanent hires unless 1) Our level of monthly funding (Patreon, Paypal, etc.) can cover it, with some extra margin 2) We have enough money saved up to ensure two years of paid work for all current contractors.
Please understand that it is always a risk for our contributors to quit their current jobs to work for the project, so we need to ensure we will be able to pay them for a considerable time before hiring them.
Hiring Matias Goldberg to help him create GPU-based texture compressors
One of the main problems we have in Godot is the time it takes to import textures. Most texture compressors are often slow and focus on the highest quality possible as a priority instead of attempting to do trade-offs between quality and encoding performance.
To work around this, for Godot 4.0, we want to move our texture compressors to GPU using compute shaders. Using them allows to convert all the import formats at the same time and make them as efficient as possible. The idea is to have near-instantaneous import while optionally marking some of your textures for high quality and having those imported in higher quality in the background (but still have a lower-quality version usable right away).
Because we want this work to benefit other projects as well (so more can contribute to it), we will do a financial contribution to Matias Goldberg (the lead developer of Ogre 3D) for his work on Betsy, which is a new, very high performance GPU-based texture compressor.
X11 fixes
Godot 4.0 will support a new display system based on a DisplayServer. This allows much cleaner code for handling display and input, as well as allowing multiple window support. Unfortunately, we ran into some issues in the X11 platform that are very difficult to fix, and X11 is an extremely difficult API to work with (requiring a combination of text based atomics with manually marshalled data) that requires years of experience. Eventually, if we can’t fix them in the coming weeks, they idea is to look for paid work from experienced X11 developers to solve those issues.
Renewing Ignacio’s contract
Ignacio has worked two years full-time on the C# support for Godot thanks to a very generous grant from Microsoft. He has done an incredible job which has now allowed 20% of our users to make their games using C# and, upon the imminent completion of his tasks, more users will be able to use Godot with C# as it will support all platforms for deployment.
Unfortunately, given the COVID situation, and even though there is full interest from all parties, doing a timely renew of his contract with another donation so he can continue working on C# is looking a bit difficult for the time being.
Because of this, and given so many users and companies are now interested in his work, we will be adding a funding goal so Ignacio can be hired full-time. When the situation becomes more normal worldwide, and we can manage to get sponsoring for his work going again, this will allow us to use the extra funding for more paid work.
Renewing Fabio’s contract
Fabio Alessandreli has been doing a fantastic job the past years improving Godot networking, multiplayer, HTML export and even getting Godot editor to work on the web (which has been highly requested by the education community). He has been working thanks to generous donations by Mozilla, and his work package still has some months to go, but the idea is that, given he has proven his enormous worth and ability to contribute to the project, we want to secure the budget to hire him full-time for the foreseeable future.
While it may be possible for us to negotiate other donations for him to work further on networking on Web support, it has been decided to add a funding goal for hiring him full-time too.
Documentation infrastructure work package
We have been discussing that, besides improving the documentation itself, we want to improve how documentation is shown to you. Currently, we are using Sphinx via ReadTheDocs, and we’re overall quite happy with it, but our users are also finding some limitations, such as:
The built-in search engine doesn’t provide the most useful results.
There is no way to leave feedback, notes, or questions on documentation topics, which is common in modern doc systems.
We need a system to switch references to API methods easily from snake_case to PascalCase, depending on the scripting language you are using.
Other many smaller usability issues.
For this, we discussed and we plan to use accumulated project funds to hire Hugo Locurcio (who has been a longstanding Godot contributor) to do a work package consisting of improving the Godot documentation system.
Accessibility work package
A common request for Godot is that we improve tools meant for accessibility in games, so developers can more easily make their games easier to enjoy by users with accessibility issues. There have been some ideas and discussion floating around, but it’s difficult to come up with a proper proposal of what would constitute good accessibility support in Godot. Because of this, we decided to work on a proposal and allocate some extra budget for this (or maybe try to get this work sponsored).
Future
As you can see, we are very serious in how we use project donations and funding, and we make our biggest effort so donations are used as best as possible for the common good. The idea of these reports is to add more transparency in how we decide to use our funding. Donations help us hugely to achieve our goals faster and to provide you a fully free and open source game engine that you can own as if you made it yourself for your game.
And as always, if you are not yet, please consider becoming our patron (BTW, the Patreon page will soon be updated to better reflect our current and future funding goals as outlined above).
-
+
\ No newline at end of file
diff --git a/article/godot-course-kickstarter-next-monday/index.html b/article/godot-course-kickstarter-next-monday/index.html
index 18c26f6809..dca69c564f 100644
--- a/article/godot-course-kickstarter-next-monday/index.html
+++ b/article/godot-course-kickstarter-next-monday/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 May 2017
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.
This is a guest post from GDquest, a content creator who will soon start a Kickstarter campaign for a professional Godot course, with the full support of the Godot dev team.
Hey there, I’m GDquest. I make game creation tutorials with open source technologies. The developers and I decided to collaborate to fund and produce the first game creation course for the upcoming Godot 3. A professional training costs a lot to make, and because of that it has to be crowdfunded. We asked you, the community, if you were interested, and the response was extremely positive!
So, it’s happening. The project will be up on Kickstarter next Monday, on May 22, at 12PM CEST!
The course’s content
Once we reach the initial funding goal, you’ll get at least 40 exclusive tutorials, 10 assignments and commented code sources in the premium version. I sure could lower the quality and make a lengthier series, but I’d rather help you learn more in less time. If you watch GDquest on Youtube, you’ll know I’m all about quality over quantity. Also, take it as minimum! I don’t want to stop there, and i’ll work hard to provide as much value as I can.The training will reuse the work done for the Krita course, but in a top-down game
The series will revolve around a 2D Zelda-like, as the mechanics we’ll look at are directly applicable to all kinds of games. But the goal is to teach you much more than that! It will give you a better understanding of the engine, of the game creation workflow, and how to write solid code! Fellow developers and teachers offered to give advice and share insights to elevate the content even more.
Oh, and as you might expect, the higher the funding, the more content you will get, regardless of your pledge. Every single cent will be spent on the course.
30 days tutorial challenge
There is already a ton of videos on the channels for you to watch now. But there’s only a short series dedicated to Godot. During the Kickstarter campaign, I’ll release one free tutorial every single day, mostly about the engine! It’s going to be tough, but that’s my way of giving back to the community.
It’s all based on your feedback
I put out a form to ask you what you wanted to learn exactly, and you’ve been more than 600 to reply!
Your requests shaped the project already. There are hundreds of completely different suggestions, some as challenging as “show how to make a 3D MMORPG”, so I can’t cover them all. But I took note of everything that’s most useful, and exciting. You’ll see some of them in the free tutorials.
It starts next week
Crowdfunding, by essence, involves the community. It cannot happen without you.
The Kickstarter starts on Monday 22 at 12 PM CEST.
-
+
\ No newline at end of file
diff --git a/article/godot-developer-fund/index.html b/article/godot-developer-fund/index.html
index 02474e6a54..e76884d68b 100644
--- a/article/godot-developer-fund/index.html
+++ b/article/godot-developer-fund/index.html
@@ -5,7 +5,7 @@
Emi12 September 2023
We are excited to introduce a major improvement in funding the development efforts of the Godot Engine – the Godot Development Fund! The goal for the Development Fund is to create a direct way for everyone to help us secure stable funding and ensure the longevity of the project.
The Development Fund was soft-launched in July and already welcomed a lot of new and old sponsors, but we need to take it to the next level to sustain the current development pace, and increase it with new hires.
Reducing platform fees, amplifying impact
The Development Fund will make the Godot Project more sustainable and independent. This new platform lets us significantly reduce platform fees, and as a non-profit we do not charge VAT on donations, unlike a platform like Patreon does. So your contributions go directly towards the development and improvement of the Godot Engine itself.
If you are currently supporting us through Patreon, we encourage you to switch to the Godot Development Fund to increase the effectiveness of your donations.
Giving back to the community
The support of the community is what keeps making it possible to reach new heights. With you, we can achieve even more!
Every donation, no matter the size, helps us immensely! With your help we can hire more developers, create high quality demos, pay for hosting services and infrastructure, and make the best possible Godot Engine. The more funds we have, the more we can give back to you and the entire gamedev community.
Future enhancements
While this is a good, fully functioning starting point for the platform, we will keep improving the Developer Fund.
In the future, the platform will give automated rewards, like a special Discord role, and you’ll be able to showcase your contribution level next to your username on our main platforms.
Freedom and independence
By relying more on recurring user-funded contributions and company sponsorships, we reduce our dependence on large one-time grants from corporations. This financial independence empowers us to prioritize the needs and interests of our community and the open source principles at the core of our projects. Your help ensures that we can create our own journey, uphold our core values, and continue to evolve the engine in ways that truly benefit you, the users.
A heartfelt thanks
We would like to take a moment to express our deepest gratitude for your ongoing support, dedication, and passion for Godot. It’s thanks to you and our amazing community that the Godot Engine is what it is today. Let’s continue to make it the game engine of choice for developers worldwide!
We absolutely understand that not everyone can donate. In that case, please share the Godot Dev Fund link! Spreading the word is an excellent way to help.
-
+
\ No newline at end of file
diff --git a/article/godot-docs-improvements-report/index.html b/article/godot-docs-improvements-report/index.html
index 7832f9333d..7f9daea048 100644
--- a/article/godot-docs-improvements-report/index.html
+++ b/article/godot-docs-improvements-report/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest4 December 2020
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.
Some of you like the docs for what it covers already; others dislike it for what it lacks.
The team’s well-aware there is always room for improvement, and so they hired me to work part-time since September.
My job was to take the maintainer’s role for about two months and tackle some high-priority tasks. As such, I got to do a mix of reviews, editing, writing new content, and maintenance.
Here’s a report on the changes and the new content you can already enjoy today.
In everything I wrote or edited, the goal was to simplify the language, improve precision, organize the information, and generally enhance your experience reading the docs.
Note: you can find the changes in the bleeding-edge manual. We haven’t back-ported them to the “stable” documentation yet as there are over 100 pages to redirect. More on that below.
We’ll start with the boring stuff and finish with the re-written getting started series.
The audit
The job started with an audit of the existing manual. I read the manual from start to finish and took notes about the parts that needed edits, a re-write, to move, or that were missing.
From there, I created individual issues so both contributors and the team could see what’s missing. I also triaged hundreds of existing issues and reviewed, edited, and merged dozens of pull requests, many pending since months ago. I also reviewed contributions to the class reference for a time.
Reorganization
I moved about 150 pages to improve your browsing experience. The sections now have clearer names, some were merged, and many files moved to more appropriate sections. You will now find sections dedicated to rendering and performance optimization, for example.
This change involves registering as many redirections on the back-end, affecting every version of the online manual. This is the main reason we haven’t included the changes in the “stable” docs.
Content and contribution guidelines
The guidelines are much simpler and are now split into shorter pages based on your interests. The new contributing section now gives you a better overview of how you can help.
We have new content guidelines to define what should and shouldn’t go into the docs.
Until now, we accepted a bit of everything; we lacked a clear direction and quality standards. These guidelines give us clear goals and help to set priorities for the online manual.
We are moving towards delivering a complete reference manual, the perfect companion to the class reference, and moving away from game-specific tutorials that we could never manage to keep up-to-date. The only exceptions are the two “your first game” tutorial series for new users.
The new “step-by-step” series
The series of articles introducing new users to Godot was a bit of a melting pot. It always lacked a clear target audience, coherent style, tone, and teaching goals.
Yet, it’s essential to nail this one because it’s the first experience tens of thousands of new users will have while learning Godot. It introduces key concepts you need to know to understand Godot and that other tutorials online don’t necessarily cover.
I re-wrote it entirely to make it more accessible, avoid introducing many new concepts at once, and generally provide you with a more coherent series.
It starts with an introduction to Godot to answer the most common questions newcomers have: what can it do for me? How does it work? Do I need to know programming to use it? You then get to learn some key concepts, have a first look at the editor, and learn how to make the most of official learning resources and maximize your chances of getting support on the QA site or Discord.
The step-by-step series now covers the essentials in a relatively short amount of time.
The goal here is to get you to the point where you can follow the “your first game” tutorials as fast as possible, so you can apply what you learned early on and get results quickly.
Note: the extra pages moved to other sections, and I improved some about scripting.
There is now a complete Your first 3D game tutorial series to introduce you to 3D game creation with Godot. That was commonly requested, and it’s now available.
The game itself is similar to the 2D one, with a twist, for learning purposes. It will help you spot similarities and differences working with 2D and 3D in Godot. They’re complementary tutorials, yet we’ve designed them so you can read only one or the other if you so desire.
What next
This job was funded by a generous donor who requested that the money went to the docs’ specifically. We’ve invested it in a range of tasks that we felt would give you the biggest value for the budget and help onboard more contributors in the future.
There is always more to do, and more you can get. Completing the manual is a colossal yet essential job for you and tutorial-makers to learn the beast that Godot is.
Yes, on top of you, tutors need good documentation to create the tutorials everyone loves, starting with me.
But to fund more quality work on the docs and Godot, we need you.
-
+
\ No newline at end of file
diff --git a/article/godot-doing-well-gdc-2018/index.html b/article/godot-doing-well-gdc-2018/index.html
index 36c21276ab..21a731d2c7 100644
--- a/article/godot-doing-well-gdc-2018/index.html
+++ b/article/godot-doing-well-gdc-2018/index.html
@@ -5,7 +5,7 @@
Juan Linietsky25 March 2018
This article is from March 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.
I went to GDC yet again (this time GDC 2018) trying to see how Godot is doing at the game industry. To my surprise this time, it was quite different..
Game Developers Conference
Before anything, I’m sure that many reading this article don’t really know what GDC is.
GDC stands for “Game Developers Conference”, and it’s the biggest industry wide event for game developers. Almost 100k developers (companies and indies) meet in San Francisco every year in March to showcase their work, make business meetings, socialize, have fun, etc. This event is not mainly about showcasing games, like E3 or Gamescom, but entirely for developers themselves.
There are also talks about technology, production or any other aspect one can think about related to game development.
It’s a really incredibly huge event and you get overwhelmed by so much going on at the same time.
Godot at GDC
As until Recently I worked as a technical and business consultant for a few companies, I accompanied them every year to the event. I also took the chance to see how Godot was doing in the industry.
To recap a bit. I will quote from GDC blog posts I wrote in past years:
2016
The sad truth is that, even after two years of being open source…
NO ONE KNOWS ABOUT GODOT
2017
Compared to last year, some more people had heard of Godot, but it’s still very largely unknown. We seriously need to consider ways to improve on this
Enter GDC 2018
This time, thanks to your infinite generosity, I can work full time for the project. I decided to do the economical effort to go to GDC and spend it entirely for Godot.
Even if I had to go booth by booth, person by person, I was determined to let everyone know that Godot exists.
Amazingly (and I still don’t know what or how it happened) it was not necessary, because..
This GDC, Godot was well known!
I took weeks before the event preparing meetings with many companies to talk to them about Godot. Yet, what happened is the opposite. Most companies wanted to meet with me because they heard about Godot and wanted to either let me know about it, or find out more about it.
I would probably say most of the industry still has not heard about it, but there is a very significant chunk that did, though.
This is a ton of information, so I will try to break it down a bit.
Godot magic is at work
Reasons why a company may be interested in leaving their current technology may be varied (will expand on that later), but until recently they really had not much of an alternative.
Thanks to the effort of all our contributors, Godot is becoming more and more amazing every year. There seems to be no limit to how good it can become, and the hard work from everyone paid off.
Godot (and mainly since verson 3.0) is now robust, has amazing features, great documentation, and the source code is very polished.
For most developers, just giving Godot a try is enough to convince them that, it not only works as an alternative but it’s also a significant improvement over their existing software.
The gambling industry is largely moving to Godot.
This is not an overstatement. A large part of the meetings I had with were with companies in the gambling industry (slot machines, casino, etc). Many of them were pretty large (some of the biggest in the industry, I would dare to say).
In that industry, it seems Godot got a head start. Many are already using it and many more are already developing with it.
The reason for this is, as I was told, that other commercial engines have a pretty expensive gambling license and their source code is pretty difficult to deal with.
As a result, Godot is the next logical choice for them.
Godot is growing from the middle, not the bottom.
One would naturally expect that small companies would be the first to be interested in Godot, then that interest would move to larger ones. This is not what is happening, though.
I discussed with many companies that are moving to Godot and tried to understand their reasons. Most are middle-sized and some are large. Their reasoning goes along the following lines, from what I could gather:
Many companies (mostly from Europe and Latin America) simply love open source and, just for this fact, will pick Godot whenever possible.
Companies that used to develop their own technology moved to Unity/Unreal because it allowed them to cut largely on development costs. Yet, they definitely miss flexibility. Godot gives them back this flexibility while still helping them cut costs.
Many medium (and large) sized companies told me they are angry at the major player in this industry for trying to abuse its dominant position by using analytics and telemetry built into their closed engine to force them pay for per seat licenses. Some even called it “Being forced to pay the game development tax”.
People usually says “If my game makes it big, I would gladly pay 5% of revenue share”. Yet for companies, 5% is actually a lot (games are not a commodity, and most are made at loss, so paying 5% of an actually successful game is a lot).
Small companies are still uninterested in Godot
Most small and indie companies I discussed with are uninterested in Godot. Their current technology suits their needs fine because they are not doing anything too complex and they don’t plan to grow either.
Still, at the indie booth, I found many companies that were doing the switch to Godot and were interested about it (mostly, because by chance, they had the chance to try it out and that is usually enough).
A large part of them (maybe about half?) still didn’t even know about it either. I wish we could improve on this.
Academy is very interested in Godot
Many schools and universities have found that Godot is a lot more efficient to teach game programming (or even programming alone) than commercial counterparts.
It filled me with joy to hear stories that, once they learn Godot, students prefer to keep using it because it’s closer to how they like to think about developing games.
The open source nature in Godot is also very appealing to students (the dozens of GSoC applications we are getting are also proof of this too, I guess).
Picking issues from our GitHub issue tracker and trying to fix them is a great learning excercise in programming and how game engines work.
The main problem we seem to have in this regard is that most institutions are creating their own teaching material, and there is not a stabilished channel for them to share. Any ideas or suggestions about it would be very welcome as we would really like to improve on this area.
We had our first Godot Meetup at GDC!
There has been many Godot events in Europe already, but none in North America.
Thanks to the huge generosity from GitHub, we organized a meetup at their offices. More than 300 individuals signed up to attend and it was a great opportunity for developers to meet each other.
This is just the starting point
As mentioned before. Most companies that decided to give Godot a try for their next projects are still completing projects in their current technology, or just begun to use it very recently.
It will be a long time until we start see a considerably larger amount of games published that were made with Godot.
Growth is slow and it will take many years, but I believe we are finally begining to be a significant player in the industry.
Again, please donate
We hope in the near future, as more companies are using Godot, more companies will be able to sponsor the project.
In the meanwhile, we are still dreamers that are spending our lifes trying to make game development a better place for everyone. We couldn’t do this without your help, so (if you are not already) consider becoming our patron!
Rémi, who has been doing an incredible job as project manager, is this close to becoming our project representative.
Your donations will help him spend of time going around the world, meeting companies, going to game development events (so I can stay at home programming Godot instead of travelling :-P) , organizing communities, etc. Please help make it happen!
-
+
\ No newline at end of file
diff --git a/article/godot-editor-horizon-store-early-access-release/index.html b/article/godot-editor-horizon-store-early-access-release/index.html
index c719aaeda2..6fc9f90166 100644
--- a/article/godot-editor-horizon-store-early-access-release/index.html
+++ b/article/godot-editor-horizon-store-early-access-release/index.html
@@ -11,7 +11,7 @@
An important step for the XR & Game communities
Besides the technical achievements required to make this port feasible, we believe this is a significant milestone as it impacts the XR & Game community in a few but critical ways:
Turns the Meta Quest into a true Spatial Computer
The Meta Quest gains the ability to create (and distribute) its own native apps without the need for a PC or laptop computer!
Being able to run a full game engine on a mobile XR device should serve as inspiration for the type of apps that can be brought to the mobile XR ecosystem.
Grows the OpenXR ecosystem by providing a seed for building feature rich apps
Godot Engine is a free and open-source software (FOSS) project which means that, in partnership with the Godot Foundation, OpenXR vendors can bring similar capabilities to their devices to grow the OpenXR ecosystem.
Reduces XR development friction
XR development on PC and laptop devices has significant friction due to the need to switch back and forth between the development device and the target XR device (i.e. taking the headset off for development, putting back on for playtesting).
This is not an issue when using the Godot Editor natively on XR devices since the development and target device are now the same device!
Lowers the barrier of entry for XR and Game development
This version of the Godot Editor turns devices like the Meta Quest into an easily accessible development device with the ability to natively create, develop and export 2D, 3D or XR apps and games for all Godot-supported platforms.
Provides a more flexible development experience
Developers can leverage the virtual space to gain more screen estate than a laptop could provide.
The virtual floating panels provide a more flexible layout than a traditional desktop + multi-monitors setup.
The ability to playtest and modify XR projects in-headset in real-time is a capability that can’t be replicated on PC and laptop computers.
Next Steps, Feedback & Contributions
This is only the beginning!
As mentioned in the previous section, we believe this is an important milestone for the XR, GameDev, and Open Source communities and we aim to build on this foundation to make Godot Engine a powerful, flexible and cross-platform tool for XR and Game development.
To that end, we welcome feedback and contributions from partners, members of the community and interested parties.
-
+
\ No newline at end of file
diff --git a/article/godot-editor-running-web-browser/index.html b/article/godot-editor-running-web-browser/index.html
index c321d35c84..3e5c2885c3 100644
--- a/article/godot-editor-running-web-browser/index.html
+++ b/article/godot-editor-running-web-browser/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli29 May 2020
This article is from May 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.
Hello Godotters! It’s-a me, Fabio! In the last few months, thanks to the great sponsorship of Mozilla I’ve been working on a big surprise for Godot 4.0, namely making the editor available as an HTML5 application.
This DOES NOT mean that we will move completely to the Web like other engines did. It will only be provided as a complementary option to the native editor, as a way to lower the entry barrier. Let me explain further.
Rationale
Godot Engine supports exporting games to the HTML5 platform (i.e. browsers). Given that the editor itself is written using the Godot Engine API it should be possible to run the editor in browsers as well.
The reason why the editor wasn’t able to run in browsers up until now was due to some historical Web browsers limitations, mostly lack of support for threading, but also file system access.
With the introduction of WebAssembly, WebAssembly threads, Javascript SharedArrayBuffer, and possibly an upcoming Native FileSystem API, it should now be possible to have an almost-native user experience when running the editor on the Web.
This will be beneficial in many ways to the engine itself for multiple reasons:
It will lower the barrier for new users, which will be able to try out the engine without the need to download anything.
Any modification towards reaching that goal will also improve the HTML5 export itself (given that the editor is made like a Godot game).
It will allow to use Godot in a reasonable way in environments where installing/downloading applications is not an option (e.g. schools’ computers and tablets), fostering the usage of the engine for educational purposes (which is something we, as an open source community, deeply believe in).
This DOES NOT mean that Godot will move completely to the Web, nor that the Web browsers version will be the recommended way for professional development, but it will be an additional option for cases where it might be useful (again, pick the education sector as an example).
To stress this out again: The good-old native editor will always be our main focus.
After this necessary preface, let’s get to the news: a Godot Editor prototype running in browsers is being presented at this address this address https://godotengine.org/online/godot.tools.html (Edit: As of December 2022, the editor can be found on https://editor.godotengine.org/releases/latest/)
Note: As of this writing, this prototype requires a recent Chromium-based browser or Firefox Nightly.
This is a very early stage version, but it allows to run the editor (including the project manager), and make simple projects, while storing the files in either your browser local storage, or an external cloud service (Dropbox is currently supported, but not recommended due to speed limitations. In the future, standard WebDAV support will allow for more providers and better speeds.) See the *“Known limitations”z section below.
Usage
When opening the URL you will be asked how to load the engine, specifically, selecting the persistence support. There are 4 options available:
None – no persistence will be used, you will lose everything when you close the browser or refresh the page.
IndexedDB – will use the IndexedDB API to store your files. This is usually limited to 50 megabytes on desktop, and 5 megabytes on mobile (this is the RECOMMENDED storage type for now).
Dropbox – will store your files in a Dropbox folder, created specifically for the test application. You will also be able to upload files directly to Dropbox and they will be available in the engine (after refreshing the page!). This is a very powerful tool, but is currently quite slow, both when loading and saving (it will need to download the whole folder on startup, and changes will be stored asynchronously). Improvements in this area are much needed, and Dropbox support is provided as a proof-of-concept for now and in no way recommended. Cloud support (via standard WebDAV) will in time become the preferred way to use the web editor. Note: At the time of your reading, Dropbox support might not work due to limits in terms of maximum number of users.
FileSystem API – will use the new Web FileSystem API, which could potentially expose native file system support in the future, if browser vendors agree on a safe way to do that. This is, again, provided as a proof-of-concept and browser support is very limited for now.
You can also opt to preload a zip file to the chosen virtual file system, allowing you to quickly test demo projects and load your offline projects inside the editor browser. Once the project manager starts, you will need to scan the virtual file system for new projects via the “Scan” option when preloading a zipped project. The editor config with the available projects list and other options will be stored according to your persistence method.
Editing & running the project
Once you have imported a project, or after creating a new one, you will be able to edit it, create new scenes, create new scripts, and upload assets via drag and drop. You will also be able to run your editor project inside the editor via the play button. Extra HTML UI allows you to close the game and the editor, and switch between them.
Known limitations
As stated above, this is a very early stage prototype, and there are some known limitations:
SharedArrayBuffer support is still limited among browsers. Recent versions of Chrome will work, as well as Mozilla Firefox Nightly builds (the beta and stable versions don’t have SharedArrayBuffer enabled yet). Other browsers are untested.
Importing and using audio assets is still not well supported (and may cause a deadlock prompting the browser to ask the user to stop the script).
Closing the project manager and game the via the HTML UI works, but closing the editor might deadlock and will always cause a memory leak.
Sometimes refreshing the page when an error occurs is not enough, this is mostly due to browsers not clearing WebAssembly memory correctly. You might find yourself in a situation (after many realoads usually) where you have to open a new browser window/tab and visit the URL again for the editor to be able to run.
The debugger connection between the editor instance and the running game does not work currently, so print() output or errors will not be raised in the editor. They are however accessible from the browser console.
Work done so far
Getting this far required quite a bit of time (I’ve been working on it since February), but a lot of this work will greatly improve the HTML5 export too. Here are a few nice things that you will see in Godot 4.0:
The exported game can now exit properly, calling get_tree().quit() will work as expected in HTML5 exports, freeing up the memory in the user machine (this could for example be useful if you present more games in the same page, and allow the user to switch among them, so you don’t have to reload the page to free up memory).
Files drop support. The user will be able to drop files in the game window, and you will get them available in the game via the files_dropped signal
Thread support! The HTML5 plaform will finally support the Thread class.
Rudimental OS.execute support has been added to the HTML5 export, allowing you to “catch” those call via JavaScript code. (This is used in the prototype to switch between project manager/project editor, and to run the game.)
Simpler JS Engine code that gives you more control over the game lifecycle.
Safer and smaller JS code, via Closure Compiler to better minify the required JS support code.
More to come
There are still quite a few improvements that I will work on in the HTML5 platform, some of which will also benefit other platforms. Here is a sneak peak:
Virtual keyboard in the HTML5 plaform, for working text input in mobile devices.
Persistence support, WebDAV integration.
Gestures for the editor, allowing using the editor from touch devices (this will also be beneficial to make native Android or iOS versions of the editor for example).
Better HTML5 Audio support, trying to offload audio processing (e.g. effects, mixing) into a separate thread.
GDNative support in the HTML5 platform.
Easier interface to external JS libraries (expecially asynchronous ones), so you don’t have to rely on complex JavaScript.eval.
-
+
\ No newline at end of file
diff --git a/article/godot-engine-awarded-50000-mozilla-open-source-support-program/index.html b/article/godot-engine-awarded-50000-mozilla-open-source-support-program/index.html
index 9d05421aba..99aab5d3a0 100644
--- a/article/godot-engine-awarded-50000-mozilla-open-source-support-program/index.html
+++ b/article/godot-engine-awarded-50000-mozilla-open-source-support-program/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde11 April 2019
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.
We are delighted to announce that Godot Engine has been awarded USD 50,000 by Mozilla as part of the Mozilla Open Source Support (MOSS) Mission Partners program. This is the second time that Godot receives a MOSS award, after a first award of USD 20,000 in 2016.
This award will be used to fund the work of some of our core contributors on three different work packages, all linked with Mozilla’s mission of furthering an open and accessible Web. For Godot, this means making sure that everyone can build and play networked and browser-based games with open source technology.
The work packages (WP) that we defined together with Mozilla are described hereafter. All the contributors working on those work packages are hired as contractors by our fiscal sponsor Software Freedom Conservancy, part-time and for a duration of 9 months. They will post progress reports on this blog.
WP1: Godot Engine’s editor on the Web
Godot’s editor is built with Godot itself, using the same runtime and UI toolkit as games developed with Godot. This means that it can run on any platform where Godot can run, including browsers via WebAssembly. While it’s relatively easy to make the editor build and run for browsers, many of its features can’t work out of the box and need specific development for HTML5, such as handling multi-threading or the lack thereof, running/debugging edited projects, filesystem management, cloud storage, etc.
Our contributor Leon Krause (eska), who is the maintainer of our HTML5/WebAssembly platform port, will work on providing a first-class integration of the Godot editor in browsers.
This might open many possibilities in the future such as sharing direct links to projects/scenes in bug reports of the Godot Q&A, being able to run and edit demo projects directly from the browser, collaborative edition features… Notably, this could also be an advantage for Godot’s adoption in teaching environments, where getting software installed and configured on all computers of an institution can be a hassle (even for an engine with such a small footprint like Godot).
The WP also includes work to make the editor work on mobile browsers, such as touch screen gestures, responsive UI, etc. This should also make it possible for us to port the editor to Android and iOS natively to tweak your projects on the go.
Additionally, while working to make the editor run smoothly on all major browsers, Leon will have to fix issues which are also relevant for exported games, so all users of the HTML5 port should benefit from this work.
Leon will start the work on WP1 in coming days.
Update: Due to unforeseen circumstances, Leon was not able to working on this work package. Instead, it’s also Fabio (from WP2) who will work on the HTML5 improvements in 2020, once his networking work package is completed.
WP2: WebRTC and networking improvements
Fabio Alessandrelli (Fales) is the maintainer of both low-level and high-level networking APIs in Godot. In 2018, he mentored the student Brandon Makin as part of the Google Summer of Code, who did initial work on integrating the WebRTC technology in Godot. The project faced various hurdles with the WebRTC library and could not be completed during GSoC, so Fabio will complete this work. He will also write documentation and create demos and plugins showcasing the use of WebRTC and WebSocket.
WP2 will also cover better tools and debugging features for networked projects, including some changes which will be relevant for Leon’s work in WP1, such as implementing an HTTPServer to serve HTML5 exported files, and use WebSocket instead of TCP to communicate between the editor and debugger in HTML5 exports.
Finally, Fabio will work on further networking improvements, including a refactor of the low level TCP/UDP abstractions, implementing DTLS over UDP using mbedTLS, and improving the error handling in the Multiplayer API.
Fabio already started working on WP2 in March, and will soon post his first progress report.
WP3: Artwork commission for high quality demos
Fernando Calabró, the artist who worked on the TPS demo, is going to make professional 3D assets for two more demos. These demos will be used to showcase and benchmark various features of the engine. Particular attention will be given to optimize them for Godot’s HTML5 platform (in part thanks to work done in WP1). This will enable them to be used as benchmarking material for upstream WebAssembly developers, thus contributing back to improving this stack.
Fernando started working on WP3 in March, and will soon share his current progress and more details about the planned demos.
A big thank you to Mozilla for supporting our project again with such a substantial award!
As a non-profit entity, we rely on the generosity of the many users who support us on Patreon, as well as companies who sponsor us or grant us funding for specific work packages. Being able to add two part-time developers and one artist on the project’s “payroll” will be a huge boost in productivity and development for the engine, and should greatly benefit the community as a whole.
-
+
\ No newline at end of file
diff --git a/article/godot-engine-donation-opgames/index.html b/article/godot-engine-donation-opgames/index.html
index b0a3a6c5e0..292985dc5b 100644
--- a/article/godot-engine-donation-opgames/index.html
+++ b/article/godot-engine-donation-opgames/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde11 November 2021
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.
We are happy to announce that the gaming platform OP Games is donating USD 100,000 to the Godot project. These funds will be used to further the general development of the engine.
As mentioned in their announcement, OP Games is also similarly supporting the open source game development tools Blender and Phaser, and the source available Defold engine. OP Games is also actively looking for game developers interested in their platform, see this contact form for details.
Thank you OP Games for your support of Godot and other open source game development tools!
Like all grants, sponsoring and donations given to the not-for-profit Godot project, these funds are managed by our legal and fiscal sponsor Software Freedom Conservancy, and will be used to accelerate development of our free and open source game engine.
Such funding enables us to hire more contributors to work on the areas which need it most, as well as renew contracts for the currently hired contractors – always with the guarantee that all the work done by contractors is under Godot’s MIT license and beneficial to the community as a whole.
We’re thankful to all users and companies in the Godot community who take part in making this open source game engine, be it with code, documentation, user support, bug reports, or funding.
-
+
\ No newline at end of file
diff --git a/article/godot-engine-go-public-2019/index.html b/article/godot-engine-go-public-2019/index.html
index 414c4ee832..a9a5162f80 100644
--- a/article/godot-engine-go-public-2019/index.html
+++ b/article/godot-engine-go-public-2019/index.html
@@ -5,7 +5,7 @@
Juan Linietsky1 April 2019
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.
Edit: This was of course a joke for April Fools’ Day 2019. Godot is not going public (and cannot, as it’s not owned by a company). There is truth behind the “Initial Pullrequest Offering” system outlined below though :)
We hear you and we understand your concerns. You feel like Godot, in the end, is not “public” enough. Even though there are over 800 contributors pushing code (surpassing any other engine, open or closed, on GitHub), Godot still doesn’t feel corporate enough. You miss the excitement of trading company shares, that can only happen when a company goes public.
Worry no longer! Today we announce that Godot will go public this year. Starting today, we are launching an IPO!
IPO
We will be launching our IPO (Initial Pullrequest Offering). This will allow you to own a piece of Godot.
I’m sure that you are confused at this point, but there is nothing strange about this, you actually can own it!
Ownership
Godot is licensed under the MIT license and, like in any open source project, any contribution that is merged (via pull-request) is owned by its author under the same license. This way, the more you contribute, the more you actually own it. Still, the license ensures that your work will be shared, so your contributions are actual shares.
So, what benefits are there in owning a piece of Godot?
Shareholder meetings
Sharing a piece of Godot allows you to prove yourself as a capable contributor, and this makes it possible for you to be better prepared to discuss the direction of the project when me meet online (or IRL at GodotCons!). The more you share, the more you will help shape the future of Godot!
High frequency sharing
The more exciting part of trading for shares is the speculation part. Love watching at graphs every day? GitHub insights are the right tool for you!
Want to be part of this? Do your Initial Pullrequest Offering today and start contributing! You can start by checking out the engine development documentation and also taking a look to our junior job issues.
Investing
Oh, but we understand, and realize that many reading this were thinking of investing real money in Godot (who wouldn’t?). Well don’t worry, as there is still a way to do it! If you are not yet, please consider becoming our patron and help shape the future of the project!
-
+
\ No newline at end of file
diff --git a/article/godot-engine-reaches-1-0/index.html b/article/godot-engine-reaches-1-0/index.html
index c1b8728a8b..5d4e21d8e3 100644
--- a/article/godot-engine-reaches-1-0/index.html
+++ b/article/godot-engine-reaches-1-0/index.html
@@ -5,7 +5,7 @@
Juan Linietsky15 December 2014
After 10 months of hard work following the open sourcing of Godot, we are proud to release our first stable version, Godot 1.0!
Several hundred issues were fixed, and dozens of contributions from the community were merged. In the meanwhile and in the absence of any publicity or mention in the developer press, the user community has silently grown a few orders of magnitude, via just word of mouth. The forum (edit: now replaced by the Q&A), IRC and Facebook are now full of life!
Likewise, documentation and demos have improved enormously, and there are several video tutorials created by the community available on YouTube. Soon, we will be opening the public wiki for users to contribute documentation.
The 1.0 release is a good time to consider Godot as a serious production tool.
Website issues
As probably noticed, the website was down for most of the year due to hacking. It seems to be in good shape and properly secured now (hopefully), so news will be posted more often. A monthly roundup of development is planned after this release.
We still could not find the problem going on with the forum, where sometimes it simply does not send verification e-mails. If you have experience with PHPBB, please let us know.
Future
This release does not mean that Godot is as stable as it can be, but ensures that bugs are rare enough to find and, and with easy workarounds that do not affect the workflow. As Godot matures, stability and workflow will keep improving.
The plan for 1.1 is to focus on improving the 2D engine with all the feedback that we have gathered during the past months, improving shader support for 2D, visual shader editing (for 2D and 3D), and more draw options such as per-node z-priority. Version 1.1 will also see a much improved interface, with movable docks, improved code editing features, initial drag & drop support, live editing and better platform support, such as WindowsRT, Chrome PNACL and improved HTML5 export.
One of the areas where Godot is still weak is the 3D renderer, which while it is still relatively powerful, it is designed for compatibility and optimized for mobile and low end-PCs. Eventually, the plan is to create a new next-gen renderer, with support for PBM and real-time global illumination. As this method of rendering is too new, it will be analyzed and evaluated for some months, with a potential implementation by half 2015.
Get involved!
Godot development is sponsored by Okam, so donations are not currently needed. Code contributions are always very appreciated, and we are always looking to expand the developer community. However the best way you can help is spreading the word. The biggest problem Godot has is that most potential users and contributors (and most of the world) do not even know Godot exists. We do not have the press budget of commercial engines, so spreading the word is very difficult for us.
So, in order to help the engine and the community grow, please mention Godot to your peers and in the communities you usually take part of. Help us let the world know this little game engine exists!
-
+
\ No newline at end of file
diff --git a/article/godot-engine-reaches-2-0-stable/index.html b/article/godot-engine-reaches-2-0-stable/index.html
index a84ff9ca85..0e4aa3a3f0 100644
--- a/article/godot-engine-reaches-2-0-stable/index.html
+++ b/article/godot-engine-reaches-2-0-stable/index.html
@@ -8,7 +8,7 @@
Godot uses IPC to synchronize the editor state with the running game. This means that any change made to the scene being edited is reflected automatically on the running game.
While this approach to live editing does not allow easy inspecting into the game from different editor cameras (something it might be implemented eventually anyway), it has the huge advantage of allowing the possibility of editing a level while it’s being played (and avoid the edited state from being lost when the game stops). Just add enemies, move them around, change their properties, add colliders, platforms, tiles, etc. and everything is reflected instantly on the running game.
To enable live editing, just toggle it at any time from the remote options menu.
Video of live editing in action:
It is also possible to do live editing on an actual device! Just select “Deploy Remote Debug” together with “Live Editing” in the remote options menu:
New color picker
There is a new color picker courtesy of Mariano Suligoy, supporting visual HSV, raw mode, screen picking, favorite colors, and more!
Smaller new additions
Godot 2.0 brings several smaller new additions to aid in usability:
Visible history for property editor
Selection for overlapping objects in 2D and 3D
Categorized project and editor settings
Inline documentation as property tooltips
Array / Dictionary property editing
Multiple node editing
New Animation Editor Layout
Improved anchoring tool
SpinBoxes (both controls and in property list) can be dragged to change value.
Many more small additions.
Future
We know the weakest part of Godot is still the 3D engine and we plan to fully work on modernizing it. However, we feel there are several more urgent issues that need to be improved usability wise. Godot 2.1 will continue in the same vein as 2.0 and keep adding usability improvements. (Feel free to check the Roadmap).
Asset sharing
Godot community keeps growing and users keep producing more assets, scripts, modules, etc. we are in need of an unified platform for sharing them. As such, we will be working towards having an asset sharing platform (website + REST API + Godot integration) for 2.1. The built-in platform will be free (it will be integrated with GitHub), but we will make sure that the REST API is well defined so anyone can make a commercial asset sharing platform and integrate it with Godot.
Spread the love!
If you like Godot, let everyone know about it. The more users the better Godot will become. Share this news!
Please donate!
You don’t have to be an experienced C++ developer to help with Godot development! Your donations help us dedicate more man hours to the project and make it progress faster! Donate
-
+
\ No newline at end of file
diff --git a/article/godot-engine-receives-120000-grant-from-kefir/index.html b/article/godot-engine-receives-120000-grant-from-kefir/index.html
index 0cc3ff8280..76926c56f1 100644
--- a/article/godot-engine-receives-120000-grant-from-kefir/index.html
+++ b/article/godot-engine-receives-120000-grant-from-kefir/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde10 February 2021
This article is from February 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.
We are delighted to announce that the game development studio Kefir is giving the Godot Engine project a USD 120,000 grant to fund further development of the engine. Thank you Kefir for supporting our free and open source game engine!
Kefir is known for hit survival games such as Last Day on Earth, Grim Soul and Frostborn (not made with Godot). They’re currently using Godot for internal prototypes and are considering using it more in the future.
Many thanks to the Godot team for their incredible contribution to game development. It’s a great honor for us to provide a little help in this grand endeavor. And we are always ready to support powerful, cool, and unusual games and teams, regardless of their platform, tools, and stage of development.
– Alyosha Stalin, Chief Business Development Officer, Kefir
Like all grants, sponsoring and donations given to the not-for-profit Godot project, these funds are managed by our legal and fiscal sponsor Software Freedom Conservancy, and will be used to accelerate development of our free and open source game engine.
Such funding enables us to hire more contributors to work on the areas which need it most, as well as renew contracts for the currently hired contractors – always with the guarantee that all the work done by contractors is under Godot’s MIT license and beneficial to the community as a whole.
We’re thankful to all users and companies in the Godot community who take part in making this open source game engine, be it with code, documentation, user support, bug reports, or funding.
-
+
\ No newline at end of file
diff --git a/article/godot-engine-receiving-new-grant-meta-reality-labs/index.html b/article/godot-engine-receiving-new-grant-meta-reality-labs/index.html
index 1c3008d951..73c13d0d31 100644
--- a/article/godot-engine-receiving-new-grant-meta-reality-labs/index.html
+++ b/article/godot-engine-receiving-new-grant-meta-reality-labs/index.html
@@ -10,7 +10,7 @@
We’re thankful to all users and companies in the Godot community who take part in making this game engine, be it with code, documentation, user support, bug reports, or funding.
-
+
\ No newline at end of file
diff --git a/article/godot-engine-receiving-support-funded-facebook-reality-labs/index.html b/article/godot-engine-receiving-support-funded-facebook-reality-labs/index.html
index e84ba65aeb..9d7bf91736 100644
--- a/article/godot-engine-receiving-support-funded-facebook-reality-labs/index.html
+++ b/article/godot-engine-receiving-support-funded-facebook-reality-labs/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde11 December 2020
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.
It is with great excitement that we announce that the Godot Engine project is receiving support funded by a grant from Facebook Reality Labs to further the development of Virtual Reality (VR) features within Godot.
Godot is a not-for-profit free and open source game engine which aims at empowering all users in their 2D and 3D game development projects. This grant will enable us to accelerate our efforts in providing first-class support for VR technologies. This includes cross-platform OpenXR support, an extended input action system for VR, Vulkan rendering and optimizations on mobile, and more!
We designed a work package for VR and mobile rendering which we are now able to fund thanks to this generous grant. Like all Godot donations and corporate sponsoring, this grant is administered by our legal and fiscal sponsor Software Freedom Conservancy, a not-for-profit charity that promotes software freedom.
VR support in Godot
Godot has had initial VR support since version 3.0 in 2018, thanks to the dedication of our contributor Bastiaan Olij who implemented all AR and VR features in the engine. As of Godot 3.2, many VR devices are supported through the official OpenVR, Oculus VR and Oculus Mobile VR implementations. A vibrant community of VR developers is now actively working with Godot on VR titles for most platforms.
VR work package for 2021
Bastiaan and the growing Godot VR community have created a great ecosystem, and this grant will enable us to go further and faster. We will now be able to hire Bastiaan Olij full-time starting in February 2021!
Bastiaan is a senior generalist developer who has been one of our top contributors since 2016, working primarily on AR and VR support, but also on GDNative, mobile platform ports (Android and iOS) as well as rendering features. Having him available full-time for Godot work will be greatly beneficial to the project and to the contributors he will be able to help on the way.
Bastiaan’s main tasks in 2021 will be related to VR and rendering:
OpenXR implementation for desktop and mobile. OpenXR is the new open standard for XR (Extended Reality, encompasses Augmented Reality (AR) and Virtual Reality (VR)). The OpenXR specification reached version 1.0 in 2019, and now has multiple conformant implementations by major XR players (Oculus, Microsoft, Valve, and more!). As an open source, cross-platform and vendor neutral game engine, we’re thrilled by the support that IHVs are giving to OpenXR and want to rely on it as our main interface.
Extending Godot’s input action system to support VR specific actions across all devices based on their respective capabilities (hand tracking, controller sensors, buttons).
Adapt the XR plugin system to the new Vulkan renderer design. While Godot 3.2’s XR support is functional, the upcoming Godot 4.0 release changes all the rendering backend and needs work to make XR functional again.
Implement Vulkan rendering on Android. This is necessary for mobile VR devices such as Oculus Quest 2, and will benefit all Godot users who want to make Android games.
Various rendering optimizations:
Stereoscopic rendering enhancements, providing details about the eye for which an image is rendered.
Support for compositor layers, which make it possible to render e.g. UI as an overlay without going through the eye buffer with lens distortion, allowing for sharper and more stable UI.
Support for variable rate shading in Vulkan, providing performance gains with techniques such as foveated rendering.
Rendering optimizations for mobile, implementing alternative techniques to the ones suitable on desktop platforms for better mobile performance.
As you can see, there’s a lot of work ahead for Bastiaan, and it will benefit both XR and traditional Godot games.
All this work will of course be fully free and open source like the rest of Godot Engine, and will be made available in Godot 4.0, either built-in or as first-party plugins.
Supporting Godot development
Godot is a fully not-for-profit open source game engine, and all development happens thanks to the dedication of hundreds of contributors, including a handful of paid developers.
These paid developers could be hired thanks to user donations (Patreon) and corporate sponsoring, as well as grants such as the one given by Facebook Reality Labs.
We’re thankful to all users and companies in the Godot community who take part in making this game engine, be it with code, documentation, user support, bug reports, or funding.
-
+
\ No newline at end of file
diff --git a/article/godot-engine-was-awarded-epic-megagrant/index.html b/article/godot-engine-was-awarded-epic-megagrant/index.html
index 52361494ee..4640eb0f2f 100644
--- a/article/godot-engine-was-awarded-epic-megagrant/index.html
+++ b/article/godot-engine-was-awarded-epic-megagrant/index.html
@@ -5,7 +5,7 @@
Juan Linietsky3 February 2020
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.
With great excitement, today we want to officially announce the great honor of having been awarded an Epic MegaGrant!
This is a huge honor for us and greatly helps to keep on improving Godot development at an even greater pace. We want to personally thank Tim Sweeney for the encouragement and support, and for sharing the belief that open source software makes the world a better place.
The grant
Godot applied for a $250k usd grant for the category of open source graphics software, (which does not have the necessary requirement to be related to Unreal Engine), and expressed the wish to use the grant to improve graphics rendering as well as our built-in- game development language, GDScript.
Both are areas where the Godot contributor community consistently innovates and we believe this effort, together with the very permissive license, can eventually be used to benefit the industry as a whole.
The grant was awarded at the beginning of this month and we are still discussing the next steps to follow.
Future
We are still discussing how the budget will be used and allocated so expect announcements (and many improved features) soon thanks to it.
-
+
\ No newline at end of file
diff --git a/article/godot-foundation-update-2023/index.html b/article/godot-foundation-update-2023/index.html
index 61d50c485b..b6b651bd8f 100644
--- a/article/godot-foundation-update-2023/index.html
+++ b/article/godot-foundation-update-2023/index.html
@@ -5,7 +5,7 @@
Godot Foundation5 December 2023
This has been a monumental year for the Godot Foundation. We announced the Foundation one year ago and have been busy since getting all the legalities in place and transferring over all our assets from the Software Freedom Conservancy.
On September 12, 2023 we officially introduced the Godot Development Fund which we had teased earlier in the year. At the time we had an informal goal of reaching €50,000 per month which would allow us to cover our current costs while opening up enough room to hire 1-2 more developers. We reached our goal much faster than expected, and we also received a sizable one-time donation of $100,000 from Re-Logic! We are incredibly grateful to all the individuals and companies who joined our fundraising effort to make Godot’s development sustainable.
When we launched the funding drive, our largest priorities were and continue to be (in no particular order):
More assistance with production tasks including PR review, release management, and team management
A dedicated C# maintainer
Asset import and asset workflow
Web infrastructure, website, asset store
Communications, community management, and event planning
We have already onboarded Winston Yallow (winston-yallow, a long time Godot user and contributor) to focus on web infrastructure. We are currently onboarding Adam Scott (adamscott) to focus on production tasks, and K. S. Ernest Lee (fire) to work on asset import and asset workflow. We have people in mind for some of the remaining roles and are currently busy exploring whether that will lead to new hires.
Of course, our current increase in funding is not enough to sustain all these extra roles. At the same time, thanks to the sizable one-time donations we received, we also have savings in the bank that we can use for project-based funding without putting ourselves into a permanent cash flow negative situation. Our idea is to start hiring for short and medium-term contracts in order to address high-priority areas quickly and continue to grow the team with any future increase in monthly donations.
This year has marked significant milestones for the Godot Foundation, and it’s all thanks to the incredible support from our community. To maintain this momentum and achieve more ambitious goals, we would like to invite you to contribute to the Godot Development Fund. Your donations will help us to sustain our current growth and enable us to hire more talented individuals, to make the Godot Engine and community the best it can be.
If you represent a company interested in joining the Godot Development Fund as a corporate sponsor, please get in touch.
-
+
\ No newline at end of file
diff --git a/article/godot-foundation-update-dec-2024/index.html b/article/godot-foundation-update-dec-2024/index.html
index cabfa88f86..808bd5e82f 100644
--- a/article/godot-foundation-update-dec-2024/index.html
+++ b/article/godot-foundation-update-dec-2024/index.html
@@ -35,7 +35,7 @@
however you are able!
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors in their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/godot-game-awards-stayathomedev/index.html b/article/godot-game-awards-stayathomedev/index.html
index f07bf196a7..f0a96fd47c 100644
--- a/article/godot-game-awards-stayathomedev/index.html
+++ b/article/godot-game-awards-stayathomedev/index.html
@@ -4,7 +4,7 @@
Emi9 December 2024
If you’ve watched Godot-related content on YouTube, StayAtHomeDev needs no introduction. He’s been sharing his passion for game development and the Godot Engine through his channel. As the creator of the popular “This Week in Godot” series, and the Godot Game Awards, he’s helped showcase the amazing work of the Godot community. We had the chance to talk with him about his journey, what inspired the awards, and his efforts to support the community.
What inspired you to create the Godot Game Awards, and how long has it been running?
I started the “This Week in Godot” series over two years ago on my channel. At first it started as a compilation of cool projects or games I found throughout each week. About 7-8 videos in, I thought it would be cool if people could vote for their favorite each week and the engagement exploded. People would comment every week and eventually I compiled every winner into a final vote for the “Best Godot Project of the Year” in 2023.
This year I wanted to expand that into multiple categories, highlighting certain achievements like art design and music, and give attention to other things like plugins, tutorials, even devlogs. From that came the Godot Game Awards, a compilation of the best Godot-based games, plugins, and projects as voted by viewers on my channel.
How can people get involved in this year’s edition?
People can get involved from now until December 15th by voting on the 20+ different categories with an official 2024 🗳️ Godot Game Awards Ballot.
The winners will be announced in a premiere video on December 28th at 2:00pm EST on my channel so that everyone can watch together and help support the great work by these developers.
Tell us about your YouTube channel—what kind of content do you focus on, and what motivated you to start creating videos?
I started StayAtHomeDev over two years ago to share my passion for creating through game development. At the time, I had a potential job offer to be the Web Coordinator for a professional football team in the US. But I had just been given a grant by Meta for some VR development work with their Oculus Quest 2 headset so I used that to launch the channel. It really was an exercise to create independent income so I could stay at home with my kids. That was a lifestyle choice I knew I wanted to make for them, so I took a shot at YouTube.
I’m very interested in sharing knowledge so the channel has had an element of teaching with tutorials or game development concept videos. With the “This Week in Godot” series, the channel started to steer more towards enriching the Godot community and showcasing what people were creating with the engine. Now, it’s a mix of tutorials, QAs about general game development topics, and the newest format, interviews. I am actually most excited about the interview videos because they really give a chance for viewers to peek into real game dev life with stories and advice from developers actively breaking through the industry or those who are already successful, and of course doing it with the Godot Engine.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?
If you look at the earliest videos on the channel, you’ll notice they were all focused on the Unreal Engine. I actually worked within Unreal first. Long ago…like long ago…I started making little games with an engine called 3D GameStudio.
When I started the channel, I knew of Godot (which I thought was called GoDot) but never tried it. After spending more time on YouTube and lurking around other game dev content, Godot kept popping up, so I took it for a test drive. I ended up making a video about it which went “viral” for a small channel while my first kid was being born. There was clearly a lot of interest in the engine so I kept playing around with it and fell in love. Not only with how streamlined it felt but also because it was open source and had such a strong sense of community and pride. I decided I wanted to help support that with the channel.
What advice would you give to someone starting out as a game developer or content creator in the Godot community?
I would say the WORST thing you can do is stop yourself before you even try. Game development and content creation are both difficult. They are also largely self-motivated so telling yourself you can’t do them means you likely won’t.
The BEST thing you can do is just try. If you are interested in making games, download the engine and try. You are going to hit walls and fail at a number of things but that’s part of the learning process. The information and tools are out there, you just need to start the climb.
In more applicable terms…start small, remake Pong or level 1 of Mario Bros. If something seems too difficult to understand, break it into smaller pieces. Don’t try to make an entire 2D platformer controller, make it move left and right first. And don’t think you’re going to sell your first game and make tons of money. You’ll put too much pressure on yourself and it won’t be fun anymore, you’ll get frustrated, and you’ll quit.
For content creation, it’s a marathon so the most important thing is don’t worry about the views. Make content that you want to make. If a video gets more views than normal, analyze why, and do it again with a small change. YouTube is sort of a constantly moving target and you won’t get a good idea of your style, your interest, or what people want to watch for a while. And even then, those things can always change. Consistency is the important variable…keep doing it and consistently try to get better. Better sound, better speaking, better editing, better pacing, better thumbnails, better topics, better storytelling. There is always something you can improve. If you create videos consistently and improve with every video, you’ll get to where you want to go and build a ton of new skills along the way.
Do you plan to continue organizing the Godot Game Awards in the future?
Absolutely! There have already been nearly 1000 ballots submitted, which is crazy to me. People comment how they enjoy finding new Godot projects every week with the weekly video series and tell me that they feel inspired to make something themselves. That is the best thing I could hope for, that people feel inspired to create. I’m also a music therapist so I have seen the effect creativity and expression can have on a person’s well-being. To me, games are an art form and within that lies the ability to create powerful feelings in other people through interactive play. If one person continues to be inspired by the games showcased in the awards, then I’ll keep making the videos.
-
+
\ No newline at end of file
diff --git a/article/godot-gamejam-dec-2016-jan-2017/index.html b/article/godot-gamejam-dec-2016-jan-2017/index.html
index 76b490af19..7a6e237bfb 100644
--- a/article/godot-gamejam-dec-2016-jan-2017/index.html
+++ b/article/godot-gamejam-dec-2016-jan-2017/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 December 2016
This article is from December 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 the success of our previous games jams in March 2016 and June 2016, and since the community seemed pretty motivated for a new one, we are organizing a new Godot Community Game Jam that will run from 16 December 2016 to 31 January 2017.
As the previous one, it is an informal jam with relatively loose rules, and not much to gain apart from international fame within the Godot community and more experience with using our great engine! This is why this jam will run for a month and a half, giving everyone plenty of time to experiment with the engine to create something new, beginners and experienced users alike.
Check the game jam’s page on itch.io: https://itch.io/jam/godotjam122016
Jam theme and rules
The jam will take place from Friday, December 16th 2016 to Tuesday, January 31st 2017, i.e. for one month and a half. It is hosted on itch.io.
The guys from the Discord channel took the initiative and gathered some theme proposals, which were then submitted to the vote of the community. The proposal that received the most votes is Two buttons, and it will therefore be the main theme of the jam. The other proposals were Demake, No-death, Rust / decay and Round-based - those are not part of the voting criteria, but you are free to take them as an additional source of inspiration for your games.
Contestants are free to interpret the theme as they want, but keep in mind that your interpretation should be understandable if you want voters to give you many points for it.
Contestants can partake alone or as a team. Reusing existing code and assets is allowed.
Open source and educational
We see this jam as an opportunity for each community member to share their knowledge with other users, which is why we ask that all games developed for this jam are published with their source code and assets under open source licenses, thus helping build quality examples for new Godot users.
Of course jam participants are free to continue their game after the jam as a proprietary project if they want - only the jam version should be open source for the whole community to learn from it.
The minimum requirement for a valid jam entry is thus to provide the full source code to play the game; you are of course welcome to also post exported binaries for players that might not be familiar with running Godot projects from source.
Have fun!
The main purpose of this jam is to have fun together as a community of Godot users. If you are beginning with Godot, don’t hesitate to ask any question on our various community channels; there are no silly questions, so go ahead!
If you are more experienced, why not take this opportunity to try to discover new features of Godot that you might not be using yet (e.g. shaders, particles)? You may also use the current development version of Godot 3.0 (no GLES 3 support yet in the master branch though) to do some alpha-testing while working on your jam game.
-
+
\ No newline at end of file
diff --git a/article/godot-gamejam-june-2016/index.html b/article/godot-gamejam-june-2016/index.html
index 5a2aabe517..5e41881f61 100644
--- a/article/godot-gamejam-june-2016/index.html
+++ b/article/godot-gamejam-june-2016/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde3 June 2016
This article is from June 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 the success of our previous game jam, which had been spontaneously organized by community members, we decided to start a new game jam for this month of June 2016.
As the previous one, it is an informal jam with relatively loose rules, and not much to gain apart from international fame within the Godot community and more experience with using our great engine! This is why this jam will run over three weeks, giving everyone plenty of time to expriment with the engine to create something new, beginners and experienced users alike.
Check the game jam’s page on itch.io: https://itch.io/jam/godotjam062016
Jam theme and rules
The jam will take place from Saturday, June 4th 0:00 UTC to Monday, June 27th 23:59 UTC, i.e. for a bit more than three weeks (and four week-ends). It is hosted on itch.io.
After an intense consultation with the community, we settled on Procedural as the jam’s main theme. Contestants are free to interpret it as they want, but keep in mind that your interpretation should be understandable if you want to get points for it.
We also propose an optional bonus theme, Only two colors, which can also be interpreted freely. You can decide to use this bonus theme together with the main theme if you want, but it is not mandatory. The contestants that use both themes will have a small bonus, but which shouldn’t create a strong disadvantage for contestants that did not use the optional theme.
Contestants can partake alone or as a team. Reusing existing code and assets is allowed.
Open source and educational
We see this jam as an opportunity for each community member to share their knowledge with other users, which is why we ask that all games developed for this jam are published with their source code and assets under open source licenses, thus helping build quality examples for new Godot users.
Of course jam participants are free to continue their game after the jam as a proprietary project if they want - only the jam version should be open source for the whole community to learn from it.
The minimum requirement for a valid jam entry is thus to provide the full source code to play the game; you are of course welcome to also post exported binaries for players that might not be familiar with running Godot projects from source.
Have fun!
The main purpose of this jam is to have fun together as a community of Godot users. If you are beginning with Godot, don’t hesitate to ask any question on our various community channels; there are no silly questions, so go ahead!
If you are more experienced, why not take this opportunity to try to discover new features of Godot that you might not be using yet (e.g. shaders, particles)? You may also use the current development version of Godot 2.1 to do some alpha-testing while working on your jam game.
-
+
\ No newline at end of file
diff --git a/article/godot-games-steam-next-fest-oct-2021/index.html b/article/godot-games-steam-next-fest-oct-2021/index.html
index 1c333e00ec..9894604188 100644
--- a/article/godot-games-steam-next-fest-oct-2021/index.html
+++ b/article/godot-games-steam-next-fest-oct-2021/index.html
@@ -8,7 +8,7 @@
‘s soundtrack seems pretty fitting anyway for this fast-paced “die and retry” runner with a beautiful art direction!
Birb Café by @birbgames has you, a birb, make coffee for furry and feathery customers (who would have guessed)! It’s a visual novel with branching paths and multiple endings. We don’t know yet if it features skating birbs, we’ll see!
Smelted Kin: Inhuman Impact by @MicrobatStudio is a 2D shooter in a sci-fi environment, which has you play both a human character and an armored vehicle.
It’s only in Chinese for now, but @Team9Games‘《文字遊戲》 is looking pretty sweet! If we understand correctly, its prequel is “Word Game: Episode 0”, which is one of the most popular Godot-made games on Steam (2500 reviews, 99% positive!).
Long Tail by Kamil Rams is Snake with a twist (a knot?) - adds in route planning based puzzle solving. It’s tagged as relaxing so after checking all these cool but content heavy demos, that might be a good one to chill.
@VoxStoryRPG by Current Year Gaming brings 3D digital content to tabletop roleplaying. The Game Master creates a 3D voxel world as support for the good old pen and paper roleplaying.
-
+
\ No newline at end of file
diff --git a/article/godot-gdc-2016-aftermath/index.html b/article/godot-gdc-2016-aftermath/index.html
index 1483f34d20..a30f8c5c6c 100644
--- a/article/godot-gdc-2016-aftermath/index.html
+++ b/article/godot-gdc-2016-aftermath/index.html
@@ -5,7 +5,7 @@
Juan Linietsky19 March 2016
This article is from March 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.
What is that?
GDC (or Game Developer’s Conference) is an event hosted every year in San Francisco at some point in March. The point of GDC is to reunite as much as possible of the video game develoment industry in a single week. The event is used for conferences (educational mostly), business, mixers, award ceremonies (IGF), technology showcases and partying hard with fellow developers.
It is without a doubt a fantastic time of the year if you are a video game developer and you can attend to it.
Godot at GDC
We took Godot to GDC with a number of goals, mainly to see the industry feedback to it (see how we can improve) and to find sponsoring for its development by the big companies.
We spent most of the week meeting with programmers, artists, designers, company representatives, etc. Went to parties, talks and more.
On the sponsoring side, we have many promising leads but it’s probably too early to write about it.
On the feedback side, what we found, however, was not what we were expecting. The sad truth is that, even after two years of being open source…
No one knows about Godot
It’s as simple as that. Developers and companies are enthusiastic and amazed when we show them Godot, the games that the community is making, the maturity of the engine, etc. Yet, they simply had no idea it existed and never heard about it.
This GDC, organizers estimated that the number of attendees was over 70.000. One could argue that most of the developers attending GDC are not video game technology enthusiasts so they don’t bother looking beyond what the companies ask them to learn (Unity likely). Our problem is not that users dislike Godot, but that developers do not bother to find out if there are alternatives to what they use.
Amazon, on the other hand, set up an enormous booth for Lumberyard (very fitting to its 40 GB install size :P) and you could see developers surprised there was a new engine around.
We need visibility
At this point, I think it’s becoming quite clear that Godot needs better visibility industry wide, so we should start thinking about ways to achieve that. Some things that come to mind are:
We should start contacting company CTOs or technical directors and offer them to do a private showcase of Godot.
We could actually try to crowdfund a booth at GDC, which would definitely give us visibility in the chunk of the industry that attends the event. A decent booth is quite expensive though (15-25k USD), but we might actually share it with other popular open source software that is used for games such as Blender or Krita.
It could be interesting to create sets of training materials, so other Godot users could use them to set up jams, workshops, etc. in their local regions too.
Any ideas are welcome, and this is an issue we’ll most definitely be going to be working on during the year.
-
+
\ No newline at end of file
diff --git a/article/godot-gets-2d-skeletal-deform/index.html b/article/godot-gets-2d-skeletal-deform/index.html
index 47c3a4d3a2..b9a93d64e5 100644
--- a/article/godot-gets-2d-skeletal-deform/index.html
+++ b/article/godot-gets-2d-skeletal-deform/index.html
@@ -11,7 +11,7 @@
-
+
\ No newline at end of file
diff --git a/article/godot-gets-brand-new-animation-editor-cinematic-support/index.html b/article/godot-gets-brand-new-animation-editor-cinematic-support/index.html
index b8f9277216..c215dddfe1 100644
--- a/article/godot-gets-brand-new-animation-editor-cinematic-support/index.html
+++ b/article/godot-gets-brand-new-animation-editor-cinematic-support/index.html
@@ -5,7 +5,7 @@
Juan Linietsky7 June 2018
This article is from June 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.
The existing animation system in Godot was already one of the most powerful of any game engine, but its age was starting to show (it was written 10 years ago and barely improved). The new one builds upon the strengths of the previous one but does massive improvements to features and usability.
A bit of history
Animation editing was one of the first distinctive Godot features. If you are familiar with Godot, you may already know that any property from any object can be animated or tweened. Changing sprite textures, colors, animation frames, calling functions, playing animations in other animation players, playing sounds, etc. All is done transparently by simply animating property states.
Although this approach works really well, it started showing its age as it was not improved very much in almost 8 years. The reason for this is that the code behind animation editing was too hard-coded in general, which made it difficult to add new features or improvements. In the image below, the animation editor can be shown as it was in 2010. Nothing much has changed since:
Rewriting from scratch
As it has been the trend the past months, with the rewrite of the 2D editor, inspector, etc., the time has come for a new animation editor to come forward. The new code is more modular, and allows extending track editing to show custom visualization. It also has a plethora of new features that will indeed be very useful.
With the new trend of cinematic tools and timelines coming recently to the big engines, this workflow (which was already possible) was cleaned up and made much easier and visual.
Following is the long list of changes and improvements included in the new animation editor!
New layout
First of all, there is a new layout (keep in mind the visuals are not final, and will be further refined by our UI styling contributors before 3.1).
The old layout wasted a lot of horizontal space in buttons that were seldom used. Buttons in large groups are, in general, not a very helpful usability convention so the whole layout was confusing. Some useful menus (such as add track) were hidden in the clutter, and the animation name had only a bit of space to show itself.
Some buttons were unnecesary, such as move up/down, which remained from the ages when Godot did not support drag and drop.
The new layout is much simpler and has moved most functions to menus. Only the really important buttons remain visible. The animation length and loop options are now together in the timeline, as well as the button to add tracks.
The step field was confusing, so it was renamed to a snap button. Snapping can now be toggled on or off.
New track workflow
Besides the usual workflow of inserting keys (and creating tracks) from the inspector, new tracks can be created directly from the Add Track menu. This not only provides an alternative workflow, but works much better for non-property tracks, such as Call tracks and the new Bezier, Audio and Animation tracks.
Keys can also be inserted at any position in the timeline by simply right-clicking over the track at a given position in time.
Adding a Call track and calling a function, as an example, is a lot more intuitive:
Just trust this new menu, as it will always lead you through the right dialogs to get your tracks set up in no time!
Key editing in inspector
The old layout had a small sub-window where key values as well as transition curves could be edited for each key. Most users did not even know this feature existed due to the huge amount of clutter.
In the new animation editor, just clicking a key will allow editing it in the inspector:
Key previews
Most types of keys can have their values previewed directly in the track, thanks to track editor plugins. Godot comes with a bunch of built-in ones for most key types.
As an example, editing animation frames is a lot more friendly now:
As well as many other key types, such as:
Boolean tracks
Color tracks (which show colors and transitions)
Call tracks (which show the function and arguments)
Stream playback (shows a stream preview)
Volume DB (shows a gradient with the volume)
Bezier Tracks
To be more in line with other software and thanks to the work done by Bojidar Marinov on set/get indexing for tweens, it is now possible to create Bezier tracks.
These are normal tracks and look like regular tracks that edit a single float component:
But with the push of a button, it is possible to edit the Bezier curves directly in the integrated bezier editor!
Related tracks in the same object will appear in the background for reference, and switching between them is easy with the menu on the left.
Animation and Audio tracks
Two new track types were added: Animation and Audio. Animation tracks need to point their path to an AnimationPlayer node (must be different from the current one). Audio tracks need to point to an AudioStreamPlayer node (can be AudioStreamPlayer, AudioStreamPlayer2D or AudioStreamPlayer3D).
Audio tracks work very similar to a DAW. Just draw audio resources into the animation track and it will play them back. Editing their start and end offset is allowed, to better adjust the sound to the rest of the animation.
This workflow is very smooth, and previews of the audio are rendered in a thread to not obstruct your work, just like in a real DAW!
For animations, just insert current animation keys in the same way as before, but now they will be previewed with full length on the timeline.
Added to that, the new tracks are designed to work better with seeking, so you can seek (via code or editing) to any point of the master animation, and both audio and sub-animations will start from the right offset:
To also help with this workflow, the currently pinned animation editor is displayed in the Scene Tree:
All this together makes Godot’s built-in animation support the most powerful tool for in-game cinematic creation and editing. This goes in-line with Godot’s philosophy of having a single, powerful and well designed tool instead of several ones duct taped, like in other engines.
Track grouping and filtering
This has been a long-standing request. It is now possible to see tracks grouped together by object. This makes complex animations with lots of tracks much less confusing.
It is also possible to filter tracks with the push of a button. When filtering is enabled, only tracks selected in the Scene Tree dock will appear editable.
Track copying and pasting
Another long standing request is the ability to copy and paste tracks between animations. this has been made much easier with the new copy/paste menu:
Capture Mode
The last significant feature introduced in the animation editor is capture mode for property tracks. When these tracks are set to capture, the current property value in the object is remembered. From there onward, it will blend with the first animation key found:
The main use of this feature is for animating UI components (as in, menus sliding in an out, buttons becoming bigger or smaller, etc.) without having to resort to tweens. Still, it can be used with anything else, so I’m sure that other creative uses will arise.
Future
Please test this code well (it’s now available on GitHub HEAD) so all the bugs can be ironed out before Godot 3.1 is out!
Some features were left out due to lack of time, but may be implemented later, such as a global track (for ease of selecting long list of keys). Others are still in the works (like proper auto-keying).
And again, please remember that Godot is made with love for everyone! If you haven’t yet, please consider donating and becoming our Patron!
-
+
\ No newline at end of file
diff --git a/article/godot-gets-csg-support/index.html b/article/godot-gets-csg-support/index.html
index 181d2a9f21..7a2232cb55 100644
--- a/article/godot-gets-csg-support/index.html
+++ b/article/godot-gets-csg-support/index.html
@@ -5,7 +5,7 @@
Juan Linietsky28 April 2018
This article is from April 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.
After years of discussion on how to implement CSG, Godot finally gets suport for it. This implementation is simple, but makes use of Godot’s advanced architecture to shine.
Wait, what is CSG?
CSG stands for “Construtive Solid Geometry”, and is a tool to combine basic (and not so basic) shapes to create more complex shapes. In the 3D modelling software, CSG is mostly known as “Boolean Operators”.
Why is CSG relevant?
The aim of CSG in Godot is for it to be used in level prototyping. This technique allows to create simple versions of most common shapes by combining primitives. Interior environments can be created by using inverted primitives instead.
CSG is a vital tool for level design (and level designers in companies) as it allows to test gameplay environments without modelling a single triangle. Unreal has always offered similar boolean CSG, while Unity has recently acquired ProBuilder (which is a different type of tool, but still aimed at prototyping level geometry).
For developers, creating 3D art is a time consuming process. For indies or small companies, it may even involve outsourcing to third party artists. With CSG, a game can be developed almost entirely without relying on 3D environment artists, only for that content to be filled in the end when gameplay is already working.
How does it work?
Godot provides a bunch of Primitive nodes:
Sphere
Box
Cylinder (can be used as Cone)
Torus (donut shape)
Polygon (can be drawn in 2D and then extruded)
Mesh (can use any custom geometry)
Each of these operates on the parent CSG node, in order. Supported operations are:
Union: Geometry of both primitives is merged, intersecting geometry is removed
Intersection: Only intersecting geometry remains, the rest is removed
Subtraction: The second shape is susbtracted from the first, leaving a dent with it’s shape.
Process order
Every CSG node will first process it’s children nodes (an their operation: union, intersection substraction), in tree order and apply them to itself one after the other.
There is a special CSGCombiner node that is pretty much an empty shape. It will only combine children nodes. It’s used for organization mostly.
Polygon and lofting
The CSGPolygon node is very convenient, a Polygon is drawn in 2D (in X,Y coordinates), and it can be extruded in the following ways:
Depth: Extruded back a given amount
Spin: Extruded while spinning aroud it’s origin.
Path: Extruded along a Path node. This operation is commonly called lofting.
Custom meshes
Any mesh can be used for CSG, this makes it easier to implement some types of custom shapes. Even multiple materials will be properly supported. There are some restrictions for geometry, though:
It must be closed
It must not self-intersect
Is must not contain internal faces
Every edge must connect to only two other faces
Make sure CSG geometry remains relatively simple, as complex meshes can take a while to process.
A note on performance
If adding objects together (such as table and room objects). It’s better if this is done as separate CSG trees. Forcing too many objects in a single tree will eventually start affecting performance. Only use binary operations where you actually need them.
Godot CSG Implementation
As many libraries seemed to exist for this, I decided to pick one and put it in Godot and implement it over a weekend. Of course, this unfortunately did not work well. A few things stopped me. Pretty much every library I found was:
Under GNU GPL or GPL, making it incompatible with Godot
Using really crappy algorithms such as voxel or BSP, making them inefficient.
Designed for 3D modelling or mathematics, so they used very tuned algorithms dealing with avoiding precision errors.
Nothing was really meant for games. This led me to write a custom one for Godot, with focus exclusively on performance.
The current implementation is really simple. It does brute force clipping of triangles without relying on vertex IDs, or isolating edges to detect interior faces. Instead the implementation in Godot does triangle-triangle raytracing to detect which halves ended up inside the intersection.
This is expensive per se, but it’s optimized by doing a pre-aabb intersection and balanced binary trees to minimize the amount of ray tests. As a result, the performance is really good.
As the implementation is pure brute force, some visual artifacts may rarely appear in some cases if you look well, but truth is that they don’t have any practical impact as CSG in Godot is mostly meant for level prototyping. In fact I’m sure for some types of game CSG could easily be usable in production.
Future
The main missing feature now is the ability to export the scene to a 3D modelling software (likely via GLTF2), so the process of replacing CSG art by final art can be done by a professional artist. This will be added soon.
Please test well! And remember that we make Godot with love for everyone. If you are not already, please consider becoming our patron, so we can continue doing this for you!
-
+
\ No newline at end of file
diff --git a/article/godot-gets-new-animation-tree-state-machine/index.html b/article/godot-gets-new-animation-tree-state-machine/index.html
index 5b12db912a..870df4ae09 100644
--- a/article/godot-gets-new-animation-tree-state-machine/index.html
+++ b/article/godot-gets-new-animation-tree-state-machine/index.html
@@ -6,7 +6,7 @@
have inputs and outputs and can be blended. This new implementation has a lot of visual feedback, though:
Animations show their progress with a proper bar, and active wires become blue.
It is also possible to use blend spaces, state machines and even other blend tree as sub-nodes. In the example below, two state machines are blended via a Blend2 node, with filters set. This way, a functionality similar to state machine layers (from other engines) can be achieved easily.
Blend Space 1D and 2D
With the help of karroffel, both 1D and 2D blend spaces are supported in Godot.
For the 2D version, an automatic triangulation option is set by default (which can be changed to manual if required). Other engines hide it by default, but we believe it should be better that users see how blending happens behind the scenes (As well as having the freedom to change it ):
State Machine
Finally, Godot introduces a state machine. This state machine is rather simple but very efficient, and relies on the concept of travel.
Conditions to change states are not supported, but can be easily scripted by adding scripted transitions (we’ll see in the future whether this is worth adding to the core or can remain an extension).
Custom Blend Nodes
You can add your own custom blending logic with the new Godot API, even writing your own state machine. The new API is very easy to extend and use:
Root Motion
It is also easy to set a track as root motion. If set as such, a transform with the motion for the frame can be obtained and used as well. A new node RootMotionView was added to aid in debugging root motion.
Compatibility
The old animation system (AnimationTreePlayer) has now been deprecated and will be removed in future versions. By the time, we will add a compatibility API so they get converted to the new system.
Future
This lays the foundation for a new animation system, which will hopefully keep being worked on and improved over time.
As always, everything is done for everyone with love, so again please consider becoming our patron!
-
+
\ No newline at end of file
diff --git a/article/godot-gets-new-filesystem-dock-3-1/index.html b/article/godot-gets-new-filesystem-dock-3-1/index.html
index 4cc0505dc9..8c0b214efa 100644
--- a/article/godot-gets-new-filesystem-dock-3-1/index.html
+++ b/article/godot-gets-new-filesystem-dock-3-1/index.html
@@ -8,7 +8,7 @@
A right-click menu, to handle files exactly as in the file list.
The “Mark as favorite” button has been moved to a menu entry, found when you right-click files or folders.
The “Find current scene in files” button has been moved to a menu entry, when right-clicking on a scene tab.
We hope you will enjoy this new FileSystem dock. We are waiting for your feedback!
Note: this new feature is outside the scope of the current feature freeze, since it has been on the roadmap and worked on since before the feature freeze took effect.
-
+
\ No newline at end of file
diff --git a/article/godot-gets-new-inspector/index.html b/article/godot-gets-new-inspector/index.html
index b5fc7035d6..d5d13d57a3 100644
--- a/article/godot-gets-new-inspector/index.html
+++ b/article/godot-gets-new-inspector/index.html
@@ -6,7 +6,7 @@
Multiple field editing for vector types
Properties of types such as Vector3, Vector3, Transform, etc. can now edited and visualized directly. Many fields are exposed as a single property.
Sub-Resource editing within the same inspector
One of the biggest usability hurdles in Godot was the fact that sub-resources would go to a separate inspector. In many types of nodes (Mesh, Particles, etc), editing sub-resources was truly a hassle.
This no longer applies to the new inspector. Sub-Resources wil open within the same list of edited properties:
It also makes animation easier, as any sub-resource property can be animated transparently.
Named layers
Besides the boxes, the list of layers now appears in a proper drop down, making it easier to select them by name:
Proper Array and Dictionary editing
With the old inspector, editing arrays and dictionaries was more or less a hack. A new proxy object was created that would edit it, which requiered going into a separate inspector. Undo and Redo also did not work well on it, given the hacky nature.
Currently, editing them is done properly and without even going to a sub-inspector. Here is an example of two arrays, of different types, being edited at the same time. Arrays can be collapsed to save vertical space.
Same goes for dictionaries, which can be visualized and edited within their parent objects:
Future
The new inspector will also result in many improvements on current features, such as animation editing, visual scripting, visual shader editing, etc. Many of those are being reworked for 3.1 and will see their usability and features improved.
Make sure to test well and report all the issues you can, so the new inspector is as stable as possible for the upcoming Godot 3.1.
As always, remember that Godot is done with love for everyone who enjoy making games. If you are not already, please consider becoming our patron.
-
+
\ No newline at end of file
diff --git a/article/godot-getting-more-languages/index.html b/article/godot-getting-more-languages/index.html
index 1812020214..27b6e0cd0e 100644
--- a/article/godot-getting-more-languages/index.html
+++ b/article/godot-getting-more-languages/index.html
@@ -5,7 +5,7 @@
Juan Linietsky10 August 2016
This article is from August 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.
Why more languages, isn’t GDScript enough?
There is a common misundertanding about us in the industry: Godot devs, always trying to reinvent the wheel because we like it. This could not be further away from the truth.
The reality is that we are extremely demanding with our requirements from third party solutions and it just happens that very often, even if a library, language, etc. is very popular, it does not satisfy our needs. This was the case of third party scripting languages such as Lua, Python, Squirrel, etc.
When we originally made Godot, we were completely certain that we wanted our main scripting language to be dynamically typed due to the high accessibility this provides. We understood that most of the code written for a game is not performance critical, and that the C++ part of the engine already covers most of the critical parts, so we originally went for Lua, and then for Squirrel (while trying Python in the process).
Unfortunately, we had many problems with those languages. Binding code was always large, complex and prone to bugs. True multi-threading (with a stack per thread, but sharing memory) was not supported, and vector types had to be created with custom userpointers, which provided much slower performance than built-in types. Added to that, we could never completely eliminate the stalls related to the garbage collector.
GDScript was born as a way to make all these problems go away. When users write code in GDScript within the IDE, everything simply “just works” and you have the added value of live code completion. None of this could have been made with a third party language. We tried, we became experts at it, but it just didn’t work out.
Because of this, GDScript will always be the main supported language, and our recommended choice for all Godot users.
Why other languages, then?
Even though we will always recommend new users to go the GDScript route, because we know it’s the least hassle option, we understand that developers have different needs and experiences, and that believing in “one size fits all” is a mistake. That’s why we are working on the support of C# and visual scripting for the upcoming Godot 2.2.
Why C#?
In the case of C#, there is a huge amount of love towards this programming language, which is expected due to the main designer being the same guy who created Object Pascal (which was very popular in the 90s with Borland Pascal and later through Delphi).
Truth is that Mono is very well made, has excellent, modern binding extensions (the complete opposite to Java/JNI) and supports multi-threading just fine. As a result, it should integrate smoothly into Godot. The only reason we did not want to go this route in the past was due to license restrictions, but this ceased to be a problem a few months ago when Microsoft acquired Xamarin and relicensed Mono under the MIT license.
The main benefit of supporting C# is that, all of a sudden, Godot will become a more-than-tempting option to the indie and corporate cultures who are used to products supporting this language. This should greatly help us reach potential users who might have been initially puzzled by having to learn GDScript (though we still guarantee that any programmer can pick up GDScript in less than an hour).
This is, however, not the main reason behind our intention to support this language. As always, we want to implement the features that our community wants the most, and C# support is definitely one of the most recurrent topics. We also believe that it will provide a high performance alternative to GDScript without having to compile Godot manually for C++, and a statically typed language for the developers allergic to duck typing.
To clarify things: since the Mono runtime is relatively heavy, and many Godot users will prefer to stick to GDScript, we intend to provide the Mono-enabled version of Godot as a separate download. This means that users will have the choice to use Godot with GDScript only, or GDScript and Mono.
Why Visual Scripting?
Another language currently being added to Godot is VisualScript, our take on visual programming. We are using an approach similar on the surface to Unreal’s Blueprint, but pretty different under the hood.
As we have seen so far many Godot users and other developers puzzled about Godot adding this functionality, we want to make very clear that it is not our intention to replace GDScript or traditional programming for a visual approach.
To make it clearer, it is not our belief that forcing programmers to write code with visual blocks will result in a more efficient workflow. We know other game engines and solutions try to sell you this point of view, but rest assured that this is not our view or intention. We stand by programming and still believe it’s the best.
So then, again, why visual scripting? Our goals with it are the following:
Provide a way for non-programmers to experience what developing in Godot feels like, by ensuring they have a way to manipulate their game’s logic.
Allow programmers to set up their scenes, AI, etc. in a way they can expose the coarse parameters and logic to level designers or game designers. This way, they can do tweaks without bothering programmers.
Allow programmers to expose how data is organized in a visual way. Godot’s VisualScript has so much flexibility in how the graph flows that it allows creating dialogue trees, coarse game flow, event handling, etc. with small effort.
Please understand it as just an extra tool, not as a replacement to programming. It will be possible to use both GDScript and VisualScript as complementary tool in a same project.
Binding new languages
There currently is a lot of demand for additional languages, such as Java, Haxe, Swift, Object Pascal, etc. As Godot 2.2 will focus on new languages, this a great time to help us develop and improve the binding API. Of course it may seem like a challenging effort.
Officially, our supported languages for now will be GDScript, Mono, VisualScript and C++. If you want to help integrate another language, you should first of all contact us (see contact info at the bottom of the site or use IRC: #godotengine-devel on Freenode). The process to add new languages is more or less the following:
Re-create Godot’s basic types in your new language: These are types such as Vector3, int, float, String, etc. Many of these are usually provided already.
Create a module: A C++ module that creates binding code needs to be done (creating modules in C++ is well documented). The entire exposed Godot API can be accessed via the static functions in ObjectTypeDB.
Generate binding code in your new language that accesses the exposed functions in the MethodBind class (there is one for each exposed method).
Create a ScriptLanguage class and supply the neccesary methods exposed for debugging, profiling, etc. You can supply symbols, code completion helpers, etc. if this language is meant to be edited inside Godot.
Again, as this process is not fully streamlined yet, we encourage you to get in touch with us if you want to do this effort.
-
+
\ No newline at end of file
diff --git a/article/godot-google-summer-code-2018/index.html b/article/godot-google-summer-code-2018/index.html
index ab85911d10..2b157ce4c5 100644
--- a/article/godot-google-summer-code-2018/index.html
+++ b/article/godot-google-summer-code-2018/index.html
@@ -5,7 +5,7 @@
George Marques24 April 2018
This article is from April 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.
For those who might not be aware, the Google Summer of Code is a yearly program that brings students from all over the world into open source projects. The students have the opportunity to get involved into a real software development process, while the organizations can welcome a new contributor working on a valuable feature, potentially becoming a regular after the summer is over.
We developed a list of ideas to apply to the program (though students are free to come with their own proposals). Everything was made in a bit of a rush and without many announcements since we were quite busy with Godot 3.0 release and a few big events in the schedule. In February 12 we got the good news that Godot was accepted as participant organization.
This is the first year Godot is participating in the program and we got the chance to accept five student projects that will be developed from May to August. The projects were just announced publicly and we are looking forward to see the development of the features.
We hope that the Godot community will give a warm welcome for these new contributors that will be working with us during the summer. I’m sure that if the students feel the good vibes from the community they’ll hang around and keep contributing to our engine.
Without further ado, let’s go through the list of accepted proposals:
Support for video decoder modules with GDNative
This project will be about creating an interface into GDNative so custom video decoders can be added without the need of recompiling the engine. It’ll enable Godot to support several video formats that are hard to integrate because of patents or licenses, while also avoiding the bloat in the base engine for those who don’t need it.
The proposal by Brandon Michael Makin will add support for the WebRTC protocol into Godot’s high-level network layer. This will make possible to create multiplayer games in the HTML5 platform among other benefits. Max Hilbrunner (mhilbrunner) and Fabio Alessandrelli (faless) will help him in this endeavor.
GearVR and Daydream support
With the help of Bastiaan Olij (Mux213), who added the AR/VR system into Godot, Paritosh Sharma will extend the system to support two mobile VR platforms: Samsung’s GearVR and Google’s Daydream.
Support for MIDI playback
Daniel Matarov proposal’s include the development of a MIDI bus, similar to Godot’s audio buses, along with a sampler to allow the playback of MIDI songs. He’ll be mentored by Gilles Roudiere (Groud), Marcelo Fernandez (marcelofg55), and myself.
TSCN exporter for Blender
While already in development, the plugin that exports Godot scenes directly from Blender is still in its infancy. With the help of Geoff (sdfgeoff), who’s already improving the plugin, and Juan Linietsky (reduz), the student Jiacheng Lu will further work on it to get into a fully usable state. The exporter will help the workflow by removing the intermediary formats, such as Collada and glTF, so the output can be specifically tailored for Godot’s needs.
We from the Godot team want to thank Google for this great program that bridges the connection from universities to open source projects. We also want to give a big welcome for the students and wish them the best of luck. Hopefully we all will get great things from this experience. Now let the work begin!
-
+
\ No newline at end of file
diff --git a/article/godot-google-summer-code-2019/index.html b/article/godot-google-summer-code-2019/index.html
index a7d2b87192..92128a120f 100644
--- a/article/godot-google-summer-code-2019/index.html
+++ b/article/godot-google-summer-code-2019/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde27 February 2019
This article is from February 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.
Google has accepted our application as participant organization in Google Summer of Code (GSoC) 2019! It’s our second participation in the programme, after GSoC 2018 where we had 5 students working on exciting topics. Here’s our organization page for 2019, and our list of ideas for potential projects. This list is not exhaustive, students are encourage to come with their own proposals (after having their relevance validated by core developers).
Google Summer of Code is a yearly program that brings students from all over the world into open source projects. The students have the opportunity to get involved into a real software development process, while the organizations can welcome a new contributor working on a valuable feature, potentially becoming a regular after the summer is over. (Note: The program is called “Summer” of Code, but in the Southern hemisphere it happens during Winter. See the timeline for exact dates.)
Now’s the time for interested students to become familiar with the engine’s source code and our development workflow, get in touch with developers on IRC and use these contacts to define or refine their project proposal.
We strongly encourage prospective students to try to start contributing on junior bug reports before the actual application deadline: we’ll be more likely to pick students who have demonstrated that they can fit into our workflow. The application period goes from March 25 to April 9.
See our organization page for more details on the process, how to get started contributing to Godot and how to prepare your application.
-
+
\ No newline at end of file
diff --git a/article/godot-has-been-renamed-godette-engine/index.html b/article/godot-has-been-renamed-godette-engine/index.html
index 5e70517fcd..296b51b14a 100644
--- a/article/godot-has-been-renamed-godette-engine/index.html
+++ b/article/godot-has-been-renamed-godette-engine/index.html
@@ -5,7 +5,7 @@
Juan Linietsky1 April 2021
This article is from April 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.
Edit: We have seen many comments on our April Fool’s joke. We strive to make the Godot community, and game development in general, a welcoming place for everyone. By not understanding the various ways in which our joke could be interpreted we have failed in this goal.
The Godette character was made years ago. It was not created for this joke. The joke itself was intended to poke fun at a very vocal minority of users who think that our robot logo isn’t “professional”, thus the joke was us pretending to be switching to an even more playful character.
Having said that: our intention does not matter if so many people interpreted the article in the way they did. We apologize for the oversight. We strive to do better in the future.
After months of internal debate, we have decided to deal once and for all with a hot topic and the source of much criticism. Godot is being rebranded in order to gain wider commercial appeal.
Epiphany
It may have taken us a long time, but we finally understood and accept that Godot is about reaching wider audiences, about making something ultimate, about going be beyond what any other game engine has ever attempted.
We thought we had everything. Passionate contributors, an amazing community, and dedicated leadership. Yet, something kept getting in our way and we could not figure what it was. Sleepless nights and months of watching anime during lockdheated debate were required for us to achieve epiphany, the realization that something had to change.
The Godot name
How are we supposed to work on something the English speakno one knows how to pronounce? Is it Go-Dot, Go-DOUGH? GOH-do? Robot? Not even the original authors have a clue when you ask them.
Additionally, we realized that a big problem of Godot as a project name is that it’s simply not cute. To attract wider audiences, a different name must be found, a more marketable one which speaks to a broader public.
The Godot logo
Since Godot was open sourced, we received countless amount of criticism from a small vocal minmajority of the community, pointing out the lack of professionalism of the Godot logo. Have you ever read comments from community members like these?
It doesn’t look like the logo of a commercial game engine.
I would not pay for something with this logo.
The robot scares me; I can’t sleep at night.
Uh, I thought the original logo was a guy’s head popping out of a castle tower, now the new one does not even make sense.
I’m afraid of clowns.
Yes, we did too. They are all over the place. They are the writing on the wall we would refuse to see.
The NEW branding
After weeks of consultation with Reddit usersprofessional marketing experts, it was decided to rebrand both Godot and its logo to convey a more professional branding. From now on, the project will be known as Godette Engine and the new logo will reflect this:
Our official Twitter account has also been moved over to @godetteengine so make sure to give it a follow.
More changes coming
Also, in order to make the engine more commercially appealing, we are evaluating other changes, such as moving the engine to a premium shared revenue model, increasing the download size to a few gigabytes, and making any kind of help or support paid. A bright future is coming for our shareholdcommunity. We hope to be able to tell you more very soon (probably on April 2, since it’s now April 1).
-
+
\ No newline at end of file
diff --git a/article/godot-history-images/index.html b/article/godot-history-images/index.html
index 621f880cea..04046e3b43 100644
--- a/article/godot-history-images/index.html
+++ b/article/godot-history-images/index.html
@@ -5,7 +5,7 @@
Juan Linietsky15 January 2014
This article is from January 2014, 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.
A trip down Godot Memory Lane
Godot was not always called Godot, it went through many (horrible) names, in the following order:
Larvotor
Legacy
NG3D
Larvita
Larvita2
Larvita3
Godot
In fact, Godot was just a code-name for what would be something else, a more general purpose engine with a proper UI instead of a set of assorted tools. We knew it would take a long time, so we used a name based on a play by Samuel Becket to represent that feeling. Eventually the name would change to something with a connection to our home country, Argentina.
In a bizarre twist of fate, at some point and well into the development of the engine, we played a video game with a character that formed that connection (bonus points to anyone who figures it out), so the engine is also named in honor to that. This is good, because the original Godot was never supposed to arrive (well, that’s one interpretation…).
History in pictures
Enough talk. So, how does more than a decade of engine development look like? Like a mess, obviously! (wait for images to load if it’s taking too long!)
We hope that future screens in the next years will be of your games, not ours!
-
+
\ No newline at end of file
diff --git a/article/godot-jam-starts-now-theme-temperature/index.html b/article/godot-jam-starts-now-theme-temperature/index.html
index 6808bff0f9..1dbc79660c 100644
--- a/article/godot-jam-starts-now-theme-temperature/index.html
+++ b/article/godot-jam-starts-now-theme-temperature/index.html
@@ -8,7 +8,7 @@
Rémi Verschelde15 June 2018
This article is from June 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.
With a slight delay(1), the Godot Community Game Jam is now starting and we can announce the theme that was elected by the community:
TEMPERATURE
That’s it! The jam starts today (Friday 15 June) at 19:30 UTC and will end on Monday 18 June at 23:59:59 UTC.
Rules
The rules are detailed on the jam page, but let’s mention them here too for clarity:
Theme: TEMPERATURE
The theme can be interpreted freely, but keep in mind that your interpretation should be understandable if you want to get points for it.
The game should use Godot Engine :)
Contestants can partake alone or as a team. Reusing existing code and assets is allowed.
Once the jam ends, everyone with an itch.io account will be able to play and rate the games. The categories used for evaluating games will be:
Theme interpretation
Gameplay
Graphics and sound
Those three criteria are averaged into the Overall criterion, which is used to determine the jam winners. The winners in each category will also get their spotlight :)
Prizes
Like many jams, the main purpose of the Godot Jam is to encourage users to actually make games and be proud of their achievement. And like many jams, the main outcome of Godot Jam is exposure \o/ and experience (and a wealth of open source projects to play with and learn from).
But we may have some goodies for the jam winner and category winners, and maybe some more… Stay tuned for a later announcement :)
Have fun and good luck!
(1) Reportedly due to some project manager enjoying a leisurely real-life time and completely forgetting that he had to announce the jam theme, only to discover one hour too late the panic that roared on the Discord group in the meantime... But those alternative facts could not be confirmed, and it's unlikely that an organization as serious as Godot Engine would have a single point of failure for such an event.</style>
-
+
\ No newline at end of file
diff --git a/article/godot-joins-software-freedom-conservancy/index.html b/article/godot-joins-software-freedom-conservancy/index.html
index 28f73c48b2..0759776fc0 100644
--- a/article/godot-joins-software-freedom-conservancy/index.html
+++ b/article/godot-joins-software-freedom-conservancy/index.html
@@ -5,7 +5,7 @@
Juan Linietsky4 November 2015
This article is from November 2015, 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 is the newest member of Software Freedom Conservancy!
Conservancy is a non-profit public charity that provides a home to its member projects that develop Free, Libre, and Open Source Software (FLOSS). Conservancy’s assistance allows software developers and documenters to enjoy the benefits of nonprofit incorporation and expertise without having to independently undertake all of the effort to do it on their own. Joining Conservancy allows projects to collect donations, hold assets, and provide some liability protection for their lead developers’ project-related activities. Software Freedom Conservancy, Inc. is a tax-exempt 501(c)(3) organization, incorporated in New York State.
Ariel Manzur, core Godot developer, commented, “This is a huge step for us towards becoming a more open, rooted, and long lasting organization, to provide a more meaningful and robust contribution to the game development community, and software in general, and we’re honored to have the support of Conservancy to achieve this.“
“We’re thrilled to have Godot join Conservancy’s projects,“ said Karen Sandler, Executive Director of Conservancy. “Games are an important part of the software ecosystem and freedom in this area is essential as they are often the first entry point for people to learn about software and how it works.“
As a result, we will soon be able to offer the possibility to ask for donations and get corporate sponsoring programs. Stay tuned!
-
+
\ No newline at end of file
diff --git a/article/godot-leap-motion-support/index.html b/article/godot-leap-motion-support/index.html
index 7aa3a2040c..db4ebf5607 100644
--- a/article/godot-leap-motion-support/index.html
+++ b/article/godot-leap-motion-support/index.html
@@ -6,7 +6,7 @@
For a VR application you should place the sensor node as a child node of your ARVROrigin node and turn the ARVR mode of the sensor on. It will automatically take into account that the Leap Motion sensor is attached to your HMD.
When you select your sensor node you will see that all the properties to configure the sensor are shown:
-
+
\ No newline at end of file
diff --git a/article/godot-now-really-free/index.html b/article/godot-now-really-free/index.html
index 1807bd55b2..4e64b01c42 100644
--- a/article/godot-now-really-free/index.html
+++ b/article/godot-now-really-free/index.html
@@ -5,7 +5,7 @@
Juan Linietsky1 April 2015
This article is from April 2015, 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: This was of course a light-hearted joke for April Fools’ Day 2015 :)
Free Godot
We have noticed a happy new industry trend amongst the major video game engines. In the interest of keeping hip with the trend, we decided to also follow suit. As of 12:01am CST today, we are very excited and overwhelmingly proud to announce that the entire Godot Engine is now FREE!
You must be wondering what has changed. Truth is, Godot’s license allowed users to do anything, so it wasn’t really following the true definition of “free” which was adopted by the industry leaders. To make Godot a more viable choice in the eyes of developers, we have decided to attach strings to its freedom.
Finally, Godot now has usage restrictions more fitting of a real-world game engine. What follows is a brief introduction to the changes we have implemented, effective immediately:
Splash screen of pride
We know you are too poor to afford professional software, so we are following industry leaders and Free Godot is adding an unchangeable, mandatory splash screen. This way you can let your customers know how proud you are to be poor.
No scripting language
You have a lot of complaints about GDScript. We hear you! Loud and clear. Every few days someone is asking for Lua, C#, real Python, or some other kind of scripting language that isn’t the one that we had so tightly integrated into the engine.
Effective immediately, Godot has no scripting language. Just download the Free Godot Engine source code program directly in C++! Or better yet, you can integrate your favorite VM!
Sharing your success
We want you to be successful, and we want to be successful right there with you. But only if you succeed. In other words, your success will never be 100% completely yours. If your game makes money, we want a small part of it. If you go out for drinks, we want a beer. The same way if you purchase a new house, we want a room there. Some kinds of success are priceless; in such cases you are not required to share. An example of this is having success with a romantic partner (as long as you don’t pay for it).
We feel that a 10% cut of all sales is not unreasonable to ask for. Think of it as a tithe to Lord Godot. True, you don’t have a choice in the matter. But remember, the Lord Godot loveth a cheerful giver!
Democratizing development
We also want to democratize game development. As you know, Godot Engine developers and other members of the community have always listened to your concerns, troubleshot your problems, fixed bugs you reported, implemented many of your suggestions and merged untold numbers of pull requests. This may have sufficed at one point in our history, but can continue no longer, as it’s clearly a greivous form of communism, and communism is the enemy of democracy.
From now on, you will be free to continue sending improvements, reporting bugs, and suggesting improvements, however, we will not act of any of it without first receiving the appropriate payment (we accept cash, checque, money order, and beer). As the core development team, we will only do asmall, fixed amount of work, and then sit on our asses drinking beer until we are re-elec^H^H publish a new major version – just like real democracy.
To make it clear, the new terms will being applying at 12:01am CST of April 1st. Of course, you can always ignore all this and keep using the MIT license, which gives you complete and absolute freedom, without any strings attached, even if it’s not trendy!
-
+
\ No newline at end of file
diff --git a/article/godot-oculus-quest-support/index.html b/article/godot-oculus-quest-support/index.html
index 8a053eca98..50743c31be 100644
--- a/article/godot-oculus-quest-support/index.html
+++ b/article/godot-oculus-quest-support/index.html
@@ -30,7 +30,7 @@
Now hit the little Android button that should be visible in the top right hand side of your Godot window. It should build your game and export it to the Quest.
The above does the bare minimum to get your project running on the Quest, it’s not very exciting. Holger Dammertz has made a great toolkit for the quest that contains a lot of scenes to get help you on your way including really nice controller meshes.
Last but not least, Android C# support for Godot has been added and is being tested in Godot 3.2 beta 4. We will be doing a getting started tutorial on that soon.
-
+
\ No newline at end of file
diff --git a/article/godot-openxr-111-plugin-release/index.html b/article/godot-openxr-111-plugin-release/index.html
index 491d13e5f0..155d776c8d 100644
--- a/article/godot-openxr-111-plugin-release/index.html
+++ b/article/godot-openxr-111-plugin-release/index.html
@@ -6,7 +6,7 @@
The documentation has been updated to provide instructions for how to leverage this capability!
We’re planning to expose more capabilities of the Passthrough api in future releases, so don’t hesitate to provide feedback on desired features!
Meta Quest Hand Tracking Support
This release adds support for OpenXR’s hand tracking api on the Meta Quest and Meta Quest 2.
Support for this api was already enabled for other platforms and devices, but a bug prevented it from working correctly on the Quest. The issue has been resolved in this release, making the feature available to use across all supported devices.
The documentation will be updated shortly with instructions for how to better leverage this capability.
And more!
In addition to these features, this release contains several bug fixes and QoL improvements to improve the experience of Godot XR developers!
For more details on the other changes, please consult our curated changelog.
Reporting Issues
For any issues encountered while using the Godot OpenXR plugin, or for any clarifications/improvements to the Godot XR documentation, feel free to open a github issue under the Godot OpenXR github page!
The list of current known issues can be found here.
-
+
\ No newline at end of file
diff --git a/article/godot-openxr-support/index.html b/article/godot-openxr-support/index.html
index 5e3c7639fa..6697d9bf09 100644
--- a/article/godot-openxr-support/index.html
+++ b/article/godot-openxr-support/index.html
@@ -8,7 +8,7 @@
The focus for March lies with getting the Vulkan renderer working on Android after which we’ll start making changes to the rendering engine to support a better way of doing stereoscopic rendering then we had in Godot 3.
The image is courtesy ofVRWorkout, a popular VR workout game made with Godot and available on SideQuest and Steam for free.
-
+
\ No newline at end of file
diff --git a/article/godot-project-management-101/index.html b/article/godot-project-management-101/index.html
index bcaaadcc49..3df26a96a7 100644
--- a/article/godot-project-management-101/index.html
+++ b/article/godot-project-management-101/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde27 March 2018
This article is from March 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 eagerly watching our Patreon page for news or following Juan on Twitter, you might have seen that we just reached our third Patreon goal at a very generous USD 7,500 per month!
After hiring our lead developer Juan Linietsky full-time in September 2017, and our GDNative and GLES 2 developer karroffel part-time in December 2017, we can now hire myself (Rémi Verschelde) full-time too as project manager, release manager, and representative!
Given the good progress of our Patreon campaign, we actually anticipated this goal and I have been working full-time since early March (after quitting my previous job in February). Reaching the goal means that we’ll be able to honor our payroll without having to eat into our limited pre-existing assets, which is more sustainable :)
In this post I will try to highlight a bit what those three “positions” mean, to shed some light on the less glamorous but very needed management and public relations of a community-led FOSS project like Godot. For those interested, I’ll start by a quick history of how I came to Godot and my involvement so far, which can give you a “real life” illustration of what community-led project management means. You can also skip directly to the “What now?” section if it’s TL;DR for you ;)
From user to contributor and project manager
I first heard of Godot in December 2014, when version 1.0 was released (note that author information on those old blog posts is incorrect, I was not posting articles at that time :)). I was (and still am) quite fond of Free Software, including libre games, and a free and open source engine that runs natively on Linux was very appealing to me. My first interest was actually to package Godot for my Linux distribution Mageia, which was the first one with an official Godot package. Like Godot, it’s a community-led not-for-profit free and open source project, so I could eventually reuse my Mageia experience to help improve Godot’s development.
I read some of the documentation and tried demos, but only started learning and using the engine for real mid 2015 with version 1.1. Since I was familiar with open source projects, I quickly found my way to the GitHub repository to report a few bugs and enhancement requests.
I saw that there was a great momentum and that Juan was a very friendly and caring project maintainer, but that there were some things hindering the project’s full potential:
The issues repository was a mess. Most issues lacked the information that could actually be of use to developers (detailed bug description, steps to reproduce, affected version and platform, etc.), and a big part of the issues were actually fixed already in released versions of Godot, but nobody had taken care to close them. Juan (and Ariel too to a lesser extent) was the only one able to manage the issue tracker, and did not have time nor bug triage experience to do it efficiently.
Similar story for pull requests (PRs). Most PRs had inconsistent code quality and style, and a relatively messy git history (e.g. 3 or 4 merge commits in the same PR for a simple change in one file). Here again Juan was the only one “in charge” of reviewing PRs, and that showed. Worse for the momentum of the project: Juan likes to stay focused when developing features, so he would not check PRs often. He would usually check all PRs at the same time once a month, and merge most of them after a quick glance, then do fixes himself for what was problematic in some of the merged PRs. This had two negative effects:
No real code review was done, and good features with not-so-good code were merged, slightly increasing the technical debt.
Most contributors had to wait for weeks if not months to get feedback on their PRs. Since most of those were first-time contributors, they would eventually stop caring about the project and move to something else.
It was almost impossible to contribute to the documentation. We were using the GitHub wiki feature at that time, which meant that only users with write access to the git repo could modify documentation. At that time, that meant only Juan and Ariel, since they were understably not willing to give full permissions on the repo to new contributors.
Release cycles for minor versions were long (6 months from 1.0 to 1.1, 8 months from 1.1 to 2.0), and in the meantime some users were stuck on an outdated stable versions while others were putting up with the occasional post-mass-merge instability in the master branch.
Back then I did not formalize those issues as clearly, but I saw that stuff needed to be done and that I had experience with it thanks to my involvement in Mageia as a packager, QA tester and bug triager. As a jack of all trades and master of none, I started working on a bit of everything that seemed necessary for the project to continue growing and be successful.
Bugsquad
So I started with the most pressing issue: developers (be it Juan or any other contributor) can’t work efficiently if they don’t know what are the bugs users are experiencing in the engine, and how to reproduce them. I started by going through issues, asking reporters for more details or to check if their issue was still valid in Godot 1.1 or the master branch… it was tedious work but helped us close some obsolete issues and prioritize some valid ones. I still wasn’t able to press the “Close” button on issues myself though, due to GitHub’s restriction that only people with write access to the repo (i.e. able to push commits live without making PRs) could triage issues, though I was still dependent on the issue reporter or Juan closing the fixed issues.
Eventually I harassed Juan so much that he agreed to give me write access to the repo, as well as to a couple other trustworthy contributors, to organize the “Bugsquad” or bug triage team. Its role was (and still is) to assign labels to issues (bug report, enhancement request, what platform does it affect, what part of the engine is it about, etc.) and pull requests, and ensure that fixed or invalid issues were actually closed and that open ones were descriptive enough to be useful. It took us several weeks of work to go through the backlog of 2,000 issues, but we could close about half of them and give more visibility to the still valid ones (leading to a much better user experience in Godot 2.0, since contributors could find and fix usability quirks much faster). I did a big part of that work initially, and little by little I encouraged more experienced Godot users to join the Bugsquad and help spread the workload.
Merging PRs
In parallel, I started bugging Juan regularly about pull requests. It was hard for me to review them with very little experience with the engine’s internals, but some were simple enough even for me to understand: typo fixes, documentation updates, compilation fixes (there was no CI and some platforms broke regularly), or usability improvements in the editor. It made no sense for such changes to wait in the limbo for the next “big merge” a month later, so I sent Juan links to PRs to review and merge in priority on IRC.
Eventually, since I had full write access to the repo because of the Bugsquad’s work, Juan told me that I could merge such PRs myself if I was confident enough. I was a bit impressed to have so much responsibility while being a quite average developer (I’m energy engineer initially, not engine programmer :)), and afraid to do mistakes. But I went ahead and merged some stuff, at first very conservatively, and later on a bit boldly. The first reverts when I merged something that I shouldn’t have arrived quickly, but I got better at reviewing PRs and got more familiar with the engine itself.
And what we saw happen was well worth the effort: in the months following the initial big Bugsquad triage of the issues backlog and the faster PR reviews, we saw a lot of new contributors come to the engine, and many existing ones staying and gradually becoming our first “core contributors”, doing several PRs each month. In one month we doubled the number of monthly PRs, and it kept on increasing. Existing and new contributors were more motivated when seeing that contributions were valued, reviewed and merged (or refused, if need be) quickly.
Eventually I spent so much of my (free) time reviewing and merging PRs that it was not sustainable in the long run, so with Juan we created a “PR mergers” team and invited some core contributors to it, so that they could review and merge PRs themselves (they could already review them without merge permissions, but it’s more effective to get contributors to do work for free when they have a responsibility ;)).
Migrating the documentation to ReadTheDocs
As mentioned, Godot’s documentation was initially in a GitHub wiki, and could only be edited by developers with write access (so only Juan and Ariel initially, later on the Bugsquad too). It was a big issue as the docs were far from perfect, and many users wanted to contribute.
Thanks to Theo Hallenius, we migrated our Wordpress website, phpBB forum and GitHub wiki to a common OpenProject instance. Theo did a lot of work to convert the GitHub wiki (in Markdown) to the Textile markup format used by OpenProject, and it was great: we finally had a wiki that any logged user could edit, and we even had localized versions of the wiki (far from completion, but there were starts of Spanish, Chinese, French wiki, etc.). Sadly we quickly started to have big performance issues with OpenProject, making it often unreachable or very slow. After trying several things to fix those issues, we eventually decided to migrate everything again to a new modular setup (the current one): the website and blog on OctoberCMS, the forum outsourced to the nascent GodotDevelopers community, a new Q&A to replace it in the main website and be more focused on a StackOverflow-like platform, and the docs moved to a git repository using Sphinx and ReadTheDocs.
Understandably, Theo did not wish to work on yet another migration after we decided to abandon the work he had just did, so others had to take over. I naturally took on the “manager” hat and helped coordinate the work of our contributors (especially Alket Rexhepi) on the website’s backend, design, etc.
And on my end I looked into how to migrate the OpenProject wiki to something better. I was no happy with the wiki system as it typically lets anyone make edits, and you have to review edits afterwards and correct issues, if any. It seemed to me that using a GitHub repository for the documentation, with the same PR workflow as for the engine code, would be the most efficient. Sure, learning how to use git and our PR workflow would be a hindrance to some technical writers, but we found that the pros outweighed the cons.
I settled on the Sphinx doc builder, which generates static HTML pages based on source files in the reStructured Text markup language (yet another conversion needed, Julian Murgia and I became pretty good at regular expressions!), and the ReadTheDocs platforms, which provided hosting, automated builds on new commits, and a great looking theme. This is still the system that we’re using today for the official documentation and we are pretty happy about it!
For the first year and a half or so Julian and I did our best with limited time to manage the docs repository. Then a year ago or so, we encouraged professional tutorial makers like Nathan Lovato (GDquest) and Chris Bradfield (KidsCanCode) to help us, and they eventually completely took over, making our 3.0 documentation the most complete and well-written so far! And with “recent” contributors like Max Hilbrunner, they are now reproducing the workflow that I outlined above, with a better issue triage and reviews of pull requests, so that the godot-docs repository is becoming a hive full of buzzing documentation bees working everyday to improve your learning experience!
Making stable and develpoment releases
The last big issue I had noticed was the long release cycles and lack of bugfix/maintenance releases in the stable branches. Coming from the Free Software ecosystem, I knew the value of the release early, release often saying, and wanted more frequent releases for Godot.
At the same time, we started running out of credits on the build server that Ariel was using to make the official binaries, so we needed to look into (cheap or free) alternatives.
With the help of various contributors, we setup a full buildsystem (ab)using Travis CI to build Godot binaries for all platforms, and then upload them to a GitHub repository (since then we replaced the cross-compiled MinGW Windows builds on Travis by native Visual Studio builds on AppVeyor, but it’s still the same idea). Though CI services are not designed for this, it allowed us to get binaries for a wide variety of platforms, including macOS and iOS without needing to buy/rent a macOS server ourselves.
Using this new system, I could prepare official builds of Godot more often (still not in a nightly fashion, as the whole setup would still take 5 to 10 hours to build everything, and I didn’t want to DoS Travis’ infrastructure with Godot builds). We could publish frequent beta builds of Godot 2.0 to get more testing before the final release in February 2017, which turned out pretty good!
Once 2.0 was out, I decided to keep maintaining a stable 2.0 branch with bugfix releases, while development was ongoing for Godot 2.1. So I branched off at the 2.0 release commit, and started cherry-picking bugfixes and usability improvements to this stable 2.0 branch. We released 2.0.1 a couple of weeks after 2.0, and so on and so forth up to 2.0.4.1. And we did the same for the 2.1 branch.
Now with Godot 3.0 released in January 2018 and the huge community growth that we experienced over the last year, we decided that stable branches needed more guarantee of forward compatibility (you should be able to run your 3.0.1 project in Godot 3.0.4 for example). HP van Braam proposed to offload me of this responsibility and to be the official maintainer of the 3.0 branch, which I gladly accepted. For now I’m still handling the buildsystem and helping review what should be backported to the stable branch, but they’re taking on more and more of the work so that I can focus on the master branch.
What now?
The above was meant to be a quick (haha) overview of how I came to Godot and what I helped setup for the project to be as successful and fast-growing as possible. It turned out to be a very detailed history (I hope not too boring, but as you can see I like talking of things I’m passionate about :)), but the conclusion of each part is: I set up and maintained a ton of stuff, and now I’m offloading more and more of this ever-increasing workload to new contributors.
So what’s next? What am I going to work on especially now that thanks to our generous patrons, I can work on Godot full-time?
Keep doing it
Well the first part of my “new job” is not really revolutionary: I’ll keep doing what I have been doing for 2.5 years. Even though I’m offloading more and more of those tasks to other contributors, the community is growing at a tremendous pace, and at each major or minor release that we have the workload basically doubles.
So I’ll continue working on sharing and even giving over more of my responsibilities to other contributors, but as I just wrote it, that’s work too. And we still need someone to coordinate the work of the different teams.
Moreover, I’m now working full-time on Godot as my paid job, but I was already basically working 30+ hours a week for free previously next to my normal full-time paid job (and partly overworking myself), so I don’t have so much more time right now if I want to keep some more of my newly found free time for different healthy activities :)
Be Godot’s representative for the industry
Thankfully I haven’t detailed it in my long history of all the Godot things I’ve been doing in the past, but I have also taken the role of communications manager (writing blog posts, managing social media accounts and Godot email addresses, etc.) and events organiser (FOSDEM, GodotCon, etc.), and I’ll continue doing that.
But now I have actual time that I can allocate to create and nurture Godot’s relationships with the gamedev industry and the educational world, as the project’s representative. As Juan mentioned in his GDC 2018 review, with events such as GDC he has to spend a lot of time doing communication and relations work instead of writing code and (more importantly) help contributors write code. At the same time he lives in Argentina and many industry events take place in Europe, where I live.
So the idea is that I should take over part of those tasks, and push them further: I’ll give talks and workshops at universities, meet companies to talk to them about Godot (and sponsorship!), participate in industry events, etc.
This also includes all kinds of administrative tasks needed for the project, such as applying for grants or programmes like the Google Summer of Code (GSoC), and then following up on them. For example I’ve spent most of the past week answering questions from prospective GSoC students and reviewing their draft applications, as well as encouraging fellow contributors to volunteer as mentors for the GSoC programme.
Just like all the other things I’ve been working on in Godot, I’ll also gradually find ways to offload more of this work to the community: that might include helping setup local communities which could organize events of their own in the town/region, collect and improve presentation and teaching material for users and teachers to use in their talks or curricula, etc.
What it will all be exactly is still to be determined, but we definitely agree with Juan and other core contributors that Godot needs public figures who can do the link between our hardly-known yet awesome bundle of technology and the real world, with its needs and expectations. This should eventually help us gain more adoption, more contributions, more funding and more awesome features and – that part is yours – games!
Next goals
With the impressive USD 7,500 milestone reached, we can now pay salaries for Juan and I (USD 3,000 each) and karroffel (who works part-time and as an intern, so she’s exploited for USD 1,050 from us + USD 400 from a generous thirdparty interested in her work). That’s actually slightly less than we needed for this payroll as we also give 10% of our donations to our fiscal and legal sponsor Software Freedom Conservancy, so strictly speaking we need over USD 7,800 per month. But 7,500 was a rounder symbolic value :)
On top of that, we’d like to have some cash flow to pay for travel expenses, as when Juan goes to Europe for GodotCon or to the US for GDC 2018, plane tickets are pretty expensive. As the project representative, I’ll also be travelling a lot in Europe to meet companies, universities and take part in industry events. In first approximation we’re setting a goal at USD 9,000 that should reflect the monthly expenses we expect to have in the near future (if you’ve followed, that USD 8,100 for Godot, so ca. USD 1000 for variable expenses after paying salaries).
Once we’ve secured that, we’ll think about growing the team of paid contributors again, as we have quite a few very talented contributors who would welcome a part-time job to work on the engine.
Another, simpler alternative to get more paid developer time on the engine is for thirdparty companies to hire Godot contributors themselves to work on what they need and contribute it upstream. That’s what Pedro J. Estébanez is doing with AdPotNet for example, and we want to encourage more companies to do the same, as it’s much more flexible than going through Conservancy and donation-based income (and should also be more lucrative for contributors hired for such contracts! ;)).
I hope this writeup helped shed some light on how the Godot project is managed, including how we handle donations and what we use them for. If you have any question, you can ping me on IRC or Discord (Akien).
-
+
\ No newline at end of file
diff --git a/article/godot-ragdoll-system/index.html b/article/godot-ragdoll-system/index.html
index f2010f142f..d66eeb3fb1 100644
--- a/article/godot-ragdoll-system/index.html
+++ b/article/godot-ragdoll-system/index.html
@@ -10,7 +10,7 @@
With the code above, we are passing to the engine the names of bones for which we would like to simulate physics, and this is the result:
Collision Layer and Mask
Last but not least you have to properly set layer and mask in a way that doesn’t collide with kinematic capsule but collide with ground:
What’s next?
The next thing that I will implement is the active ragdolls that will allow us to influence the physical bone position. This mean that the body will tend to maintain a defined position while ragdoll is active.
-
+
\ No newline at end of file
diff --git a/article/godot-reaches-2-1-stable/index.html b/article/godot-reaches-2-1-stable/index.html
index a0b697a9c9..aec0104390 100644
--- a/article/godot-reaches-2-1-stable/index.html
+++ b/article/godot-reaches-2-1-stable/index.html
@@ -6,7 +6,7 @@
New AnimatedSprite features
While using an AnimationPlayer to switch frames is a very powerful approach, we always felt AnimatedSprite could be a little more accessible to new users. To do this, we added multiple animation support to it, and the ability of simple auto-playing of animations at a given speed without the need of using an AnimationPlayer.
Finally, we reworked the UI to make it more accessible, with full drag & drop support.
Future
This has been a fun and exciting release, and we feel Godot is finally where we want it to be in terms of usability. It has been more than a year since 1.1 was released and not focusing on new core engine features for so long was difficult, yet we feel it was worthwhile as Godot is now much more accessible than it used to be.
From now on, and for at least a few releases, we will focus on making Godot even more fabulous. Our next release is already in the works and will be 2.2 (which we hope to deliver in 2/3 months). It will include a new visual scripting language, support for Mono (C#), high level multiplayer networking and a more advanced audio engine. It should also feature many improvements to 2.1 features such as the Asset Library or plugin API, based on your feedback over the coming months.
Meanwhile, work on Godot 3.0 is starting already (expected in 6/7 months from now), and will include a new reworked, modern renderer with support for Physically Based Shading, improved shader language, VR, and many other nice things, as well as a greatly improved HTML5 export platform with WebAssembly support.
Our goal with 3.0 will be to have a game engine that can output really, really beautiful 3D visuals involving a lot less hassle than existing solutions. We know how difficult it is for artists and even programmers to make things look good with existing game engines, so our approach will be to give you every tool you need for your game to look great out of the box using built-in Godot features.
Spread the word!
As always, we ask you from the bottom of our hearts to spread the word about Godot. We know how good this little engine we are making together (developers and community) is, but we are still little known in the game development world. With no marketing budget and 100% voluntary contributors, we need every member of the community to partake in the effort and spread the love of Godot by word of mouth, blog posts, press articles, game jams and events, published games, etc.
Please make as much noise as you can so that more developers know about us and give a try to our professional-grade open source game engine! :)
-
+
\ No newline at end of file
diff --git a/article/godot-rmll-2015-france/index.html b/article/godot-rmll-2015-france/index.html
index b3b7892bf0..cbb116fb26 100644
--- a/article/godot-rmll-2015-france/index.html
+++ b/article/godot-rmll-2015-france/index.html
@@ -7,7 +7,7 @@
More information at the RMLL website.
Thanks enormously to the organization of RMLL for this invitation!
Godot in Paris
Juan will be having meetings in Paris the week from the 10 to the 17, so if you want to schedule a meeting with him (or just want to go out for beers), please contact him beforehand!
Spread the love!
If you have contact or work in the organization of technology, video game development or libre software events, and would like to bring one of the main Godot developers, also contact us. We are also working hard so everyone willing to give a talk in their local community can have access to the materials we use in our talks and workshops (please help us translate them to your native language!).
-
+
\ No newline at end of file
diff --git a/article/godot-rmll-lsm-2018-strasbourg-july-7-12/index.html b/article/godot-rmll-lsm-2018-strasbourg-july-7-12/index.html
index 97ff408005..2bc2432e37 100644
--- a/article/godot-rmll-lsm-2018-strasbourg-july-7-12/index.html
+++ b/article/godot-rmll-lsm-2018-strasbourg-july-7-12/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde27 June 2018
This article is from June 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.
Godot will be at the Libre Software Meeting 2018 (also known as RMLL – Rencontres Mondiales du Logiciel Libre) in Strasbourg, France from Saturday 7 July to Thursday 12 July. We will give a 1-hour talk, a 3-hour game development workshop, and there will be a Godot stand with core developers to welcome you for the whole duration of the event.
LSM is a yearly community event in France focused on Free/Libre and Open Source Software, and we’re looking forward to representing Godot there this year. At least three core developers will be there (Julian Murgia (StraToN), Gilles Roudière (Groud), and myself (Akien)), and we hope that some more as well as many Godot users will join us in Strasbourg. The location should make it relatively accessible for people from neighbouring regions of France, Germany, Switzerland, Belgium and Luxembourg.
Godot-related activities
We have three Godot-related offers for visitors of the LSM. Note that they are all located in different buildings of the LSM venue, see the venue map as well as each activity’s page for details.
Godot stand in the Libre Village during the whole event. We’ll be there showcasing Godot, games made with it, and selling the awesome T-shirts designed by Daniel Ramirez (djrm) :) If you’re coming to LSM, please come to our stand and say hi. You’ll also be welcome to give us a hand manning the booth and talking about Godot to visitors :)
Indicative poll: It’s not mandatory, but to give us an idea of who to expect, you can add yourself to this poll. We may plan a Godot dinner and/or a real-life meeting if we have many community members around, so you can send me your contact details (email in the poll description) if you want to be in the loop.
-
+
\ No newline at end of file
diff --git a/article/godot-sdk-integrations/index.html b/article/godot-sdk-integrations/index.html
index 04c7c89af2..19ae06a265 100644
--- a/article/godot-sdk-integrations/index.html
+++ b/article/godot-sdk-integrations/index.html
@@ -5,7 +5,7 @@
Godot Foundation24 September 2024
Developing and publishing games often involves relying on third-party services, middleware, or platforms. Numerous vendors offer commercial products like advertising networks, backend services, sound engines, user authentication, and more. These tools simplify the process of monetization, expanding player reach, storing data on servers, and performing other functions beyond what a game engine typically provides.
To facilitate integration, these vendors often supply SDKs tailored for specific game engines, allowing developers to easily install them and interact with their products.
Godot, while rapidly growing in popularity, is still relatively a newcomer. As such, while some vendors are beginning to support the engine, many others have not yet invested on it, given the necessary development and maintenance costs.
For some, this is due to the significant resources required (finding the right developers to hire to make the SDKs), while for others, it’s simply a matter of being unaware of Godot’s growing market or dealing with internal bureaucracy that slows down the process of supporting the engine.
As the Godot Foundation is committed to using donations solely for creating FOSS and prioritizing open standards, it does not allocate resources from the general pool of donations to integrate proprietary SDKs into the engine.
While officially incorporating monetization SDKs into Godot might not align with the project’s goals, for example, there is still a widely recognized need within the community for such support to help developers make a living. As there is a need for many other SDKs.
Community to the rescue
To tackle this challenge, many in the Godot community have taken matters into their own hands, developing proper integrations for third-party services. Talented developers have done an incredible job to bring the most popular services into Godot, enabling the community to publish games on their desired platforms using the necessary third-party tools.
However, this approach still presents several issues for the community:
Not everyone is committed to creating and maintaining a full SDK integration. Often, developers only implement the features they need for their specific game.
Developers may not have the time or inclination to support other users’ issues as long as their integration works for their project. Likewise, they may not continue developing the integration after their project has been published.
As a result this means that, over time, multiple forks of the same integration can be found on GitHub, maintained by different individuals who needed it at different times, leading to fragmentation.
Adding to this, some vendors who provide SDKs for other game engines have expressed interested in supporting Godot but are not ready to allocate internal resources to develop an integration due to costs or other constraints. They might be willing to donate their integration (or donate the money to do an integration) to the Godot Foundation and collaborate with the community.
While this is amazing, the Foundation doesn’t want to become responsible for maintaining such integrations using general funds once the specific donation runs out.
The Godot Engine Community SDK Integrations GitHub organization
After extensive discussions with the community and various vendors, the Godot Foundation has decided to maintain its stance on not directly developing SDKs. However, recognizing the need for a more organized approach, the Foundation has established an official centralized GitHub organization for hosting SDK integrations, thereby encouraging community contributions.
This organization eases the burden on developers who create their own SDK bindings, as they will now be able to accept contributions without bearing the sole responsibility for maintaining the integration. It also provides a clear and official platform for companies that wish to donate their SDK integrations, offering a centralized location for these contributions.
The new Godot SDK Integrations organization has its own GitHub page already. Developers who have been working on SDK integrations are invited to move their work here, if they desire so. You can join the new sdk-integrations channel to discuss this transfer.
Likewise, vendors interested in donating integrations for their first-party SDKs are also welcome to move them to this new organization, if they deem it preferable to hosting SDKs themselves. Please contact the Godot Foundation in order to make arrangements. Likewise, if you would like to finance the development of Godot integrations for your SDKs, the Godot Foundation can help facilitate contacts with trusted community maintainers or companies who can take on such work.
Please note that this organization is a public space for centralizing SDK integration efforts and collecting repositories. The Foundation will not manage or update the integrations, so ongoing development will depend on the community and vendor contributions. This initiative is intended to be a collective effort.
Contributing to the Godot SDK Integrations organization
As we mentioned, the Godot Foundation is hosting this new space, but doesn’t intend to spend its resources on maintaining it.
We are therefore calling for motivated community members to get in touch and help organize the structure of this new organization, and help support developers and vendors who want to provide new SDK integrations for Godot.
Aside from the actual work of developing and maintaining SDK integrations, we foresee the need for contributors with a production profile who can help write common contribution guidelines, instructions on how to “recruit” new maintainers, or generally ensure some quality and fitness for purpose of the various SDKs offered by and to the community.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-2dynamic-games-lumencraft/index.html b/article/godot-showcase-2dynamic-games-lumencraft/index.html
index 09d508a824..fbf1d95aa7 100644
--- a/article/godot-showcase-2dynamic-games-lumencraft/index.html
+++ b/article/godot-showcase-2dynamic-games-lumencraft/index.html
@@ -12,7 +12,7 @@
We like the freedom to modify source code and implement features on top of C++ code base. We hope to upgrade Lumencraft to Godot 4 in the future.
Lumencraft is available on Steam and GOG for Windows, Linux and Steam Deck.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-ben-kurtin-fnf-vr/index.html b/article/godot-showcase-ben-kurtin-fnf-vr/index.html
index 315ebb5153..d7c85b70e2 100644
--- a/article/godot-showcase-ben-kurtin-fnf-vr/index.html
+++ b/article/godot-showcase-ben-kurtin-fnf-vr/index.html
@@ -7,7 +7,7 @@
In general, I chose Godot because, like I said before, I wanted something easy to work with. Maybe it was also for a bit of that counterculture feeling, since even when I picked up the engine in 2020, Godot was a niche engine. Of course, now I’ve been hearing lots of talk about it. In fact, I know a few professional software developers who have been using Godot for their game projects for the same reason: it’s easy! While it does take away from the nicheness of the engine, that’s not a change that I mind. I’m glad that more people are starting to use it.
How was your experience building a VR game specifically?
It’s a lot tougher than making a 2D or a non-VR 3D game, that’s for sure. Not because it’s necessarily harder to program or harder to make assets for, but it’s much, much harder to debug. You have to put on the headset, wait for it to wake up, hit F5 awkwardly with the headset on, and then kind of peer through the nose gap to see the info you get on screen. And if you run into an error, you have to take off the headset, put it in a safe place, edit the code, and then rinse and repeat this process until you get it running stably. Simply put, it’s tedious and a pain in the butt. Despite that, the satisfaction you get from seeing your work come to fruition when you put on the headset is incredible!
Which parts of the game development process did you enjoy the most while working on your project?
Like many other game developers, I enjoy seeing the final product come together harmoniously. This effect has been magnified during the development of FNFVR, because there’s something magical about seeing a game you enjoy from a different perspective. Besides that, however, FNFVR has given me deep insight on how to make a good rhythm game. Over several iterations, I’ve learned how to make an extremely accurate timekeeper (usually referred to as the Conductor, similar to the person who keeps tempo for an orchestra), as well as a highly flexible note and lane system. These revised components will be making their way into an upcoming update for the game. I’m very proud of the work I did for those and had a lot of fun making them! I hope they can be reused in other Godot rhythm game projects that I make or that others make (since the code will be open source, in the spirit of FNF).
Which parts of the game development process did you find the most difficult to apply in your project?
I’m very new to 3D game development, and I only had a little experience prior to FNFVR. It was an arduous process figuring out how to get the player model right. At first, I was going to use inverse kinematics, similar to how VRChat works, but fortunately one of my fellow VR enthusiast friends guided me in the right direction and suggested floating hands. Not only that, but with a bit of hindsight, I’ve figured out that the game is extremely unoptimized in so many different ways. I’m going to be fixing this very shortly with my newfound knowledge (such as: it’s actually a bad idea to make every model local since all the data of each model is duplicated into text).
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
I’ve said this to others when talking about Godot, and I’ll say it again: Godot is very good for making games quickly. The rapid and hotfix prototyping that Godot provides made it possible for me to learn the engine quickly and then make a VR game quickly. The first prototype of FNFVR was made in around two weeks if I remember correctly. Granted, I worked my butt off for those two weeks, but I guarantee you that trying to do the same thing in other VR-compatible game engines would have been a slog. Even besides FNFVR, almost every game in Godot has been made quickly and efficiently (even with my spaghetti code in earlier projects!), which is something I truly appreciate about the design of the engine and the editor.
Which challenges have you encountered when using Godot?
I did encounter a few issues, mostly nitpicks, during the development of FNFVR:
Some documentation leaves something to be desired. For instance, the SkeletonIK node, a node that would be very useful for controlling a VR avatar, has zero documentation on it. Or the PCKPacker, which is useful for an upcoming update for FNFVR, does not have a great tutorial on how to use it, so I had to brute force my way into learning how it worked.
Blendshapes / shape keys simply don’t work in the GLES2 renderer. For those reading who don’t know, blendshapes, or shape keys, are parameters that morph a part of a 3D model to have a different shape. It’s typically used for facial animations, like lip sync. This means the faces of every character in the game, which are controlled by these blendshapes, do not work on the Quest. There does seem to be an open request to fix this, which I would implement myself if I was confident enough to debug an entire game engine.
Animating 3D stuff in-engine. I had to write my own custom code just to be able to animate the 3D models myself. Fortunately, I now work with people who are better at animating than I am, but I did find it odd that 3D skeleton animation was not built-in like it was for 2D.
By far the biggest challenge of the project was learning how to properly use (and then promptly almost never using) yield statements. Because they can’t be interrupted or destroyed (which is bad for pausing and quitting out of levels), I’ve decided to use signals for almost every event I need to handle. While this does produce uglier code, it makes it more flexible and ultimately allows us to be more creative with levels!
You ported your game to the Quest. How was that experience?
While the Quests have been a major step up in affordable and accessible VR, it’s not fun to develop for the standalone side of them. Having to switch renderers, design and manage levels so that they look the same on both platforms, debug across devices, and do operating-system specific set-up is a slow and tedious process. This process is so slow and tedious that I might’ve given up on developing for the Quests if they didn’t happen to have the largest share of all personal VR users (and incidentally, the large share of our player base). I can only hope that the move to OpenXR and the eventual release of Godot 4.0 makes it easier to develop for the Quest platform.
Which features would you like to see in future versions of Godot?
Most of the features I already wanted to see in Godot are actually coming in 4.0, which I’m pretty happy about. If possible, having those blendshapes work in GLES2 would be great to have (unless 4.0 is coming soon enough to fix that problem). However, my #1 request would be for AnimationPlayers to have the same easing options as Tweens do; that would be very useful. Otherwise, Godot already packs quite the punch with the features it has, and I can’t wait to see what you guys are working on in future updates!
Would you use Godot for a future project?
If you ask some of my friends what they know about me, a couple possible answers are: “Ben never shuts up about Godot” and “Ben sounds like he’s sponsored by Godot.” I think that’s a sufficient enough way to say “yes, absolutely!”
Friday Night Funkin’ VR is available as a free download for Windows, Quest and Quest 2 on Itch and SideQuest. The project’s source code is also available on GitHub.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-cassette-beasts/index.html b/article/godot-showcase-cassette-beasts/index.html
index 2dc98af42d..bcbed0d08b 100644
--- a/article/godot-showcase-cassette-beasts/index.html
+++ b/article/godot-showcase-cassette-beasts/index.html
@@ -5,7 +5,7 @@
Emi26 April 2023
It’s been a long time since our last showcase interview. This time, we bring you Jay and Tom, the team behind Cassette Beast, an 80’s vibe Creature Collector turn-based RPG set in a vast and colourful open world.
Could you tell us a bit about yourselves and your studio, and how you got started in game development?
Jay: My name is Jay Baylis and I’m one half of Bytten Studio, a micro game dev team based here in Brighton, United Kingdom. I’ve been making indie games for over a decade now, and have made games for fun ever since I was a kid. Whilst pixel art is my specialty, I also do writing and design.
Tom: I’m Tom Coxon, and I’m the other 50% of Bytten Studio. Although ‘Studio’ is in our company’s name, we don’t actually have one! I’m Bytten Studio’s programmer and also do design.
I first started making games in my bedroom as a kid, using Delphi (I don’t know whether that still exists). I picked up this hobby again after finishing university, and then after a few years in a software engineering job, I decided to jump to the games industry. I went to work for an indie publisher for a while, and then left that to start Bytten Studio with Jay.
Can you tell us a bit about your game?
Jay: Cassette Beasts is an open-world monster collecting RPG. It is set on the mysterious island of New Wirral, where people transform into monster forms using cassette players to defend themselves. As the player explores this world in order to find a way home, they’ll make new friends, uncover lost secrets and do battle with beings that defy reality!
What were some of the biggest challenges you faced during the development process, and how did you overcome them?
Jay: On the art and creative side, figuring out how exactly we would be able to create the amount of content needed to realise the project was challenging! For a game about collecting monster forms, we needed a lot of monster designs, and for them to look good. On top of that, figuring out how the game’s “Fusion system” would work was also pretty daunting! A lot of work went into it ultimately, but I’m very proud of how it turned out!
Tom: The biggest and most consistent technical challenge we’ve faced is getting performance to where we need it for smooth gameplay. That’s not unique to Godot though - and in fact Godot being open source gives us ways to address this that other engines don’t.
Engine code is often optimised to be fast enough in the most common cases, at the expense of poor performance in highly specific cases. Cassette Beasts actually hit several of those poor-performance cases in Godot, and I had to patch engine code in a few places to claw back a few frames. However, I think that this is a strength of Godot. No code can be perfectly optimised for every case. Optimising for better general performance in the most common cases, while allowing game developers to customise the engine for weird cases, is exactly what engine developers should be doing.
How did you discover Godot? What made you pick it for your project?
Tom: I don’t remember how I discovered it, but I’m a long-time Linux user, so it was probably through r/linux_gaming!
We tried out a few engines before settling on Godot for Cassette Beasts. High up on our list of priorities was workflow efficiency. We wanted Cassette Beasts to feel dense with content, and that requires good tooling. After making a few prototype projects and editor plugins with Godot I was convinced.
I do think Godot is how Bytten Studio, as a two-man team, was able to build an open world RPG with 30+ hours of content in it.
What do you like about Godot?
Tom: I like lots of things about Godot! As I’ve already mentioned, I like that we get total control of the source code.
But a massively undersold advantage Godot has over other engines, in my opinion, is its scripting language, GDScript. Unity devs using C# jump through tons of hoops just to avoid garbage collection, whilst the reference counting and manual memory management options that GDScript has built-in completely side-step it. GDScript isn’t perfect, but I do feel like developers who come to Godot and continue using C# (outside of performance-critical code) are missing out.
What do you dislike about Godot?
Tom: I would like it if stability was a higher priority in the engine. There are a number of crashes that were reported over a year ago that still aren’t fixed. For example, it seems like certain things in the engine that should have thread-safety (like resource loading and audio) just aren’t thread-safe, and I had to apply fixes and workarounds on our end.
Obviously, I’ll submit pull requests for whatever I can when I get time, because that’s how open source software works - and I expect the situation will naturally improve over time as larger and larger projects are built in Godot. But I’d still like to see a bigger effort by the project’s leadership to bring down the number of serious bugs.
What advice would you give to aspiring game developers who are just starting out in the field?
Jay: Just make stuff! A lot of online discussion around “getting started in game dev” focuses so much on “what engine to use” or “what genres are popular” when I think the best approach is to simply start making things and not worry about the other stuff. You don’t have to come out of the gate with a professional commercial project (and, in fact, this rarely happens) but the only real way to learn how to make stuff is to start doing it. It’s easier than ever to jump into game development as a hobby -
Tom: I’ll give some different advice! It’s an unavoidable truth about the games industry that who you know matters just as much as what you can do. If what you want to do is work on your own indie projects full-time, my advice would be to first spend a few years at other companies building connections, or to partner with someone who is already connected. Good connections can provide opportunities you wouldn’t otherwise get, as well as keep you from making mistakes they’ve already made!
Did you find any issues when looking for a publisher? How is it like working with Raw Fury?
Jay: We revealed our game before we had a publisher in order to try and attract one, which was a risky move but ultimately ended up working! One challenge we faced was, I think, the perception that turn-based RPGs are “outdated” games and not in line with the genres that are more commonly seen in the indie game space (such as rogue-likes, town sims, deck building games etc.) but we were pretty insistent that the “monster-collecting RPG” genre was a popular one with fans that would support games in it. We were super happy to get to partner with Raw Fury, and they’ve understood our goals and aspirations with the game from the very start. Considering that they also published Dome Keeper, I’d say they’ve already developed a good track record of publishing and supporting Godot games!
Tom: We love working with Raw Fury!
How was the experience of porting Cassette Beast to consoles?
Tom: We knew from the start that porting to consoles would be a challenge with Godot. The situation seems like it’s starting to improve now that the various closed ports of Godot 3.x are maturing, and Godot 4.0 has arrived.
We partnered with Pineapple Works to bring Cassette Beasts to Switch and Xbox–and you’ll soon be able to see the results of their efforts on Switch and Xbox! I would encourage any indie who wants to bring their Godot project to Switch/Xbox to have a chat with the folks at Pineapple Works.
I can’t go into the details of what it’s like to port to consoles unfortunately. But here’s some general advice for game development:
Before committing to working with a third party, make sure each parties’ schedule is aligned, and that budgets are happy.
Don’t announce any release dates until the final builds are locked in, because the unexpected can and does happen!
Finally, what do you hope players will take away from your game, and how do you see it contributing to the broader gaming landscape?
Jay: The “monster-collecting RPG” space is one with some big franchises in it that cast a long shadow, but we want to prove that there’s room for new and original games in it that can stand on their own! We also hope to show off the potential of what a very small development team can do with Godot.
Tom: Hopefully developers who see our game will see that Godot is ready for more than just small projects! I also hope developers see that you can mix fantasy, comedy, horror, and genuine heartwarming moments, AND wrap it all up in whimsy and mystery, without it coming across as indecision. Because I’m bored of playing monotone games. And because if I’m wrong then Cassette Beasts probably won’t do very well. 🙂
Cassette Beast is available on Steam for Windows, Linux and Steam Deck. You can join their Discord server here.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-cheeseness-hive-time/index.html b/article/godot-showcase-cheeseness-hive-time/index.html
index 671f97333e..8aca684b5b 100644
--- a/article/godot-showcase-cheeseness-hive-time/index.html
+++ b/article/godot-showcase-cheeseness-hive-time/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio18 February 2021
My name is Cheese, and I’m an Australian independent game developer/Linux porter/freelance generalist based in the small island of Tasmania. I’ve been making games in some form or another for over thirty years now.
I like to contribute to Free/Open Source Software projects when I have time, and release my own work under F/OSS and open culture licences when appropriate. I’ve even made some small contributions to Godot itself. I enjoy photography, playing guitar, and long, long walks in the wilderness.
Introduce your project in a few sentences: description, supported platforms, release date, etc.
Hive Time is a bee-themed management sim, which invites players to construct a generational bee hive and manage its population’s diversity. It’s cute, silly, and has a big heart.
I released Hive Time for Linux, Mac, and Windows on the 12th of Beecember 2019, and shipped a large update coinciding with World Bee Day on the 20th of May 2020.
Hive Time is $10, but in the interests of making sure it’s still accessible to people who aren’t able to afford that and to explore the dynamics of pay-what-you-want models, I decided to release it with a minimum price of $0.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?
I first came across Godot when backing The Interactive Adventures of Dog Mendonça & Pizzaboy on Kickstarter back in 2014, but I think the first project I used the engine for was a prototype for Super Happy Fun Sun developed as part of a game jam in 2015.
Over the years, I’ve worked on projects that have used GoldSrc (Half- Life 1’s engine), Serious Engine, Unity, SLUDGE, Adventure Game Studio, jMonkeyEngine, Blender Game Engine, and SCUMM/Remonkeyed Engine. I’ve also worked on games that have been built from scratch or use frameworks rather than general purpose engines like SDL, SFML, and Allegro.
For the past six years, I’ve been writing my own game engine called Icicle, which is written in C/C++, using SDL and OpenGL.
Why did you choose Godot for your project?
I’d previously attempted to make a 3D game in Godot in 2015 (it would have been a third person plafomer about a ladybug), but my initial experiments before the jam I was planning to use it for weren’t yielding the kind of results I was after.
The next time I had the opportunity to try again, Godot had come a long way, and I was able to develop the initial Hive Time prototype during a 10 day game jam.
Which parts of the game development process did you enjoy the most while working on your project?
For me, the most enjoyable part of both making and playing Hive Time is sitting back and watching my little bees bumble arund and go about their business.
I also loved going out to local honey farms to record bees, and it was wonderful to see/hear Peter’s work on the soundtrack breathe extra life into the game.
Which parts of the game development process did you find the most difficult to apply in your project?
Broadly speaking though, the game came together with very few signficant design or production hurdles. I worked hard to lean on my existing development and project management experience and keep the game’s development timeframes tight and overheads small.
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
I felt like Godot enabled me to pull the core game together very quickly. The most attractive parts of the engine for me come from its nature as a Free/Open Source Software project and the ability that gives me to debug, fix, or modify the engine to suit my personal needs.
I also feel more comfortable using free and Free tools because I can be confident that if others want to follow in my footsteps, financial or philosophical hurdles won’t prevent them from doing so.
How do you find Godot’s multi-platform support, both for the editor and your final project?
I pretty much exclusively developed Hive Time on Linux, so I didn’t have much opportunity to expose myself to the editor tools’ multi-platform support.
I’m glad that Godot allows me to deploy builds for all my supported platforms from my Linux build server without having to involve other operating systems or set up cross-compiling pipelines.
Which challenges have you encountered when using Godot?
I’ve struggled a little with performance optimisation, and the now-addressed dangling variants bug likely caused the majority of unidentifiable problems that had been reported in the wild.
Unclear or incomplete documentation has been a long time friction point for me. Things have definitely improved on that front over the years, though there’s always room for improvement. These kinds of hurdles are rarely significant and the option to fall back on reading engine code is always there, but cumulatively, these can add up to be a reasonable time sink across a large project.
Which features would you like to see in future versions of Godot?
I’d love to see an option to treat underscores as punctuation for the purposes of text navigation. I run custom editor builds that already do this, but that applies to all string handling engine-wide rather than just the editor tools, so it’s been difficult to formulate that into a patch that I can contribute upstream.
Would you use Godot for a future project?
I plan to!
Hive Time is available on itch.io for Windows, macOS and Linux.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-fat-gem-primal-light/index.html b/article/godot-showcase-fat-gem-primal-light/index.html
index 72bddbe106..d7ac5aff14 100644
--- a/article/godot-showcase-fat-gem-primal-light/index.html
+++ b/article/godot-showcase-fat-gem-primal-light/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio4 March 2021
Welcome to the fourth developer interview following the introduction of the Godot Showcase page! This week, we are interviewing the studio Fat Gem about their first game Primal Light.
Introduce your studio in a few sentences.
Hi, I’m Shane Sicienski. My friend Jeff Nixon and I make games together under the name Fat Gem.
Introduce your project in a few sentences: description, supported platforms, release date, etc.
Primal Light is a linear 2D action platformer for Windows, Mac, and Linux. It was released on July 09, 2020 and is available on Steam.
In the game, you play as Krog, a one-eyed blue caveman wearing a red loincloth, who is on a quest to save his tribe from an evil moon god.
The game features 10 challenging levels with arcade-style combat reminiscent of the 16-bit era. As you progress, you acquire new acrobatic abilities which allow you to overcome obstacles and enemies. Each level ends with a gruesome boss.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?
Around 4 years ago, I was learning how to program (in order to do natural language processing) when it suddenly dawned on me that I had probably learned enough to be able to make a game. I prototyped a little top-down Zelda clone and showed it to my friend Jeff one night while we were hanging out at his apartment. We were so excited by the prospect of making a game that he dove headfirst into pixel art and I into programming. That was around August 2017.
We started making Primal Light in Python (using the PyGame module), but when we started getting serious about the project, we decided to shift to a full-fledged engine.
I had seen Godot come up in comments on Game Development Stack Exchange with people describing it as “Pythonic”, so it seemed like a natural candidate for me.
At that time, I didn’t have experience with any engines outside of PyGame, but since then I’ve become proficient in GMS2 and Unity, in addition to Godot.
Why did you choose Godot for your project?
When we were deliberating on moving to a full-fledged engine, I had seen Godot come up in comments on Game Development Stack Exchange with people describing it as “Pythonic”, so it seemed like a natural candidate for me. The fact that I am also a big fan of Samuel Beckett didn’t hurt Godot’s chances with me.
Which parts of the game development process did you enjoy the most while working on your project?
Jeff and I both enjoyed designing bosses and boss battles.
Which parts of the game development process did you find the most difficult to apply in your project?
Jeff and I were flying by the seat of our pants on this project, as it is our first game. We encountered difficulties all over the place, but our sheer excitement at making a game sustained us. We found level design intimidating at first, but, like lots of things, it becomes fun once you try to study it and learn its mysterious rules.
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
Godot has a ton of strengths. A few come to mind. First, Godot uses the pixel as the native unit of measurement, which makes it ideal for 2D games. Second, Godot has a much better implementation of coroutines than other engines (and coroutines are a game developer’s best friend). Third, Godot’s signal system provides an out-of-the-box implementation of the observer pattern that is more intuitive that what you have in other engines (for example, using C# events). Finally, Godot has better animation tools than other engines I have worked with.
How do you find Godot’s multi-platform support, both for the editor and your final project?
We developed Primal Light on both Windows & Mac and had no issues whatsoever, even on old hardware (I started development on a 2008 MacBook). We built for Windows, Mac, & Linux, and found it a breeze, even accommodating Steam integration across all three platforms using the life-saving GodotSteam repo. Godot’s option to toggle between GLES2 and GLES3 also makes it easy to build for specific rendering architectures if needed.
The only issues we encountered were some inconsistent capitalization in our filenames causing crashes on case-sensitive OSes, and using the same variable name in both a local and nested local context causing crashes on Mac (both easily fixed).
Which challenges have you encountered when using Godot?
We had some thorny issues with pixel jitter when our camera would settle on the player, but I think that’s a cross-engine problem which plagues pixel art games in general.
We tried to use Godot’s native Camera2D offset when implementing screenshake, but offset alone wouldn’t allow the viewport to traverse camera limits if the camera was adjacent to them. I filed that as a bug on GitHub and Godot devs fixed it in Godot 3.1 or thereabouts.
We originally had Light2Ds littered throughout the game (for example, for candle effects), but it caused severe performance issues. This was a known issue for Light2Ds back then. I think I heard that Godot devs recently made strides in improving their performance, but I’m not certain.
Which features would you like to see in future versions of Godot?
I think Godot has an excellent feature set as is, and I am typically a fan of minimalism. Some of the larger engines have bloat that irritates me aesthetically.
I know some people would like to see a sprite editor in the engine (similar to what you have in GMS2), but I never encountered a use case for that in my own development.
I recall a Twitter poll recently which asked Godot users what should be focused on in the near future. I voted for improvements to tilemap functionality, which was the frontrunner at least at that time.
Would you use Godot for a future project?
One hundred times yes!
Primal Light is available on Steam for Windows, macOS and Linux.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-garden-path-developer-talks-about-his-experience/index.html b/article/godot-showcase-garden-path-developer-talks-about-his-experience/index.html
index fee1938fd3..aa21377dd0 100644
--- a/article/godot-showcase-garden-path-developer-talks-about-his-experience/index.html
+++ b/article/godot-showcase-garden-path-developer-talks-about-his-experience/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio22 July 2021
Hi, I’m Louis Durrant, and I make games under ‘carrotcake’. I’m an illustrator living in Bristol, UK. The studio was me in my parent’s attic to start off, but now it’s me in a home-office, so we’re making inroads.
Introduce your project in a few sentences: description, supported platforms, release date, etc.
‘The Garden Path’ is really just the relaxed, whimsical social-sim I’ve always wanted on PC. Something slow-spaced that you can put on a podcast alongside, or just soak in the atmosphere - you know?
I want to keep things fairly low-key, as this is my first real release. I’m hoping to release the game this autumn or winter, but I’m not rushing myself. I’ll be supporting the game with more content after it’s released, but I want it to feel like a polished product worth the price tag on release day.
It will be a PC game at heart, but it is built from the ground up with a controller in mind. When the time is right, I think it would be an ideal game for the Nintendo Switch.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?
I lurk around a number of forums for open source software and Godot was always in the back of my mind.
I remember opening it up many years back and having no idea where to start.
I introduced myself to game development during my time at university studying graphic design. It was an artsy enough course that you could go ahead and do things like that. I started with Visionaire Studio because you can build something pretty substantial without any code, but it helped me understand the fundamentals.
After I graduated in 2017 I told myself I’d start learning code and start learning Godot.
Nowadays working in the engine feels right at home.
Why did you choose Godot for your project?
I’ve been an advocate for open source software since I can remember, so Godot just seemed like the right fit. It’s a good feeling knowing that my work isn’t under the thumb of any kind of restrictive licensing.
I also liked the idea of being an early adopter at the time. There was buzz around the engine, but it still needs those flagship titles that people can point to. And that’s really very important, because if people are asking ‘how was this made’ and the answer is something open source, that’s a big accomplishment.
Something for me to aspire toward, anyway.
Which parts of the game development process did you enjoy the most while working on your project?
As ever the joy of game development is bringing each puzzle piece together and seeing the final result. I love art, animation, soundtracking and programming, and those are all tools to capture a certain mood I’ll have in mind.
It’s when each of those elements comes together in the way you intended, or perhaps even in a way you hadn’t, and it’s like a toy springing to life with it’s own quirks and character.
Which parts of the game development process did you find the most difficult to apply in your project?
The raw maths. Not that there’s an awful lot with a game like mine, but it’s surprising how often you need a certain formula to return the number you’re after.
I spent most of my maths lessons watching crows out the window. I’m fortunate enough to have some pretty mathsy friends who I can ping my questions to. They’ll tell me ‘use modulo’ or ‘you want the absolute number for that’ and I learn something new.
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
I love how modular everything feels. Just in the last few months or so I’ve started to really appreciate how you can break everything down, and start building your own systems within the engine.
Once I started understanding how you can make your own objects and resources, you can really start creating flexible methods tailored to your own game.
Which challenges have you encountered when using Godot?
Godot is still young, which is part of its appeal, but there isn’t always an easy solution for certain complex things you don’t necessarily need. The community is great and it’s growing, but it isn’t as big as more established engines, so the answers aren’t always out there when you go looking.
I spent longer than I care to admit trying to get a white outline drawn over multiple sprites, but couldn’t for the life of me get it to work. Something to do with a BackBufferCopy node, I got that far.
Which features would you like to see in future versions of Godot?
Honestly I feel spoiled by the engine already, so I’d feel cheeky asking for much more. Directional shadows for 2D are already on the roadmap I believe, and that would be a big step up for my game’s visuals.
And hey, being able to adjust easing in the AnimationPlayer of multiple properties would be mint.
Hat’s off to everyone working on the engine, I wish I had an ounce of the mental wherewithal to build or contribute to a project like this. Keep up the great work, and keep keeping it real.
Would you use Godot for a future project?
In a heartbeat.
The Garden Path is expected to be released in Autumn/Winter 2021. It currently has an ongoing Kickstarter campaign at the time of publishing this interview.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-john-watson-gravity-ace/index.html b/article/godot-showcase-john-watson-gravity-ace/index.html
index 3a59da1bfc..933b3e67dd 100644
--- a/article/godot-showcase-john-watson-gravity-ace/index.html
+++ b/article/godot-showcase-john-watson-gravity-ace/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio18 April 2021
Hi, I’m John, I’m a (mostly) solo game developer making games that I want to play. I’ve been making games as a hobby since 2013, mostly by participating in weekend or month-long game jams. My first game was for the One Game A Month challenge. Now I’m working on my first commercial project. My formal training is in programming but I’ve always been interested in art and music as well. Game development is fantastic because it allows me to bring all of that together into a single project.
Introduce your project in a few sentences: description, supported platforms, release date, etc.
Gravity Ace is a 2D multi-directional gravity shooter (cave-flyer). It’s a love letter to Thrust and Gravitar and all of the amazing games they inspired. Remember Thrust? Most people don’t but I loved that game and I really wanted to play it again. Gravity Ace is inspired by Thrust but adds a lot of modern touches and generally brings the art, sound, and gameplay up to modern standards. It’s currently in Early Access with an expected release date in 2021. Linux and Windows. You can wishlist or buy it on Steam or itch.io.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? Why did you choose Godot for your project?
I’ve made games in a bunch of different engines and frameworks and languages over the years. Haxe, Lua, JavaScript, Java. Those experiences were great but they all fell a bit short in terms of ease of use or features or productivity. I think I discovered Godot not long after the project was open sourced. At the time I was looking for an engine with a built-in visual editor because I was tired of moving things around by typing coordinates in code. I needed something to speed up my workflow and make it less cumbersome to quickly prototype ideas.
Of course I tried Unreal and Unity but as a full-time Linux user I was unsatisfied with their lack of official support. And those engines felt just so… massive. I chose Godot for a lot of reasons. It’s small, fast, and has first-class support for Linux. It has all the features I need for the games I want to make. It’s open source with great leadership and community. And I think it has a bright future.
Which parts of the game development process did you enjoy the most while working on your project?
One of the reasons I like making games is because it allows me to combine several of my interests into one project. I enjoy programming. But I also enjoy making art and music. So I tend to bounce around between those things. That’s one of the benefits of working on a game solo. I get to do everything. (That’s also one of the drawbacks of working on a game solo.) So if I get tired of programming I can switch to animation or sound or music. It keeps things interesting.
Which parts of the game development process did you find the most difficult to apply in your project?
I mean… My mind went immediately to the cliché answers to this question but really, when I think about it deeply, I can’t think of anything about game development that is easy. It’s all difficult and it’s hard to pick one thing. Yesterday I was working on a bug that is caused by some combination of timers and bad math that I still haven’t solved yet. I’ve thrown away more art than is in the actual game.
Game development is hard, right? It’s not the engine or the programming or anything like that… it’s the process. Designing things, thinking deeply about how things should work, making interesting artwork, it’s all hard. But it’s the kind of struggle that’s fun to do if you have a certain kind of personality. Like, I guess there are people who climb mountains? For fun? That’s not easy and it’s certainly not me but I get it. Would I make games if it was easy? Probably. Maybe. But it’s hard to imagine.
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
I think without Godot I’d be much farther behind where I am now. Godot just works in a way that meshes with how I like to think and work. I’d be much less productive for sure.
The 2D workflow is pretty great. Just drop some images in and drag them onto the canvas, attach a script, write a few lines of GDScript and you’ve got the beginning of a game. Modifying assets is seamless. And the node tree is super powerful. Reusing scenes in other scenes allows me to do a lot of stuff quickly and visually that would have been much more cumbersome in other frameworks.
How do you find Godot’s multi-platform support, both for the editor and your final project?
This is a huge selling point for me. Being able to build for multiple platforms from a single code base and all from a single machine is amazing. The fact that all of my builds finish in under a minute is icing on the cake.
Which challenges have you encountered when using Godot?
Nothing out of the ordinary really. Every engine I’ve ever used has a few warts and bugs that you have to work around.
Which features would you like to see in future versions of Godot?
Nice thing about an open source project is that you can see all of the open issues and the developers are very open about what they are working on. So I know better 3D support is coming, which I’m very excited about. I’m pretty happy with the 2D support as-is. New features are great but I’d almost like to see the devs focus on stability, performance, and improving the features that we already have rather than continue to work on new stuff. I’d love to be able to edit shaders in the main code editor instead of a dock. I’d also like to see better and more stable support for 2D lights.
Would you use Godot for a future project?
Yes, absolutely. In fact, I already am.
Gravity Ace is available on Steam and Itch.io for Windows and Linux. You can also follow its development on Twitter.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-justin-arnold-rpg-in-a-box/index.html b/article/godot-showcase-justin-arnold-rpg-in-a-box/index.html
index ee70315504..a9e87b3882 100644
--- a/article/godot-showcase-justin-arnold-rpg-in-a-box/index.html
+++ b/article/godot-showcase-justin-arnold-rpg-in-a-box/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio12 January 2022
Welcome to a new Godot showcase developer interview to start off the new year! This time, we asked Justin Arnold about his experience developing and releasing his project RPG in a Box. This “engine within an engine” demonstrates that Godot is not only capable for game development, but also for creating applications with complex user interfaces.
Introduce yourself (or your studio) in a few sentences.
Hello! My name is Justin Arnold and I’m a solo developer working on RPG in a Box. I’ve always loved programming since my dad got me interested in learning BASIC on our C64 as a child. As I got older I developed a strong desire to build an RPG-focused tool that would allow others to easily create their own worlds and adventures. This idea has gone through several iterations over the past two decades and I’m excited to finally be bringing it to fruition through RPG in a Box!
Introduce your project in a few sentences: description, supported platforms, release date, etc.
RPG in a Box is an engine that lets you easily create 3D grid-based, voxel-style RPGs, adventure games, and more! I began developing it around the beginning of 2015. It was released into Early Access on August 12th, 2019 for Windows, Linux, and macOS. Games created with RPG in a Box can also be exported to these platforms. A free demo version is available on Steam and Itch.io if you’d like to check it out and get a feel for the current state of the engine! It includes all features found in the full version, with some limitations on map size/count and a splash screen on exported games.
I also have a Patreon for those who are interested in supporting the development of RPG in a Box beyond a purchase of the software.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?
I first heard about Godot from a Slashdot article when the engine had reached its 1.0 stable version. I started playing around with it shortly after (around the beginning of 2015) as it seemed to be a great fit for what I wanted to create. I had some prior experience with Xith3D and jMonkeyEngine (alongside various UI frameworks like Swing and Eclipse RCP) while working on RPG Toolset, the Java-based predecessor to RPG in a Box.
Why did you choose Godot for your project?
One of the primary aspects that drew me to try Godot was its built-in UI components, since it would allow me to easily build the various editors and interfaces that I needed while also supporting graphical elements like 3D viewports. The fact that it’s open source and supports multiple platforms, as well as how lightweight the engine is, are all attractive aspects that made the choice even more straightforward.
Which parts of the game development process did you enjoy the most while working on your project?
One of the most enjoyable and satisfying things has been getting to see the community bring their own game ideas to life through RPG in a Box. As programming has always been a passion of mine, coding new features and functionality into the tool and then seeing people use it to make something creative and imaginative is a wonderful part of the process!
Which parts of the game development process did you find the most difficult to apply in your project?
Being a solo developer, I’d say the most difficult part is testing new functionality and changes to ensure they won’t break something else, especially as the tool continues to grow.
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
Having access to a large variety of built-in UI components that work seamlessly with the rest of the engine has been extremely helpful. I love the flexibility of the scene system and GDScript, and how the API seems to pretty much always have the specific functionality I’m looking for.
How do you find Godot’s multi-platform support, both for the editor and your final project?
Great! It’s been simple and straightforward to compile the binaries and release the software for Windows, Linux, and MacOS. It’s also convenient since it allows RPG in a Box users to easily export their created games to multiple platforms as well.
Which challenges have you encountered when using Godot?
None that I can think of! Using Godot for my project has been a great experience overall.
Which features would you like to see in future versions of Godot?
Nothing in particular at this time. I believe I will be more than happy with everything that Godot 4.0 is bringing!
Would you use Godot for a future project?
I would definitely use Godot for any future projects! Of course, that’s if I ever get around to it, as I’m quite sure I have enough ideas for RPG in a Box to last a lifetime, haha. And as Godot just keeps getting better and better, there will be even more opportunities to expand RPG in a Box further, which is really exciting!
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-leocesar3d-human-diaspora/index.html b/article/godot-showcase-leocesar3d-human-diaspora/index.html
index 5e246d49e1..c123e2f5ca 100644
--- a/article/godot-showcase-leocesar3d-human-diaspora/index.html
+++ b/article/godot-showcase-leocesar3d-human-diaspora/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio11 March 2021
My name is Leonardo Veloso and I am a 3D artist working on TV broadcasting in Brazil, in my spare time I am a hobbyist game developer.
Introduce your project in a few sentences: description, supported platforms, release date, etc.
Human Diaspora is a First-Person Shooter where the player must conquer the colony planet to save humanity. It is available for Linux and Windows and I released it in September 2020. You can find it as Early Access in Steam.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?
I found Godot when I looked up for a FOSS alternative for Unity/Unreal and first used it in October 2019. I began making games with Game Maker 8, then switched to Unity to create my first 3D game and kept using it until I tried Godot. Now I use Godot as my only Game Engine tool.
Why did you choose Godot for your project?
Foremost, Godot is FOSS. It entails freedom to dispose of my game projects as I best see fit without worrying about the intricacies of software licenses. And while learning to use it, I realized it already had the necessary set of tools to pull out my game ideas. The node architecture with the concept of scene within scenes and the straightforward way of scripting with GDScript sealed the deal for me.
Which parts of the game development process did you enjoy the most while working on your project?
I just love to see my 3D models come to life inside the game engine, walk around, look at the details, and of course, generate interactivity for them is pure bliss and joy.
Which parts of the game development process did you find the most difficult to apply in your project?
I am probably not alone on this one: Game Design. Creating a fun game is second nature to some people, but for me, it is the most challenging aspect of game creation. What is fun for me maybe is bad design, not fun, or lacking for most of the players?
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
I love the iterative approach of Godot to test ideas as fast as possible: import a model, create a sub-scene for it with its associated specialized scripts, hit play and iterate over.
How do you find Godot’s multi-platform support, both for the editor and your final project?
In my case, it is just a button press away to see my game running on Linux/Windows/Mac.
Which challenges have you encountered when using Godot?
Debugging: some errors pop here and there, and it is really hard for me to trace its roots or if it is an engine bug. Sometimes their description is lackluster and confusing. I am staring at you shader compilation and parenting errors.
Which features would you like to see in future versions of Godot?
I want the “Make it look beautiful” button implemented. Jokes apart, as a 3D artist I want hassle free look and feel configuration of 3D scenes. The PBR approach associated with groundbreaking dynamic/static global illumination, environmental effects as volumetric lighting, realistic post-processing effects, and of course, everything working together in an optimized and performant manner. Specially when 4K monitors may become the norm in the near future.
Would you use Godot for a future project?
Of course, I’ll stick with it! I believe the game engine has a bright future and I want to be part of it. Showing off of what the tool is capable of and contributing to its growth through my own games, reporting and tutorials.
Human Diaspora is available on Steam for Windows and Linux. You can also follow its development on Twitter.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-little-red-dog-games/index.html b/article/godot-showcase-little-red-dog-games/index.html
index 7c434a2f52..17693fa638 100644
--- a/article/godot-showcase-little-red-dog-games/index.html
+++ b/article/godot-showcase-little-red-dog-games/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio15 December 2020
We’re Little Red Dog Games! We’re a commercial developer that has been developing deep strategy games with despotic roosters and snarky surveyor probes for almost a decade now.
We’d love to show off Rogue State Revolution, which will be debuting for Windows and Linux in late February 2021. As President of the People’s Republic of Basenji, you must appoint ministers and make sure they stay loyal. Build roads, factories, nuclear power plants and more, if you can afford it. Anything can happen: meteor strike, a pandemic, a cane-toad infestation, a robot apocalypse… if you can imagine it, there’s a good chance that it’s hiding somewhere in this game, waiting to be discovered. Your role is to care for your society, but a growing rebellion threatens to remove you from power. The game has lots of FMV, beautiful 3D visuals and represents a huge creative effort over the past two years. You can check it out on Steam.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?
We’ve worked with other engines and frameworks before, but we stumbled upon Godot while actively looking for new game engines to try out with strong Linux support in 2015. We started with version 2-point-something and have delighted to see the engine grow and mature at the same pace as our own ambitions.
We published two games with Godot already, Deep Sixed in 2018 and Precipice in 2019.
Why did you choose Godot for your project?
Well, we’ve been using Godot for years and have grown very familiar with every little nook and cranny of the engine. Whenever the topic of switching comes up, we look around and it’s clear that this free, open-source, incredibly versatile engine meets all our needs and we can’t think of a good reason why we would need to. The node and scene architecture lets us design our games based on what we think makes sense for development, rather than forcing us into how an engine would want us to structure things.
Which parts of the game development process did you enjoy the most while working on your project?
I think most of us agree that the most fun is in the early stages when you’re fleshing out the design basis, building the foundations and implementing the basic structure of the game code. This is the time that every little addition feels like a big step and the progress is measured in miles rather than inches. It’s easy to see why people love to write tutorials and conceptual-proofs, it’s so rewarding!
Which parts of the game development process did you find the most difficult to apply in your project?
We’ve struggled a little with harmonizing the asset importation pipelines between Blender, Maya and other 3D tools software, and developing games with very large object counts has made optimizing for speed quite a challenge (though admittedly, that would also be a challenge regardless of what engine we were developing in).
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
We love how Godot’s scene structure emphasizes getting things done quickly and flexibly. Writing editor plugins and custom nodes is very useful, and if there is ever something that we want to tackle that it’s in the main branch, there is nothing stopping us from cracking the thing open and building our own solutions to whatever problems we might encounter.
How do you find Godot’s multi-platform support, both for the editor and your final project?
The platforms that Godot supports by default all work very well, especially the desktop platforms, where it shines. We’ve got a console partnership that we’ll be excited to reveal soon that has gone very smoothly. We have very little experience with mobile or HTML5 development.
Which challenges have you encountered when using Godot?
Importing 3D assets and animations can sometimes be a pain. Even though the compatibility with various formats has improved lately, we’re still running into issues with UV maps or shape keys from time to time, which are typically resolved by trying different file formats until one of them does the job in the matter intended. We have also encountered difficult-to-trace crashes in our exports that are exceedingly difficult to debug because they are not captured in the release build.
Which features would you like to see in future versions of Godot?
There’s a short-list of GDScript optimizations we’re looking forward to and improvements to the asset importation pipeline is welcome. Can we bring back particle attractors? Oh, and the themes system could use a bit of a restructuring. Like everybody else, we’re extremely excited about what is coming with Godot 4.0 and the road is now paved for us to pursue some really beautiful 3D products in the future.
Would you use Godot for a future project?
You can count on it and we have already broken ground on the next big thing in Godot. In our opinion, there are no perfect engines, just preferred tools for certain kinds of jobs. For us, Godot has always been our preferred tool for the kinds of games we like to develop.
Rogue State Revolution can be wishlisted on Steam and will be available on Windows and Linux.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-monolith-of-minds-resolutiion/index.html b/article/godot-showcase-monolith-of-minds-resolutiion/index.html
index bd3d21a39b..7c3c8e17e5 100644
--- a/article/godot-showcase-monolith-of-minds-resolutiion/index.html
+++ b/article/godot-showcase-monolith-of-minds-resolutiion/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio19 January 2021
Five years in development, Resolutiion tells the story of the soldier Valor and his AI Alibii’s journey through a 2D dreamworld of lovely pixels, dirty jokes and badassemotional tunes, inspired by classic Zelda and similar action-adventure-games.
How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?
We love to rummage in the software world, digging up tools that help us tell our stories better. While we explored some more or less popular engines earlier, we love Free and Open Source Software, so naturally we came across Godot and fell in love with it right from the start.
Why did you choose Godot for your project?
Developing with Godot is very easy. The core functionality can be picked up quickly and the engine is powerful enough to accomplish everything we were looking for in our game. Also the community is awesome and creates plenty of valuable tutorials and guides.
Which parts of the game development process did you enjoy the most while working on your project?
Since we had no previous experience in game-development, learning everything from scratch was the biggest challenge but also the greatest pleasure. Seeing all those tiny splashes of color coming together into forming a full picture certainly was an amazing experience.
Which parts of the game development process did you find the most difficult to apply in your project?
I guess we struggled quite a bit with animation and cut-scenes: these things always seem so simple in your mind, but turn out to be an endless sequence of tiny steps, each one just leading into more uncertainty.
While Godot’s animation editor hits a sweet-spot between accessibility and complexity, we tried to cut corners every time a new scene emerged. After blaming each other for the shitty job, eventually we took a deep breath and put in the handiwork every decent cut-scene demanded.
How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength?
We have a fable for Python, therefore can appreciate GDScript a lot. For an iterating workflow the scene-system and its flexibility is a master piece in software design.
How do you find Godot’s multi-platform support, both for the editor and your final project?
Having such a full fetched editor run on Linux was probably a big selling point for us when we started. Also being able to export to all PC platforms, iOS and Android is definitely one of Godot’s strengths.
Which challenges have you encountered when using Godot?
None, haha.
Which features would you like to see in future versions of Godot?
Porting the game to the Nintendo Switch worked out fine, since we had Lone Wolf Technology to back us up. However, so far we haven’t found a way to get the game running on any of the other big consoles, such as PlayStation and Xbox. Better console integration is definitely something we are looking forward to.
Would you use Godot for a future project?
Definitely, yes. Godot’s open source philosophy, fast development cycle and indie-friendly community make it an obvious choice for us. We have already started work on our second video game, and hope to share some first glimpses in early 2021.
-
+
\ No newline at end of file
diff --git a/article/godot-showcase-usagi-shima/index.html b/article/godot-showcase-usagi-shima/index.html
index 985483b159..db4d504cd5 100644
--- a/article/godot-showcase-usagi-shima/index.html
+++ b/article/godot-showcase-usagi-shima/index.html
@@ -6,7 +6,7 @@
All-in-all, mobile is definitely a different beast compared to releasing a PC game on Steam!
Finally, what do you hope players will take away from your game, and how do you see it contributing to the broader gaming landscape?
I hope mobile games make a comeback as a reputable platform for gaming, and that one day it could also be a place where indies can shine. I really like mobile as a platform because it opens up new and different genres by virtue of having a device that is constantly in your pocket. It’s a platform that accompanies players throughout their days, unlike a console or PC. Not only that, it’s massively accessible too - while not everybody has a PS5 or Switch, nearly everybody has access to a smartphone these days.
Admittedly, mobile games are not as common a target platform for indie game developers compared to PC and console. Mobile games have earned a negative reputation because of how aggressively they are usually monetized (e.g. microtransactions), and because of how the mobile market is unfortunately plagued with poor quality apps, shovelware, and clones. I hope to one day contribute to the idea that mobile can be a viable platform for indie developers to thrive too!
-
+
\ No newline at end of file
diff --git a/article/godot-slides-gamified-slideshows-with-godot/index.html b/article/godot-slides-gamified-slideshows-with-godot/index.html
index 80376c35a7..ca8cfc08dc 100644
--- a/article/godot-slides-gamified-slideshows-with-godot/index.html
+++ b/article/godot-slides-gamified-slideshows-with-godot/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest5 October 2018
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.
Last year, I was invited to present Godot 3 at a few venues in France:
Making good presentations takes a lot of time, and I felt fellow teachers and in the community could reuse this one.
As Godot has an international community, we would need to translate the slides and to use a technology that would allow us to improve it over time. Traditional slideshow programs are not designed for that, so they were out of the question.
It turns out there’s a mature technology that would allow us to create many translations with ease, to showcase interactive game demos, and lot more than that: the Godot engine itself. That is how Godot Slides was born.
Long story short, the first version was tricky to use. Although it was available in seven languages, the presentation was a little too long and technical. But some of you used it all around the globe, showing there was a need for it. So…
Better, Faster, Stronger: Godot Slides 2.0
Slides 2.0 is a complete makeover of the slideshow system: it is now entirely drag-and-drop, it’s modular and extensible, it uses Godot’s built-in translation system, the engine’s UI system, and it’s easier than ever to insert game demos inside of your slides!
You can even change the language in real time if, like me, you have to give it into two languages at the same time.
Godot Power pitch: a 10 minutes intro to the engine
Slides ships with a 10 minutes introduction to Godot, a few of its flagship features, and information on how to get started with the engine:
It’s a short talk you can give at gamedev meetups, or for longer presentations, to get everyone on the same page before showcasing the editor for instance. The Power Pitch is still a little technical, with a few slides targeted at developers. But as it’s short, it should not be too dull either.
New languages and better pictures: we need your help!
At the time of writing, the presentation is already available in English, French, Japanese (written by me, so it needs proofing), and Spanish thanks to Antonio Torres Moríñigo.
Here’s a video guide to contribute a new language:
Even if you’re not familiar with Git, but you would still like to do translations, you can still contribute as explained in the tutorial, be part of the project history, and appear in the contributors’ tab!
Please help us translate it into new languages! It will help people in your community cover the engine in their native language. This contribution will count towards your Hacktoberfest progress as well.
We’re also looking for beautiful pictures of the editor with professional grade assets, to not only showcase some of the latest features in Godot 3.1 but to hopefully impress people.
-
+
\ No newline at end of file
diff --git a/article/godot-sprint-and-user-meeting-barcelona-june-2022/index.html b/article/godot-sprint-and-user-meeting-barcelona-june-2022/index.html
index 1a7a490bdf..13257b9f3a 100644
--- a/article/godot-sprint-and-user-meeting-barcelona-june-2022/index.html
+++ b/article/godot-sprint-and-user-meeting-barcelona-june-2022/index.html
@@ -7,7 +7,7 @@
08014 Barcelona
Car restrictions
If you plan to come by car, be aware that the city of Barcelona has specific restrictions to limit traffic, more info here.
-
+
\ No newline at end of file
diff --git a/article/godot-web-export-progress-report-4/index.html b/article/godot-web-export-progress-report-4/index.html
index 27cdcf2d21..305820c1a4 100644
--- a/article/godot-web-export-progress-report-4/index.html
+++ b/article/godot-web-export-progress-report-4/index.html
@@ -9,7 +9,7 @@
In an effort to improve the current situation, we plan to create a small addon that allows to remap the gamepad on the fly that you can bundle in your game, or send your generated mappings to us (so we can bundle them in future Godot versions). While this won’t solve all the problems until the specification is improved and browser support gets better, it should allow for many more controller to work out of the box across different platforms.
I’ve recently proposed a better way than eval to communicate with JavaScript, and that will need a tentative implementation.
-
+
\ No newline at end of file
diff --git a/article/godot-web-progress-report-2/index.html b/article/godot-web-progress-report-2/index.html
index 00699b416c..20ddb0badf 100644
--- a/article/godot-web-progress-report-2/index.html
+++ b/article/godot-web-progress-report-2/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli28 August 2020
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.
Howdy Godotters! It’s time for a long overdue update on the status of the HTML5 export and the web version of Godot in general.
Many of the improvements made for the Web editor’s early prototype have been merged in the master branch and backported to the 3.2 branch. Support for SceneTree.quit() and drag and drop of files via the files_dropped signal are already in the upcoming 3.2.3 release.
The HTML5 export is also getting further improvements in the upcoming point releases:
Support for low processor usage mode, and FPS limiting (via Engine.target_fps). This is especially useful for non-game apps.
Better control over the audio buffer size, to allow customizing the trade-off between audio delay and glitches on low-end devices (via the audio/output_latency and audio/mix_rate options in project settings and their overrides).
Link time optimization (LTO) for exported games (smaller size, shorter load).
Along with these changes, I’ve been working to bring virtual keyboard support for the HTML5 export on mobile browsers. But this deserves a chapter of its own.
Virtual Keyboards support
Sadly, web technologies do not allow us to directly show virtual keyboards on mobile devices. Like most of the time, when it comes to the web, one must (sigh) rely on hacks.
To force the browser to show the keyboard, we need to rely on a hidden <input> (or <textarea> for multiline) HTML element. Additionally, we cannot detect keypresses, due to autocomplete, and the only reliable way to update the content of GUI elements is by listening for changes in the input or textarea element, which makes it very inefficient and “clunky” for long texts. Still, it should allow your users to put their name in the leaderboard ;-). This work is still not merged to master and will receive some further improvements.
There is no update to the prototype Web editor yet, but stay tuned for more as GDNative support is coming to web and that’s a matter for the next blog post.
-
+
\ No newline at end of file
diff --git a/article/godot-web-progress-report-3/index.html b/article/godot-web-progress-report-3/index.html
index ab7cab0572..e21512c154 100644
--- a/article/godot-web-progress-report-3/index.html
+++ b/article/godot-web-progress-report-3/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli27 October 2020
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.
Howdy Godotters! It’s-a me! Fabio! It is time for an update on the Godot export for the Web.
In the last few months, a lot has been going on regarding the Godot export for the Web. Most of the enhancements mentioned in the previous report have now been merged into the master branch, and backported to 3.2 (included in 3.2.4 beta 1).
This sadly does not yet include the virtual keyboard support, since implementing it without impacting the experience on touchscreen-enabled devices that also have a physical keyboard has proven harder than expected.
There is great news, though, on the other topic mentioned in that report, which is… GDNative support on HTML5 exports!
Additionally, a new prototype version of the Godot Web Editor is now available for you to try out.
Change includes a lot of stability and usability improvements, the ability to download the project sources via a dedicated button under the Project > Tools menu and various performance optimizations.
All this work, as mentioned in the initial report, also resulted in various improvements to games exported for the Web including a much more reliable user file system for saving persistent game data on the end user browser (user://) and more work on audio processing.
Getting closer to GDNative support on the Web
GDNative is the C language interface to Godot Engine that allows integrating third-party libraries without recompiling the engine. It is also used to write bindings that allow game developers to write game logic in the programming language of their choice (e.g. Python, Rust, etc.).
It could also be a good way, in the future, to further reduce the offical templates binary size by moving some of the features to offical modules, letting game developers choose which features of the engine they want, and only export those (without recompiling the engine like you can already do).
For this to work though, GDNative has to run on all platforms! The trouble here is that GDNative relies on dynamic linking, which (oversimplifying) means opening a program-like file and running functions contained in that file from another program (apologies to the tech people that will skip a heartbeat reading this description). Now this could seem to be an easy task for a human but not for a computer, since it has both compatibility and security ramifications. On the topic of compatibility specifically, linking is not mentioned in the WebAssembly standard, so build tools started creating their own convention.
The good news is that after a huge refactor of the Godot code to play nice with the build toolchain, we are very close to getting GDNative support in the Web exports. If you read all this, and you want to try it out, well, I’m sorry, but you’ll have to wait a little bit more, since the code is not merged yet, but we are very close.
Future work
We plan to soon have a faster release cycle for the web editor, possibly tied to Godot point releases, and to focus on usability and bugfixing, so it can enter a stable status soon.
GDNative support is really close to coming to the Web, and its inclusion will likely be the topic of the next blog post.
Virtual keyboard support, which has been so long delayed, should also come after GDNative support, along with a lot of bug fixes that have piled up while refactoring the JavaScript code handling browser-related functionalities.
-
+
\ No newline at end of file
diff --git a/article/godot-web-progress-report-5/index.html b/article/godot-web-progress-report-5/index.html
index 892d773e2d..8631ee9300 100644
--- a/article/godot-web-progress-report-5/index.html
+++ b/article/godot-web-progress-report-5/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli4 February 2021
This article is from February 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.
Howdy Godotters! Time for another brief update on the HTML5 export for Godot.
Web Editor
First of all, the Web Editor reached release candidate state, and now has a dedicated address where you can also browse previous releases. There are still few issues (#44754, 44755) we are ironing out, but it should be gold by the end of the month.
Gamepad API
During December, realizing how poor gamepad support was on the web, I spent some time fiddling around with the HTML5 Gamepad API trying to improve the situation. The standard itself is sadly incomplete (see w3c/gamepad#7 and w3c/gamepad#9) making remapping of controllers hard guesswork.
Important: When talking about mapping in this post, I’m not referring to your game action mapping, but making sure that pressing the button labelled “A” in your Xbox controller is correctly recognized by Godot as JOY_XBOX_A (i.e. JOY_BUTTON_0, i.e. JOY_SONY_X, i.e. the button labelled “X” in your DualShock controller).
First of all, gamepads cannot be detected on the Web until a button is pressed on them. Then, the controller is either remapped to a standard mapping by the browser, or its raw inputs are used.
Normally, Godot and other software would remap raw inputs using a database of known controllers and detecting them based on information passed by the operating system like the device vendor and product ID, and its “connection type” (bus information). As mentioned above, those information are not always available using the Web Gamepad API, but can sometimes be obtained via guesswork.
The main issues are:
The gamepad.id does not always contain vendor and product ID, additionally its format differs across browsers. Bus informations are not available.
The same product/vendor IDs results in different raw inputs on different operating systems.
Some [browsers,OS,gamepad] combinations produce inputs or mappings outside of the specification (e.g. axis values outside the [-1,1] range, or gamepad.mapping set to standard but not actually following the standard specification).
In case you are wondering: yes! This is quite a mess! As you can also see from browsers issue trackers about the subject (Firefox, Chromium, Safari/WebKit).
But nevertheless, we can do something to better our gamepad support on the Web for many devices. To do this, we need to guess the operating system the browser is running on, then try to read informations about vendor and product from the gamepad.id string, and finally provide mapping informations for that gamepad on that OS. Of course, none of this is necessary in the (rare for now) cases where the browser already remaps the gamepad following the standard.
A simple UI is being added to the joypads demo that allows to easily generate a controller mapping for a new device. That UI was used to generate mapping for all controllers I could come across on Linux/Windows/macOS after bothering friends and family during the holidays. This includes most (all?) official Xbox controlers (wired), and two compatibles I had lying around.
You can check if your device is mapped correctly on the web here, and try to remap it in case it’s not (reporting your fixed mapping in #45078).
Please note: If the controller is detected as standard but it’s not correctly mapped or if moving any axis shows a value outside the range [-1,1], it’s probably a browser bug and we can’t do much about it (probably worth reporting to the browser issue tracker).
Future work
There are quite a few things I’ve been working on during January: the Godot <-> JavaScript interface for HTML5, some refactoring of custom HTML templates and fixes to fullscreen/HiDPI support on the web. Stay tuned for another post soon.
-
+
\ No newline at end of file
diff --git a/article/godot-web-progress-report-6/index.html b/article/godot-web-progress-report-6/index.html
index f58d916211..8b22de0f34 100644
--- a/article/godot-web-progress-report-6/index.html
+++ b/article/godot-web-progress-report-6/index.html
@@ -20,7 +20,7 @@
For those who have been following previous updates, this was preliminary work needed for the now long awaited JavaScript <-> Godot interface which is coming soon™.
Faster load times
The aforementioned JavaScript Engine class has been heavily refactored as a result of the HTML shell update, so while at it I also took the time to finally implement WebAssembly.instantiateStreaming which allows the WebAssembly file (the engine web binary file) to be processed while it’s being downloaded. This significantly improves load times, especially on low end devices and slow networks.
Further work
There’s actually much more to talk about since the new 3.3 release will also provide an improved HTTPClient class and experimental virtual keyboard support on the Web. That’s a matter for another blog post though, so stay tuned for more :)
-
+
\ No newline at end of file
diff --git a/article/godot-web-progress-report-7/index.html b/article/godot-web-progress-report-7/index.html
index a4b9f40c2b..444915925d 100644
--- a/article/godot-web-progress-report-7/index.html
+++ b/article/godot-web-progress-report-7/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli16 April 2021
This article is from April 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.
Howdy Godotters! It’s time for another brief update on the status of Godot on the Web.
If you read through the last post, you already got the spoiler that Godot 3.3 is getting experimental virtual keyboard support on the Web. This has been a highly requested feature, but also a hard one to implement (as you might also guess by the fact that most engines, even famous ones, do not support that). It is still in experimental state, and comes with limitations, but should be enough to allow your users to insert their high-score name, or simple chat messages.
Experimental virtual keybaord
But why is it so hard to implement? And what are the limitations?
Well, accessing the virtual keyboard directly is not possible with the current web standards. Web browsers pretty much only show this virtual keyboard when the user selects an <input> or <textarea> HTML element.
Additionally, the standard for handling input method editor (e.g. insertion via autocomplete) is still being drafted by the World Wide Web Consortium (W3C), and browser implementations for it are very inconsistent.
To provide basic VK support, we can only rely on what is currently available: using an input/textarea element, and reading its content when it changes. This is sub-optimal, because it forces us to clear Godot’s LineEdit/TextEdit every time a character is inserted or removed via SceneTree._input_text (or the DisplayServer input_text callback in 4.0).
For this reason, while TextEdit nodes are supported, you should limit them to small amounts of text (i.e. no (GD)scripting via the Web virtual keyboard yet).
Zooming is not supported for now, so plan your LineEdit placement carefully:
While this is far from the best experience for the developer, it allows using the device virtual keyboard, with auto-completion, and corrections, and can be used for letting the user insert their nickname, email, etc.
Given its experimental state and limitations, virtual keyboard support must be enabled manually in the Export window:
Even implementing such a basic support took a great amount of time, testing different strategies across different browser, and trying to get a minimal implementation working. While I still don’t feel like recommending it for your game in production, it could be a very good addition to one of your jam games. I hear the Godot Wild Jam is up ;)
Hopefully, not too long from now, we’ll be able to do another iteration on this and add zoom support.
HTTPClient improvements
Talking about more “production-grade” improvements, the HTTPClient implementation on the Web has been rewritten using the Fetch API.
Tthis rewrite means you can now process chunks of the HTTP response before it completes like on native platforms, allowing the usage of APIs based on “server-sent events” which were traditionally handled on the web using the EventSource API and is not exposed by Godot being specific to the web.
This means finally being able to use important endpoints of various internet APIs (Google’s Firebase/Facebook/your own!) that rely on server-sent events. As an example, there is a good Godot Firebase plugin which now works really well on the web. Kudos to its developers for helping me out in testing this improvement :)
Future work
It’s been a year since I started working on the Godot Web export, and I feel it’s finally getting where we want to to be, a close-to-native experience.
There are still 2 important steps I want to take in that direction:
Implement PWA support for exported apps and games like we’ve done for the Web Editor.
Finish the Godot <-> JavaScript interface that I started working on months ago, and it’s not yet finished (but soon!).
-
+
\ No newline at end of file
diff --git a/article/godot-web-progress-report-8/index.html b/article/godot-web-progress-report-8/index.html
index 1b999fb3f1..6283f9fd3b 100644
--- a/article/godot-web-progress-report-8/index.html
+++ b/article/godot-web-progress-report-8/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli16 June 2021
This article is from June 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.
Howdy Godotters! Time for another update on the status of Godot on the web.
It’s been a while since the last web report as we were busy releasing Godot 3.3 and the following hotfixes, but as we move onto preparing for Godot 3.4 and the first alpha of Godot 4.0 (soon™), I’m happy to announce that starting from Godot 3.4 you will finally be able to export your HTML5 game as a Progressive Web App (PWA)!
PWA
Progressive Web App is a term to define a web application that uses a set of technologies to provide a more native-like experience to the user. Godot exports will leverage those technologies to provide out-of-the-box PWA of your game by enabling the relevant switch.
Enabling PWA will generate a few extra files that will need to be distributed along with your game, including the service worker, the web app manifest, and the relevant icons.
When a user visits the web page it will be presented with the option to install your application if the browser supports this feature. The way the installation is proposed to the users depends on the browser, here is an example on Chrome for Android:
Once installed, the web app will be added to the home screen, and will be able to start like a native app, even when the device is offline.
Extra features may also be avaible for installed web apps like locking the device orientation, and starting in fullscreen.
Better HTTP “run” server
Testing Godot Web exports on different devices can be cumbersome when you have to re-deploy your application multiple times.
A while ago we introduced an HTTP debug server to the editor be able to run your game in the browser, or on a device on your local network.
The HTTP server was never meant for production use, and never implemented SSL. Over time though, more and more features like threads, gamepads, clipboard access, etc., have been disabled by browser vendors when running from a page served without HTTPS.
For this reason SSL support has been added to the HTTP debug server, making it easier to debug your fully featured web export from a different device than the one running the editor.
You will find the relevant options in Editor -> Editor Settings under the section Export -> Web:
Http Host defines the address the server will listen to. By default, it will only listen to local connections for security. Change it to 0.0.0.0 to listen to connections on any interface.
Http Port defines the port the HTTP server will listen to.
Use Ssl will enable HTTPS for the server.
Ssl Key and Ssl Certificate can be optionally specified to provide your own SSL certificate and key (otherwise, a self-signed certificate will be generated).
More news coming soon
There is more news coming very soon, since the long awaited Godot <-> JavaScript interface for HTML5 exports has also landed in master and will be included in future 3.4 releases.
That’s a very exciting topic that deserves its own blog post, so stay tuned for more ;-).
-
+
\ No newline at end of file
diff --git a/article/godot-web-progress-report-9/index.html b/article/godot-web-progress-report-9/index.html
index 8c30b22427..11713bc44d 100644
--- a/article/godot-web-progress-report-9/index.html
+++ b/article/godot-web-progress-report-9/index.html
@@ -123,7 +123,7 @@
Future work
Working on the Godot HTML5 export for more than a year has been a great experience, and I love seeing the many developers releasing their Godot games and apps on the Web, even with the limitations this platform still has. I like to think Godot can help revitalize the web games ecosystem.
While I will keep maintaining the HTML5 platform, and there will be some more news in the next months beside the usual bug fixing, it’s time to get back at the other aspect of Godot that’s been overlooked in the last year… Networking and Multiplayer! Those of you following GitHub development might have noticed something already, but there’s much more to come.
-
+
\ No newline at end of file
diff --git a/article/godot-webrtc-report1/index.html b/article/godot-webrtc-report1/index.html
index e78d4facd8..fb2fff3789 100644
--- a/article/godot-webrtc-report1/index.html
+++ b/article/godot-webrtc-report1/index.html
@@ -8,7 +8,7 @@
https://github.com/godotengine/godot/tree/master
A compiled version of the WebRTC GDNative library is available at:
-
+
\ No newline at end of file
diff --git a/article/godot-webrtc-report2/index.html b/article/godot-webrtc-report2/index.html
index a1eb33511f..7a469de4ec 100644
--- a/article/godot-webrtc-report2/index.html
+++ b/article/godot-webrtc-report2/index.html
@@ -6,7 +6,7 @@
The connection must be in STATE_NEW as specified by the standard, the data channel must have a label, and can be optionally configured (see MDN docs for options).
You now need to call create_data_channel at least once before calling create_offer (or the connection will have nothing to setup at all).
offer_created was renamed to session_description_created and new_ice_candidate to ice_candidate_created to better fit Godot’s signal naming.
A new data_channel_received signal was added to receive in-band (not pre-negotiated) channels (if you don’t store it, the channel will be closed).
Other featuers that were added includes:
A new WebRTCPeerConnection.initialize method to create a new connection with the desired configuration provided as dictionary (see MDN docs). This allows STUN/TURN configuration.
The WebRTC GDNative plugin (for desktop plaforms) is now a singleton, and will be loaded automatically if dropped inside the project.
The updated GDNative plugin that works as a drop-in plugin (need a recent build from master branch).
The updated GDScript demo that uses the new functionalities.
We want goodies, where’s the multiplayer?
I’ve spent some time to get the Multiplayer API running, but I feel that it still needs a finishing touch and it’s not ready to be released yet. Additionally, this report was already overdue and I’m sorry about that.
For now I can tease you with the following image and this small video (forgive the screencast quality), while you wait a few weeks for another update.
-
+
\ No newline at end of file
diff --git a/article/godot-webrtc-report3/index.html b/article/godot-webrtc-report3/index.html
index 4096d94724..65cbbe12ef 100644
--- a/article/godot-webrtc-report3/index.html
+++ b/article/godot-webrtc-report3/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli19 June 2019
This article is from June 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 the last two reports we laid out the basis for building a Godot application that uses WebRTC to communicate with other peers.
Now, the WebRTC module got an interface to the High Level Multiplayer API, so it can be used as a transport for RPCs/RSETs. The implementation is a full p2p mesh, meaning every player is connected with each other via a “direct” connection, and there is no need for a player to act as a server.
WebRTCMultiplayer
The WebRTCMultiplayer class interfaces WebRTC with the High Level Mulitplayer API. Due to the way WebRTC works, this class needs a slightly more complex setup before it can be used compared to other network peers, but as said it will create a full p2p mesh that is also encrypted at transport level. The idea, is that you will have a signaling server assigning ids to peers, and letting them know about each other.
To setup the multiplayer class one would need to:
Call initialize with the id assigned by the signaling server.
For each newly connected peer (as notified by the signaling server along with its id), create a new WebRTCPeerConnection and pass it with the given id to add_remote_peer. You can optionally add channels to it, but the first three (negotiated 1, 2, and 3) are reserved for the high level mutiplayer.
Do the usual signaling procedure to exchange ICE candidates and session descriptions.
Note 1: You don’t have to poll each WebRTCPeerConnection separately, just call WebRTCMultiplayer.poll and it will poll all connections added via add_remote_peer.
Note 2 The WebRTCMultiplayer class does not fire connection_succeded and server_disconnected unless run in server_compatibility mode.
Server compatibility mode can be used to adapt games written using server/client architecture in mind (e.g. the ENet implementation). The connection will still be a p2p mesh, but one peer will be expected to have id 1 (server), and all peer_connected signals will be suppressed until such a peer connects. When that happens, server_connected will be emitted, the connection state will be set to CONNECTION_CONNECTED and then peer_connected will be emitted for each connected peer.
You can read more about the WebRTCMultiplayer class in the docs.
WebRTC tutorials and demos
This blog post will be a bit shorter then the previous ones, but don’t worry, there is much more reference material to learn from now!
Two new demos are available in the godot demo repository. The demos includes one with the two examples in the tutorial, and a reference signaling server using WebSocket, with two server implementations (GDScript, and Node.js) and two GDScript client implementation (raw, and WebRTCMultiplayer).
There is a port of the multiplayer bomber demo using the reference signaling server running live here. Have fun playing it with your friends (and/or studying its source code).
Future work
Beside documenting the GDNative plugin build system and building binaries for macOS, the work on WebRTC is pretty much concluded for now, ready for the 3.2 release.
Future work in the network department includes SSL server support, basic Crypto support (generate keys, random bytes, certificates), DTLS support, built-in editor web server for debugging HTML5 exported games, plus other neat features (in no particular order).
Stay tuned, for more Godot goodies, and as always, thank you for your support!
-
+
\ No newline at end of file
diff --git a/article/godot-wild-jam-2018/index.html b/article/godot-wild-jam-2018/index.html
index 31a240a18b..1a99eba381 100644
--- a/article/godot-wild-jam-2018/index.html
+++ b/article/godot-wild-jam-2018/index.html
@@ -5,7 +5,7 @@
Max Hilbrunner10 October 2018
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.
While the GodotCon in Poznań is ongoing (Livestream here!), our awesome community could not wait for the next official Godot Jam and just got one started on their own: The Godot Wild Jam.
Conveniently starting right after GodotCon, the second iteration of their monthly community jam already has lots of signups on itch.io - and because we always love community members stepping up to create things for others to enjoy, we encourage you to join them and have fun!
If you want to know more, read on as we’ll let them speak for themselves:
What is the Godot Wild Jam?
This game jam is here to inspire you to let go of your limits and Go Wild. Make a game in 9 days, and be part of a monthly event that will give you experience, add to Godot the community, and help further develop the engine. We strongly encourage the use of Godot 3.1 so as to stress test the engine, but all levels of experience are welcome. Please be sure to report any bugs you discover!
Where did it start?
The artist of Stern Flowers, Krystof, was anxious for the next Godot jam. Rather than wait for one to happen, he pitched the idea of organizing one to our group. Immediately, we ran with it. We decided that we wanted to have a game jam that would allow people to discover how easy Godot is. We wanted to test out new features. We wanted it to be fun and relaxing. We wanted it to be wild!
Kati, the group’s designer, created the jam page, while Krystof designed the jam’s image, including logo and color schemes. A Discord server cropped up, and John, one of the group’s programmers, made a dedicated website to the Godot Wild Jam. Even before the theme announcement, our composer, Kyle, made a killer video to present the theme in an over the top and engaging way. Staying true to our word, we provide a link to an itch.io page kept by Ernest, our other programmer, where bleeding edge builds of the engine are compiled every day for OSX, Linux and Windows, including export templates. All of Stern Flowers has worked hard to make this game jam a memorable one.
Why join?
This was the first time any member of Stern Flowers had hosted a game jam. We shared our jam page in every Godot-related space we could, and this gave us a lot of feedback. We listened and updated. By the end of our first game jam, we had 100+ participants around the world and 20 awesome games to play.
Now, we are about to start our second round of Godot Wild Jam. It has and will continue to be an amazing journey. We are proud to see the Godot Wild Jam community grow and are extremely thankful to our participants. We are also honored by the Godot Developers who have chosen to highlight our work.
We will see you at the next Godot Wild Jam. The next theme. The next game.
Who even is Stern Flowers?
We are an international group of game developers who found each other roughly 8 months ago for the second iteration of the “UE4 vs Unity vs Godot” jam. We used Godot, developing Roaming Ravenous and won first place. Since then, we have continued to work together on several other projects, Power Tower being the most recent one. Should you have any questions or curiosity gets the better of you, get in touch or check out our itch.io page.
Thanks for reading - and a big heartfelt thanks to the organizers. Godot Engine is and always will be a community effort - thank you for being part of it!
-
+
\ No newline at end of file
diff --git a/article/godot-wild-jam-october-2018-results/index.html b/article/godot-wild-jam-october-2018-results/index.html
index 9fba2cfe5b..921235f5ee 100644
--- a/article/godot-wild-jam-october-2018-results/index.html
+++ b/article/godot-wild-jam-october-2018-results/index.html
@@ -5,7 +5,7 @@
Max Hilbrunner26 October 2018
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.
Incoming transmission from our awesome community members and Godot Wild Jam hosts at Stern Flowers about the Godot Wild Jam October:
With roughly 170 participants and 31 games submitted, the second Godot Wild Jam was a huge success! We bestowed our winners, DeltaKey and Sklaiser, with the title of Godot Wildling for the next month. We hope someone out there reading this will design a proper crown for them. Our Discord server has grown to 300, and our community is anxious to start the third Godot Wild Jam which will be ongoing from November 9th to the 18th. Be sure to sign up!
Godot Wild Jam Submissions Compilation
After the jam, an enthusiastic supporter went out of his way to make a compilation video of all the game submissions from the second Godot Wild Jam. He was kind enough to share his work and ask us for feedback. Once we agreed on something we all loved, we uploaded it to the Stern Flowers YouTube channel. It’s an awesome feeling to see all these works back to back. If you haven’t had a chance, you should play some of them!
Stern Flowers can’t thank our participants enough for the support and community we have begun building around the Godot Engine. Not only are we impressed with the polish from these game jam submissions, but we are inspired and excited to learn from other game developers.
Again, be sure to sign up for the third Godot Wild Jam! Your submission will be featured in our next compilation video.
You could be the next Godot Wildling.
Thanks for hosting the jam! For more about Stern Flowers and the Godot Wild Jam, see the first blogpost. In other news, Hacktoberfest is still ongoing for a few more days, so if you ever thought about contributing to Godot Engine and Open Source - this is the time to get started!
-
+
\ No newline at end of file
diff --git a/article/godot-xr-progress-update-jan-2023/index.html b/article/godot-xr-progress-update-jan-2023/index.html
index 9154f20123..4ff517f38a 100644
--- a/article/godot-xr-progress-update-jan-2023/index.html
+++ b/article/godot-xr-progress-update-jan-2023/index.html
@@ -7,7 +7,7 @@
We’re also working on a new player controller that should make it easier to drop XR support into an existing first-person game.
Contributor Teddybear082 has used Godot XR Tools to implement VR ports of various open source projects. This shows how easy it is to apply our toolkit. The latest project he is working on is a port of the highly successful Cruelty Squad — see it in action!
Engine developers have organized a documentation sprint this January to ensure the documentation for Godot 4 was brought up to spec in anticipation of Godot 4’s stable release. XR of course was part of this sprint. Various documentation pages were completed and are now under review; others are still being worked on. Expect to see new pages added to the documentation soon.
New backends in Godot 4
OpenGL XR support in Godot 4
For low-end devices with limited Vulkan support, OpenGL was added as a backend to Godot 4. This implementation of OpenGL is based on OpenGL ES 3.0, but its architecture is more friendly to low-end/mobile devices compared to Godot 3’s GLES3 backend.
While there are a few loose ends, contributor David Snopek has added stereoscopic rendering support to the OpenGL renderer. This has proven to be a very efficient solution for XR. This is an upgrade for anyone using the GLES2 renderer in Godot 3 to consider. This implementation takes advantage of the improvements in OpenGL ES 3, but does not make use of Godot 3 GLES3 renderer technniques that were detrimental to performance on mobile XR. The only footnote is that the implementation requires the OpenGL multiview extension.
WebXR support in Godot 4
The added OpenGL support has enabled us to port our WebXR implementation to Godot 4 as well, again thanks to David Snopek.
Great care was taken to make WebXR support as portable as possible. This allows games developed with Godot to be deployed to both OpenXR and WebXR-based platforms.
The only footnote is that WebXR has fixed actions bound to controller inputs. This puts restrictions on the setup of actions on the OpenXR side to ensure portability between the platforms.
For a future version of Godot 4, we’re planning to add WebXR support to the action map implementation as well.
Support for PICO headsets in Godot 4
Support for PICO headsets was recently added to Godot 4, mostly to the credit of Dirk Steinmetz with help from several people at Bytedance. While we’re still waiting for a driver update to fully support Vulkan, the OpenGL renderer is working fine.
We hope to soon share instructions for setting up Godot on your PICO headset.
Support for Magic Leap 2 headset in Godot 4
Support for the Magic Leap 2 is in its final stages of development as well, the credit here goes to Ron Bessems.
This is the first HMD we’re supporting through the official Khronos loader. In theory, this should provide support for several other headsets as well.
Again, we hope to share instructions soon for setting up Godot on your Magic Leap 2 headset.
Honorary mention
Godot 4.1 will get a Direct3D 12 backend. This backend doesn’t support stereoscopic rendering yet, but adding this is on the roadmap. With that, we’re planning to add Direct3D support to our OpenXR implementation as well. This will mean having native Windows Mixed Reality support for PCVR.
Godot VR Editor
2022 kept us far busier than expected to get Godot 4.0 to a state we can release it in. As such, work on the VR editor was pushed back. A start has now been made on this interesting feature.
Noteworthy to mention here as well is the work that was done on getting the Godot editor to run on an Android device. This way, game development can be performed on tablets and similar devices. Much of this work is instrumental for getting the VR editor to work. In fact people have already successfully tried running this version of the editor on the Meta Quest!
Basic setup is now completed and work is starting on navigating and interacting with the loaded scene. A build that runs natively on the Meta Quest is now also working.
However, it must be noted that our focus and attention remains on the release of Godot 4.0 and the inevitable work that comes out of the community feedback.
-
+
\ No newline at end of file
diff --git a/article/godot-xr-progress-update-june-2021/index.html b/article/godot-xr-progress-update-june-2021/index.html
index 91a04c9025..21603a757d 100644
--- a/article/godot-xr-progress-update-june-2021/index.html
+++ b/article/godot-xr-progress-update-june-2021/index.html
@@ -17,7 +17,7 @@
We’re still working on porting this toolset as it uses a few reworked features in GDScript that are still in development.
If you want to have a play check out this draft PR.
-
+
\ No newline at end of file
diff --git a/article/godot-xr-update-feb-2022/index.html b/article/godot-xr-update-feb-2022/index.html
index bbe696df9b..0e710d7b33 100644
--- a/article/godot-xr-update-feb-2022/index.html
+++ b/article/godot-xr-update-feb-2022/index.html
@@ -6,7 +6,7 @@
Work is also progressing on some of the newer OpenXR features that are currently still in experimental builds such as supporting the new Meta Spatial Anchors API.
Reporting issues
For any issues encountered while using the Godot OpenXR plugin, or for any clarifications/improvements to the Godot XR documentation, feel free to open a github issue under the Godot OpenXR github page!
The list of current known issues can be found here.
The bulk of the changes center around the movement implementation in the plugin. There is a lot more flexibility in moving your player around including climbing mechanics, glide mechanics, wind mechanics, etc. This change does introduce a separate player object that needs to be added into your project however the plugin will attempt to do so automatically. This means some settings have moved so this could lead to minor breakage on existing projects.
The pickup and throw mechanics have been greatly improved.
There is now a vignette implementation that includes an automatic mode that will vary the vignette based on the players movement.
Godot 4 port
The port of this module to Godot 4 is well under way and used in the test project mentioned above. You can follow the work being done here.
The list of current known issues can be found here.
Community
If you need help, want to help or just like to chill with those who are making stuff with Godot XR, the best place to come and hang out is on the Godot Engine Discord server in the XR channel.
If you’re interested in contributing to either the plugins or the core functionality, come and hang out on the Godot Contributors chat server in the XR channel to discuss ideas.
-
+
\ No newline at end of file
diff --git a/article/godot-xr-update-oct-2024/index.html b/article/godot-xr-update-oct-2024/index.html
index 44a240ea19..1e485bcd0a 100644
--- a/article/godot-xr-update-oct-2024/index.html
+++ b/article/godot-xr-update-oct-2024/index.html
@@ -11,7 +11,7 @@
We’re looking into supporting this in a future 4.3 patch release.
What’s next
Stay tuned for further blog posts focusing on XR as we start looking ahead and as new features become available.
-
+
\ No newline at end of file
diff --git a/article/godot-xr-update-sep-2023/index.html b/article/godot-xr-update-sep-2023/index.html
index 9424c75c0c..3f324602a3 100644
--- a/article/godot-xr-update-sep-2023/index.html
+++ b/article/godot-xr-update-sep-2023/index.html
@@ -7,7 +7,7 @@
He has also contributed a new audio system to XR Tools that makes it easy to create audio cues as a player moves through the virtual space and interacts with various objects.
In the works are improvements to physical interactions with the world and various improvements and fixes in physics interactions.
Godot XR Template
Godot XR Template is a new repository that was created by Malcolm Nixon and Bastiaan Olij and provides a boilerplate for XR applications made with Godot. It contains a copy of XR Tools, the required loader library, all the configuration setup and a basic setup for a game.
Upcoming improvements to core Godot OpenXR features
While no promises can be made to how quickly things will become available, the team is working on implementing various new OpenXR extensions that will be added to Godot itself.
Eye tracking support is nearly finished but is awaiting some enhancements regarding permission requirements.
We are planning on supporting the new hand interaction feature which will allow easy support for both controller based and hand tracking based games and lets them seamlessly switch.
In the same line the new hand tracking data source extension should make it easier to visualise the players hands both when controllers are held and when full optical hand tracking is used.
We are also looking into the feasibility of supporting various vendor extensions for creating meshes suitable for displaying the players hands in such a way that this can be supported in core. It will also need to include a fallback feature.
Nub’s Western Gun Slinger game
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 the Godot Development Fund or PayPal.
-
+
\ No newline at end of file
diff --git a/article/godotcon-2018-venue-and-call-proposals/index.html b/article/godotcon-2018-venue-and-call-proposals/index.html
index 5bc83371f1..3bb97205df 100644
--- a/article/godotcon-2018-venue-and-call-proposals/index.html
+++ b/article/godotcon-2018-venue-and-call-proposals/index.html
@@ -6,7 +6,7 @@
Even longer workshops could be imagined (e.g. 1h or 1h30), in which case they might be in a separate room from the main event so that only the interested attendees take part in them.
Please send your proposals to contact 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)
Technical requirements (whether you need a projector, with or without sound, etc.)
Don’t overthink the above too much, given the late CfP we likely won’t be posting a detailed schedule on the website as done in bigger events, so this is mostly for us to tell you if your idea is interesting, and fit you in the schedule for the two days.
Last chance to register
If you haven’t registered for GodotCon yet, please do it ASAP using our registration form. We currently have 54 participants, which should fit well in our venue, but if we were to get 50 additional surprise attendees it might become problematic. So if you plan to attend the event and haven’t registered yet, please do it now :)
-
+
\ No newline at end of file
diff --git a/article/godotcon-2023-call-participation/index.html b/article/godotcon-2023-call-participation/index.html
index ea8b1fef3c..6ffe05c3d9 100644
--- a/article/godotcon-2023-call-participation/index.html
+++ b/article/godotcon-2023-call-participation/index.html
@@ -9,7 +9,7 @@
-
+
\ No newline at end of file
diff --git a/article/godotcon-2023/index.html b/article/godotcon-2023/index.html
index 3cbb14080c..4d99ebe4cd 100644
--- a/article/godotcon-2023/index.html
+++ b/article/godotcon-2023/index.html
@@ -8,7 +8,7 @@
-
+
\ No newline at end of file
diff --git a/article/godotcon-2024/index.html b/article/godotcon-2024/index.html
index d674d805ed..e8e9afb208 100644
--- a/article/godotcon-2024/index.html
+++ b/article/godotcon-2024/index.html
@@ -6,7 +6,7 @@
Even if you do not plan to attend this installment, we recommend taking a look for potential business contacts and to be the first to know about any future events.
-
+
\ No newline at end of file
diff --git a/article/godotcon-july-2021-schedule/index.html b/article/godotcon-july-2021-schedule/index.html
index 5174980507..6f688980e3 100644
--- a/article/godotcon-july-2021-schedule/index.html
+++ b/article/godotcon-july-2021-schedule/index.html
@@ -8,7 +8,7 @@
Here’s the complete list of channels, you can just click on them and then press the join button if you have an account:
-
+
\ No newline at end of file
diff --git a/article/godots-2d-engine-gets-several-improvements-upcoming-40/index.html b/article/godots-2d-engine-gets-several-improvements-upcoming-40/index.html
index 75f13fa6d0..a2ab9e2192 100644
--- a/article/godots-2d-engine-gets-several-improvements-upcoming-40/index.html
+++ b/article/godots-2d-engine-gets-several-improvements-upcoming-40/index.html
@@ -42,7 +42,7 @@
A large amount of other effects can be easily achieved with SDF, such as mist or heat distortion over the floor, 2D global illumination, rain hitting the floor effects, or even procedural shading for the whole screen. The SDF distance is based on scene global coordinates, so measuring distances can be done in a familiar way.
The 2D GPU particle system will support particle collisions against the whole scene via SDF. Hopefully, users will give many other cool uses to this new feature.
Future
More work is also going towards the 2D engine. Gilles Roudiere is working on a new 2D tilemap system an editor that will hopefully overcome most of the limitations with the current one. You can follow his progress on this twitter account.
As always, keep in mind that we make Godot out of love for you and the whole game development community. We want to make the best and easiest to use game engine, and make it so free and open that you can feel that you made it yourself. If you are not, please consider becoming our patron to help us out!
-
+
\ No newline at end of file
diff --git a/article/godots-documentation-now-open-translation/index.html b/article/godots-documentation-now-open-translation/index.html
index 252e92e261..cfdbfa5337 100644
--- a/article/godots-documentation-now-open-translation/index.html
+++ b/article/godots-documentation-now-open-translation/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde17 April 2018
This article is from April 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.
Ever since Godot was open sourced in 2014, localized documentation has been requested every now and then by new users. Some eager translators even started unofficial localized wikis, but without a proper infrastructure for internationalization, those were incomplete and quickly grew obsolete as the English documentation changed.
Today, we are finally ready to open the documentation for translation on Hosted Weblate, where we already manage the editor localization.
You can contribute to an existing localization effort, or request the addition of a new language, but read the rest of this blog post first for a few words of caution – localization of something as big as Godot’s documentation is not a light task!
Doing things right
As mentioned above, some community members were so eager to help with localizing the documentation that they even started their own thirdparty wikis to work on it – so why didn’t we build upon this motivation and waited 4 years to open the documentation for translation?
Ensuring the quality of the content to translate
The main reason is our expectations for quality content. As long as we were not fully confident that our English documentation was of top quality, we did not want translators to spend countless hours translating content that might be obsolete or bound to be rewritten in the near future. Godot’s documentation is huge, likely requires hundreds of hours of work for each language to be well translated, so even if some translators are motivated, it’s not a task that should be undertaken lightly with no preparation.
During the 3.0 release cycle, a huge effort has been done on improving the documentation. Nathan, Chris and Max took charge of the Documentation Team, writing guidelines, reorganizing the sections, removing outdated or low quality content and writing new high quality tutorials.
Since the 3.0 release and the arrival of dozens of new documentation contributors, the pace at which improvements are written, contributed and merged is so strong that I’m hardly able to keep up with the changes.
Suffice it to say, Godot’s documentation is now a well-managed and high-quality project, and it seems to be a good time to consider translating it to new languages. It will continue evolving in the future, but we are now confident that the available content is worth translating, and with the right infrastructure, future content should be easy to translate as it comes.
Setting up the infrastructure
Seeing that the time has come to make the documentation translatable, and thanks to some additional research by contributor Juankz, I started working on preparing the documentation repository for internationalization.
I’ve spent a good chunk of my work time those last three weeks working on this, doing some research on what workflow can be used with our existing Sphinx/Read the Docs documentation system.
Those can then be committed in the Git repository, and new Read the Docs projects can be configured for each language to build the docs with the right translated strings.
So far so good – but the main issue for me was the sheer amount of content to translate, which would make a Git-only workflow very bothersome (especially if localization PRs would be in the same repository at the English documentation PRs). Since we were using the free and open source (and generously hosted) Weblate web-based service for the editor translations, I wanted to do the same for the documentation. Sadly there isn’t a lot of documentation available on how to best combine Weblate and Sphinx/Read the Docs, so I got in touch with their respective developers to discuss possibilities.
While discussing with the Weblate maintainer, it became clear that having one template (POT) file for each page would not be a good workflow, as it would mean configuring almost 200 components in Weblate! (and deleting them when files are removed, and having to ask admins to add new components each time we add a file).
I saw that some projects like PhpMyAdmin would concatenate all their template files into one monolithic file, and only upload that one to Weblate, then convert the translations back to each single file for Sphinx… I wrote some Makefile logic to do that (since changed to a Shell script because my Makefile-fu is limited), and was a bit concerned to see that the resulting monolithic file would be over 2.5 MB for Godot (meaning that catalog (PO) files would end up as over 5 MB with English source + localized string). And this is without the Class Reference, which is currently excluded from the documentation and would otherwise bring the template to 8 MB! I started looking into grouping files together in related sections, to have maybe 10 components instead of 200, but several would still be over 500 kB, so bringing little gain in usability while complexifying the maintenance a lot.
Finally, thanks to the advice of Yuri Chornoivan, who is an expert in internationalization of free software, including their documentation (such as that of the KDE, GNOME, Fedora and Ubuntu projects), I settled on the “huge monolithic template” approach. Weblate makes it relatively easy to work even with such big files, and offline translation tools like Poedit or Lokalize have features to filter the catalog to isolate a given page you want to work on.
Time will tell if it’s a good workflow for localization and how we can improve it further. Suggestions and bug reports can be made in the dedicated godot-docs-l10n repository.
Translation workflow
Now that you know how it was set up, what’s the workflow to contribute?
As mentioned above, once logged in Hosted Weblate, you can contribute directly to your language if it’s already a work-in-progress, or add it (“Start new translation” button in the bottom left part).
You can translate directly in the Weblate interface (pro tip: the “Zen mode” is quite useful to see the previous and following strings next to the one you want to translate, which can help understanding the context), or download the current translation catalog, work on it with an offline tool of your choice, and upload it back to Weblate.
Do not make PRs to the godot-docs-l10n repository (at least not to add translations), I will be syncing the Git repository with Weblate manually, as the process I outlined above is non trivial:
Translations pulled from Weblate are the “monolithic” translation files, and need to be split into the per-page files that Sphinx expects before building the docs.
Updating the Weblate monolithic template requires syncing the per-page Sphinx templates with the godot-docs repository, then creating the monolithic template again and merging the changes in the monolithic translation catalogs.
Moreover, for now only two localized documentation websites exist (es and zh_CN, created for testing purposes), I will create the other relevant ones as needed when some languages have a good level of completion in their translations (e.g. 10-15%, which would amount to the Getting started section for example).
Strive for quality
Finally, if you are considering contributing to the documentation’s localization for your language, please take your time to do it right, and ensure a high level of quality. There’s enough content for several months of work with a handful of contributors, so don’t rush it and focus on the most relevant parts first (especially the Getting started section).
Translating from English to your mother language may seem easy at first, but make sure that you have a good mastery of writing skills for your own language, and that you understand the English texts that you are translating. Approximate translations in software and documentation are always the source of a lot of frustration.
Also try to get in touch with other Godot translators for your language and define some guidelines for the writing style, punctuation, etc.
If you notice issues with the translation workflow, please report them in the godot-docs-l10n repository. If you find issues with the English documentation itself (typos, unclear sentences, overall bad section), report them directly to the godot-docs repository and/or make a PR to fix them.
Have fun translating Godot’s documentation and making it accessible to all the users who struggle with reading English documentation!
-
+
\ No newline at end of file
diff --git a/article/godots-graduation-godot-moves-to-a-new-foundation/index.html b/article/godots-graduation-godot-moves-to-a-new-foundation/index.html
index bac40020ac..106c52a888 100644
--- a/article/godots-graduation-godot-moves-to-a-new-foundation/index.html
+++ b/article/godots-graduation-godot-moves-to-a-new-foundation/index.html
@@ -8,7 +8,7 @@
foundation.
When Godot was first open-sourced in 2014, it was a very small project mostly developed by Ariel and Juan. Even after open-sourcing, contributions to Godot were almost exclusively made by volunteers. Over time, and to our surprise, many users expressed a wish to contribute financially to the project to speed up development.
Creating a foundation at the time would have been too costly and difficult, so we turned to Ton Roosendaal for advice. Ton introduced us to the Software Freedom Conservancy (SFC), which is a charity located in New York.
The SFC was a fantastic fit for Godot. They work as a non-profit home for several high profile FOSS projects (such as Git, Samba, Wine, etc) and they have tested and proven rules to ensure that donations are only used for the benefit of projects, as well as rules to avoid conflicts of interest. They allow open-source projects to grow and prosper and focus on their project while the SFC handles non-profit governance, accounting, and legal issues (including successfully walking back on Non Disclosure Agreements to ensure that all our work can happen in the open); essentially aggregating the work required for the operation of a not-for-profit organization.
Ariel and Juan signed a fiscal sponsorship agreement with the SFC, allowing them to receive donations on behalf of the project. They also managed the creation and growth of the Godot PLC (Project Leadership Committee), formed by some of the most veteran contributors at the time.
Thanks to the SFC, Godot was able to become what it is today as many of its most prominent contributors were able to work part or full time, paid by donations. We were also able to meet in person thanks to their excellent policies for travel and hosting reimbursement. Without this, many contributors would not have been able to make it to events. They have also masterfully negotiated large donation grants by companies, ensuring that anything signed is beneficial to the project.
In all, from the Godot project leadership, we are immensely thankful and proud to have been part of the Software Freedom Conservancy.
Godot joined the SFC when the project was still in its infancy and its needs were fairly limited. Now the Godot project is many times larger, it employs multiple people, and it has more complex needs and aspirations. Accordingly, as the project continues to grow even more, it makes sense to have the control, independence, and flexibility in managing funds of an organization that is solely focused on Godot.
For this reason the Godot Project Leadership Committee (the PLC) and the SFC have agreed that it is time for the Godot project to leave its home at the SFC and form its own organization: the Godot Foundation. Like a lot of other Open Source projects (Blender and Krita, for example), the Foundation will be located in the Netherlands, which means Godot will be Blender’s neighbor! The structure of the Foundation is modeled after the policies of SFC, which will ensure continuity in the way Godot operates.
Why create a foundation?
As Godot keeps growing, so do our needs. Godot’s size merits the flexibility of having its own organization and the opportunity to explore broader funding sources.
Examples of this are crowdfunding campaigns (like Blender or Krita do), the highly requested ability for users to sell assets on an asset library (and have a share going to the Godot Foundation), selling merchandise, and other types of funding. An independent entity will allow us to make decisions with solely Godot’s benefit in mind, instead of as one of many important open source initiatives.
Having our own foundation will also project a stronger image of the Godot Project, which will allow us to have stronger footing when negotiating big donations with donors. The SFC has done a stellar job at negotiating for us so far, showing us how to ensure that the FOSS nature of Godot is never compromised in those agreements. We intend to continue with the same passion and dedication to FOSS that the SFC has shown us in all those years.
Ultimately, we want the Foundation to serve as a home for community initiatives, by allowing it to have its own funding lines (this means, so they can raise funding on their own for a specific goal, but the Foundation receives and uses it according to what was agreed), such as initiatives to promote education, communication and diversity.
We plan to regularly post public reports of our financial situation and the usage of funds, similarly to what the Blender Foundation does.
What will change?
From the perspective of the Godot project, not much will change. Governance/Financial decisions were previously made by the PLC with input from the advisor group. The PLC will become the Foundation’s Board of Directors, so it will be the same people, but just with a different name. Additionally, the SFC will be part of the new foundation in advisory capacity, to help us with this new adventure, and to ensure to you all, the community, continuity in the way Godot is managed.
This transition does not affect in any way the technical development of the engine, which is detailed in our Governance and Teams pages. The development process of Godot will not change with the Foundation.
The Godot Foundation is dedicated to creating Free and Open Source Software and to ensuring that work on the Godot project is sustainable. The Foundation’s Mission is to “financially support the growth, initiatives and activities of the Godot Engine project, an open-source project that provides a free suite of tools and educational materials around the Godot Engine.
The Foundation strives to help the Godot Engine continue to break down barriers to video game development and make it possible for everyone to create high quality video games, regardless of who they are and where they are located.”
Additionally, the Godot Foundation is adopting most of the policies from the Software Freedom Conservancy. Their policies worked very well and we can’t think of a better way to manage the subtleties and challenges that come with a non profit organization. From the composition of the board in respect to conflict of interest and transparency, to the fair usage of funding, we are committed to granting the same ethical quality as the SFC has ensured so far.
What’s next?
We have just started the process of moving to the Foundation. For now all of Godot’s funding and contractors are still managed by the SFC. The SFC will gradually reduce its work for Godot and the new foundation will slowly ramp up. Stay tuned for announcements in the future as we finalize the Foundation’s organizational structure and officially begin operations.
If you have any questions, please reach out to contact@godotengine.org. We will compile a list of questions and update this page with an FAQ shortly after.
-
+
\ No newline at end of file
diff --git a/article/godots-new-high-level-networking-preview/index.html b/article/godots-new-high-level-networking-preview/index.html
index 50194f825d..dbd1cffe2d 100644
--- a/article/godots-new-high-level-networking-preview/index.html
+++ b/article/godots-new-high-level-networking-preview/index.html
@@ -9,7 +9,7 @@
This means that only the player who is master for that instance will actually get the function.
This function, then, calls the stun function in the same instances of that same player (but in different peers), and only those which are set as slave, making the player look stunned in all the peers (as well as the current, master one).
From this first insight, it may not seem very obvious how the high level networking works in Godot. You’ll most likely have to try it yourself to completely “get it”.
The huge advantage of this approach is that, once you are used to it, you can make a multiplayer game with almost the same amount of code as a single player game (save for placing master/slave keywords and calling some functions as RPC instead of regular call). As a plus, your multiplayer game will run single-player just fine without any changes (all nodes will be master, calls to slaves will be ignored).
Please remember that this is a first implementation of high level networking, and we would love to hear your feedback on how we can improve it! Thanks for reading!
-
+
\ No newline at end of file
diff --git a/article/godots-new-renderer-progress-report-1/index.html b/article/godots-new-renderer-progress-report-1/index.html
index 581833782e..e72d6598ee 100644
--- a/article/godots-new-renderer-progress-report-1/index.html
+++ b/article/godots-new-renderer-progress-report-1/index.html
@@ -11,7 +11,7 @@
Future
This has been our first report on the new renderer progress towards Godot 3.0 new renderer, hope everything was clear!
Seeing the code
If you are interested in seeing what each feature looks like in the code, you can check the gles3 branch on GitHub.
-
+
\ No newline at end of file
diff --git a/article/godots-new-renderer-progress-report-2/index.html b/article/godots-new-renderer-progress-report-2/index.html
index 19bdbcc012..6399923f53 100644
--- a/article/godots-new-renderer-progress-report-2/index.html
+++ b/article/godots-new-renderer-progress-report-2/index.html
@@ -5,7 +5,7 @@
Juan Linietsky4 December 2016
This article is from December 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.
Introduction
It’s been a month since the first progress report, and progress continues towards the new Godot renderer. Little by little every system falls into place, and rendering starts feeling a lot more mature.
That said, there is still a lot missing. Unfortunately, some tasks initially planned for Milestone #2 could not be completed yet, so they will be pushed to the next milestone.
Here’s the list of tasks for the current milestone and the next one:
Implement more PBR parameters: Sheen, Clearcoat, Anisotropy.
Implement more Material parameters: Displacement, Refraction, Subsurface Scattering.
Implement Post-Processings: Tonemapping, adjustments, Motion Blur, SSAO, DOF Blur, Bloom and Screen Space Reflections.
Implement more types of geometry: Instancing (MultiMesh), Skeletons, and Immediates.
Implement Decals.
The remaining post processing tasks and decals will hopefully be done this week, though, so it’s not that bad.
TODO for Milestone #3 (December 2016)
Implement the new version of the Godot SVO-based Light Baker.
Implement Particle Shaders, with support for: Sorting, Collision and Soft Particles.
Improve Culling: Portals (rewrite as polygon-based) and Rooms.
Add Clustered lighting (before this all is forward).
Add Layered/Stencil rendering
The new baker will probably take a bit more time, as this is an exciting area of research and a lot of nice ideas are ready to be tested (including the possibility of realtime-GI using an innovative technique).
Detail of tasks done for Milestone #2 (November 2016)
Following is the detail of everything that was implemented and a little background on how this was done!
Implement Shadowmapping
Shadow mapping is implemented in Godot 3.0 using a Shadow Atlas. This allows rendering multiple lights in a single pass, be it using forward or clustered rendering. Shadow atlases exist for Spot and Omni lights (Directional uses its own texture, and multiple directional lights need several passes).
How the atlas texture is organized is up to the user, though the default is sensible enough to work in most cases. Atlas cells are assigned according to their size in pixels on the screen (e.g. if the light is using the whole screen, the biggest cell is assigned, otherwise an intermediary or smaller one will be assigned).
Below is an example of how this process happens:
Shadow Caching
As most light shadows will not change unless something moves around that area, Godot will not redraw such shadows unless needed. This ensures that a lot of shadows can be drawn on screen at decent performance. To improve on efficiency, we were contemplating adding some optimizations such as updating farther away shadows at a lower framerate.
Point Light Shadows
One of the big problems with point lights is that, to render them correctly, a depth cubemap must be used. This obviously conflicts with the idea of using an atlas (can’t really store cubemap lights efficiently on it).
Godot 2.x used Dual Paraboloid Shadow Mapping, a technique that is very efficient, but produced deformed shadows (notice the rounded edges and discontinuities). This was the source of complaints from many users.
To fix this, Godot 3.0 provides an extra point light rendering mode where the shadow is rendered to a cubemap, then converted to DPSM. This produces flawless results at a bit higher (but not by much) cost. Users can now choose this mode when correct shadows are desired, or keep using the old method when performance is a priority over quality.
For point and directional lights, everything is more or less the same as before.
Implement Reflection Probes
One of the main features of PBR rendering is having all sort of sources for reflections. The most common (and cheapest) one is reflection probes.
These are basically cubemaps which capture a given area, and then everything inside their box uses them as a reflection source. To allow proper roughness, cubemap mipmaps are gradually filtered using the a GGX lobe, which allows quick look-ups.
In Godot, unlike in other engines, probes are also implemented as dual paraboloid. There are two reasons for this, but mainly that Godot 3.0 uses GLES 3.0 as it’s main backend and makes compatibility a priority. This means:
Cubemap arrays are not supported in older hardware, mobile and WebGL2, and reflections need to be put into an atlas (for single-pass forward or clustered).
Blending of cubemap faces is not supported in mobile and WebGL2, making blurred reflections look terrible. This is not a problem with DP.
Dual paraboloid reflections fix this, and have the added advantage of being able to choose cubemap-correct or fast, but incorrect reflections.
Reflection probes are relatively simple to use in Godot. Just instance one, set the bounds and adjust the origin. Everything inside will automatically reflect itself:
As you can see though, the reflection is too broad (there is a giant “lamp” at the bottom). For interiors, there is a “box project” option that will map the reflection to the sides of the probe, improving the reflection quality:
Of course, for a complex interior, several probes must be used to properly map all rooms and passages. This is one of the strong points of Godot implementation, which uses a novel blending algorithm between probes. Other popular game engines present hard edges between one probe and the next.
Godot also provides some nice options per probe, like custom ambient light, and the ability to mark them as “interior”, which changes some options with regard to how they are rendered (such as rendering the skybox and blending to it).
Implement more PBR parameters
Several more PBR parameters were implemented. Thanks to Godot’s Forward/Clustered design, the material system is far more advanced than in other popular game engines, requiring no hacks to allow a much larger amount of parameters ready to use for the artists, at no cost.
Specular Color instead of Metalness
Godot uses a specular color instead of metalness. This works as if metalness could be controlled per color channel, allowing a broader range of materials:
Rim Lighting
It is possible to set up a special rim lighting parameter. This adds some back-lighting to the contours of objects according to each light. It works well to simulate cloth or Mario-Galaxy style art.
Clearcoat
This parameter acts like a second specular dot. It works great on objects that have a certain amount of roughness, but that are also covered in some sort of shiny glass, pastic, liquid, etc.
Anisotropy
Anisotropy works great for materials that distort the specular reflection, such as hair, an LP, brushed metal, etc. A tutorial on how to use this will be eventually uploaded.
Ambient Occlusion
Materials can provide their own ambient occlusion, overriding global effects such as SSAO.
Subsurface Scattering
This parameter is used to simulate surfaces that reflect the light internally, such as skin, rubber, marble, milk, soap, wax, etc.
Implement Mid-Processing
Mid-Processing is the effects that are applied in the middle of rendering, before alpha pass and post-processing.
Screen Space Reflections
Godot uses it’s own screen-space reflection implementation. This effect allows showing reflections that can be calculated from the same screen-space. It’s meant to be used together with reflection probes, so there is always a fallback when a reflection can’t be found.
Blurring the reflection according to roughness is also supported, using a fast screen-space blur. This technique is not correct per se, but it’s very efficient.
Screen Space Ambient Occlusion
This effect is used and abused by a lot of developers. It obscures parts of the scene where the light should have more difficulty reaching. Godot’s implementation provides a few interesting things:
It uses the Scalable Ambient Obscurance algorithm, which is very, very fast, allows huge radiuses.
It allows two different radius and intensity settings, to be able to cover large areas and small areas at the same time.
It allows “bleeding” into direct lighting too, so stuff that is receiving direct light can be obscured to customizable degree.
FUTURE
This month has been mostly implementing standard modern engine features, always with a twist to improve them the Godot way. Next month should hopefully be more interesting when work goes towards the new light baker!
SEEING THE CODE
If you are interested in seeing what each feature looks like in the code, you can check the gles3 branch on GitHub.
-
+
\ No newline at end of file
diff --git a/article/godots-new-renderer-progress-report-3/index.html b/article/godots-new-renderer-progress-report-3/index.html
index 54317d07a9..f4df28f134 100644
--- a/article/godots-new-renderer-progress-report-3/index.html
+++ b/article/godots-new-renderer-progress-report-3/index.html
@@ -8,7 +8,7 @@
Finally, dynamic objects get full light and reflections from the GIProbe when they move around inside, without having to use any kind of probe groups:
Future
The last remaining big feature is the new particle system, then everything else is simpler, and includes cleaning up the implemented techniques. Hoping that by the end of January, the new renderer will be mostly done!
Seeing the code
If you are interested in seeing what each feature looks like in the code, you can check the gles3 branch on GitHub.
-
+
\ No newline at end of file
diff --git a/article/gsoc-2018-progress-report-1/index.html b/article/gsoc-2018-progress-report-1/index.html
index f12e9e09d4..9968537d35 100644
--- a/article/gsoc-2018-progress-report-1/index.html
+++ b/article/gsoc-2018-progress-report-1/index.html
@@ -21,7 +21,7 @@
I want to explore a lot more in Mobile VR and both GSoC and Godot have helped me a lot in doing so.
Future
A lot of stuff is yet to be implemented. Keep checking GodotVR frequent updates.
The code
You can see all of the commits for Gear VR here. Code for the Google VR module will be uploaded soon.
Thanks
On behalf of the Godot community, a big thankyou to all students involved in our GSoC program this year, as well as all the mentors who give some of their time to help students reach their project’s goals. And finally thanks to Google for organizing GSoC each year and sponsoring the development of free and open source software, as well as giving students the opportunity to get professional experience.
-
+
\ No newline at end of file
diff --git a/article/gsoc-2019-progress-report-1-part-1/index.html b/article/gsoc-2019-progress-report-1-part-1/index.html
index 5c8c552038..d128545b29 100644
--- a/article/gsoc-2019-progress-report-1-part-1/index.html
+++ b/article/gsoc-2019-progress-report-1-part-1/index.html
@@ -7,7 +7,7 @@
Through discussions on the IRC channel it was discovered that the code just crashes on a Linux system (I use Windows). When I ran it through VS 2017’s debugger it seemed to be a case of generate_preview() being called constantly, however I could not quite identify why that is happening. Currently I have disabled the preview generator in order to be able to work and for a while that problem still persisted until I added some safeguards in my playlist mix logic, but when the generator is turned on it still creates that problem. It will likely be something I try to fix later on, potentially by disabling the preview generator for playlist and probably transitioner specifically, instead of disabling it for all streams. I don’t see a need for these classes to have a waveform preview displayed below AudioStreamPlayer, since they contain multiple audio files, rather than one.
What is next
I aim to have transitioner functional by the beginning of August which will give me time to debug any potential issues and come up with a fix for the memory leak. Some of the things I wrote about here such as changes to how transitioner will be layed out need to be further discussed and approved by my mentor reduz. I will also aim to create an example project that displays the functionalities of the new feature, probably something simple such as pressing a few different buttons playing different music loops fading in and out. I think it will be a nice way to show it working and also give an example of the functions exposed to GDScript being used in context.
Student server working branch: https://github.com/ankitpriyarup/godot/tree/lsp
Mentor server working branch: https://github.com/GodotExplorer/godot/tree/gdscript-lsp
Student client working branch: https://github.com/ankitpriyarup/godot-tools/tree/lsp-client
Mentor client working branch: https://github.com/GodotExplorer/godot-tools/tree/lsp-client
What is the project?
The integrated script editor in Godot lacks features found in editors like VS Code, Sublime, Emacs, etc. These editors are also more popular among developers and therefore many want to switch to them for their usability. However, to implement core functionalities such as diagnosis, registering custom symbols, jumping to definition, etc. a Language Server structure has to be adopted. For example, the client (say VS Code) will communicate with the Godot Language Server to get desired results.
Microsoft’s Language Server Protocol (LSP) is flexible and powerful to implement these functionalities. It also supports many editors - VS Code, Atom, Sublime, etc. Hence, instead of writing complete extensions for each editor (client), using LSP the server is the same for all and only the client have to be implemented as an editor extension.
How it’s like to work with Godot
I had a wonderful time coding with the fantastic and helpful community at Godot. I am mentored by Jason0214 and Geequlim. Jason0214 is very responsible as he always points out my mistakes and potential weekness from the regular code review. Geequlim is very active in the project and I always get to learn a lot from his commits. Besides that, it’s an amazing experience to talk to other students and share whatever we learned. Writing clear and well-structured code to meet standards, and making sure your changes does not break anything else was a truly educational experience.
I have the freedom to arrange my time and set my own plan, there’s no pressure at all. Mentors encourage me to be as creative as I can and I’m free to choose how to finish my work. Summing it all up working at Godot has been a really great experience for me.
Current progress
I started off by getting familiar with the existing Godot tool for VS Code, improving existing configuration and grammers, we had to remove most of client-side code because we wanted to rely on LSP server (Godot) for most of the task for two reasons:
To make the client smaller and easy to port to other editors such as Atom and Emacs.
To reuse the existing implementation of the built-in GDScript editor and reduce duplication.
The LSP Specification is based on an extended version of JSON RPC which can be basically used for sending notifications, requests and responses. For example: VS Code (client) will first send a notification that the opened file is GDScript by matching its extension, and then the Language Server will be connected. Client then again sends a notification defining what capabilities it can provide. Then most of the tasks can be broken down into a request-response structure, where the client requests something and the server responds with a result.
1) Diagnostics
An Extended GDScript Parser is created inheriting from the original GDScript parser with the aim to carry specialized parsing task for LSP. Everytime a code change is notified to the LSP Server by the client, diagnostics (i.e. errors and warnings) are updated along with their relevant details such as range (line and column number for both start and end) and message, which are stored in a map for faster lookups.
2) Code completion
The existing complete_code implementation for the built-in code editor is reused, however Godot also matches written code continuously to filter possible options, while in LSP the complete list of possible items is sent to the client by the server initially. The client then handles the matching part, and typically does it better than the built-in editor. In the example below writing texture in the LSP client matches not only initial characters but also substrings present anywhere within the item.
3) Symbol cache pool
To provide lookup functionalities such as Function Assist, Hover Provider, Symbol Resolve and Go to Definition, we use a symbol pool to cache all of the symbols (both native and script symbols). The cache pool is filled at the startup by parsing all scripts in the workspace for script symbols and loading native symbols from DocData.
4) Documentation provider
To provide quick lookup of a class documentation, the entire Godot docs are converted and dumped into system files which can be directly opened by the editors. A simple regex parser is capable of parsing the class name on ‘View Symbol Documentation’. In case the parsed symbol isn’t recognised, a list of all the symbols will be shown.
5) Rename symbol
Besides these other features such as Rename symbol is also implemented, it first finds out the position of symbol definition and then the code replaces the previous name to the newly specified name from the position of definition until the end of its scope (by checking the indentation).
Future steps
For the remaining of the coding period, we’ll be focusing on:
CodeLens support for disable warnings and show slots informations connected nodes.
Adding a way to auto insert the signal connection code via the LSP.
Fixing bugs in current implementation and merging them in Godot’s master branch.
Porting the client to other popular editors like Atom and Emacs.
Improvements to the Visual Scripting System – Swarnim Arun
PR on upstream repository: https://github.com/godotengine/godot/pull/29681
Project overview
This is a project dedicated to reworking/refactoring/improving the Visual Scripting system that exists in Godot as a whole to make it a viable option for the people who choose to use it.
The main goals of the project are to simplify the UI/make the system more accessible and increase the ease of use.
The steps taken in that direction include unifying the Visual Scripting Graph, and making the functions system much simpler and easier to use, while adding usability changes that have long since been due for the system, and have been discussed in some length or the other in the various groups and platforms of the Godot communities.
Tasks completed are:
Unifying the Graph.
Adding basic usability changes:
Port swapping.
Automatic type cast nodes.
In-graph editable nodes
Right-click for node search dialog.
And a few others…
Changing the Layout structure for more efficient use of the precious space.
Tasks planned that still remain are:
Bug fixing and error debugging.
Testing and further improvements via quality of life changes.
Work of the Super Node or Visual Script-based custom nodes/modules feature for greater reusability and modularity of the Visual Scripting system.
Demo clips of the progress so far
Unified graph (all functions in the same view)
Port swapping
In-graph editable node
Right-click for nodes
That’s it for this first batch of progress reports from our GSoC students. Four more reports are in the part 2 blog post, and we should have a second progress report from all students towards the end of the coding period.
We hope that you will find good use cases for all the features that are being worked on, and we thank all students and mentors for their dedicated work on these projects!
-
+
\ No newline at end of file
diff --git a/article/gsoc-2019-progress-report-1-part-2/index.html b/article/gsoc-2019-progress-report-1-part-2/index.html
index 85bb0d41ee..efdaef89fd 100644
--- a/article/gsoc-2019-progress-report-1-part-2/index.html
+++ b/article/gsoc-2019-progress-report-1-part-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde18 July 2019
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.
As mentioned in the first part of this progress report, Godot is taking part in the Google Summer of Code (GSoC) programme for the second time, and we have 8 students working on specific projects for Godot Engine.
We’re now in the middle of the GSoC 3-months coding period, and we asked students to write a progress report to present their project and the work done so far. The 8 reports are split over two posts, the first 4 of which was posted yesterday. This second post will cover the remaining 4 projects.
Here is the list of projects and students with links to the relevant sections.
Light maps are a really easy way to improve performance on statically lit scenes. Instead of computing the amount of light that reaches a certain surface every frame for every light source, we precompute all this information and store it in a single texture. This means having lots of lights no longer creates a performance hit on the rendering pipeline, since all we need to do is sample a single texture and we get the amount of light coming from all light sources.
Godot’s 3.1 light mapper is based on the same approach used in global illumination. That means the whole scene is subdivided in a regular grid of voxels and, for each of these voxels, we compute the amount of light reaching it. This allows us to have some great results for computing real time illumination, but the discretization of the scene has various downsides (e.g. some walls may be thinner than the size of a voxel, therefore they can leak light through them).
The main goal of my GSoC project is to completely rewrite the light mapper in Godot and, instead of a voxel approach, use ray tracing to compute the scene lighting. This will hopefully give better looking light maps and will reduce the amount of artifacts such as self occlusions or light leaks.
Current progress
During the first weeks of coding I added caching to UV2 generation. The process of generating light map texture coordinates takes a while, and it was being triggered on every scene reimport. By adding a simple cache to it, we made it so that light map texture coordinates are only computed when there’s an actual change to the geometry of the mesh.
With that simple task out of the way my main focus went to getting the direct illumination pass done. That involved generating the actual light map texture and, for every light inside the BakedLightmap node, compute the amount of light reaching every texel.
Here you can see the Sponza demo model, with baked direct lighting, and the corresponding light map:
Note that this first pass is not taking occlusion into account yet. That will be added in the following weeks.
Next steps
I’m currently working on integrating Embree as a ray tracing library into the Godot editor. Once I get it fully working I will use it to add occlusion tests to the direct light pass as well as doing all the required computations for indirect lighting.
The first results will probably look noisy and with graphical artifcats, so I will spend some time implementing all the tips and tricks detailed in this wonderful article. If I still have some time left I will take a look at adding some sort of AI denoiser, but I can’t promise anything :)
While making medium to large scale games in Godot, many small bugs start to creep in that cannot be caught by the compiler. These can only be dealt with manually while debugging. This project will build a tool to be used semi-regularly to highlight these problematic pieces of code in an automated fashion. This essentially extends the scope of static checks, currently just done within each script, to operate across scripts and scenes.
It can be used to deal with things such as non-existent node being referenced in a get_node() call, wrong arguments in a function connected to a signal, etc.
What kind of static checks can be expected?
Within the time frame of this GSoC, these are the static checks that can be expected to be completed:
Check to ensure a script does not refer to a non-existent node in the scene (this can be a problem when nodes are deleted or the tree is re-organized).
Check to ensure that a script does not refer to a non-existent method/property in the node (this can be a problem when there is a change type operation).
Check to ensure that the arity and type of arguments declared in a function connected to a signal are correct.
However, this is not an exhaustive list and hopefully many more can be completed by the time GSoC ends.
Current state
UI
The UI so far is still a work in progress (since most of the work done so far is behind the scenes), however you can expect the final tool to reside here:
Behind the scenes
The way I’m going about this is to essentially go through each scene and within that, traverse through each script to check if there is any potentially problematic code. Then that particular code can be checked to ensure that it is correct (e.g. ensure that the NodePath in a get_node call does point to an actual node). Further optimizations will be done so it isn’t necessary to process the same scripts again and again.
Currently, the mechanism to traverse from scene to scene, as well as ensure that the scene files are valid, is complete. Most of the mechanism to traverse through any particular script is done as well. So, it can run through each scene file, make sure it’s valid, and extract scripts from the nodes within the scenes to perform static checks on them.
What next
The Scene Traversal mechanism needs to be fully finished. Once that is done, I can start working on the static checks. The few mentioned in this post will be created first and based on the time remaining, more can be implemented. The last step will be to tidy up the UI and ensure that the tool works with extensive testing. Looking forward to a fruitful next couple of months.
Motion Matching Implementation Using KD Trees – Aditya Abhiram
Project: Motion Matching Implementation Using KD Trees
Hey! This is Aditya Abhiram a.k.a. DestinyGamer. I am working on the implementation of Motion Matching in Godot.
First of all, I want to thank the Godot project and my mentors, Juan Linietsky and karroffel, for giving me a chance to work on this project.
Godot, being an open source game engine, was built with a never-ending wish of adding new features to it.
Motion matching is one of the latest features in game animation which is quite revolutionary. Usually, setting up a basic animation system needs a lot of work and time. Even after that, we barely manage to make a perfect one. Motion matching, on the other hand is a method where the computer chooses the best pose for each frame by itself from a huge database of motion capture (MoCap) data using some algorithm.
Choose the best pose for each frame and jump to it!
This wonderful feature needs to be included in Godot!
Overview
This project has three parts:
Cost function
Future trajectory prediction model
KDTrees for KNN search (optimisation)
We started off by collecting datasets for testing while reduz worked on the UI of the editor. Along with data collection, I tried out implementing KDTree and KNN search. The UI was ready by mid June and then I started adding and testing the KDTree and KNN search algorithms with it.
AnimationNodeMotionMatch in AnimationTree:
AnimationNodeMotionMatchEditor UI:
Just before the first evaluation [ed. after one month of coding], I successfully added KDTree and KNN search to the AnimationNodeMotionMatch.
During the evaluation period, I tried making a simple future trajectory prediction models.
After that, I started implementing Pose and Trajectory Matching (i.e. calculating the cost function using pose and root trajectory comparisons) without including KDTrees yet (just as a brute force attempt). I’m still working on fixing the crashes in this matching.
‘Animation Player not set’ error:
‘Root Motion Track not set’ error:
Things to do
Getting Pose and Trajectory Matching running without any crashes.
Adding Velocity Matching too so that the matching gets more natural.
Taking past data into account during matching, so that we won’t ignore weight-shifts and get a natural looking animation.
Replacing the brute force approach with KNN search using KDTrees.
Adding sliders for parameters such as Pose and Trajectory, etc.
Godot Engine is pretty easy to use for most things and is becoming a better competitor to Unreal Engine and Unity by the day. But one area where it’s lagging behind is in the way it handles file and network IO on various platforms, especially on systems like consoles.
Nowadays, all IO operations are cached to speed up access to data from hard drives or the network. The cache sits in RAM and holds on to information that is frequently accessed so we don’t need to wait a long time for the data. For desktop and mobile systems (like android and iOS), this may be less of a problem because the OS can provide caching for disk and network IO. But consoles and other more specialised systems may not have an OS that does this for us, which means we may need to do the caching ourselves.
The current mechanism that Godot Engine provides for such cases is pretty bad – it only reads ahead, it doesn’t allow for seeking backwards and it’s only for files on disk. My project aims to provide a more flexible solution that manages caching centrally, and allows for using different caching strategies as the situation demands through a C++ module which can be dropped in at compile time.
Current progress
As of now, about half of the project’s goals are complete. I have created a cache structure that can hold data from multiple files which may be cached under different policies like FIFO (first in, first out) or LRU (least recently used).
The system is designed so that the actual interaction with the network/file system, which may take time, takes place on a separate thread alongside the rest of the engine. If data is already in the cache because we’ve read ahead a little, access will be much faster. Otherwise, we only need to wait a little while the bits of the file that are needed are loaded in the background.
The engine sees a normal file interface which it can use to read, write and seek within a file. Behind this frontend, the module keeps track of what parts of the file are in the cache, and loads more of the file into the cache on demand.
The cache breaks each file into a bunch of equally sized parts which can be easily shifted in and out of the cache.
There are three different caching algorithms I’ve set up.
FIFO (First In First Out)
FIFO is a straigntforward algorithm that just reads ahead by some number of parts. If the cache runs out of space, this algorithm discards the oldest part first. This may be ok for a file that doesn’t ever need to be seeked through, and which will only be read sequentially.
LRU (Least Recently Used)
LRU is a great caching algorithm that handles cases where we may read old data again very well. My particular implementation keeps a list of parts in order of the time they were accessed. When we run out of space, we discard the part that was accessed least recently (hence the name).
Permanent store
Sometimes we may want to use a file for a really long time, to the point where it’s probably going to be open the entire time the game is running. Maybe it’s for logging, or for autosaving progress. I’ve included a caching policy for this use case as well. Parts of files that are accessed with this policy are cached in the same manner as with LRU, except that permanent cached parts cannot be replaced by parts of other files.
For example, if we have a choice betweeen a permanent part and an LRU part which may be replaced, we must choose to replace the LRU part instead of the permanent one.
Summary
Currently, files can be read from and I’ve got some GDScript integration set up to test things. I want to be able to write to files as well, but right now there are still a few bugs in the read logic that I need to squash.
What’s next?
For now, the module uses standard library file handling functions in the backend. These can be switched out for the platform specific unbuffered IO functions. That way, things won’t be cached twice by both the OS and the engine. I plan to add unbuffered versions of the FileAccess class specific to each platform for this reason.
By August, this module should be feature complete with regards to my proposal.
What more can be done?
I want to provide support for something like magic streams, which are a way to store assets as a contiguous stream of data, where assets are stored in the order they are accessed in a game. So for a game, if the splash screen asset is loaded first, and then a character model, the magic stream for the game would have the contents of the splash image file appearing first, then the contents of the model, and so on.
Magic streams are great because they reduce the amount of time spent seeking for hard drives (since all the assets are stored contiguously in one file), and could also be useful for streaming assets over the network (just one request for all the data).
I also think this module could serve as a basis for streamlining the asset loading pipeline for Godot engine, which is currently single threaded.
That’s it for this second batch of progress reports from our GSoC students. The first four reports will be can be read in the previous blog post, and we should have a second progress report from all students towards the end of the coding period.
We hope that you will find good use cases for all the features that are being worked on, and we thank all students and mentors for their dedicated work on these projects!
-
+
\ No newline at end of file
diff --git a/article/gsoc-2019-progress-report-2/index.html b/article/gsoc-2019-progress-report-2/index.html
index b7952715cb..65df6eb539 100644
--- a/article/gsoc-2019-progress-report-2/index.html
+++ b/article/gsoc-2019-progress-report-2/index.html
@@ -36,7 +36,7 @@
We hope that you will find good use cases for all the features that are being worked on, and we thank all students and mentors for their dedicated work on these projects!
-
+
\ No newline at end of file
diff --git a/article/gsoc-2019-progress-report-3/index.html b/article/gsoc-2019-progress-report-3/index.html
index 94892d0b36..b58a37fc42 100644
--- a/article/gsoc-2019-progress-report-3/index.html
+++ b/article/gsoc-2019-progress-report-3/index.html
@@ -50,7 +50,7 @@
We hope that you will find good use cases for all the features that they have being working on, and we thank all students and mentors for their dedicated work on these projects!
Remember that while the GSoC 2019 has ended, many of the features worked on by the students have yet to be formally merged in Godot Engine’s repository. The most mature ones will likely be merged in time for the Godot 3.2 release, while others might have to wait for Godot 4.0’s development cycle.
-
+
\ No newline at end of file
diff --git a/article/gsoc-2020-progress-report-1/index.html b/article/gsoc-2020-progress-report-1/index.html
index 4ad53c6191..6e845ed939 100644
--- a/article/gsoc-2020-progress-report-1/index.html
+++ b/article/gsoc-2020-progress-report-1/index.html
@@ -24,7 +24,7 @@
I will be sharing some testing builds if anyone is interested in a bug hunting trip… ;)
Extra
Other than that I will try to look at ways to improve the parts of Godot I worked on (depending on the free time I have), once everything is done this summer. Like the Theme editor, and adding submodules to Visual Shaders, so please feel free to suggest stuff that you think could help with anything you are having issues with.
That’s it for this progress report! You’ll hear more about each project as we draw closer to the end of the GSoC 2020 coding period.
A big thankyou to all students for their quality work and creative ideas to implement or improve those features in Godot, and thanks to all the mentors who support them!
-
+
\ No newline at end of file
diff --git a/article/gsoc-2021-progress-report-1/index.html b/article/gsoc-2021-progress-report-1/index.html
index f36b01adfa..b6eedcbf3f 100644
--- a/article/gsoc-2021-progress-report-1/index.html
+++ b/article/gsoc-2021-progress-report-1/index.html
@@ -20,7 +20,7 @@
What’s next
The next goal is to make the whole layout compact and getting rid of overlaps that occur between nodes in the same block. After testing it out on large graphs in both the VisualScript and VisualShader editors, and merging the feature in master, I’ll be adding the functionality to bind the nodes together in a comment node, so that when a comment node is moved, the nodes enclosed by it should also move with it intuitively, which is something currently missing in Godot.
Also, making this functionality work with the node auto-arrangement feature is on my to-do list. So, you can expect quite a few features coming up in the VisualScript and VisualShader editors.
The Command Palette provides a quick way to access commands that don’t have a key binding or would usually be hidden away in a menu.
Features commonly found in command palettes:
A single shortcut to invoke the palette.
A fuzzy matcher to find commands.
A way to see the direct shortcuts for next time.
Current progress
My initial proposal was to build upon the draft PR Add an editor actions API #47002 and use it to register command palette commands, which are searchable and executable from a command palette dialog. But after some discussion with my mentors we decided to use a new InputEventShortcut, which inherits InputEvent and would hold a reference to a Shortcut, i.e. a mapping between a keyboard input and a function.
So the idea is to register editor actions by creating an InputEventShortcut object for all the necessary actions and create a callable for the function Viewport::unhandled_input() and pass the created InputEventShortcut object as the argument. All these callables (commands) are stored in a HashMap with their shortcut_path as key. The Viewport::unhandled_input() function has also been edited to handle InputEventShortcut as an argument. I added a new function ED_SHORTCUT_AND_COMMAND which will create a new shortcut and register it as mentioned above.
For the frontend I inherited a ConfirmationDialog that has a LineEdit to search for commands and a Tree to show the search results. Each TreeItem (row/search result) has two columns which contain a command name and its shortcut if it’s bound to one. We can navigate the search results with arrow keys, execute the command with the Return key and exit the palette with Esc.
Result
Coming up next
Add more commands.
Add plugin support.
Make command palette to open scenes and scripts (Quick Open).
That’s it for this progress report! You’ll hear more about each project once they’re finished at the end of August.
A big thankyou to all students for their quality work and creative ideas to implement or improve those features in Godot, and thanks to all the mentors who support them!
-
+
\ No newline at end of file
diff --git a/article/gsoc-2022-progress-report-1/index.html b/article/gsoc-2022-progress-report-1/index.html
index 3df096d1a0..ff82756f62 100644
--- a/article/gsoc-2022-progress-report-1/index.html
+++ b/article/gsoc-2022-progress-report-1/index.html
@@ -16,7 +16,7 @@
Along with the basic feature and controls, some integrations were done:
When the Script editor is undocked, the last selected Viewport is shown.
When the Script button is clicked and the Script editor is undocked, the Script editor window is focused.
Undocking the code editors can be done using shortcuts and command palette too.
Window save and restore
Undocking the Script editor (or the Shader editor) on every editor restart and placing it in the second screen can be annoying. For this reason, the window positions, sizes, and other information for the code editors are saved when saving the editor layout and restored when the editor is reopened.
The new system can take into account changes in the user’s screens, like resolution changes or missing screens, and try to put the undocked window into another position. If the recover fails, the windows is attached into the editor window.
Future
The next step is to implement most of the feature available for the code editor to the docks (which are already undockable).
After them, I plan to work on the following tasks:
Add an icon for the “Make Floating” button.
Add a complex UI instead of the simple “Make Floating” action that allows to choose the screen where to place the undocked window.
Add some editor settings to configure the behavior.
Godot 4.0 announced its new GPU lightmapper back in 2020. It’s been two years since then, and a lot of work has gone into it. My project aims to further improve the 4.0 GPU lightmapper by porting some of the essential features from the 3.x CPU lightmapper and adding a new debug draw mode for visualizing the texel density of lightmaps.
Project overview and progress
Multi-image atlases
Previously every LightmapGI node used to store its lightmap atlas in a single large image. This meant that the larger scenes might refuse to bake because they don’t fit within the size limits of an image. I modified the implementation to allow saving the lightmap atlas as multiple images if it doesn’t fit inside a single image.
Soft shadows
The general idea behind soft shadows is to take into account the light source’s size instead of treating the light source as a point. When one also takes the contribution of light rays from parts of the light source other than its centre, there is a gradual transition from shadowed to fully lit instead of an abrupt change.
I added support for soft shadows to the GPU lightmapper by incorporating this idea in the lightmapper’s raytracing compute shader.
No soft shadows
With soft shadows
Debug draw mode for texel density
This will be a draw mode that previews the texel density of lightmaps (without actually (re)baking them). It will aid users in adjusting the lightmap scale of their objects.
How do you show the texel density visually?
The idea is to overlay a checkerboard pattern with the same square size (in texels) on the textures of all the meshes. Upon rendering, the checkerboard pattern will appear diminished in the regions with high texel density, and magnified in the regions with low texel density.
For this to work, the lightmap_size of each object would need to be read from the draw mode’s godot shader. We can conveniently use Godot 4.0’s per-instance uniforms to make this work.
I have created a crude proof of concept for this. Here’s a sneak peek:
UV2 texel density debug draw mode
Next steps
My priority would be to complete the texel density debug draw mode PR and get it merged. After that, I would like to take up an experimental task related to rendering.
Lastly, shoutout to my awesome mentors (clayjohn & jfons) for always coming up with ingenious ways to get around my blockers!
That’s it for this progress report! You’ll hear more about each project once they’re finished at the end of September.
A big thankyou to all students for their quality work and creative ideas to implement or improve those features in Godot, and thanks to all the mentors who support them!
-
+
\ No newline at end of file
diff --git a/article/guest-post-small-team-big-project-building-moonwards/index.html b/article/guest-post-small-team-big-project-building-moonwards/index.html
index 5caea5fa0f..f1d079fb0a 100644
--- a/article/guest-post-small-team-big-project-building-moonwards/index.html
+++ b/article/guest-post-small-team-big-project-building-moonwards/index.html
@@ -13,7 +13,7 @@
Sorry, your browser doesn't support embedded videos.
With just a little bit of work, we can make the Logger and Logger Console an add-on for anyone to use. There are a few features we would like to add first though before official addon release:
Make the color schemes recognizable for all types of color blindness.
Variable displays. Quickly add variables to watch in real time from the console.
Filtering logs by class that generated the log.
Filter logs by the name of the node that made them.
Filter by group the node is in.
The addition of a temp log level that will store logs you make while testing code.
A setting for release versions to store logs in a way that is unobtrusive for players and easy for devs to check.
Another addon that will be of help to the Godot community is the Docs Generator. A tool for automatically generating documentation by reading your project’s GDScript files. The documentation generated is styled like Godot’s read the docs pages. All generated docs will be saved as files in the directory of your choosing as Markdown files. This way you can choose how to best integrate them within your chosen documentation website. The tool is currently in early alpha, so not all features are implemented yet. You can take a look at the early prototype here. Connect with me on Fosstodon or Twitter.
I have a lot planned after the initial alpha release of Moonwards. The two plans I am most excited for are refactoring Moonward’s UI scene and resource management to serve as an example of best practices. Our team’s other plan is making a tool for any project to let players make custom controls in game.
-
+
\ No newline at end of file
diff --git a/article/handling-axis-godot/index.html b/article/handling-axis-godot/index.html
index a88e288e0a..b82f805e87 100644
--- a/article/handling-axis-godot/index.html
+++ b/article/handling-axis-godot/index.html
@@ -16,7 +16,7 @@
and this will handle buttons, keys, axes, triggers, etc. transparently.
Dealing with two separate systems (actions and axis mapping) would have led to many complex GUI settings (up to 15 in Unity) and as considerably more complexity in the Input mapping API.
The solution presented above was implemented by a minimal amount of added lines of code to the existing action system. It requires a tiny bit more code to read an axis, but it makes remapping and action management incredibly easy!
Please take the time to give it a try! Even if this approach is not obvious at first, we strongly believe that users will appreciate it in the long run. If you face problems with it, don’t hesitate to give us your feedback in the Github issues. :)
-
+
\ No newline at end of file
diff --git a/article/headsup-vulkan-merged-master-branch-unstable/index.html b/article/headsup-vulkan-merged-master-branch-unstable/index.html
index bd72d3e6a2..c0d573ead5 100644
--- a/article/headsup-vulkan-merged-master-branch-unstable/index.html
+++ b/article/headsup-vulkan-merged-master-branch-unstable/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde11 February 2020
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.
In many Git-based development workflows, the default master branch is where most of the development happens. It can be from well-defined feature branches (or in our situation Pull Requests) that are merged into master once ready, or with development work happening directly on this branch. Whatever the workflow, the master branch will rarely be meant for use in production, and end users are only encouraged to use it if they want to help with day-to-day testing, not if they want to get some work done :)
As we do our releases directly from the master branch after a stabilization period (feature freeze, release freeze and then branching off to e.g. 3.2 when releasing), many of our users are used to running the master branch or a nightly build as a daily driver.
This changes today as we merge our work-in-progress Vulkan port (until now in the vulkan branch) in the master branch.
Why merge now if it’s WIP?
The Vulkan port is not ready yet, but we need to get it merged into the master branch as a lot of further development planned for Godot 4.0 depends on it.
We plan to rework a lot of Godot’s internals (core) to allow fixing long-standing design issues and improving performance (including GDScript performance improvements). Moreover, our long-awaited port to C++14 will also happen now that the vulkan branch is merged into master, and many other codebase-wide changes were waiting for this: code style changes, Display/OS split, renaming of 3D nodes to unify our conventions, etc.
The scope of the planned changes means that it would be impossible to do these changes in the master branch while keeping the vulkan branch separate, just as it would not be possible to do all those changes in the vulkan branch itself before merging into master: any rebase/merge would become extremely difficult due to the sheer amount of lines of code that will change.
Up until now, we’ve been very cautious with regard to what changes we allow in the vulkan branch, as well as what new PRs we merge in master, to ensure that the vulkan branch can always be rebased on top of master for a later merge. I’ve been rebasing it periodically over the past 8 months, and even though we’ve been very conservative in the scope of the changes, in later months a full rebase could easily take me a full day of work.
So we need everything in the main branch to stop limiting ourselves.
What changes?
The vulkan branch includes the preliminary support for the Vulkan graphics API, which Juan has been covering in many devblogs (see e.g. last progress report).
In its current state, the Vulkan port works on Linux, macOS and Windows only. Support for other platforms will be restored in coming months prior to the 4.0 alpha release.
Godot 3.2’s GLES2 and GLES3 backends have been disabled as they do not match the new design of the RenderingDevice API. The GLES3 will eventually be completely removed, and the GLES2 backend will have to be ported to the new API. This will also be done in coming months.
In the meantime, it means that the master branch will be Vulkan and desktop-only for some time. Please bear with us during this transition period, and be assured that bringing back mobile and web support are high on the priority list. (Note that the actual platform ports are of course still included in the latest code, but without a properly setup rendering backend, they don’t have anything to show.)
Implications for users
If you’re a “regular” Godot user, nothing changes for you. We strongly recommend that you use the latest stable version, which is Godot 3.2. We’re all hyped for Godot 4.0, but at the current stage, it’s much saner to wait for engine developers to do their Earth-shattering magic. Once we have an alpha build that it worth testing broadly, we’ll be sure to let you know :)
If you need custom fixes for your game, feel free to track the stable 3.2 branch, which will be used for all upcoming 3.2.x maintenance releases.
Implications for code contributors
Even though it’s less stable and lacks full support for all platforms, the master branch stays our main development branch, and any Pull Request should be merged in that branch in priority. Relevant changes merged in the master branch can eventually be cherry-picked in the 3.2 branch for maintenance releases (especially bug fixes).
As the master and 3.2 branches will quickly diverge a lot, cherry-picking changes may end up being non trivial, so it might become necessary for 3.2-relevant PRs to also see a custom version for the 3.2 branch. Yet, we ask that you please focus first on master and discuss with us whether a 3.2-specific PR would be welcome. We do not want to merge new features or experimental changes in the 3.2 branch that could compromise its stability.
Many of them are relevant and would be worth merging, yet the merge of the vulkan branch and the upcoming refactoring work will introduce complex merge conflicts for the vast majority of them.
Ideally, we’d want to clear that backlog before doing such massive codebase-wide changes, but we know from experience that we do not have the capacity to do so. It’s a nice problem to have, but Godot’s popularity and the sheer amount of PRs that we get on a daily basis are extremely time consuming to handle, and such a backlog would take us many months to resolve (while struggling to keep on top of new PRs).
On top of that, many of these PRs pre-date or did not follow our new proposals workflow, which aims at ensuring that all changes we merge are actually useful additions to the engine and supported by the community. Reviewing PRs which have not been pre-approved at the idea/design stage can be very difficult, as we don’t always know ourselves whether a code proposal is a good idea: we can review the code, but reviewing use cases is a difficult task for which we need help from experienced community members.
We discussed this at the Godot Sprint with core contributors in late January, and we decided on the following approach as the most practical one. We will close all pending PRs, asking their authors to:
Review if the proposal/bugfix is still wanted/necessary in the current master branch
For feature proposals, ensure that they have been approved via the godot-proposals repository
If relevant, rebase (or reimplement) the patch on the current master branch and open a new PR (referencing the old one for completeness)
While closing PRs may seem a bit abrupt, we ask all contributors to understand that this is done to help us cope with the sheer amount of proposals in parallel to having to refactor a lot of the engine’s codebase. This closing does not mean that we reject the PRs, nor that we do not seem them as worthy contributions. But by asking the authors to re-assess their own proposals and make them compatible with Godot 4.0, we will save a lot of precious development time and get ourselves some breathing air in the current overcrowded PRs.
Closed PRs will have the salvageable label, which we use to denote PRs with code that could be salvaged to make a new, updated (and possibly improved) PR, either by the original author or by a new contributor. So we will not lose code in the process, since everything will still be accessible from the closed PRs and easily identifiable thanks to the salvageable label.
This is definitely a tricky time for core developers and engine contributors, and we ask everyone for their understanding. I for one feel a moral obligation towards all contributors to review their work and get it merged if it’s good, and so this proposed cleanup is not an easy decision for me to act upon, but I do see that it’s the most efficient way that we have to avoid getting stuck in an endless PR backlog (as we were to some extent following the 3.1 release, even though the backlog at that time was barely 250 PRs…).
Note: We’ll wait a couple of weeks before closing all older PRs as outlined above, since many codebase-wise changes are planned in coming days. We do not want to encourage all contributors to rebase their work endlessly in the middle of those changes, so it will be better to send this signal once the master branch is ready to welcome those refreshed contributions.
-
+
\ No newline at end of file
diff --git a/article/help-complete-translations-godot-3-0/index.html b/article/help-complete-translations-godot-3-0/index.html
index c203ed3f22..3243cbf02a 100644
--- a/article/help-complete-translations-godot-3-0/index.html
+++ b/article/help-complete-translations-godot-3-0/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde22 November 2017
This article is from November 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.
Since Godot 2.1, we have support for translating the Godot editor, and recent stable releases have almost complete translations in Spanish, German, French, Russian, Chinese Simplified, Korean and many others!
As we are nearing the 3.0 release, it’s the right time to contribute to the localisation effort and make sure that your native language has an accurate and complete translation upon release.
We handle translations on Hosted Weblate, so you can register there and contribute directly to your favourite language. There are some reviewing/commenting features on the website, but they aren’t used yet consistently by all translations, so if you need to discuss some changes, the best would be to contact other translators of your language by email (you will find their contacts in the header of the corresponding PO file).
No need to make a Pull Request with your changes, everything should be done on Weblate and I will sync the changes with the git repository every now and then (and of course before each release).
You will be able to test the current state of the existing translations in Godot 3.0 beta, which should arrive in a few days. Stay tuned!
-
+
\ No newline at end of file
diff --git a/article/help-us-complete-godots-api-reference/index.html b/article/help-us-complete-godots-api-reference/index.html
index b8ec6eb4e5..80fe2385d1 100644
--- a/article/help-us-complete-godots-api-reference/index.html
+++ b/article/help-us-complete-godots-api-reference/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde14 July 2016
This article is from July 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.
A bit less than 3 months ago, we made a call for contributors to help us work on filling the class reference. We got a handful of new documentation writers who did a great job, helping document some of the most important classes for the upcoming 2.1 release. Many of those improvements were backported to the stable 2.0 branch too and are available in the freshly released 2.0.4.1 and on the online documentation already.
What’s the current status?
We all love some stats every now and then, so here are some numbers. Since our call for help, 900 methods have been documented, i.e. an increase by almost 50% compared to the previous status (2634 documented today vs. 1730 at the end of April)! It brings us short of 60% of completion on the methods’ side, which is arguably the most important one (constants or member variables often have self-explanatory names, though we will definitely document them all too little by little).
We still need your help to reach 100%!
As you can see on the above graph, the progress has been impressive lately, but there’s still a lot of work to do. Sadly we’re still only a handful of contributors working on the documentation, so the work is huge.
If we can grow the team and get more regular contributors, this would reduce the load for everyone and we should be able to close the gap pretty fast.
To write documentation for Godot, you don’t have to be a power user, but mostly you need to have some time available. So if you do, please consider helping us with the effort! Check the previous blog post on this topic for all the details about the workflow. Note the link to the class reference status which shows the current progress and who’s working on what.
If you have any questions, get in touch with the Documentation team on Freenode IRC, channel #godotengine-doc.
-
+
\ No newline at end of file
diff --git a/article/help-us-reach-next-funding-goal-ensure-continued-c-support/index.html b/article/help-us-reach-next-funding-goal-ensure-continued-c-support/index.html
index 1072f613ff..505022480e 100644
--- a/article/help-us-reach-next-funding-goal-ensure-continued-c-support/index.html
+++ b/article/help-us-reach-next-funding-goal-ensure-continued-c-support/index.html
@@ -5,7 +5,7 @@
Juan Linietsky10 July 2020
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.
During the past year, Ignacio Etcheverry worked on significantly improving C# support and its integration in Godot, adding support for Android, HTML5 and iOS, as well as popular third party IDEs. This was financed thanks to a generous donation from Microsoft. Unfortunately, due to the Covid situation, the renewal of this grant has been suspended and is uncertain.
Ignacio excelled at his work, resulting in a significant increase of C# users in Godot (which is near 25% now, and which will probably grow further when the recently implemented mobile and HTML5 support becomes stable).
While GDScript remains the primary programming language for Godot (George Marques is working full-time on it) due to its soft learning curve, ease of use and editor integration, the improved C# support has proven that there is a very significant amount of users who find C# better suited for their needs and that it’s key for the project to continue supporting it.
There is still a lot of work remaining and also upcoming tasks like ensuring Godot supports the new upcoming .NET version. Additionally, we want to ensure continued work to ensure bug fixes, stability and usability improvements for C#.
Next funding goal
We announced a funding reorganization some days ago and we are soon going to announce new hires that will start working full-time in the coming months. To ensure that the project has sufficient funds to hire Ignacio in the long term (or at least until the new grant can be worked out), we are hopeful you can help us reach the next funding goal at $15,000.
-
+
\ No newline at end of file
diff --git a/article/help-us-write-floss-manual-godot/index.html b/article/help-us-write-floss-manual-godot/index.html
index dfe10c17b2..eac15a4421 100644
--- a/article/help-us-write-floss-manual-godot/index.html
+++ b/article/help-us-write-floss-manual-godot/index.html
@@ -5,7 +5,7 @@
Ariel Manzur7 September 2015
This article is from September 2015, 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.
Do you love FLOSS Manuals? Do you love France in the summer? Come help us do a Booksprint for Godot Engine next week!
As you may know Ariel is spending some time in Hamburg, and since he’s so close to France, the people from Floss Manuals FR invited him to do a Booksprint with them for Godot Engine! If you’d like to help, come down to Rennes, France next weekend to hang out! Check out these posts (in French) for more information:
Edit: The Booksprint was a success and the draft of the resulting book can be consulted online on FlossManuals.net. All sections are not 100% finished yet, but feel free to give us suggestions for improvements!
-
+
\ No newline at end of file
diff --git a/article/here-comes-godot-3-2/index.html b/article/here-comes-godot-3-2/index.html
index c8317c9027..909b30c495 100644
--- a/article/here-comes-godot-3-2/index.html
+++ b/article/here-comes-godot-3-2/index.html
@@ -9,7 +9,7 @@
And many other things!
Coding tools
Our contributor Geequlim with help from the GSoC 2019 student Ankit Priyarup implemented a Language Server Protocol for GDScript, which is used to provide code completion, documentation and other tools to external editors. As of now, there are client plugins for VS Code plugin and Atom.
There were also many improvements to the built-in GDScript editor:
While working on LSP features, Geequlim also took the time to improve the code completion feature of the built-in editor, notably showing different icons based on the type of code completion option (classes, methods, properties, constants, etc.).
Juan implemented a “pseudo 3D” feature which enables an easy way to add depth to 2D games by using several canvas layers, making them follow the main viewport and scale automatically to fake perspective.
Support for texture atlases also comes back to Godot with 3.2, with an easy way to generate deterministic atlases directly from the editor.
Along with various performance optimizations for Godot’s AStar implementation, an AStar2D variant was implemented to simplify its use for 2D pathfinding.
After having done a lot of work on the usability of GUI Controls in Godot 3.0, Gilles Roudiere did another pass at improving UX based on user feedback, with a pull request improving the anchors and margin workflow.
To add to the 3.2 feature set before diving into Vulkan, Juan implemented audio stream generators which let you easily generate sound waves by pushing individual frames or a buffer, and a spectrum analyzer.
This greatly simplifies the process of generating e.g. collision shapes to add collisions to any given 3D mesh.
Many more features
We would like to take the opportunity to thank all of our amazing contributors for all the other great features merged since 3.1, and the hundreds of bugfixes and usability improvements done over 2019. Even if not listed here, every contribution makes Godot better, and this release is truly the work of hundreds of individuals working together towards a common goal and passion.
For more details on other changes in Godot 3.2, please consult our curated Changelog, as well as the raw changelog from Git (chronological, or sorted by authors).
Giving back
As a community effort, Godot relies on individual contributors to improve. In addition to becoming a Patron, please consider giving back by: writing high-quality bug reports, contributing to the code base, writing documentation, writing tutorials (for the docs or on your own space), and supporting others on the various community platforms by answering questions and providing helpful tips.
Last but not least, making games with Godot and crediting the engine goes a long way to help raise its popularity, and thus the number of active contributors who make it better on a daily basis. Remember, we are all in this together and Godot requires community support in every area in order to thrive.
-
+
\ No newline at end of file
diff --git a/article/hero-wanted-31-version/index.html b/article/hero-wanted-31-version/index.html
index 472bbecfe3..41fefb5ec9 100644
--- a/article/hero-wanted-31-version/index.html
+++ b/article/hero-wanted-31-version/index.html
@@ -5,7 +5,7 @@
Juan Linietsky8 September 2018
This article is from September 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.
Looking for a good chance to learn about Godot internals and development? Want to become a hero and help with the release of Godot 3.1? This is your chance!
Like every time we release an alpha, many issues were tagged as “Hero Wanted” and include a description of how they could be fixed. You can take a stab at them and create a pull request with the fix.
Don’t know how to set up a development environment? Here are guides for compiling Godot on Windows, Desktop Linux and OSX. You will most likely need an IDE for editing code, which can be Qt Creator (Scroll down for the stand-alone installer) or Visual Studio Code. Guides on setting up the IDE can be found here.
If you feel this is too easy for you and want a bigger challenge, you can help other contributors with their issues.
-
+
\ No newline at end of file
diff --git a/article/hero-wanted-campaing-fixing-final-bugs-launchs/index.html b/article/hero-wanted-campaing-fixing-final-bugs-launchs/index.html
index 890b095441..8af938c13d 100644
--- a/article/hero-wanted-campaing-fixing-final-bugs-launchs/index.html
+++ b/article/hero-wanted-campaing-fixing-final-bugs-launchs/index.html
@@ -6,7 +6,7 @@
definitely need a hand to speed up the work!
Because of this, we are re-launching the Hero Wanted campaign, this time it’s the ultimate battle!
Hero Wanted (v2)
While most issues require more experience with the codebase, we have marked a good amount of issues with the “Hero Wanted!” tag. They include a description on how the problem can be approached, so it’s great for new contributors unfamiliar with the code.
Feel free to join irc (#godotengine-devel) if you need assistance from other devs. We are counting on you!
-
+
\ No newline at end of file
diff --git a/article/hero-wanted-help-fix-remaining-issues-30/index.html b/article/hero-wanted-help-fix-remaining-issues-30/index.html
index bf1959ff6e..38541a2367 100644
--- a/article/hero-wanted-help-fix-remaining-issues-30/index.html
+++ b/article/hero-wanted-help-fix-remaining-issues-30/index.html
@@ -8,7 +8,7 @@
We may announce real rewards later, though.
-
+
\ No newline at end of file
diff --git a/article/heroic-labs-supports-godot-development/index.html b/article/heroic-labs-supports-godot-development/index.html
index 185688ee48..3f4c5b34c9 100644
--- a/article/heroic-labs-supports-godot-development/index.html
+++ b/article/heroic-labs-supports-godot-development/index.html
@@ -6,7 +6,7 @@
For this occasion, we asked Heroic Labs co-founder Mo Firouz to write some words about the company, why they chose to support Godot and their plans to integrate Nakama with our engine.
Imagine a world where all music had been written for piano.
In a piano-only world, we’d never have the guitar solo from Comfortably Numb, or the drum loop from Straight Outta Compton, and the Flight of the Bumblebee would lose its frantic energy.
Pianos are wonderful but the world’s richer for all the many ways that we can make music.
At Heroic Labs, we see games development in a similar way. The rich variety of tooling available to games developers has delivered an explosion of creativity over the past decade.
From match-3 puzzlers to immersive first person space operas, video gaming is an art form as varied and valuable as literature, film, and theatre.
And that’s why we’re excited to support the development of the Godot Engine as a sponsor.
Democratising game development
I was lucky. I grew up in a country and a time where people did their gaming on computers, rather than consoles.
Commodore Amigas, Atari STs, and early PCs made it easy to learn the ropes of game development in accessible languages like BASIC. That meant the path from gamer to game developer was inexpensive and usually free.
Today, open source game development tools do a similar job. They help everyone –– from indie developers to AAA studios –– to focus on creating the best game rather than having to rebuild a physics engine, shift graphics blobs manually in memory, or develop reliable back-end infrastructure.
That’s why we created Nakama and made it open source. We wanted game developers to have access to the same high quality back-end functionality that’s available to developers working in other industries. Crucially, we wanted to make sure that anyone could build their game with Nakama, whether they’re learning in their bedroom, bootstrapping as an indie dev, or trying something new at a big studio.
We’re thrilled that Godot shares our passion for open source tooling and we’re excited by the possibilities unlocked by combining Godot and Nakama.
What comes next?
Nakama is a real-time, competitive, social back-end that helps game developers create compelling multiplayer experiences. Already we have integrations with Unity, Unreal Engine, Swift, Android, and more.
Right now, we’re working on our integration with Godot Engine and we’ll post an update once it’s available. Nakama and Godot together will give a whole new generation of game developers the opportunity to build resilient, beautiful, and immersive gameplay experiences.
Welcome to Heroic Labs in the Godot community, and many thanks for your support!
-
+
\ No newline at end of file
diff --git a/article/home-sweet-home/index.html b/article/home-sweet-home/index.html
index b49a2beaf4..f7d82c9f7c 100644
--- a/article/home-sweet-home/index.html
+++ b/article/home-sweet-home/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde21 February 2016
This article is from February 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.
Here it is: Godot Engine’s new homepage! Some of you might have been awaiting it for a long time, while others might have never used the previous website, so we will recap what motivated modifying the website again.
Thanks enormously to Andrea Calabró, Alket Rexhepi, Hugo Locurcio (Calinou) and Rémi Verschelde (Akien) for their hard work!
Note: The old forums (and rest of the OpenProject website) can still be accessed for now on op.godotengine.org.
Why change again?
The early Godot users might remember that we used to have a WordPress-powered website in 2015, with a self-hosted forum and the official documentation on Godot’s GitHub wiki. With the growing community and the project getting more and more new contributors, we wanted to have a platform that eases the project management so that we can work efficiently in teams. It was also becoming clear that GitHub’s very limited permissions management would not let us have contributions on the wiki without giving push rights on the source code to everybody (!), so we needed an alternative for the documentation.
Some Godot contributors (mainly Theo Hallenius – TheoXD – who has our biggest thanks and appreciation for carrying out this task) put a lot of time in setting up an OpenProject instance to replace the previous website. OpenProject is an open source project management system that features most of what we needed in the same software: tasks management, wiki, forum, blog, and good possibilities for handling localized websites. In contrast to setting up several separate software packages, OpenProject seemed like the obvious way to go.
Unfortunately, OpenProject proved to be too complex of a beast for us. It was difficult to find contributors who could spend enough time to learn how its backend works and we also ran into performance problems we couldn’t figure how to fix. As a result, the site looked unpolished and ran slow.
New website and its tools
So we decided to make a new homepage that we could easily theme with PHP, HTML and CSS that most of us know quite well, and to which we could easily add components little by little to match the needs of the community (did I hear someone say “asset sharing system”?). After having difficulties with a monolithic platform that was too big for us, we decided to go for a more modular approach using tools that should be easy to maintain by our current and future contributors.
Main website
For the landing page, we wanted a lot of technical freedom to theme everything as we wanted, and as little clutter as possible to ease the maintenance. We worked first on the design, HTML and CSS implementation, and finally decided to use the lightweight OctoberCMS as a backend, which powers among other things this simple news section.
Thanks to this straightforward setting, we could easily design good looking (we hope!) pages to showcase Godot and its features, make the downloads easily accessible, etc. In the future we would like to add a section showcasing games made using Godot.
Q&A platform
As we increasingly noticed that people were asking many technical questions on the Facebook group, which provides no good search feature nor search engine referencing, we decided to setup a Question2Answer instance, also in PHP and easy to customize with a great number of plugins. It is very similar to popular technical platforms like StackExchange or StackOverflow, and should help increase the visibility of Godot-related questions and their best answers. Check it out!
For the time being we also propose specific categories to showcase Godot games and WIPs and discuss off-topic stuff in the Q&A - this used to be in the forums but we did not want to setup yet another new tool just yet. This might change in the future if/when we settle on a better-suited solution. In the meantime, you can still access the old forums.
Sphinx documentation
Finally, to make the documentation easier to contribute to, we chose to use the well established Sphinx documentation generator. It allows us to have the source of the documentation in a public git repository, which means that everybody can easily contribute to the documentation will pull requests, and it’s easy to keep track of changes to any page using git features. Sphinx then generates HTML pages based on this source, which we can then host on our website.
To make things easier to manage, we use the open source readthedocs.org frontend, which rebuilds the HTML documentation each time the git repository is updated (as well as PDF and Epub versions!), and enables us to handle different versions of the documentation (e.g. for each Godot version, though for now there is only the “latest” branch which might become “2.0”) as well as translations. We’ll post more about this documentation and how to contribute to it in the future!
That’s it for today! We hope that you will like Godot’s new home, and we will gladly welcome your feedback on IRC or in the Facebook group. The current website is not final, we’ll continue to improve it little by little to make it as functional as possible.
-
+
\ No newline at end of file
diff --git a/article/how-actually-make-your-dream-game/index.html b/article/how-actually-make-your-dream-game/index.html
index 15c3c7b255..01209a5ecc 100644
--- a/article/how-actually-make-your-dream-game/index.html
+++ b/article/how-actually-make-your-dream-game/index.html
@@ -8,7 +8,7 @@
What matters is that the experience feels great. Usability wise, the prototype must feel final or near final. It must convey your idea as best as possible.
Iterating in this phase before moving to the next is vital. Don’t leave any core functions left to test, and keep doing changes to it until it feels perfect.
Anything core not resolved here will be a pain to fix later on. This means that controls have to feel smooth and action rewarding. It has to click and show your idea.
Ask for feedback as much as possible here!
Money wise, the prototype stage is the best to find seed capital investment. These type of investors will give you enough money to develop a vertical slice (next section), and will ask for a considerable chunk of your gross earnings (usually around 30/40%).
The rationale behind seed capital investment is that they invest tiny amounts on a large amount of unproven, high-risk projects. If one of them is a critical success, they make a huge amount of money.
Making a vertical slice
If you are making the whole game on your own, on your free time, or have some investment it may not be necessary to do this step. Otherwise, this is the key step to secure investment for the whole game (or until Alpha).
The idea of a vertical slice is to have a small chunk of your game, but this chunk must be final quality.
As an example, if your game has 30 levels (missions, scenes, locations, etc), you make 2 or 3 of them. They need to be absolute and final quality. Even references to the rest of the content must be there and visible, even if trying to access it does not work.
They don’t need to be the first parts of the game, it can be random sections (though a good intro scene can be really good, even if more difficult to achieve).
Why is the vertical slice so important to get investment? For the following reasons:
1) It reduces risk for the investor
Investment is all about risk. The lowest the risk, the highest the chance to get investment. If a prototype shows that the idea works, a vertical slice shows that you are capable of creating the whole game.
2) It makes the development cost estimation reliable
Up to this point, you should know how much did it cost and how long did it take to make the vertical slice.
This makes extrapolation possible: If creating 10% of the game (the scope of the vertical slice) costs $20k, you can easily estimate that the final cost (100% of the game) will be around $200k.
3) It makes it easier to adjust to different budgets
Many publishers and investors may not have enough money available to make a game for the length and content you want. The vertical slice allows you to extrapolate how much content you would need to cut in order to fit their available budget.
Developing until Alpha
This is where most developers make another fatal mistake. Do not add any more final assets (art, sound, etc.) until you hit the Alpha stage. Always use placeholder art. The only exception here, if the type of game requires it (e.g. a fighting game), is animation.
The whole game, as in, all the content must be developed with placeholders (i.e. rough sketches, blocks, CSG, etc.).
I know it can be very frustrating, as seeing things come to life is enormously rewarding. Still, however, the temptation must be resisted.
There are many key reasons for doing this:
1) Gameplay is top priority
What defines your game is good gameplay. It must work as best as possible, so it only makes sense to develop all the content first. Make sure all features are implemented and that the game can be played from start to finish. Control must feel great, usability must feel great.
Ironing out all problems here is cheap because the art does not need to be redone.
2) Alpha is great to get funding
Alpha is the point in development when you have the most strength (and ease) to negotiate investment and publishing. This is because:
You can show that you can make all the final assets and you know how long it takes (thanks to the vertical slice).
You can show that the game, with the full content, works (you can literally play it and show that it’s good/fun/etc.), so there is no risk it will turn out bad.
You didn’t spent that much yet, as this was only done with mostly programmers and one or two artists/animators/game designers.
Real investment is hiring the rest of the artists (animation, graphics, music, sfx, vfx, etc.). to finalize the game.
As a result, the development risk is much lower here. This makes it easier to get a better deal.
Fill it with assets, go towards Beta!
Beta is pretty much finishing the whole, entire final game (save for bugs and maybe small very minor tweaks). It means creating all the missing assets to complete it.
This stage is very rewarding and enjoyable, but it’s pretty difficult. From a large company to a sole indie developer, filling the game with the final assets is always done near the end of development.
For indies, this is the right time to hire someone to do the art, music, vfx, etc. You know that requirements (and the game itself) won’t change so you will spend less money. You will be able to ask for precise budgets and sign specific contracts for the content that needs to be done.
This avoids the very common problem of having to hire an artist on a monthly basis and then running out of money to pay him/her because development took longer than expected.
Typical Alpha->Beta tasks, besides final assets, are translations, cinematics, voice recording, etc.
Gold
A game goes gold when all bugs and small minor quirks are ironed out and the game feels stable enough. This can take a considerable amount of time, so many studios just launch the game before the actual gold and fix bugs with updates. This sucks, but the industry got used to it.
Publishing
My experience with publishing is mixed. Publishers generally play bets with their games. They finance many projects, but only really invest (in promotion) in those that do well in sales. The ones that don’t will rarely get any money spent and will be left to die. This is the law of life.
It’s as you heard. Even if you get a publishing deal, it does not warrant you get money invested in promotion. The only situation that can get you a better deal (publisher will accept spending up to certain amount on promotion) is approaching a publisher with a finished game, or in Alpha at most.
At first, I was angry at this fact, but I understand now that it’s the most natural course of action to do for a publisher. They are companies, not charities.
Also, don’t get me wrong on this. Publishers still make a big difference. Even if they don’t invest money in promotion, they usually have very oiled channels with media and many even have cult followings (like Atlus or Daedalic) that will purchase their games. They also know their target markets well so, even if your game doesn’t sell, it does not mean they did nothing by not promoting it.
In most cases, I found out you can negotiate with the publisher that they return the publishing rights to you if the game makes less than a certain threshold of earnings… so hope exists to pitch it somewhere else. Of course, if you got investment from a publisher, they will require you to pay it back before this happens (which can be negotiated with the new publisher).
That said, my experience on this is that if a game is not selling well, the chances of it doing better with a lot of promotion money thrown on it are still slim.
Regarding engines, you might have heard some people say that publishers request you to use Unity, Unreal or a specific engine. This is a lie, I published dozens of games with Godot for console, mobile and PC and none ever questioned the technology.
The only case where you might hear this is when making work for hire games for third party intellectual properties (such as Disney, Lego, etc.). Some of them ask you for the source code in order to do changes themselves without your support. It’s up to you to negotiate this.
Self publishing
Self publishing is extremely difficult. Doing all the promotion work can take a long time, even if you learn how to do it. I know some smaller publishers can do this in exchange of sales cuts (or a monthly pay). I feel most are scammers though, so just check how well did their other published games do. SteamSpy can be a great tool.
Closing words
As you see, the whole process of making a game is incredibly complex and success is not warranted, but this article hopefully got you through the most important parts of the process (any feedback welcome from those with more experience).
Nowadays, it is estimated that one in ten games that get investment is a success, and only two or three recover the investment (this may vary depending on the source of course…).
But if you get good at it, it’s something you can live of. If you repeat the prototype/vertical slice/alpha/beta/gold/publishing cycle enough times, I think the chances of being really successful in your lifetime are actually very high.
-
+
\ No newline at end of file
diff --git a/article/html5-export-profiling/index.html b/article/html5-export-profiling/index.html
index c9162e727e..c51f664f63 100644
--- a/article/html5-export-profiling/index.html
+++ b/article/html5-export-profiling/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli28 December 2019
This article is from December 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.
Hello Godotters, as part of my October work (sponsored, as always, by Mozilla) I’ve been working on getting the script debugger and profiler to work with HTML5 exports. This, along with the ability to run HTML5 exports in debug mode, is a powerful new tool in the hand of Godot users who want to develop or port the game and applications to run inside the browser.
The following section is a brief technical excursus on the internals of godot debugging and profiling. You can jump to the next section to see all the cool things that will be available for HTML5 debug exports.
Debugger Connection
ScriptDebuggerRemote and ScriptEditorDebugger are the two classes that manages respectively the exported client and the editor server connection for the debugger.
Those classes have seen quite a few updates in the past years, grew quite a bit since their original design, and for this reason most of the serialization and message logic is hard-coded.
This will likely change in the future, but in the meantime, I focused on extracting the low level handling of the connection from them to accomodate the need to support other protocols beside TCP (in this case, WebSocket for HTML5).
First, two new interfaces where created: ScriptDebuggerConnection and ScriptEditorDebuggerServer. Their implemention, provides access to the low level network connection, without the need to know about serialization and messages. Both a ScriptDebuggerTCP and a ScriptEditorDebuggerTCP where created as default, and the websocket module now provides its own ScriptDebuggerWebsocket and ScriptEditorDebuggerWebsocket implementation.
The Javascript platform, and javascript “run native” will automatically select websocket for you.
Supported features
All the supported feature of the debugger should work, except for breakpoints. This is a limitation due to the asynchronous nature of browser networking and might potentially be addressed in the future using WebAssembly threads or emscripten asyncify.
Note: This work is not merged yet into master.
Here are a few screenshot of what the profiler connected to the HTML5 export.
-
+
\ No newline at end of file
diff --git a/article/hugo-locurcio-hired-improve-godots-web-infrastructure/index.html b/article/hugo-locurcio-hired-improve-godots-web-infrastructure/index.html
index 008f60e725..0e60672edb 100644
--- a/article/hugo-locurcio-hired-improve-godots-web-infrastructure/index.html
+++ b/article/hugo-locurcio-hired-improve-godots-web-infrastructure/index.html
@@ -13,7 +13,7 @@
Alternatively, you can watch the godot-website repository to get notified of all new issues and pull requests related to the website.
-
+
\ No newline at end of file
diff --git a/article/importing-3d-assets-blender-gamedevtv/index.html b/article/importing-3d-assets-blender-gamedevtv/index.html
index 7fdf1f5ee1..39b26ab2dc 100644
--- a/article/importing-3d-assets-blender-gamedevtv/index.html
+++ b/article/importing-3d-assets-blender-gamedevtv/index.html
@@ -105,7 +105,7 @@
Games
-
+
\ No newline at end of file
diff --git a/article/improvements-gpuparticles-godot-40/index.html b/article/improvements-gpuparticles-godot-40/index.html
index 4f49b4e741..6d8bfb45c2 100644
--- a/article/improvements-gpuparticles-godot-40/index.html
+++ b/article/improvements-gpuparticles-godot-40/index.html
@@ -13,7 +13,7 @@
Additionally, heightfield collision can detect the active camera and move along with it, ensuring that nearby terrain always has particle collision information available.
Future
Some extra features (skeletal trails and skeletal deform) are still missing and will eventually be added before 4.0 release date, as they depend on other features (some improvements and rewrite to skeleton handling). Additionaly, GPU particles are not working for 2D yet. They depend on a final rewrite of the 2D engine based on all the feedback received (it was the first feature implemented in Vulkan after all, done with much less experience than now) in the coming weeks.
Still, this marks the final feature that had to be ported over from Godot 3 to Godot 4. From now on, my focus over the next months will be on improving, cleaning up and optimizing (including optimization features such as impostors, LOD and occlusion) everything that is there with hopefully an Alpha coming by December or January (can only wish..).
As always, remember that Godot is made with love for you and the gamedev community. Help us make the best engine ever and make it free and open source for everyone by becoming our patron.
-
+
\ No newline at end of file
diff --git a/article/improvements-shaders-visual-shaders-godot-4/index.html b/article/improvements-shaders-visual-shaders-godot-4/index.html
index 209ba71200..f63dbe78ae 100644
--- a/article/improvements-shaders-visual-shaders-godot-4/index.html
+++ b/article/improvements-shaders-visual-shaders-godot-4/index.html
@@ -97,7 +97,7 @@
After placing it, you can resize it and use the context menu to modify the header and the description label like:
The Billboard node (named as GetBillboardMatrix in the member dialog) provides a way to modify the model view matrix of a 3D object to always look towards the camera.
It provides support for multiple billboard types referred to as standard Godot types in StandardMaterial3D (see docs on Billboard modes).
It only makes sense for 3D objects and should be connected to the new Model View Matrix port in the vertex shader. Therefore, this node is available only for Node3D/Vertex mode of the visual shader.
Note: These modes has been taken from StandardMaterial3D (formerly SpatialMaterial in Godot 3.x).
The particles mode (both in shaders and visual shaders) was significantly changed. Here is a quick overview of the new nodes and modes in that group.
Random generation node
Godot’s particles system already had features for random number generation. Bringing this to the visual shader system was only a matter of time. Generation of random floating-point scalars and vectors is very useful for particle systems in general. By using the ParticleRandomness node, you can achieve that.
Note: To modify the colors of the particles, you must enable Vertex Color > Use As Albedo in the material override property of the GPUParticles3D node.
Start mode
The start mode defines the void start() function of a shader and allows the user to define initial velocity, position, rotation, and scale parameters of the particles. The corresponding visual node is StartOutput.
Velocity
A velocity vector must be assigned in order to move the particles. You can assign any vector you want or use a random vector from ParticleRandomness. The engine also provides a ConeVelocity node to create a velocity in a form of a cone, defined by a normalized direction vector and the spread amount. Since it produces a normalized vector you should multiply the result by the required speed of the particle.
Emitters
Emitters define a shape where each particle could be randomly placed. They should be connected to the Position port in the StartOutput. Currently, there are three possible shapes: box, ring, and sphere. This is a demonstration of the ring emitter:
Note: If the position vector is not assigned it will be emitted from the center of the emitter’s volume.
Process mode
The process mode is defined in the void process() function of a shader and allows the user to modify each particle parameter over time. The corresponding visual node is ProcessOutput. The provided node to modify the velocity over time is ParticleAccelerator.
As you can see this node has three modes: Linear, Radial, and Tangential. Linear scales the node velocity uniformly, Radial scales relatively to the volume center, and Tangential modifies the velocity by swirling around the volume center. An amount of scaling is defined in the first port of this node. The axis port is used only by the Tangential mode to define the axis of swirl and gravity (it’s initialized with Earth’s gravity by default).
Custom mode
The start and process modes can be switched to a custom mode:
Here, you can pass custom data and modify the transform of each particle directly. The processing of this mode is placed after the main code of the start() or process() functions. To access the custom data in other modes, use an Input node.
Collide mode
The collide mode’s code is placed in the process() function and processed only when a particle has a collision with one of the GPUParticlesCollision nodes.
This is just a quick overview and you should try it yourself to understand how it works. This system is pretty new and may not contain all the nodes required by the majority of the users. Feedback is welcome on the Godot proposals repository :)
-
+
\ No newline at end of file
diff --git a/article/interblock-supports-godot-development/index.html b/article/interblock-supports-godot-development/index.html
index accb2923b5..de0e2d40c2 100644
--- a/article/interblock-supports-godot-development/index.html
+++ b/article/interblock-supports-godot-development/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde20 November 2019
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.
We are happy to announce that Interblock is now supporting Godot’s development as Platinum sponsor! For this occasion, we asked them to share some words about the company, why they chose to support Godot and their plans to use the engine for their products.
Interblock began making automated roulette games for casinos back in 1997. Fast forward twenty two years and we are now globally recognised for developing luxury products that bring top quality entertainment to players through an exclusive collection of gaming tables and video gaming. We produce all our own hardware, right here in Slovenia. Something that we are hugely proud of.
As time and technology move on, players’ expectations are high and casinos strive to provide the ultimate gaming experiences. Casino products outside of the slot game industry have a reputation of being behind the technology curve, but as a technology company we are changing that perception and our products now have more visual synology with video games, utilising realtime 3D graphics and animated entertainment.
For the last couple of years we have been looking for a technology solution that would provide the same level of performance and user friendliness that our team has been used to working with. We evaluated a few, but once Godot implemented C# it was the trigger for us to make the switch. Being an Open Source project was also a key element in our decision process, having direct access to the source is a huge advantage. Now that we are involved in the Godot project we are excited to be able to contribute back to its overall success.
We plan to bring all our products over to Godot within the next 18 months and be more involved with the community. We will of course be looking to work more closely with the experienced Godot users out there and currently have a number of open positions based in the beautiful country of Slovenia.
Email: careers@interblockgaming.com
Welcome to Interblock in the Godot community, and many thanks for your support!
-
+
\ No newline at end of file
diff --git a/article/introducing-brand-new-code-completion/index.html b/article/introducing-brand-new-code-completion/index.html
index 3c977355c9..129f5ef328 100644
--- a/article/introducing-brand-new-code-completion/index.html
+++ b/article/introducing-brand-new-code-completion/index.html
@@ -5,7 +5,7 @@
Juan Linietsky22 December 2014
This article is from December 2014, 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.
Smart completion
It has only been a week since the stable release and development is moving on to other new cool features! This week has been pushed to GitHub a new code completion for the built-in editor.
Godot previously only supported limited code completion (only symbols) in the editor. As GDScript is a dynamically typed scripted language, variables are not necessarily typed, which means at run time the value of a variable can be anything.
How does it work?
Statically typed languages such as C, C++, Java or C# require the programmer to explicitly specify the type of every variable (variant and generic objects are supported, but these are used only on special cases). Validating the parse tree for datatype conversions is typical of these kind of languages, so at parse time it’s possible to know the datatype of everything, making the implementation of code completion really easy.
In GDScript this is not possible, because type conversions happens in run-time. However, there are some things that Godot provides to GDScript:
Engine functions and properties are all typed.
Function arguments (including those of virtual) are typed.
Signal arguments are typed.
Exported variables are typed.
Constants are typed.
Preloaded resources (which are initialized at parse time).
Many built-in functions are deterministic (ie, sin() ).
Many objects are live at the time code is written (ie scene nodes).
Using this information, The new code completion, then, does something interesting. It tries to recursively back-parse variables to their origins. Unsurprisingly, most of the time, this origin does have a type, as it is one of the items in the list above.
The smart code completion will trace back identifiers through arrays, dictionaries, functions, local variable blocks, members, constants, etc. It will try by all means to go back to a typed node in the parse tree and, in most cases, it will succeed. For example..
Global, local & class scope
Global and local variables and functions are the easiest types of completion since it’s they are type independent. Only the identifier name needs to be completed. The algorithm simply goes from the current block upwards from the current block to the global scope trying to find the relevant keywords for completion. The only catch is that it must figure out whether the current block is inside a static function, in which case it must exclude regular functions and member variables.
(Edit: image lost in translation)
Indexing
Indexing refers to completing expressions followed by the ‘.’ (period) token. For this, the type of the preceding expression must be guessed, no matter if it’s a function call, an identifier string a constant, etc. The smart completion will do inverse tracing of identifiers to guess their type, or even their instance (in the case of live objects or preloads).
(Edit: image lost in translation)
Even dictionaries or arrays can be traced back to their source to guess their type.
(Edit: image lost in translation)
Since in Godot, many of the functions implemented come from signals or virtual functions, so the type of their arguments is known and be completable. For example, the type of the identifier comes from the function in the argument, which in turn comes from the argument of the virtual function.
(Edit: image lost in translation)
Live objects
Scene nodes (for node scripts) and resources can be used to trace types. Functions that return generic objects (and that are const) are called to guess the potential return type too. In the case of nodes, for example, the entire scene tree appears as completion hint:
(Edit: image lost in translation)
Or, in the case of an animation player, the animations contained within:
Most importantly, connecting signals from code also becomes easier with this feature:
(Edit: image lost in translation)
Argument hinting
The new smart completion will also hint arguments as long as they are completed. For regular script functions, the script form of the method is shown:
(Edit: image lost in translation)
For engine functions, their full form with datatypes are displayed.
(Edit: image lost in translation)
Finally, built-in types can show constructor hints for their many versions:
(Edit: image lost in translation)
Future
There is probably more room to further improve the smart code completion. If you are using this functionality and you feel Godot should be able to somehow guess the type of the code you are writing, please write to us and we will make sure to add this scenario.
-
+
\ No newline at end of file
diff --git a/article/introducing-csharp-godot/index.html b/article/introducing-csharp-godot/index.html
index c2fe9f8530..da1f606f8f 100644
--- a/article/introducing-csharp-godot/index.html
+++ b/article/introducing-csharp-godot/index.html
@@ -90,7 +90,7 @@
Exporting the game will make sure to pack all the required assemblies with your exported game, among other things.
Android platform
There are three platforms that are not supported right now: Android, iPhone, and WebAssembly. Android will be the first one we will focus on.
iPhone exporting will require the extra step of compiling the assemblies ahead of time (AOT) since JITing is not possible on this platform.
Currently, WebAssembly is not possible, but the people at Mono are experimenting to bring Mono to WebAssembly.
Debugging extensions
Debugging extensions allow developers to debug their games from their editor. The first extensions will be for XamarinStudio and Visual Studio Code, but we also plan to add editor integration with Visual Studio.
Usability and feedback
There are many usability improvements and ideas that didn’t make it in time for alpha2. We are also expecting a lot of user feedback from this release!
Further notes
Like always, keep in mind this is an alpha and there may be bugs and crashes. Please, report any issue you encounter on our bug tracker.
-
+
\ No newline at end of file
diff --git a/article/introducing-gd-extensions/index.html b/article/introducing-gd-extensions/index.html
index 60d75f1408..b135633a5b 100644
--- a/article/introducing-gd-extensions/index.html
+++ b/article/introducing-gd-extensions/index.html
@@ -61,7 +61,7 @@
The example has many more things implemented such as constants, signals, methods with a variable number of parameters, etc. It’s a good place to look at how to use those things in your own plugin.
To those who’ve written Godot modules before, this code should look familiar as much of the syntax is identical.
-
+
\ No newline at end of file
diff --git a/article/introducing-godot-proposals-repository/index.html b/article/introducing-godot-proposals-repository/index.html
index d234ab54d9..c1c97df88a 100644
--- a/article/introducing-godot-proposals-repository/index.html
+++ b/article/introducing-godot-proposals-repository/index.html
@@ -5,7 +5,7 @@
Juan Linietsky4 September 2019
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.
The past two years, the project kept growing at a steady pace. One of the most important consequences of this growth process is that our GitHub issue tracker has exploded with ideas, proposals and bug reports.
Too many proposals
While we have a very clear guideline on how bugs have to be reported, proposals went usually from simple ideas like “Implement bluetooth multiplayer” to detailed plans for enhancements. Because the entry barrier is so low, our main issue tracker got quickly flooded with too many ideas and proposals. There are so many of them that it’s just impossible to seriously discuss them all, so our issue count kept growing way past 5k.
Quality over Quantity
As this situation went beyond our control, we hosted several discussions about ways to improve the proposal workflow. The first task was to identify the problems with the current system:
We have too many proposals, way more than we could ever discuss.
Proposals are, most of the time, too many, too vague and difficult to discuss, we need to be more strict in our requirements, similar to how bugs are reported.
External contributors often create feature/enhancement PRs that we don’t know if are wanted, whether they solve actual problems, or if the way they are implemented (usability wise) is right. These are very difficult to review because we, as developers, don’t even know this most of the time, so we would prefer they go via community filter. It’s easier to review, discuss, approve or reject a proposal than a PR.
The whole process must not become more bureaucratic for core contributors than it already is. In fact, the goal is to make it less bureaucratic, given that most core contributors are doing this work on their free time.
We constantly get asked by potential new contributors what kind of work they can do and it’s not always easy to answer. By better filtering proposals, the new system can also be used to better organize new and existing contributors.
Based on this, a new proposal submission system was created. Submitting a proposal now has stricter requirements and fields that need to be filled:
Users must first describe the project they are working on, and based on it, how the proposal will be of benefit for them. This gives more importance to proposals that are helpful for real-life situations, rather than ideas that sound cool but their real benefit is unknown.
Users must show exactly how the proposed enhancement / new feature will work. Mock-ups, flow diagrams, anything that helps understand how something will be implemented is of vital importance. This puts more burden in the proposal submission, and less in the contributors reviewing it.
We want to emphasize that even pull requests for new features and enhancements can be closed if a proper proposal does not precede it. This will ease our work reviewing PRs, as we usually don’t know if the proposed code addition is wanted by the community.
Finally, we ensure that core developers (who own an area of the engine and already have significant experience) can discretionally fast-track these processes, to avoid bureaucracy.
In short, this new process aims to shift the burden from those reviewing to those proposing, so we can better utilize the time and resources kindly donated by the community to the project.
Proposal Repository
Attempting to open a feature request or enhancement issue in the main Godot issue tracker will ask you to, instead, open it in the new proposals one:
Over the next weeks, old proposals in the main issue tracker will be closed, asking those who opened the issue to please re-open them in the new one. Proposal topics with already lengthy discussions that remain open will be moved as-is directly.
The result of this is that the main issue tracker will only be for bug reports, hopefully reducing the amount of them significantly and making it more manageable.
Future
No system is perfect and, over time, we may find ways to enhance this new workflow. A common question is whether simple proposals need to go via this new process. The answer is yes, because defining “simple” is actually very difficult. Hopefully, over time we will be able to better improve this workflow.
-
+
\ No newline at end of file
diff --git a/article/introducing-japanese-indies-godot/index.html b/article/introducing-japanese-indies-godot/index.html
index dc8178beb0..3fcbf79e89 100644
--- a/article/introducing-japanese-indies-godot/index.html
+++ b/article/introducing-japanese-indies-godot/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest6 January 2019
This article is from January 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.
Last month, I was invited to Tokyo to present Godot at a local game developer’s meetup. The presentation was based on Godot Slides, our open source Godot slideshow.
The engine isn’t popular yet in Japan. This is likely due to the lack of learning resources in Japanese. Also, the community is still small in the country. So to grow a thriving community and to attract translators and tutorial creators, we first need to raise awareness: introduce Godot to local developers and try to poke their curiosity.
People need information to know whether or not Godot is a good fit for their projects. Things like Godot’s friendly plug-in API, a big time-saver for teams.
With Godot, you can code tools the same way you code your games. It’s really convenient. Every game developer on the team can contribute to tools that enhance everyone’s workflow easily!
Also, Godot tries to integrate all tools that you need to make a game almost out-of-the-box, from essentials like the off-line code reference to the new animation state machine in version 3.1. The ability to reload code and scenes while running the game, including on remote devices, is also a unique feature worth knowing about.
It went well, but…
…I feel that the Japanese are not ready to switch from Unity to Godot just yet.
Almost no one had ever heard about the engine besides the event’s organizers. The educational resources are not on par yet and switching engines is an involved job.
But at least, this 5 minutes intro seems to have poked the audience’s curiosity. Hopefully, a few persons will try it and, over time, more Japanese developers will give a hand with translations and start creating tutorials.
I met a few professional translators who already like the engine. In the future, an option would also be to fund translation work through the community.
As you’d expect, the presentation had to be entirely in Japanese. But if you open the presentation in Godot Slides, the updated slides are available both in Japanese and in English.
On a side-note, we got to meet with Securas, an inspiring scientist who also creates lovely games for jams. If you’ve ever seen Daisy dangerous, Daemon vs Demons, or Crackshot, they’re all from the same author! Also, they’re all open source, hosted on his GitHub page. He’s absolutely lovely, and his work is exciting. I sincerely hope we’ll get to meet again!
Open projects in Kyoto: showcasing Open RPG
We’ve wanted to embrace open source fully for a while with GDQuest. To build every project out in the open from the start. It’s a tough decision to take as coordinating and reviewing everyone’s work takes a lot of time. The users’ expectations with free software tend to be quite high even if all the developers contribute benevolently.
Long story short, After the presentation in Tokyo, I got to showcase our recent open source projects to a panel of foreigners and Japanese game creators at Kyoto Indies.
We’ve been doing work on the map, the dialogue system, and added touch support to open RPG. There again I’ve tried to poke at the participants’ curiosity, hoping to get some more people to check the tutorials, and eventually use our RPG system as a base for their own projects.
We’re working on AI and on the quest system at the moment. You can join the discussion and follow development on the open RPG’s GitHub page and on our Discord discussion channel.
To talk about the presentation or collaborations, you can also find GDquest on Twitter!
-
+
\ No newline at end of file
diff --git a/article/introducing-new-forum/index.html b/article/introducing-new-forum/index.html
index c6334b5825..306ba756ba 100644
--- a/article/introducing-new-forum/index.html
+++ b/article/introducing-new-forum/index.html
@@ -5,7 +5,7 @@
Winston Yallow8 December 2023
And don’t worry: no content is lost, all the old posts have been migrated to the new platform.
Why did we replace the old platform?
The old Q&A platform was based on Question2Answer, an open source project for Q&A sites. Unfortunately it is infrequently updated and had some security issues we couldn’t easily solve. This led to problems like bot registrations and spam which took a lot of manual effort to manage.
On top of that, we also wanted more forum features that Question2Answer simply couldn’t provide. It served its purpose well for quite some time, but we have simply outgrown its capabilities. So it’s time to give our community a new home!
Introducing Discourse
The new forum is based on Discourse, an open source forum software that can easily be adjusted via plugins and themes to suit our needs. For logins, the same SSO (single sign on) is used as for other Godot platforms (like the developer chat). This allows users to have one account across all Godot websites.
Data migration
Let’s look at some details about our process going from Question2Answer to Discourse!
The old Q&A platform had over 150k questions, answers and comments stored in the database. 20% of those were hidden by our moderators for being spam or breaking the rules, so we ended up importing 120k items from the old database.
What we did not import were the users. The old instance had lots of old and unused accounts, and it would have been a lot of work to reconcile those users with the users of the SSO server. Instead, all imported posts are made by a system user, and the original username is shown at the top of the post. Since Discourse does not support comments on posts like Question2Answer, we embed them directly within the post and add some styling. This way we can represent all data from the old platform in a neat way:
Permalinks
To keep existing links working, we forward any request from the old server to the new server. We then use the Discourse permalinks feature to map requests to forum.godotengine.org/{some_old_id} automatically to forum.godotengine.org/t/{new_id}.
External images
By default, Discourse downloads external images on the server to prevent linkrot. However, this is not a good idea when importing a big amount of posts at the same time. Leaving this feature on would get the server blacklisted by imgur and other providers for requesting too many resources in a short amount of time. Therefore the feature was turned off for the duration of the import.
Markdown adjustments
Discourse uses Markdown, HTML and BBCODE for the post content. Luckily, on the old Q&A platform we also used a plugin for Markdown. While this made the posts somewhat compatible, there were still a few differences in how the Markdown is interpreted.
We ended up using a Markdown parser to access the content in a tokenized form. This allows us to apply a bunch of adjustments:
Code blocks
There are two ways to denote code blocks in Markdown: either a block delimited by ``` or by indenting every line of the block by one tab (or four spaces). The old platform highlights both as code. Discourse only highlights backtick delimited blocks. So for all indent based code blocks, we remove the indentation and surround the blocks with backticks instead.
This ensures that all code blocks will be processed by highlight.js and will receive syntax highlighting if the language can be detected.
Image embeds and links
The new Markdown parser is a bit stricter about links/embeds that use the footnote syntax. They are only processed correctly if the line before is completely blank. This was easy to fix by simply adding a new line before every footnote. We also replace any references to the old server address with references to the new server. This avoids unnecessary redirects.
The future
Now that we have a proper forum, we can use it for more than just questions and answers. Beside the Help section for questions and answers, we also already have a Resources category where you can post tutorials and plugins as well as your favorite tips & tricks for Godot!
If you have any ideas for further improvements to the forum, feel free to create a post in the Site Feedback category.
-
+
\ No newline at end of file
diff --git a/article/introducing-new-last-minute-lightmapper/index.html b/article/introducing-new-last-minute-lightmapper/index.html
index 7df24c7de4..612ca57afc 100644
--- a/article/introducing-new-last-minute-lightmapper/index.html
+++ b/article/introducing-new-last-minute-lightmapper/index.html
@@ -9,7 +9,7 @@
dynamic objects that move around the scene.
Godot implementation of lightmapping uses a different method, so this process is automatic and you don’t have to do anything. Just move your objects around and they will be lit accordingly. Of course, you have to make sure you set up your scene bounds accordingly or it won’t work.
Future
Lightmap bake times are relatively fast (but raytrace+high can take an hour or two on a big scene). It should be easy to optimize the light transfer integral by eventually converting it to OpenCL. If you are experiecned with this API and would like to do this job, please let us know!
And, as always, remember that all the work we do is given to you for free, full source code, and the most open license (MIT). Please consider helping the development of Godot by becoming our patron.
-
+
\ No newline at end of file
diff --git a/article/introducing-onion-skinning-godot-game-engine/index.html b/article/introducing-onion-skinning-godot-game-engine/index.html
index 4aae5a367a..357be662da 100644
--- a/article/introducing-onion-skinning-godot-game-engine/index.html
+++ b/article/introducing-onion-skinning-godot-game-engine/index.html
@@ -6,7 +6,7 @@
This implementation is really good, and allows visualizing future and past frames. This helps animators have a much greater deal of control on repositioning objects on every frame.
-
+
\ No newline at end of file
diff --git a/article/introducing-reverse-z/index.html b/article/introducing-reverse-z/index.html
index f60901daf7..5cb2590480 100644
--- a/article/introducing-reverse-z/index.html
+++ b/article/introducing-reverse-z/index.html
@@ -32,7 +32,7 @@
You will have to modify the function manually, either using depth - clip_pos.z or abs(clip_pos.z - depth).
Operations in clip space
The above depth buffer operations are an example of the types of operations users might do in clip space. Ultimately, most operations should not be done in clip space as it is a non-linear space (i.e. relative distances will change depending on the camera’s distance to the object). We recommend that, if you are doing operations in clip space (like in the above example), you switch to doing those operations in view space instead. If you know what you are doing and insist on continuing your operations in clip space then:
I’m sorry we broke your shader.
I trust you know how to fix your shader.
We promise not to break your shader again by changing the definition of clip space anytime soon.
Summary
We know that some shaders will break with this change and we are sorry to break compatibility in this way. However, we carefully weighed our options and we decided that now was the best time to implement reverse Z. Our other option was to wait until Godot 5.0. We chose not to wait as we intend to continue working on 4.x for many, many years and we anticipate that with all the upgrades coming to the 3D renderer in the coming years, reverse Z will become a necessity for many games. Further, we are continuing to expose more ways to customize rendering, including allowing users to access the raw depth texture outside of shaders using CompositorEffects. Accordingly, the negative impact of compatibility breakage will only get worse as time goes on.
If you run into a situation where your shader breaks and it’s not covered here, please consider making a post on the Godot Forum. We can troubleshoot the issue together and leave our notes for other users to find through search engines.
-
+
\ No newline at end of file
diff --git a/article/introducing-the-godot-gltf-2-0-scene-exporter/index.html b/article/introducing-the-godot-gltf-2-0-scene-exporter/index.html
index 7bab7191b4..851dee3597 100644
--- a/article/introducing-the-godot-gltf-2-0-scene-exporter/index.html
+++ b/article/introducing-the-godot-gltf-2-0-scene-exporter/index.html
@@ -6,7 +6,7 @@
Sorry, your browser doesn't support embedded videos.
Multiple Godot contributors collaborated on developing the glTF export enhancement in their spare time. As it was done in our free time, completing the glTF enhancement was slow.
We started work on glTF export in 2019, but Blender was misreading our output.
Marios Staikopoulos fixed the glTF2 skeleton interpretation. (Thank you so much!)
Afterwards, the Blender import/export plugin before version 2.83 could not import any glTF correctly, and it was fixed thanks to scurest’s work. (Note that Blender versions older than 2.83 are not supported.)
We had trouble with Godot instanced scenes. When a skeleton was in the scene multiple times it became merged, which was fixed.
Roadmap
We will add support for these features along the way:
Improve support for MultiMeshInstance (performance optimizations).
Support for importing/exporting GridMaps (3D tilemaps).
BoneAttachments (lets you attach nodes to bones).
Limitations
No support for exporting particles since their implementation varies across engines.
ShaderMaterials cannot be exported.
No support for exporting 2D scenes.
Only supported in editor builds (tools=yes).
Who helped along the way?
I want to thank the following people for contributing to glTF import/export:
Godot Engine team - https://github.com/godotengine
Godot 4.0 changelog for glTF
Moved glTF to the Godot modules.
Allowing constructing meshes in Godot and exporting them.
Making animations in Godot and exporting them.
We can break apart the glTF data structure into something that can be combined and interpreted.
Godot works with glTF extensions, such as VRM in external plugins.
glTF was moved out of the Godot core and made into a Godot module.
Added editor-only APIs with PackedSceneGLTF’s export_gltf, import_gltf_scene and pack_gltf.
CSG is exportable.
Cameras and lights are now exportable.
Forced conversion of PBR specular glossiness, so there isn’t a white default material.
The ability to have Godot modules and have them both in core and as custom modules helped development. (Being able to override the existing glTF support using custom modules to Godot outside of the tree helped significantly with progress.)
Supports selecting between export as glTF Binary (.glb) and glTF Separate (.gltf + .bin + textures).
Supports up to 8 bone weights instead of just 4.
Animation skinning and blend shapes are using compute shaders.
We expect to fix issues along the road. If you have any problems, please report them on the issue tracker. When reporting an issue, make sure to include a minimal reproduction project with the 3D scene in question.
Addendum: Why not Collada (.dae)?
The standards body behind glTF 2.0, Khronos, is also behind Collada (.dae). The Collada format has limits that could not be overcome without an entirely new standard.
The Collada specification was very ambiguous in many aspects.
Most Collada exporters are, to this day, broken and why the Godot developers made the Better Collada Blender add-on.
The market-leading digital content creation tools worked against the Collada format adoption by including an incomplete and buggy exporter in their software.
-
+
\ No newline at end of file
diff --git a/article/introducing-the-improved-ufbx-importer-in-godot-4-3/index.html b/article/introducing-the-improved-ufbx-importer-in-godot-4-3/index.html
index 2800f65897..2330f2954b 100644
--- a/article/introducing-the-improved-ufbx-importer-in-godot-4-3/index.html
+++ b/article/introducing-the-improved-ufbx-importer-in-godot-4-3/index.html
@@ -5,7 +5,7 @@
Lyuma2 August 2024
First and foremost, it will no longer be necessary to download the external FBX2glTF converter in order to use .fbx files in Godot 4.3 projects. This also enables .fbx support on all platforms Godot supports, as well as script access using the new FBXDocument API.
The new importer also contains many technical improvements and changes:
Tested against content created in a wide range of professional 3D DCC (digital content creation) tools
Imported scenes no longer have an extraneous “RootNode” top-level node in the scene.
Unit conversion (such as centimeters to meters) is now applied to the mesh itself rather than assigned to the node scale of top-level nodes.
Improved support for PBR materials and lighting accuracy, within what the .fbx format supports. (.fbx tends to have inconsistent material support between applications).
Support for geometric pivots. Pivot offsets are applied automatically where possible.
The option to create geometric helper nodes helps support pivots and inheritance modes not otherwise possible with traditional translation, rotation and scaling node transforms.
Automatic trimming of animations based on the start and end timestamp encoded in the .fbx file header.
Preserves the original material order from the DCC tool, rather than sorted by face index.
Calculates an accurate bone rest using information such as the bind-pose. This can assist with skeleton retargeting.
The animation/bake_fps setting in ufbx now only affects interpolation of curves. Animations natively at 60 fps will now import all keyframes regardless of the bake fps setting in the Import Dock.
Compatibility with existing projects and FBX2glTF
After upgrading to Godot 4.3, existing files in your projects will continue to import with FBX2glTF. By default, only newly added files will import with ufbx. This default may be changed by using the “Preset” button near the top of the Import dock, or in the “Import Defaults” pane of Project Settings.
Use extreme caution when changing the importer of an existing .fbx from FBX2glTF to ufbx: the two will have different node hierarchies, which will break modifications made in instanced scenes, break NodePath references in scripts, adjust rest poses of skeletons, and possibly mix up surface override materials due to the change in surface ordering.
In accordance with our release policy, we will continue to support projects which have chosen to use FBX2glTF throughout the 4.x cycle for compatibility with existing imports. ufbx will affect new 3d imports by default, but the importer for .fbx files may be changed in the Import dock.
Another slight difference exists in the way FBX units are applied. The ufbx integration in Godot scales meshes directly rather than scaling nodes. Note that Blender by default exports objects at 100x scale, using 1cm units, To avoid unexpectedly scaled transforms, we recommend exporting from Blender with the setting “Apply Scalings” set to “FBX Units Scale”, which will export the file as 1m units.
Improved import of animated characters
Those who have worked with .fbx in the past may have encountered a plethora of issues when importing skeletons and animations, to the extent that it became common practice to import such animation files in Blender and re-export as glTF 2.0. With Godot 4.3, we hope that this will be a thing of the past. We have made the following improvements to the skeleton importer:
#88824 (Retargeting option to use a template for silhouette): This feature can be used to reference the RESET animation of a known good (T-pose) reference file. Having a separate reference pose .fbx is a common practice in some animation sets.
Samuli has spent exceptional time and effort testing the ufbx library on tens of thousands of .fbx test cases from a variety of sources, and we are proud to consider the new ufbx importer feature-complete with a high level of certainty.
We expect that bugs with .fbx import are going to be relatively uncommon, but if you encounter something incorrect or broken, please report the issues you find and include the .fbx files which reproduce the issue or reach out to us with instructions.
Conclusion
The ufbx importer is a major step in improving the accuracy and ease of use of Godot’s 3D importer. It is but one of many improvements, and there is more to come in future 4.x releases.
There are sure to be many applications for the native .fbx importer. Our hope is it will improve interoperability with a wide variety of animation tools and libraries out in the wild. For example, I and the V-Sekai team have integrated ufbx into Unidot Importer to allow for interoperability with asset packs in .fbx format.
-
+
\ No newline at end of file
diff --git a/article/january-jams-2024/index.html b/article/january-jams-2024/index.html
index f47303249b..38b98b8f51 100644
--- a/article/january-jams-2024/index.html
+++ b/article/january-jams-2024/index.html
@@ -6,7 +6,7 @@
Nat31 January 2024
Did you partake in a game jam this month? To us here it seemed like the beginning of 2024 was already jam-packed (yes, that pun is intentional) with opportunities to hone your game-making skills, in variable time spans from just three hours to an entire month.
Below you can find a list of our ten personal favorites from this busy month (in chronological order):
Did you hear about Mickey Mouse entering the public domain this year? How is that relevant to this jam you ask, well… you can now include the character in your games without fear of repercussions. This is precisely what the organizers turned into a creative challenge, to use the newly freed IPs from 1928 (exactly 95 years ago, the current protection period) to make a digital or analog game.
Be honest, how high is your stack of unfinished games that you once were sure would see the light of day? This particular game jam caters to your new year’s resolution to ”Finally Finish Something” and hence allows you to submit any game you have previously been working on, as long as you have used the month of January to complete the project.
While there are a plethora of “niche” game jams at any given time, it seems important to highlight at least one focused on the LGBTQIA+ community. Also, vampires are cool, and this interactive-fiction jam is not only still ongoing, but also kind of popular. Plenty of time to still submit your own bloodsucker romance!
The Squid Games of the game dev world. The previous sentence is taken straight from their own branding, albeit it does seem nobody dies in this rendition and the prize is a T-shirt. Every participant is sorted into one of five teams, spearheaded by the organizers themselves, which each adds a unique modifier to the common challenge.
An explicitly beginner-friendly jam organized by Bitter Sails Games that quickly rose to the top of itch.io’s game jam suggestions. Introductory presentations and mentoring by game industry veterans allowed for a guided experience, while the resource package prepared by the team is so comprehensive we suggest downloading it even after the fact.
A staple in our community that takes place during the second week of every month. In addition to the announced theme, three wildcards are released to provide an optional additional challenge. Most importantly, you are required to use the Godot Engine for this one ;)
A jam organized by game developer & Twitch streamer Pirate Software. Unique compared to the other events in this list is the requirement to provide a game design document for your entry. On top of that, you can almost always find co-work companions in his live streams.
As the name would suggest, this event has spread across the globe. Twice every year people from all around the world come together for a weekend to make games, in their respective local jam sites hosted by various organizations, ranging from schools to game studios to government programs.
From the numbers that are accessible to us, we can estimate that about 16% of submissions were made using the Godot Engine. That amounts to over 1500 games, more than double compared to last year!
Concurrent to the Global Game Jam this event by the same organizers caters to the younger aspiring game developers aged 12 to 17. Furthermore, it provides a curriculum of video lessons about game development basics.
Is it possible to make a game in just three hours? The hosts of this fast paced jam surely seem to think so. For those joining as a team, every member gets three hours to work on their part. Since this game jam requires the least time commitment out of our selection, and happens weekly, is there a good reason for you to not try and join the next one?
Did you join any game jams this month? Then don’t miss out on the opportunity to self-promote your projects under our #JamJanuary posts which you can find here: linkin.bio/godot.
-
+
\ No newline at end of file
diff --git a/article/joan-fons-hired-work-godot-rendering/index.html b/article/joan-fons-hired-work-godot-rendering/index.html
index b0ed9e9eb5..dbb41ecbc2 100644
--- a/article/joan-fons-hired-work-godot-rendering/index.html
+++ b/article/joan-fons-hired-work-godot-rendering/index.html
@@ -8,7 +8,7 @@
Debug output of the prototype implementation. Red: depth buffer. Green: occluded objects. Blue: visible objects.
After that, depending on the state of things, we will evaluate if I add some extra features such as TAA and proxy volumes for static lights, or we leave them for future releases and I switch to bug fixing and stabilization of the renderer.
Thanks!
Finally, I wanted to thank all the individual and corporate sponsors for their donations, and the whole Godot community for their communal effort towards making Godot the best engine it can be :)
-
+
\ No newline at end of file
diff --git a/article/join-godot-meetup-gdc-2019/index.html b/article/join-godot-meetup-gdc-2019/index.html
index d74510e47b..9c82b97376 100644
--- a/article/join-godot-meetup-gdc-2019/index.html
+++ b/article/join-godot-meetup-gdc-2019/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde1 March 2019
This article is from March 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 mentioned last week, several core developers and project representatives will be at the Game Developers Conference (GDC) in San Francisco next month.
Like last year, our friends at GitHub provide us with the awesome opportunity to organize a Godot Meetup at their headquarters during GDC!
We’ll meet on Thursday, March 21 at 6:30 pm at the GitHub HQ for an evening of Godot talks, games showcase and general networking for everyone interested in Godot Engine. Whether you’re an active Godot user and just curious about it, you are welcome to come to the Godot Meetup and get to meet other community members.
The entrance is free, but you have to sign up as soon as possible on Eventbrite, so that we can finish the organization with GitHub staff.
-
+
\ No newline at end of file
diff --git a/article/join-hacktoberfest-and-contribute-godot/index.html b/article/join-hacktoberfest-and-contribute-godot/index.html
index 98c5090896..459e50915b 100644
--- a/article/join-hacktoberfest-and-contribute-godot/index.html
+++ b/article/join-hacktoberfest-and-contribute-godot/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde1 October 2016
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.
October 1st, Hacktoberfest starts now and will last for the whole month!
What’s Hacktoberfest? The purpose of this event (run by DigitalOcean and GitHub) is to encourage people to contribute to open source projects by making pull requests. The incentive? Beyond international fame, the glorious feeling of having made the world better, and deep recognition from the project’s community, you also have the opportunity to win a cool T-shirt (sadly not a Godot one - yet) if you make four pull requests during the month after having registered with your GitHub account.
Where does Godot come into play? As an open source project hosted on GitHub, pull requests on our repository are also valid for Hacktoberfest, so it’s a great opportunity to kickstart your Godot contributor career (or confirm it if you’re already a regular).
What to work on? For this event, we created a hacktoberfest label for our GitHub issues which would be good candidates to work on (OK, to be honest it’s just the usual junior job label that got renamed ;)). You don’t have to limit yourself to those issues though, as we understand it any pull request on any project would count towards the greedy objective of getting a T-shirt.
In particular, note that pull requests done on our documentation or demo projects would also be valid, so you can contribute even if you are not familiar with C++. Just make sure to read the README when there is one, and ensure that your contribution will be useful - since the purpose is that it should of course be merged, so it should be beneficial to the project.
-
+
\ No newline at end of file
diff --git a/article/join-us-gdc-during-godot-meetup-2018/index.html b/article/join-us-gdc-during-godot-meetup-2018/index.html
index 0061237960..b91860de3e 100644
--- a/article/join-us-gdc-during-godot-meetup-2018/index.html
+++ b/article/join-us-gdc-during-godot-meetup-2018/index.html
@@ -5,7 +5,7 @@
Juan Linietsky6 March 2018
This article is from March 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.
Will you be attending GDC? If so, please come visit us at our 2018 meetup that we organize together with GitHub.
If you are a Godot user, this will be a great chance to meet other Godot users and developers.
If you are only interested about Godot (and you should!), this will be the best chance to find out more about the project during GDC.
The event requires previous registration, so please register here.
-
+
\ No newline at end of file
diff --git a/article/last-call-take-off-godot-2-1-rc2/index.html b/article/last-call-take-off-godot-2-1-rc2/index.html
index 5f388f1d18..de6e13b189 100644
--- a/article/last-call-take-off-godot-2-1-rc2/index.html
+++ b/article/last-call-take-off-godot-2-1-rc2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde3 August 2016
Despite its funky hairstyle, we were pretty happy with the state of Godot 2.1 RC1 already. Still, contributors haven’t stopped fixing bugs and adding some enhancements here and there while we were preparing our stable release announcement.
So to take into account the most recent changes and make sure that the stable release is as good as it can be, here’s a new release candidate that we believe will become Godot 2.1-stable within a week at most.
Check the 2.1 RC1 release announcement for more details about the 2.1 release as a whole. See here for the changelog since the previous release candidate.
Keep reporting the bugs you find! We expect that unless critical issues are brought up, we will release the current version as stable, but all reports will be useful for the bugfixing towards Godot 2.2 and probable 2.1.x maintenance releases.
-
+
\ No newline at end of file
diff --git a/article/let-people-touch-godot/index.html b/article/let-people-touch-godot/index.html
index 949da3a544..fbc248094f 100644
--- a/article/let-people-touch-godot/index.html
+++ b/article/let-people-touch-godot/index.html
@@ -8,7 +8,7 @@
Pedro J. Estébanez9 December 2017
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.
Maybe you have already seen an AdPod around. They are three-sided giant multitouch-capable screens. The company behind them customizes them for very important customers for promotion campaings for things like movies (Disney, Universal).
They “skin” the device cosmetically for the targeted product and develop interactive apps that run on them. People walking by can interact with them, something which creates great product awareness and also entertains.
They have decided to use Godot for such development work! The switch from a well-known non-free engine they were using formerly has been a wise decision.
They were pretty confident about Godot’s features and solvency, but they needed multitouch support on Linux. That’s why they decided to hire someone to add it. However, as they feel so grateful for the Godot community for providing such a nice tool, they kindly decided to donate the code to the project!
What is more, they wanted to be sure that multitouch support is more widely available so the job was extended to ensuring it worked well on Windows too (it was already done, but needed some improvement) and creating well-commented examples in GDScript and VisualScript. Finally, they asked for all this to work on both Godot 2.1 and the upcoming 3.0.
We thank them for their contribution and for having become new Godot believers. They won’t regret!
Next time you see an AdPod, you’ll know Godot is ruling it. :)
For more information about them and what they do, you can visit their website: https://www.adpodnet.com/
-
+
\ No newline at end of file
diff --git a/article/look-gdnative-architecture/index.html b/article/look-gdnative-architecture/index.html
index 73561d104e..ec68b4b5c6 100644
--- a/article/look-gdnative-architecture/index.html
+++ b/article/look-gdnative-architecture/index.html
@@ -24,7 +24,7 @@
That function accepts a struct with function pointers and other information about the scripting language.
After a restart of the editor the language should be ready to be used.
Future plans
We are planning to create more extensions, for example for pluggable audio and video codecs.
All in all we are pretty satisfied with the current architecture of GDNative, next steps working towards the release will be more documentation and refining language bindings.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-0-2/index.html b/article/maintenance-release-godot-2-0-2/index.html
index 3ad370b2de..d5f52f07c0 100644
--- a/article/maintenance-release-godot-2-0-2/index.html
+++ b/article/maintenance-release-godot-2-0-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde8 April 2016
Edit (2016-04-11 20:44 CEST): New binaries were uploaded for the 2.0.2 release to include a late fix for a bug causing a memory overflow on some platforms, notably iOS.
As mentioned in an earlier announcement, while working on our future major version 2.1, we intend to provide maintenance releases every once in a while for the currently supported version (branch 2.0).
So one month after the release of Godot 2.0.1, here’s version 2.0.2 with some non-critical bug fixes and some usability improvements. Grab it now!
Distribution changes
OpenSSL temporarily disabled
Godot uses OpenSSL for HTTPS support in its networking API. For easier binary distribution, most official binaries were linked against an embedded copy of OpenSSL; however this one being somewhat old and thus vulnerable to various security issues, we chose to build the 2.0.2 binaries without OpenSSL support.
This is a temporary solution to work around the warnings you might be getting on Google Play or the Apple Store about security vulnerabilities in your binary. The better solution for future releases will be to update our embedded OpenSSL copy to the latest upstream release (cf. issue 2780).
If your game requires OpenSSL support, you can either:
Keep using version 2.0.1 which was built with OpenSSL support
Build binaries yourself with openssl=builtin (built-in version) or openssl=yes (system shared library)
Uncompressed binaries
We used to compress official binaries with UPX, a nice tool that generates small binaries with little decompression overhead. However, this tool is unmaintained since 2013 and has only experimental support for 64-bit Windows, and no support for 64-bit OSX and some other platforms. It has also been known to cause various issues on Windows with antivirus software, and might be related to a couple other bugs.
So for this release, we decided to distribute uncompressed binaries and see how it goes. If you liked having small binaries to distribute, you can still use UPX yourself on your export templates or exported binaries; we will put together some documentation about which templates can be safely compressed, and how to do it (in the meantime you can refer to UPX’s website for instructions).
Engine changes
The main highlights in this maintenance release are:
Enhancements:
Add -r flag to adb install for keep app user data
Add a sleeping_state_changed signal to RigidBody and RigidBody2D classes
Add stop and delete buttons to sample library
Added insert mode to text editor
Added rotation/panning support for trackpads in 3D mode
Bind Z key (without modifiers) to toggle wireframe in 3D view
Expose android/shutdown_adb_on_exit parameter and default to true
LineEdit/TextEdit: various improvements and fixes to copy, cut and paste behaviours
Option to toggle line numbers
Option to toggle tabulation drawing and configurable size
Separate help pages from scripts by default
Syntax highlighting for numbers, functions and member variables
Syntax highlighting for selected words
Bug fixes:
Fix crash when importing sub-scenes
Fix crash when resizing ConcavePolygonShape2D segments
Fix cursor getting locked on tree control if tree is cleared while modifying numerical element
Fix editors panels, of the bottom panel, not resizing in some cases
Fix errors when switching to a new scene with a spatial editor from a canvas editor
Fix file dialog, of Particles2D plugin, showing “Error” icons
Fix inconsistent file saving validation
Fix InputMap::action_erase_event()
OSX: Fix inverted horizontal scrolling
Hotfix (2016-04-11): Use non-templated nearest_power_of_2 (workaround for iOS out-of-memory crash)
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-0-3/index.html b/article/maintenance-release-godot-2-0-3/index.html
index 510f904ce9..c77135f5f4 100644
--- a/article/maintenance-release-godot-2-0-3/index.html
+++ b/article/maintenance-release-godot-2-0-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde13 May 2016
It’s been a bit over one month since the release of Godot 2.0.2, and a lot of work has been done in both the master branch and the stable 2.0 branch.
We will soon post more details about the cool new features which are cooking up in the master branch (such as drag and drop support and editor localisation), but in the meantime, let’s treat ourselves a nice bugfix release that also comes with interesting usability improvements. Grab it now, and read along!
Distribution changes
OpenSSL support re-enabled
In the previous release, we had to disable the support for the built-in OpenSSL library due to various security vulnerabilities. Thanks to the work of @mrezai, we could update our built-in version to the latest and thus most secure upstream version, 1.0.2h. So OpenSSL support has been re-enabled in the official binaries, which is especially useful for games that need to communicate with a server.
Windows binaries built with MSVC
Up to now, we were building the official Windows binaries on a Debian virtual machine using MinGW for the cross-compilation. Though it worked fine, many users mentioned a notable gain of performance when building binaries themselves on Windows using Microsoft Visual C++ 2015 (MSVC 14.0). Thanks to the help of @Marqin, we could setup AppVeyor to generate Windows binaries with MSVC alongside our existing Travis CI buildsystem.
So please test those new Windows binaries thoroughly, and give us feedback on any regression (or improvement) that you would experience!
64-bit editor binaries for OSX
We used to distribute only 32-bit binaries for the editor on OSX. As OSX is mainly 64-bit nowadays, we decided to start ship a 64-bit version too, so please test it and report any issue you might have.
Note that the OSX export templates were already distributed for both 32-bit and 64-bit in the past, so that part did not change.
Engine changes
The main highlights in this maintenance release are:
Enhancements:
Many new classes documented! Thanks to all those that got involved after our call for contributors! Feel free to join us as there’s still a lot to do, but the progress is heart-warming!
Ability to shrink all images x2 on load
Add preview of the Camera2D’s screen boundaries
Allow dragging on only one (global) axis when holding down shift
More precise InputMap Axis descriptions in project settings
Move export GUI debug toggle to export settings window
New Dictionary.has_all(Array)
Script editor usability improvements:
Autocomplete no longer shows duplicates
Fixed code completion after opening bracket
Options to change the caret color and toggle blinking
Option to trim trailing white space on save
Subclasses can extend from other subclasses via relative paths
Update to Godot’s regex library
Update OpenSSL to version 1.0.2h
Bug fixes:
AnimationPlayer: Prevent resetting timeline when pinned
Fix behavior of OS.set_window_resizable
Fix Camera2D ignoring zoom when checking limits
Fix checking unsaved changes only in current scene
Fix launching from .app on OSX
Fix ‘Quit to Project Manager’ not stopping the running application
Fix shader editor syntax coloring
Fix to avoid video texture scaling
GridMap: Fix backwards rotate hotkeys
Keep editable instances data when replacing tree root node
Made trackpad behaviour optional in 3D mode
Reimplement key input events in Emscripten export
Rotation APIs: Better exposure for degrees methods
The screenshot used for this article comes from the awesome Mouse Boat game by @CowThing that won the Godot Engine Jam 03/2016! If you haven’t already, check out all the other jam games, they are all open source and pretty fun!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-0-4/index.html b/article/maintenance-release-godot-2-0-4/index.html
index 6ed72c2ddd..a0df921603 100644
--- a/article/maintenance-release-godot-2-0-4/index.html
+++ b/article/maintenance-release-godot-2-0-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde9 July 2016
Edit (2016-07-10 8:00 UTC): A regression was found in 2.0.4 and is being worked on, please continue using 2.0.3 until we push fixed builds.
Edit (2016-07-10 16:30 UTC): A hotfix 2.0.4.1 version is now available and should fix the regression in the previous 2.0.4 binaries. You can download it as usual.
Short of two months since our previous maintenance release, and as the development branch for Godot 2.1 is getting production-ready, we are glad to announce the release of a new bugfix version in the 2.0 stable branch, Godot 2.0.4.1!
As for the previous maintenance releases, we cherry-picked non-intrusive bug fixes and usability enhancements from the master branch to provide you with a slightly better stable version while we’re waiting for the upcoming 2.1 release and its great new features. We consider the 2.0 branch production-ready at all times, so it’s safe to deploy your existing projects with 2.0.4.1.
Please note that this will likely be the last release in the 2.0 branch, as we expect our next stable version, Godot 2.1, to be released within a few weeks.
See below for more details about the fixes and enhancements in this new version, and go download it without waiting!
Distribution changes
“Fat” binaries for OSX
In the previous release, we added a 64-bit binary for the OSX editor, which is more relevant since most OSX systems are 64-bit anyway. Thanks a patch by a contributor, we found out that we could make “fat” binaries that contain both the 32-bit and 64-bit compiled code and can thus run on both architectures.
We now use this system by default for the official OSX editor binary and for the OSX export template. When exporting a game for OSX with the new templates, the “Fat” bits mode should already be preselected and work out of the box. The “32 bits” and “64 bits” mode are still available, but you would have to build your own export templates for OSX to use them, as we only provide the fat binary.
Engine changes
The main highlights in this maintenance release are:
Enhancements:
Many new classes documented! Thanks to all those that got involved after our call for contributors! Feel free to join us as there’s still a lot to do, but the progress is heart-warming!
The screenshot used for this article comes from the nice open source game Dungeon of Cor by @CowThing that won the Godot Community Game Jam of June 2016! If you haven’t already, check out all the other jam games, they are all open source and pretty fun! The theme was “Procedural” with a bonus theme being “Only two colors”, that led to quite interesting submissions :)
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-1-1/index.html b/article/maintenance-release-godot-2-1-1/index.html
index 0727c3d564..0b99fa7711 100644
--- a/article/maintenance-release-godot-2-1-1/index.html
+++ b/article/maintenance-release-godot-2-1-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde17 November 2016
Nov 20, 2016 @ 18:40 UTC: Linux export templates were problematic when deploying games to Steam. If that’s your case, you may want to redownload the export templates.
Nov 19, 2016 @ 15:30 UTC: If you downloaded Godot 2.1.1 before this date, there were issues with the packaging of the HTML5 templates and with the libpng dependency of the X11 binaries. You should redownload and install the export templates, as well as the Linux X11 editor binaries if you use them.
There is an unexpected behaviour change with shadows that slipped into the 2.1.1 release. Consult this GitHub issue if you experience missing shadows that used to work in Godot 2.1.
Already three months since the release of Godot 2.1! That was plenty of time for us to prepare a good version 2.1.1 with various bug fixes (but not so many, looks like Godot 2.1 was a pretty stable release) and tons of usability enhancements.
Download it now! (or wait a bit if you’re on Steam for the auto-update ;))
As announced in our previous blog post, we decided to skip the 2.2 release we had planned initially to focus on Godot 3.0, and therefore we will be supporting Godot 2.1.x for some more time. We also considered that some non-breaking new features such as the new AStar API could be safely backported to the stable branch, so that you don’t have to wait until 3.0 for every new developments.
As for maintenance releases of the previous 2.0.x stable branch, the aim of those releases is to bring you a slightly enhanced version of the current stable one which you can use to further develop and/or publish your games started in Godot 2.x. We do not expect any particular difficulty in migrating projects from Godot 2.1 to 2.1.1 (import API fixes are noted below).
Highlights
Gamepad support for OSX!
Generic AStar implementation - relatively fast and useful for situations where Navigation doesn’t cut it
More drag and drop possibilities (and fixes) from and to the SceneTree, Filesystem and Viewport. Try things, some intuitive actions should now be functional (e.g. dragging a scene from the Filesystem to the Viewport to instance it)
OpenGL compatibility enhancements: improved compatibility with older OpenGL 2.1 drivers, and prevent crashing when OpenGL 2.1 is not supported
Third party libraries refactoring: now shipped in a separate folder and they can be easily unbundled (thus linking against system libraries) on Linux (especially relevant for Linux packagers)
Usability and quality of life improvements all over the place
Dozens of bug fixes
Many class reference documentation updates
Editor translation updates
Other notable changes
The full list of changes is of course much lenghtier, as we had 271 commits cherry-picked for the stable since the 2.1 release, but here is a selection of some of the most interesting ones (minus the ones mentioned in the above highlights):
Add constants from types in code completion (e.g. Label.ALIGN_CENTER or Mesh.PRIMITIVE_TRIANGLES)
Add shortcut to reset cursor position in 3D Editor
Add snapping to 3D path handles to bring it in line with its 2D counterpart
Expose more 2D/3D physics options in project settings
Fix position issues in various Controls: Accept/ConfirmationDialog, ItemList, Label
Fix LineEdit text selection with mouse selecting more than intended
Fix locale parsing on Mac OS and fallback to global language if country-specific one is not provided
Fix resetting to default value in EditorSettings
Hide the mouse cursor when MOUSE_MODE_CAPTURED is activated
Library updates: libpng 1.6.26, squish 1.14
Make the step property useful for sliders
More color magic from Paulb23: Configurable script background color, grid color, current script highlighting
Possibility to replace a node with saved branch scene instance
Preserve groups when replacing nodes
Show object StringName instead of object ID in the debugger
TileMap editor: Bucket tool - allow deleting and replacing of tiles
TileMap editor: Display fixes and enhancements on the tile palette
TileMap editor: Display current tile coordinates under the pointer
Various buildsystem improvements for Android, Windows, etc.
Various enhancements to EditorPlugins and EditorSettings classes
Various fixes and enhancements to the GridMap editor
That’s it for this relatively big maintenance release! The next one (Godot 2.1.2) should likely arrive before Christmas or in early 2017 (unless there are strong regressions to fix in the coming days/weeks ;)). Godot 2.1.2 should bring IPv6 support (already in master, but it needs to be backported and tested in the stable branch), which is becoming a requirement to deploy on Apple devices.
Have fun with this new release!
The illustration image (full size) is a screenshot from the 3D mobile game Marble Machine by Kivano, one of the nice indie studios gravitating in our community (and contributing to the engine development too!).
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-1-2/index.html b/article/maintenance-release-godot-2-1-2/index.html
index 6507d26372..22a313a3c1 100644
--- a/article/maintenance-release-godot-2-1-2/index.html
+++ b/article/maintenance-release-godot-2-1-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde21 January 2017
Five months after the release of Godot 2.1, and two months after 2.1.1, it’s the right time for another maintenance release in the stable branch!
While we are all looking with avid eyes at the awesome developments for Godot 3.0 shown on our Devblog or Juan’s Twitter, you won’t find much of them in this release… but it should already have some quality of life improvements and important bug fixes that you will definitely want for your published and WIP projects.
This release is quite important for Apple developers, as it brings IPv6 in the networking API, which is now a requirement for applications on the Apple Store. It also fixes a regression from 2.1.1 in the OSX binaries, which had unwillingly set the minimum required OSX version too high.
Another major change is that a bug was fixed in the initialization of most audio drivers which caused an audio latency of about ~200 ms, quite annoying for games which need a precise timing for samples.
Networking: IPv6 support and many bug fixes and enhancements
Audio: Fix ~200 ms audio latency bug due to misinitialization of some drivers
GDScript: Ternary operator (a if cond else b)
2D: Easy API for 2D split screen (with demo)
OSX: Fix minimum supported version when compiling with recent Xcode, now 10.9 (regression in 2.1.1)
Dozens of bug fixes
Many class reference documentation updates
Editor translation updates
Other notable changes
The full list of changes is of course lengthier, as it contains 112 commits made since 2.1.1-stable (excluding merge commits). Here’s a selection of some of the most interesting ones for end users:
Linux/X11: Fix crash when neither ALSA nor Pulse are installed
Web: Fixes and improvements for WebAssembly/asm.js
Editor: Fix Script Editor drawing over dialogs
Editor: Ability to change visibility when ancestor node is hidden (with proper visual feedback)
Editor: Add bucket fill preview in TileMap
Editor: Add favorites and recent history to create dialog
GDScript: Named colors in the Color API
2D: Fix Particle2D initial size randomness property having no effect
2D: Add the finished signal to AnimatedSprite
2D: Add Node2D’s set_global_rot, set_global_rotd, set_global_scale and corresponding getters
GUI: Make deselect work for TreeItem in SELECT_SINGLE mode and emit item_selected
GUI: PopupMenu upgrade: Hide on item selection
GUI: Flat button and and styleboxes for ButtonArray
Libraries: Embedded library updates: libpng 1.6.28, zlib 1.2.11, opus 1.3 and opusfile 0.8, webp 0.5.2
That’s it for this release, as usual it brought its fair share of bug fixes and improvements and upgrading existing projects to this new version should be hassle-free.
Support duration
As mentioned previously, the 2.1.x stable branch will continue to receive bug fixes and enhancements at least until Godot 3.0-stable is released - and potentially beyond, depending on whether version 3.0 will support OpenGL 2.x / OpenGL ES 2.x devices.
Our current gut feeling sets the 3.0 release around May/June 2017 - it will definitely be our biggest (and likely greatest) release so far!
Have fun with this new release!
The illustration image (full size) is a screenshot from the 2D game Satellite Repairman by Nuno Donato which is about to be released on Steam for Linux, macOS and Windows. Nuno is one of the nice indie devs gravitating in our community (and contributing to the engine development too!).
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-1-3/index.html b/article/maintenance-release-godot-2-1-3/index.html
index 46f16f5936..ae5e9218c2 100644
--- a/article/maintenance-release-godot-2-1-3/index.html
+++ b/article/maintenance-release-godot-2-1-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde12 April 2017
Short of three months after the release of Godot 2.1.2, the community is proud to announce this new maintenance update in the stable branch, Godot 2.1.3!
Due to the long development process of the upcoming Godot 3.0 (see our Devblog for technical posts about its impressive progress), many contributors took a renewed interest in the 2.1 branch. This release therefore brings various new features to GDScript, the editor, some nodes’ API – but we tried to ensure that compatibility with earlier 2.1.x releases would be fully preserved.
A big thankyou to all the contributors who worked on this release by implementing bug fixes or features, or testing the changes to spot potential regressions and help debug issues.
As an aside, please note that there is no ETA for the release of Godot 3.0. We still vividly recommend to new and existing users to develop their projects with the stable branch, as the current development branch is not production-ready (and might still see slight compatibility breakages as we continue improving the consistency of its API).
Highlights
Audio: Add priority setting for samples in a library
Audio: Make spatial AudioServers prefer inactive voices instead of unconditionally playing on the next voice slot
Controls: Add ColorFrame control
Controls: Add shape property to TouchScreenButton
Editor: Add contextual create/load script button to the Scene Tree dock
Editor: Implement warped mouse panning for 2D & 3D editors (enabled by default)
Editor: Only assume HiDPI mode if DPI >= 192 and screen width > 2000 (fixes editor starting in excessively upscaled mode on some configurations)
GDScript: Add enumerators (enums)
Nodes: Add ability to change A-star cost function
Nodes: Add modulate (color) to TileSet tiles
Nodes: Add get_used_rect() method to TileMap
iOS: Implement core motion API
Tools: Work in progress (read: buggy, will be improved for Godot 2.1.4) exporter to Godot 3.0 alpha format
About the Godot 2 to 3 converter, please note that it’s an early version. It does not modify your scripts, so you will have to do the relevant API changes manually (the debugger will report invalid syntax, and the documentation should help find what the next syntax is). It might also crash on some projects, it was only tested on simple demos so far.
Other notable changes
The full list of changes is of course lengthier, as it contains 201 commits made since 2.1.2-stable (excluding merge commits). Here’s a selection of some of the most interesting ones for end users:
Android: Cache DynamicFont resource
Android: Implement gravity vector
Controls: Various fixes and improvements to TouchScreenButton
Editor: Add ‘Copy Node Path’ action to right mouse menu
Editor: Add option for automatically closing the output when stopping the game
Editor: Don’t show lock icons for hidden nodes
Editor: Fixed bug in GDScript autocompletion of the parent class
Editor: Implement single-field property change for multinode edit
Editor: Improve 2D snapping behavior
Editor: Make buttons closer in Scene Tree dock
Editor: Several enhancements for the tile map editor
GUI: Fixes for TouchScreenButton
Input: Update mouse position on touch and release events and mouse button events
iOS: Fix magnetometer
Networking: Many fixes for IPv6 support, HTTPClient, UDP and TCP
Nodes: Add flags parameter to Node.duplicate() to decide whether signals, groups and/or scripts should copied
Nodes: Add process mode option to Particles2D
Nodes: Implement texture flip parameters for Particles2D
Nodes: Improve resize behaviour of TextureButton and TextureFrame
Nodes: Honor the Tween’s final value
Physics: Fix KinematicBody2D wrong motion origin
Physics: Improvements to Area and Area2D’s monitoring flag
Windows: Fix debugging when offline
Resources: Improve .tscn and .tres VCS friendliness
Various crash fixes and other bug fixes
Updates to gamepad mappings
Updates to bundled libpng (1.6.29), libwebp (0.6.0), opus (1.1.4) and squish (1.15)
That’s it for this release, as usual it brought its fair share of bug fixes and improvements and upgrading existing projects to this new version should be hassle-free.
Support duration
As mentioned previously, the 2.1.x stable branch will continue to receive bug fixes and enhancements at least until Godot 3.0-stable is released. Given that Godot 3.0 alpha currently has no support for OpenGL 2.x / OpenGL ES 2.x devices, we will likely continue to maintain the 2.1.x branch further until Godot 3.1, which should add back support for older devices.
Have fun with this new release!
The illustration image (full size) is a screenshot from RPG in a Box, a set of tools for creating 3D voxel RPGs based on Godot. It is developed by Justin Arnold and is already used for various RPG games.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-1-4/index.html b/article/maintenance-release-godot-2-1-4/index.html
index 44d9ab3bef..120eb2afda 100644
--- a/article/maintenance-release-godot-2-1-4/index.html
+++ b/article/maintenance-release-godot-2-1-4/index.html
@@ -6,7 +6,7 @@
For this release, there were 337 commits made by 81 contributors! Let’s see what they bring us.
Highlights
This release has seen many platform-specific improvements from old and new contributors, especially for macOS, iOS, X11… and quite notably the WinRT (a.k.a. UWP in the master branch) port was updated and is now provided with the export templates, which means that the Windows Store and Xbox One should now be accessible (this port is still at the beta stage though, bug reports welcome).
Here are some highlights of the most important changes:
Platform: macOS: system menu integration, better multimonitor DPI scaling, audio and input improvements
Platform: Support for UWP (Universal Windows Platform) alias WinRT as target platform, with gamepad support
2D editor: Fix IK not being solved while dragging a bone (regression in 2.1.3)
3D editor: Ability to select subscenes when clicking them in the viewport
Debugging: Many improvements to the editor’s debugger and display of complex types
Display: Add “expand” option for window stretch aspect
GDScript: Backport advanced string format feature from the master branch
Physics: Add one-way collision to tile-set/tile-map
Physics: Backport move_and_slide API from the master branch
Tools: Improvements to the Godot 3.0 exporter (still work-in-progress)
Other notable changes
The full list of changes is of course lengthier, as it contains over 300 commits made since 2.1.3-stable (excluding merge commits). Here’s a selection of some of the most interesting ones for end users:
2D editor: Clean up canvas item when changing state
3D editor: Increase the default perspective camera FOV
Audio: Implement 32 bit IEEE float WAVE format
Buildsystem: Improve support of Visual Studio 2017 compiler
Buildsystem: Update gradle to 3.3
Core: Backport StreamPeerBuffer from the master branch
Core: Improve efficiency of atlas packing algorithm
Core: Use libsquish to decompress DXT textures
Core: Various enhancements to the AStar API
Editor: Default game window placement to Centered
Editor: Improvements to remote debug configuration (host/port, better error reporting)
TileMap: Fix infinite loop when trying to bucket-delete empty tiles
Translation and documentation updates
Various bug fixes (including some crash fixes)
All in all, this is a pretty big maintenance release, and it should improvement the usability of the stable Godot 2.1 while we are waiting for the upcoming 3.0 version.
Support duration
As mentioned previously, the 2.1.x stable branch will continue to receive bug fixes and enhancements at least until Godot 3.0-stable is released. Given that Godot 3.0 is not planned to have support for OpenGL 2.x / OpenGL ES 2.x devices, we will likely continue to maintain the 2.1.x branch further until Godot 3.1, which should add back support for older devices.
So you can expect at least a 2.1.5 release in the future (especially in order to bring a more final version of the 3.0 exporter once the master branch is stable enough), likely in a couple of months.
Have fun with this new release!
Supporting the development
If you’d like to support Godot’s development, apart from making cool games with it or contributing directly to the engine with code or bug reports, you can make a financial donation on Patreon to enable us to hire our lead developer Juan Linietsky full-time, thus greatly increasing the development rate of new features and bug fixes!
The illustration image (full size) is a screenshot from GOLTORUS, an open source Game of Life simulation on the surface of a torus, using Godot 3.0 alpha1’s nice glow feature. Made by Bauxite.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-1-5/index.html b/article/maintenance-release-godot-2-1-5/index.html
index 5c675820d6..bce07ac11f 100644
--- a/article/maintenance-release-godot-2-1-5/index.html
+++ b/article/maintenance-release-godot-2-1-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 July 2018
At long last, Godot 2.1.5 is ready and comes packed with new features and bug fixes! It’s the result of 11 months of work (since 2.1.4) from many contributors who care about supporting our previous stable branch (the current one and main focus being Godot 3.0.x).
Download it now from our repositories if you are still using Godot 2.1.x for some projects. If you use it via the Steam distribution (where both 2.1.x and 3.0.x are included), it has been updated already - please keep in mind that we’ll eventually stop distributing Godot 2.1.x on Steam (likely when moving to Godot 3.1). Note: This release fixes security vulnerabilities in Godot’s marshalling code (see the Godot 3.0.6 announcement for details) as well as an OpenSSL security update, so upgrading to this version is strongly recommended if you use any networking features.
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.
Wait, what is 2.1.x again?
Before presenting the highlights of this release, let’s clear some frequently asked questions upfront:
What is 2.1.5? Isn’t the current stable version 3.0.x?
Godot 2.1 (from August 2016) was our previous major release before Godot 3.0 (from January 2018). Just like the current 3.0.x branch, it received maintenance updates with bug fixes and enhancements every few months, though the last to date was 2.1.4 in August 2017.
As some users cannot use Godot 3.0 or later for a number of reasons, we are still maintaining the 2.1.x branch for a while. Those reasons are typically:
OpenGL ES 2.0 support needed for mobile games. Godot 3.0 only supports OpenGL ES 3.0 which is problematic on many mobile devices. The upcoming Godot 3.1 will bring back support for OpenGL ES 2.0, so by then the 2.1.x branch will cease to be so important for mobile developers.
Existing projects started in Godot 2.1 might not always be worth porting to 3.0 given the important compatibility breakage.
The latter implies that new 2.1.x releases can be needed for users willing to push their 2.1 games in production, and especially:
Distribution platforms like Google Play or Apple Store regularly increase their requirements in terms of targeted SDKs, so we need to update our export templates accordingly.
Security vulnerabilities in thirdparty libraries or in Godot’s own code need to be addressed in all supported branches.
I’m using 3.0.x, do I need this new release?
If you don’t know, you probably don’t. The 2.1.5 release is strictly intended for existing users who need it to publish or update their 2.1 games. If you are already using Godot 3.0.x, stick to it as it has hundreds of features that Godot 2.1.5 does not have, since it’s based on a 2016 branching of the main development branch.
Where are all the cool new features seen on the blog?
Most new features you see on this blog or on Twitter are merged in the master branch, which is the development branch of our next stable branch, i.e. Godot 3.1. So those features are only available in nightly builds, or when compiling from the master branch - they will eventually be made available for all with Godot 3.1 alpha 1, and in a few months 3.1-stable.
Highlights
With 11 months of work and over 450 commits to the 2.1 branch since 2.1.4, there’s a lot to cover! Check the detailed changelog for the exhaustive listing.
Here are some of the main highlights of this release, listed by topic/category.
Platform support
Android
APKs no longer include placeholder permissions that Google Play started complaining about in May 2018 (same fix as in Godot 3.0.5). [GH-20082]
Minimum SDK raised to 18 (Android 4.3) to allow signing APKs with SHA-256 + RSA. [GH-18626]
Exporting for macOS from a Mac now generates a .dmg package. [GH-11476]
Implement vsync OS functions for macOS. [GH-12354]
Windows
New WASAPI audio driver with better latency than RtAudio (as in 3.0). [GH-10942]
Common
Add hardware cursor acceleration support for all platforms. Note: Breaks compatibility with cursor methods in Input, some scripts might need to be adjusted. [GH-13437]
Add OS.center_window to center the window precisely on desktop platforms. [GH-13930]
Editor tools
New crash handler to generate backtraces when crashing on all desktop platforms (as in 3.0). [GH-10124]
Dozens 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.
Add class members overview in script editor. [GH-11909]
New contextual menu in FileSystem dock. [GH-13029]
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-2-1-6/index.html b/article/maintenance-release-godot-2-1-6/index.html
index 6363fc7271..433cde21ba 100644
--- a/article/maintenance-release-godot-2-1-6/index.html
+++ b/article/maintenance-release-godot-2-1-6/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde11 July 2019
“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).
This Godot 2.1.6 release addresses new requirements from Google Play and Apple store, as well as updates 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, and will be included in an upcoming Godot 3.0.7 for the same reason. Additionally, the templates now target the Android API level 28 as required by Google Play from August 2019 onwards.
Apple Store now requires binaries compiled against the iOS SDK 12.1 or later to support the latest iterations of its OS, so Godot 2.1.6 templates are built against this SDK.
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.
Update (2019-07-12 @ 7:00 UTC): The Android templates released initially were mistakenly built against an older AndroidManifest.xml and still targeted API 27. If you downloaded the templates archive before this update was posted, you should redownload the templates to have API 28 support.
Highlights
As the focus is on release critical issues, the changelog is relatively short and upgrades should be problemless. Most fixes are related to platform-specific issues.
Thirdparty: libpng 1.6.37 (security update), openssl 1.0.2s (security update), libvorbis 1.3.6, libwebp 1.0.2, Mozilla CA certificates from Dec 2018.
Thanks to all contributors who worked on this release to make sure that Godot 2.1 users can keep publishing their games on their target platforms.
The illustration picture is a screenshot of *Kingdoms of the Dump, a gorgeous trash-themed RPG developed by Roach Games using Godot 2.1, coming to Kickstarter on July 15. Follow them on Twitter or register to their junkmailing list.*
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-0-1/index.html b/article/maintenance-release-godot-3-0-1/index.html
index 1e4af031a3..a3f7e4a452 100644
--- a/article/maintenance-release-godot-3-0-1/index.html
+++ b/article/maintenance-release-godot-3-0-1/index.html
@@ -8,7 +8,7 @@
HP van Braam25 February 2018
Since we haven’t found any major issues in our release candidate, we are now releasing Godot 3.0.1! The only regression reported was a renaming issue on Windows which we fixed.
If you were eagerly waiting for 3.0.1, you can go directly to our Download page and get the benefits of all the fixes! Both the itch.io and Steam distributions are updated.
We have added many new features to the editor (and several to GDScript) in this release which we think will make your use of Godot even better. We’ve also fixed several nagging issues and generally put together a really nice update for our users of the stable branch. Please note that this is not the much-expected 3.1 release, so OpenGL ES 2.0 is not yet supported. Adding GLES2 support will necessitate some breakage for existing projects, so we will not merge that in this series of stable releases.
Sadly C# export templates weren’t finished for this release. Preliminary support has landed in master in this commit, but a little more work and broad testing are required before we can release this for general consumption. We’ve decided that holding back all of these important fixes and little niceties in the editor to have C# exporting in a release called ‘3.0.1’ wasn’t worth the wait. Please note that us releasing 3.0.1 now doesn’t mean that C# exporting has been delayed. When C# exporting is ready we will release a new stable patch immediately. This way all our users get the best possible experience while our C# users won’t get export capability any later than they otherwise would have.
I’d like to thank all of our wonderful contributers for making 3.0.1 possible. I’d also like to thank the people who took the time to test the release candidate and report back to us. Now back to waiting for 3.0.2!
What’s new in this release
Here are some of the highlights of this release. See the full changelog for details.
The ‘server’ platform is back as it was in Godot 2.1. It is now again possible to run a headless Godot on Linux.
Godot can now be started with --build-solutions on the command line. This will let you build C# solutions without starting the editor. This is helpful for CI pipelines.
Another new CLI option is --quit which will quit the engine after the first main loop iteration. This is also helpful for CI pipelines.
It is now possible to scale an .obj mesh when importing.
Type icons are back! If you missed them you can enable them in the editor settings.
Several new GLSL built-in functions are exposed to the shader language : radiansdegreesasinhacoshatanhexp2log2roundEven.
It is now possible to center your game window with OS.center_window().
You can set the tcp_nodelay flag on a StreamPeerTCP with the set_no_delay method.
For EditorPlugins, it is possible to remove a control from a container with the new remove_control_from_container() method.
A button has been added to the debugger to copy the error messages, useful for pasting them in bug reports or other community platforms.
The Ctrl toggles snapping in the 3D viewport.
Support has been added for a new .escn, similar to .tscn, but meant to be converted to a binary .scn on import (for use with the work-in-progress Blender exporter).
CA certificates have been updated to the latest Mozilla bundle.
And many more.
Fixed issues
Here are some of the more visible bugs fixed in this release. See the full changelog for details.
Copy/pasting from the editor on X11 will now work more reliably.
The lightmap baker will now use all available cores on Windows like it does on macOS and Linux.
Fixed missing text in some FileDialog buttons.
Fixes to HTTP requests on the HTML5 platform.
Many, many fixes and improvements to C# support (including a [Signal] attribute).
Static linking of libgcc_s as well as libstdc++ to allow more portability for Linux Godot templates between older and newer distributions.
Fix broken APK expansion on Android.
Several crashes in the editor have been fixed.
Many documentation fixes.
Several hiDPI fixes.
And many more.
Known incompatibilites 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.
C# assemblies built with Godot 3.0 won’t be compatible with 3.0.1, and the editor will 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). This version still requires the Mono SDK at version 5.4 (latest being 5.4.1.7). Older and newer branches are not compatible.
Known bugs in Godot 3.0.1
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.1 so this function will remain non-functional.
The editor fails to auto-complete enums from autoloaded external scripts. This will be fixed in 3.0.2. See #17025 for details. This issue is annoying but largely cosmetic as it doesn’t affect running your project.
Running an individual scene from a project without a main scene defined does not work. This will be fixed in 3.0.2. See #17028 for details. As a workaround please set any scene as a main scene and you can run individual scenes like normal.
Moving objects around using C# has regressed since 3.0. This will be fixed for 3.0.2. See #16937 for details.
TextureProgress causes a bad polygon error when the progress percentage is between 62 and 99. This then causes it to disappear. We will fix this for 3.0.2. See #17102 for details.
RichTextEdit doesn’t properly calculate the height of the first line when wrapping text. We will fix this for 3.0.2. See #17139 for details.
Future releases
To make things clear as many users seem confused about it, we currently support two stable branches (2.1 and 3.0), and the feature development happens on the master branch which will become the 3.1 stable branch once its planned features are ready (especially OpenGL ES 2.0 support).
That means that our next releases will be (not in a chronological order):
2.1.5: We released a Beta 1 build a week ago. A Beta 2 build will come in the following days to address the main shortcomings reported in the first beta. The 2.1 branch will be supported until the 3.1 release, so at least a few months more, and afterwards with security fixes for games in production.
3.0.2: More backward-compatible bug fixes and enhancements to the current stable branch. C# support is still in alpha so backward-incompatible improvements are still allowed in this branch (and will happen).
3.1: As soon as the OpenGL ES 2.0 renderer is finalized, we will work on stabilizing the new features and release 3.1-stable.
Have fun with 3.0.1 in the meantime!
Help make Godot better!
You can greatly help us improve Godot, as well as make it faster and better. Besides contributing code (if you are a programmer), you can help us a lot by becoming our patron. We still need a last push to reach our third goal and hire Rémi (Akien) full-time as project manager and representative!
Additionally, spreading the word will always benefit us, as most game developers still have never tried (or even heard of) Godot. Finally, the best contribution might be to use Godot to develop and publish awesome games!
The illustration picture is courtesy of John Watson (@yafd), who does nice PBR scenes using the new features of Godot 3.0.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-0-3/index.html b/article/maintenance-release-godot-3-0-3/index.html
index 4f97c42436..5ed32d9210 100644
--- a/article/maintenance-release-godot-3-0-3/index.html
+++ b/article/maintenance-release-godot-3-0-3/index.html
@@ -5,7 +5,7 @@
HP van Braam13 June 2018
We are proud to announce the availability of Godot 3.0.3. Thanks to Ignacio Etcheverry (neikeq) it is now possible to export C# based projects to Windows, Linux, and MacOSX! This release, however, still has the APK permission problem. We’re hoping to fix this problem soon. In the meantime we have a tool that can fix your APKs after export available.
Apart from the C# export fixes we’ve also fixed many bugs (we pulled in over 350 patches into this release!) and have a new universal touch to mouse translation system written by Pedro J. Estébanez (RandomShaper).
As usual you can go directly to our Download page to download the new release. Itch.io and Steam releases are still in the process of being updated. Please check back later. Please note that for the Mono releases you must use Mono 5.12.0 on all platforms.
I’d like to use this space to thank our contributors. The effort they put into Godot makes the building of the pyramids look like building a sandcastle.
What’s new in this release
Here are some of the highlights of this release. See the full changelog for details.
Mono: Exporting to desktop platforms now works.
Universal translation of touch to mouse.
print_tree_pretty() was added allowing a graphical view of the scene tree.
Vector3::round(), Vector2::round(), and Vector2::ceil() methods were added.
Dynamic fonts can now have a hinting mode set.
Restore purchases feature for iOS.
AudioStreamPlayer, AudioStreamPlayer2D, and AudioStreamPlayer3D now have a pitch scale property.
Show origin and Show viewport setting in 2D editor.
You can now set Godot windows as ‘always on top’.
--print-fps options to print FPS to stdout.
Note that assets MD5 sums are now saved in the res://.import/ folder instead of each asset’s .import file (this allows you to ignore MD5 sum changes in your version control system). This will cause a reimport of all assets the first time you load your project in Godot 3.0.3.
Fixed issues
Here are some of the highlights of this release. See the full changelog for details.
Mono: Signal parameters no longer crash the engine.
Asset library thread usage, this makes the asset library more responsive.
Several GLTF import fixes.
Several memory leaks were plugged.
iPhone X support.
Several fixes to audio drivers (WASAPI and PulseAudio).
Several crashes were fixed.
Export PCK/ZIP now works again.
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.
When exporting to iOS you get an error about missing or corrupt templates if the App Store Team Id or Required Icons are not set even if the templates are installed.
There are some issues with the asset library browser when moving the window while images are loading, this sometimes leads to a crash on Windows.
The illustration picture is courtesy of FireBelly (http://tenaciousgame.com/), who is making a game called ‘Tenacious’ which is a loot-heavy 2D dungeon crawler with rogue-like elements using Godot written in C#.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-0-4/index.html b/article/maintenance-release-godot-3-0-4/index.html
index 37dc4bb7e7..f8fc276d69 100644
--- a/article/maintenance-release-godot-3-0-4/index.html
+++ b/article/maintenance-release-godot-3-0-4/index.html
@@ -5,7 +5,7 @@
HP van Braam22 June 2018
Welcome to Godot 3.0.4. This is a bit of a brown paper bag release. There is a bug in 3.0.3 causing crashing of the asset library on systems with low threadcount CPUs. This was missed as I did testing only with machines of 8 threads and higher. This bug in itself wouldn’t be the worst but for many new users this is the first interaction with Godot they have. This is why we decided on this tiny release.
We took this opportunity to add some documentation fixes as well as a fix for Bullet physics to allow Marc Gilleron (Zylann)’s terrain plugin to function with Godot 3.0.4.
If you are not affected by the asset library bug and do not need the terrain plugin there is no need to upgrade to Godot 3.0.4.
We’re planning for a larger 3.0.5 soon with Android exporting fixed and other bug/feature PRs merged.
As usual you can go directly to our Download page to download the new release. Itch.io and Steam releases have been updated too. Please note that for the Mono releases you must use Mono 5.12.0 on all platforms.
I’d like to thank everyone involved in this release. I’ll be the one wearing the brown paper bag.
What’s new in this release
Here are some of the highlights of this release. See the full changelog for details.
Marc Gilleron (Zylann)’s excellent terrain plugin now works due to some fixes in the Bullet physics.
Several documentation fixes
Fixed issues
Here are some of the highlights of this release. See the full changelog for details.
Fixed crasher in asset library on systems with a low threadcount CPU
Known incompatibilities with Godot 3.0.3
None
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.4
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.
When exporting to iOS you get an error about missing or corrupt templates if the App Store Team Id or Required Icons are not set even if the templates are installed.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-0-5/index.html b/article/maintenance-release-godot-3-0-5/index.html
index bca20c5228..045e5c3da9 100644
--- a/article/maintenance-release-godot-3-0-5/index.html
+++ b/article/maintenance-release-godot-3-0-5/index.html
@@ -5,7 +5,7 @@
HP van Braam8 July 2018
Oh hello, I didn’t see you there. Come in and join us at the dinner table with Godot 3.0.5. This is another relatively small release but many people were bitten by the Google Play privacy policy issue. This is why we decided to release sooner rather than later. In this release the placeholder permissions are gone and exported APKs are clean.
If you use any of the following permissions: CALENDAR, CAMERA, CONTACTS, LOCATION, MICROPHONE, PHONE, SENSORS, SMS, STORAGE you must add a privacy policy to your Google Play account. This is not a Godot requirement but a Google requirement. If you do not use any of these permissions with Godot 3.0.5 and later you don’t need to do anything.
Other than this we’ve fixed an error on exported C# projects and fixed some other small issues. I expect the next release to be a bit meatier.
As usual you can go directly to our Download page to download the new release. Itch.io and Steam releases will be updated soon Please note that for the Mono releases you must use Mono 5.12.0 on all platforms.
As always this release would not have been possible without the laserlike focus of our wonderful contributors.
What’s new in this release
Here are some of the highlights of this release. See the full changelog for details.
‘android_add_asset_dir(‘…’) method to Android module gradle build config.
Fixed issues
Here are some of the highlights of this release. See the full changelog for details.
Android exporter no longer writes unnecessary permissions to the exported APK.
Segfault when quitting the editor.
Debugger ‘focus stealing’ now works more reliably.
Subresources are now always saved when saving a scene.
WebAssembly: Supply proper CORS headers.
Mono: Annotated signal loading in exported projects.
Mono: Serveral fixes.
Known incompatibilities with Godot 3.0.4
None
Known incompatibilities with Godot 3.0.3
None
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.5
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.
When exporting to iOS you get an error about missing or corrupt templates if the App Store Team Id or Required Icons are not set even if the templates are installed.
32Bit Mono builds appear to not function properly with Windows 8.1 64bit.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-0-6/index.html b/article/maintenance-release-godot-3-0-6/index.html
index 56ae380da6..dcd3e8a29d 100644
--- a/article/maintenance-release-godot-3-0-6/index.html
+++ b/article/maintenance-release-godot-3-0-6/index.html
@@ -5,7 +5,7 @@
HP van Braam29 July 2018
Godot has had its first public security issue. This has been an… interesting experience for our team. The issue in question affects people that try to deserialize untrusted native Godot data. For the most part this only affects people running as a networking server but people serializing savegame data may also be affected. This last case for the most part would allow people to cheat in their local games. For details on the security issue itself please see this issue for technical details.
The issue was found by our very own Fabio Alessandrelli. He also wrote the fixes that are in 3.0.6 and 2.1.5 now. He did an amazing job.
In addition to this important security update this release also adds some bugfixes, some Mono fixes, and we introduce a new download type called ‘headless’. We had a variety of users trying to use the ‘server’ releases to do importing of assets or exporting as part of a CI pipeline. For performance reasons as of 3.0.3 the ‘server’ release actually no longer had this functionality. To retain the performance improvement for users who use the server release as, well, a server we have now added the ‘headless’ download. This download has all of the tools included and should work in a CI pipeline.
As usual you can go directly to our Download page to download the new release. Itch.io and Steam releases will be updated soon Please note that for the Mono releases you must use Mono 5.12.0 on all platforms.
Please join me in an exuberant standing ovation to our dashingly beautiful contributors and their near impossible dedication to making Godot the best game engine it can be!
What’s new in this release
Here are some of the highlights of this release. See the full changelog for details.
Added the headless build for CI use.
Upgrade bundled OpenSSL to 1.0.2o
Fixed issues
Here are some of the highlights of this release. See the full changelog for details.
Several editor crashes.
GLTF import fixes.
Windows: Fix touch/pen input.
Mono: --build-solutions now forces editor mode.
Mono: Several bugfixes.
Headless: Fix scene imports.
Known incompatibilities with Godot 3.0.5
None
Known incompatibilities with Godot 3.0.4
None
Known incompatibilities with Godot 3.0.3
None
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.6
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.
When exporting to iOS you get an error about missing or corrupt templates if the App Store Team Id or Required Icons are not set even if the templates are installed.
32Bit Mono builds appear to not function properly with Windows 8.1 64bit.
The illustration picture is a screenshot of John Gabriel’s game Fire and Fondless which won the June 2018 Godot game jam
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-1-1/index.html b/article/maintenance-release-godot-3-1-1/index.html
index 57d9b5d4bb..78e468f50a 100644
--- a/article/maintenance-release-godot-3-1-1/index.html
+++ b/article/maintenance-release-godot-3-1-1/index.html
@@ -5,7 +5,7 @@
HP van Braam27 April 2019
It’s been about a month and a half since the release of 3.1-stable, and our contributors have worked hard to get you, most valued users, bugfixes, new features, and documentation updates. So on this nice and sunny Dutch King’s Day we’re happy to announce the availability of the first maintenance release in the 3.1 series Godot 3.1.1-Stable. Hail to the king, baby!
With the -stable releases we offer you the backwards compatible changes and bugfixes. However in this release we had to break some compatibility with networking due to a security issue. See the Known incompatibilities section of this blog post. If we inadvertently changed behavior for your project started with Godot 3.1-stable please report a bug.
I’d like to use this space to say “Thank you” to our amazing contributors, none of whom would ever give you up, let you down, and/or desert you. If you too would like to to be counted amongst their ranks join us and fix bugs, write documentation, or file bugreports.
If you enjoy our work please consider becoming our Patron and help Godot main developers work full time on the project!
Changelog
A security issue was reported and fixed. This change does add some API to Godot in case you need to be able to deserialize Object data. Please see This PR for details. If you do not use networking in your project you should not be affected. However GDNative ABI was changed so any native plugins need to be rebuilt for 3.1.1.
New menu options for the Sprite editor were added: “Convert to Mesh2D”, “Convert to Polygon2D”, “Create CollisionPolygon2D Sibling” and “Create LightOccluder2D Sibling”.
Below we describe the known incompatibilities with previous releases in this cycle.
Known incompatibilities with Godot 3.1
Due to a security fix the GDNative ABI has changed. If you use GDNative modules in your project they will need to be rebuilt from source.
Godot no longer automatically decodes Objects when using high level multiplayer. If you do want your client or server to do this it is now necessary to explicitly allow it. See this PR for details.
Previously on Android OS.get_unique_id() would return the static value for Secure.ANDROID_ID. This was a bug and now an actually unique ID is returned. If you were using the unique ID for encryption purposes you must now also check the original static value or your users may lose access to any encrypted (save) data.
Known bugs in Godot 3.1.1
None
The illustration picture is a screenshot of *GRIEF, a game in development by Manuel ‘TheDuriel’ Fischer and IAmActuallyCthulhu.*
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-1-2/index.html b/article/maintenance-release-godot-3-1-2/index.html
index b1695de758..cada2f008c 100644
--- a/article/maintenance-release-godot-3-1-2/index.html
+++ b/article/maintenance-release-godot-3-1-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde29 November 2019
While Godot 3.2 is shaping up nicely in the late beta stage, it’s time for a long overdue update to the stable 3.1 branch: Godot 3.1.2 is now released with over 400 commits worth of bug fixes and improvements over the previous 3.1.1 version.
Download Godot 3.1.2 now and read on about the changes in this update. Edit: The update is now also available on Steam and itch.io.
Note: Illustration credits at the bottom of this page.
Edit 2019-12-03 @ 15:00 UTC: A regression was found in the WebAssembly (HTML5) export templates, which was fixed this day. The export templates .tpz file now contains the fixed templates, but if you installed Godot 3.1.2 and the templates before this date, you should update the WebAssembly templates manually. See instructions below in the download section. To do so, download this archive containing only the fixed WebAssembly templates, and install them manually from the editor (see details). If you downloaded Godot after the date of this edit, you do not need to do anything. The Steam distribution will also be fixed automatically.
Edit 2019-12-04 @ 10:30 UTC: A follow-up regarding HTML5 templates: if you used the “Custom Html Shell” preset option to use your own loading code, you need to update your HTML template as shown in this commit. This is necessary to support recent Emscripten versions.
Release branches
Before checking the changelog for this release, a short clarification on the release branches that we use for those not familiar with Godot’s versioning.
Our next stable branch, developing the Git master branch, is Godot 3.2. This version is currently in beta and should become stable within a few weeks. Most of the devblogs published since the 3.1 release cover features which have been merged in the master branch and will be included in Godot 3.2.
In parallel, we also work in the vulkan branch on version 4.0 which will come sometime next year with Vulkan support. We increase the “major” version number (3 to 4) as there will be some compatibility breakage.
Our current maintained stable branches are 3.1 (latest release now 3.1.2), 3.0 (latest 3.0.6) and 2.1 (latest 2.1.6). Each of those branches is tracked separately in a Git branch, where we cherry-pick relevant commits from the master branch for future maintenance releases. The new 3.1.2 release is thus a maintenance release for the 3.1 branch, with the same feature set that 3.1 already had, but less bugs and some usability and documentation enhancements.
So if you’re looking for the latest and greatest, check 3.2 beta 2, but if you have game in production using Godot 3.1.1, this update is for you!
Changes
As mentioned, this release includes more than 400 new commits, with many bug fixes, usability enhancements and documentation improvements. You can read the complete changelog for details. Below are a few selected highlights:
Animation: Fixes for onion skinning support of Skeleton2D (GH-29109).
And many more bug fixes and usability enhancements all around the engine!
You can also see the full changelog since 3.1.1-stable on GitHub, split in two parts as the web view is limited to 250 commits: part 1 and part 2.
Known incompatibilities
Below we describe the known incompatibilities with previous releases in this cycle.
Known incompatibilities with Godot 3.1
Due to a security fix the GDNative ABI has changed. If you use GDNative modules in your project they will need to be rebuilt from source.
Godot no longer automatically decodes Objects when using high level multiplayer. If you do want your client or server to do this it is now necessary to explicitly allow it. See this PR for details.
Previously on Android OS.get_unique_id() would return the static value for Secure.ANDROID_ID. This was a bug and now an actually unique ID is returned. If you were using the unique ID for encryption purposes you must now also check the original static value or your users may lose access to any encrypted (save) data.
Known incompatibilities with Godot 3.1.1
CPUParticles2D: The “Lifetime” draw order was reversed. GH-29558 fixes it, but if you relied on the previous wrong order, you would have to work it around.
RigidBody(2D): The can_sleep variable was not properly initialized (regression in 3.1). GH-32767 fixes it, but it might impact your project if you relied on the previous incorrect initialization.
GLES2: Some of the many bug fixes listed above may lead to changes in the visuals of your project (especially around lighting/shadows). Be sure to report anything that you would consider a regression.
macOS: Key mappings for KEY_BRACELEFT and KEY_BRACERIGHT were inverted. GH-28185 fixes this bug, so check your code in case you relied on these values matching the wrong keys.
HTML5: The signature of the startGame() JavaScript function changed, so if you used a “Custom Html Shell” in your export preset, you need to update it as done for official templates in this commit.
If you spot any other difference in your projects, please notify us so that we can list it here (even if it’s a good change/bugfix, it’s worth documenting it so that all users are aware).
The illustration picture is fromFantastic Creatures, a turn-based 4X strategy game set in mythological Ancient China and developed in Godot by Blue Calisto (@FmrPlays). It was released on Steam two weeks ago.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-2-1/index.html b/article/maintenance-release-godot-3-2-1/index.html
index 2a90e4239a..3b5595bd22 100644
--- a/article/maintenance-release-godot-3-2-1/index.html
+++ b/article/maintenance-release-godot-3-2-1/index.html
@@ -6,7 +6,7 @@
The illustration picture is from *Fist of the Forgotten, *a precision combat platformer focusing on fluid movement with gorgeous silhouette-style 3D art, developed by Lone Wulf Studio. Wishlist it on Steam, and follow the development on its website, Twitter, and @jitspoe’s dev streams on Twitch.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-2-2/index.html b/article/maintenance-release-godot-3-2-2/index.html
index d81bc2ae9e..df33478cd8 100644
--- a/article/maintenance-release-godot-3-2-2/index.html
+++ b/article/maintenance-release-godot-3-2-2/index.html
@@ -8,7 +8,7 @@
The illustration picture is from *Oddventure, *a charming pixel-art, lore-rich and turn-based crazy RPG set in a cursed fairytale world, inspired by the Mother series and Undertale, and developed by Infamous Rabbit. Wishlist it on Steam, and follow the development on Twitter! Check the demo on itch.io, and stay tuned for an upcoming Kickstarter by following development on Twitter and @InfamousRibbit.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-2-3/index.html b/article/maintenance-release-godot-3-2-3/index.html
index 61fa2cf813..0f9b6cbc33 100644
--- a/article/maintenance-release-godot-3-2-3/index.html
+++ b/article/maintenance-release-godot-3-2-3/index.html
@@ -7,7 +7,7 @@
The illustration picture is fromHuman Diaspora, a gorgeous sci-fi First Person Shooter developed by Leocesar3D. It was just released as Early Access on Steam, and you can follow its development news on Twitter.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-3-1/index.html b/article/maintenance-release-godot-3-3-1/index.html
index 64d637edbc..6647a54288 100644
--- a/article/maintenance-release-godot-3-3-1/index.html
+++ b/article/maintenance-release-godot-3-3-1/index.html
@@ -7,7 +7,7 @@
* Note that the denoiser is still not available on this architecture.
Lightmapper: Fixes to environment energy (GH-48089).
Linux: Fix 32-bit builds’ compatibility with older libstdc++. The builds should be compatibile with Ubuntu 16.04 LTS and any other distribution published since 2016.
Linux: Handle having no sinks in the PulseAudio driver (GH-48706).
LSP: Update the filesystem for changed scripts, fixes issues with new named classes (GH-47891).
macOS: Update Info.plist to clarify that the minimum required version is now macOS 10.12 (due to use of C++14 features).
Networking: Fix socket poll timeout on Windows (GH-48203).
Physics: Create CollisionObject debug shapes using VisualServer (GH-48588).
SkeletonIK: Fix root bones being twisted incorrectly when rotated (GH-48251).
Rendering: Fix usage of proxy textures on GLES2 PanoramaSky (GH-48541).
Rendering: Fix refraction offset by manually unpacking normal mappings (GH-48478).
Rendering: Disable GIProbe emission when disabled on a material (GH-48798).
WebXR: Fix incompatibility with Emscripten 2.0.13+ which made WebXR error out in 3.3-stable (GH-48268).
VisualScript: Fix wrongly setting default value on property hint change (GH-48702).
API documentation updates.
Translation updates.
Known incompatibilities
As of now, there are no known incompatibilities with the previous Godot 3.3 release. We encourage all users to upgrade to 3.3.1.
If you experience any unexpected behavior change in your projects after upgrading from 3.3 to 3.3.1, please file an issue on GitHub.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-3-2/index.html b/article/maintenance-release-godot-3-3-2/index.html
index 5d23930b1b..bdc27ad6fe 100644
--- a/article/maintenance-release-godot-3-3-2/index.html
+++ b/article/maintenance-release-godot-3-3-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde24 May 2021
Notably, Windows users could experience crashes when baking lightmaps. Games exported with a ZIP data package could also trigger a crash on exit. Additionally, this release includes a number of non-regression bug fixes to various areas of the engine.
Godot 3.3.2, like all future 3.3.x releases, focuses purely on bug fixes, and aims to preserve compatibility. It is a recommended upgrade for all Godot 3.3 users.
As of now, there are no known incompatibilities with the previous Godot 3.3 and 3.3.1 releases. We encourage all users to upgrade to 3.3.2.
If you experience any unexpected behavior change in your projects after upgrading to 3.3.2, please file an issue on GitHub.
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 thank you 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.
The illustration picture is a screenshot of Emilio Coppola’s *Dialogic Godot plugin, which enables you to create, organize, and display dialogue scenes in your Godot games. You’ll find the plugin on GitHub and itch.io, and you can follow Emilio on Twitter and Patreon.*
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-3-3/index.html b/article/maintenance-release-godot-3-3-3/index.html
index 95dc69fbfd..ec0a9df6ba 100644
--- a/article/maintenance-release-godot-3-3-3/index.html
+++ b/article/maintenance-release-godot-3-3-3/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde19 August 2021
While we’re busy working on both the upcoming Godot 4.0 and 3.4 releases (with a dev snapshot for 3.4 beta 4 available now), we still cherry-pick important bug fixes to the 3.3 branch regularly for maintenance releases (see our release policy).
Since the release of Godot 3.3.2 in May, there have been a number of bug fixes which are worth including in a new stable release for all Godot users.
Additionally, this release fulfills a new Google Play requirement for Android to target the API level 30 (Android 11). This includes partial support for Android scoped storage, which will be expanded in future releases.
Godot 3.3.3, like all future 3.3.x releases, focuses purely on bug fixes, and aims to preserve compatibility. It is a recommended upgrade for all Godot 3.3 users.
macOS: Fix custom mouse cursor not set after mouse mode change (GH-49848).
macOS: Fix Xbox controllers in Bluetooth mode on macOS (GH-51117).
Networking: Fix parsing some IPv6 URLs for WebSocket (GH-48205).
Networking: WebsocketPeer outbound buffer fixes and buffer size query (GH-51037).
Networking: Fix IP address resolution incorrectly locking the main thread (GH-51212).
PathFollow: Fix forward calculation for the position at the end of the curve (GH-50986).
Physics: Avoid NaNs when calculating inertias for bodies without mass/area (GH-49185).
Physics: Ignore disabled shapes for mass property calculations (GH-49699).
Porting: Fix Directory::get_space_left() result on macOS and Linux (GH-49222).
Rendering: VisualServer now sorts based on AABB position (GH-43506).
Rendering: Fixes depth sorting of meshes with transparent textures (GH-50721).
Rendering: Fix CanvasItem bounding rect calculation in some cases (GH-49160).
Rendering: Fix flipped binormal in SpatialMaterial triplanar mapping (GH-49950).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Windows: Fix platform file access to allow file sharing with external programs (GH-51430).
Windows: Fix code signing with osslsigncode from Linux/macOS (GH-49985).
Thirdparty library updates: mbedtls 2.16.11, CA root certifactes.
Translation updates.
API documentation updates.
Known incompatibilities
Update: One regression has been found which could cause crashes when using the GDScript LSP in Visual Studio Code. This bug has been fixed in Godot 3.3.4, which is a recommended update for all users.
If you experience any unexpected behavior change in your projects after upgrading to 3.3.3, please file an issue on GitHub.
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 current and future hires, you can do so on Patreon or PayPal.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-3-4/index.html b/article/maintenance-release-godot-3-3-4/index.html
index 8047d1ed06..d5c76f962e 100644
--- a/article/maintenance-release-godot-3-3-4/index.html
+++ b/article/maintenance-release-godot-3-3-4/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde1 October 2021
While we’re busy working on both the upcoming Godot 4.0 and 3.4 releases (with a dev snapshot for 3.4 beta 5 available now), we still cherry-pick important bug fixes to the 3.3 branch regularly for maintenance releases (see our release policy).
Godot 3.3.3 was released a month ago, and a handful of important fixes have been queued in the 3.3 branch since then. Most notably, users of the GDScript LSP in Visual Studio Code have been experiencing crashes in 3.3.3, which are fixed in this new Godot 3.3.4.
Note: Version numbers can be confusing with three branches worked on in parallel - this release is 3.3.4, i.e. a maintenance update to the 3.3 branch. This is not the upcoming 3.4 feature release.
Godot 3.3.4, like all future 3.3.x releases, focuses purely on bug fixes, and aims to preserve compatibility. It is a recommended upgrade for all Godot 3.3 users.
GUI: Remove deprecation warning for BaseButton.enabled_focus_mode (GH-51993).
GUI: LinkButton’s text is now automatically translated (GH-52138).
GUI: TabContainer: Fix drawing current tab when it’s disabled (GH-52299).
HTML5: Fix bug in AudioWorklet when reading output buffer (GH-52696).
HTML5: Use browser mix rate by default on the Web (GH-52723).
iOS: Implement missing OS set/get_clipboard() methods (GH-52540).
LSP: Fix completion crashing on scene-less scripts (GH-51333).
Rendering: Prevent shaders from generating code before the constructor finishes (GH-52475).
VisualScript: Fix VisualScriptPropertySet value hint (GH-52219).
API documentation updates.
Known incompatibilities
As of now, there are no known incompatibilities with the previous Godot 3.3.x releases. We encourage all users to upgrade to 3.3.4.
If you experience any unexpected behavior change in your projects after upgrading to 3.3.4, please file an issue on GitHub.
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 current and future hires, you can do so on Patreon or PayPal.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-4-1/index.html b/article/maintenance-release-godot-3-4-1/index.html
index 0621e92056..ebd5821df9 100644
--- a/article/maintenance-release-godot-3-4-1/index.html
+++ b/article/maintenance-release-godot-3-4-1/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde17 December 2021
Godot 3.4 was released a month ago, and it went fairly smoothly! Many thanks to all the contributors who worked on it, including all testers who tried beta and RC releases to ensure that the 3.4-stable branch would be an easy and worthwhile upgrade path for all users.
No software release is perfect though, so there will always be some things to iron out, which is why we provide maintenance releases for stable branches, focusing on bugfixing and preserving compatibility (see our release policy). Godot 3.4.1 is the first maintenance release in the 3.4 stable branch, and a recommended upgrade for all Godot 3.4 users.
Tiles: Only add light occlusion for visible TileMaps (GH-54435).
Tiles: Fix selecting next/previous subtile in TileSet editor (GH-55261).
Viewport: Show tooltips even when paused or time_scale is 0 (GH-55224).
Windows: Open a new console window for the editor instances on Windows 11 (GH-55925, GH-55967).
This is needed to workaround a design change in Windows 11’s new Windows Terminal, which broke Godot (GH-54076).
XR: Add support for OpenXR export configurations (GH-55158).
Thirdparty library updates: libogg 1.3.5, libvorbis 1.3.7, minimp3 from 2021-11-30, CA certificates from 2021-11-01.
API documentation and translation updates.
Known incompatibilities
Edit 2021-12-22: One regression has been found which causes flickering on macOS (affects both using the editor on macOS, and games exported to macOS). All users are advised to upgrade to Godot 3.4.2 which fixes that issue.
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 current and future hires, you can do so on Patreon or PayPal.
The illustration picture is fromNeJ, an upcoming poetic and mysterious hand-drawn adventure game developed by Ben Lega. You can wishlist it on Steam and follow development on Twitter.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-4-2/index.html b/article/maintenance-release-godot-3-4-2/index.html
index c70398dd3e..15384ce248 100644
--- a/article/maintenance-release-godot-3-4-2/index.html
+++ b/article/maintenance-release-godot-3-4-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde22 December 2021
We released Godot 3.4.1 just a few days ago with a huge array of bugfixes, but a regression was then found for macOS rendering which could cause flickering.
This new Godot 3.4.2 is a hotfix release to solve this and a few other minor issues that were fixed in the meantime. Godot 3.4.2 is a recommended upgrade for all Godot 3.4 and 3.4.1 users.
For a detailed overview of the changes that 3.4.1 included and which are also part of this new release, please read the 3.4.1 release notes.
Rendering: GLES2: Fix trunc shader function compilation on Android (GH-56061).
XR: Fix size issue for ARVR managed viewport (GH-56072).
Thirdparty library updates: mbedtls 2.16.12.
API documentation and translation updates.
Known incompatibilities
As of now, there are no known incompatibilities with the previous Godot 3.4.x releases. We encourage all users to upgrade to 3.4.2.
If you experience any unexpected behavior change in your projects after upgrading to 3.4.2, please file an issue on GitHub.
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 current and future hires, you can do so on Patreon or PayPal.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-4-3/index.html b/article/maintenance-release-godot-3-4-3/index.html
index 8f72128472..8c9ecdc751 100644
--- a/article/maintenance-release-godot-3-4-3/index.html
+++ b/article/maintenance-release-godot-3-4-3/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde25 February 2022
In parallel to our work on the upcoming feature releases Godot 3.5 (with a first beta) and 4.0 (now at alpha 3!), we backport important fixes to the stable 3.4 branch for use in production.
A number of such fixes have been queued in the two months since the 3.4.2 release, and we after a couple of Release Candidates (thanks to all testers!), we’re now ready to release Godot 3.4.3-stable as a maintenance update to the current stable branch.
If you experience any unexpected behavior change in your projects after upgrading to 3.4.3, please file an issue on GitHub.
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.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-4-4/index.html b/article/maintenance-release-godot-3-4-4/index.html
index 8e94989703..c9bfd754ff 100644
--- a/article/maintenance-release-godot-3-4-4/index.html
+++ b/article/maintenance-release-godot-3-4-4/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde23 March 2022
In parallel to our work on the upcoming feature releases Godot 3.5 (with a second beta) and 4.0 (now at alpha 4!), we backport important fixes to the stable 3.4 branch for use in production.
Last month’s 3.4.3 release was found to have a few regressions that could affect a lot of users, so we’ve been working on a bugfix-only release to solve those issues and a few other pre-existing issues. All users are advised to upgrade to Godot 3.4.4 for the best possible experience.
Note: The Windows editor binaries are signed with an expired certificate. We will re-sign them as soon as a new certificate is available.
Edit 2022-03-24 @ 12:15 UTC: There was a slight packaging mistake affecting the macOS editor, and the iOS and macOS export templates, as well as a build issue affecting the iOS debug template. These binaries have been updated on the mirror, users who downloaded Godot 3.4.4 before this edit are advised to re-download at least the export templates if they intend to export to iOS.
Core: Revert “Fix ProjectSettings has_setting() when used on a overriden setting with feature tags” (GH-58859).
Core: Fix crash on Input.get_joy_button_index_from_string and Input.get_joy_axis_index_from_string for non-existing key (GH-59195).
CSG: Fix visible seam on smoothed sphere, cylinder, and torus shapes (GH-58208, GH-59002).
CSG: Fix mixed smoothed and non-smoothed face normals computation for CSG shapes (GH-59039).
Editor: Fix showing Extend Script option without script attached to the node (GH-58821).
HTML5: Revert “[HTML5] Fetch API now passes credentials.” (GH-58862) [regression fix].
This turned out not to be a good option with the current state of the web standard.
iOS: Fix multitouch not working correctly (GH-58586) [regression fix].
Physics: Fix premature return in GodotPhysics Area call_queries (GH-58531).
Physics: Update joints on NOTIFICATION_POST_ENTER_TREE (GH-58642).
Portals: Fix duplication of instanced scenes during conversion (GH-58650).
Rendering: GLES2: Fix compression on blend shapes (GH-58838).
Rendering: GLES2: Fix VersionKey comparison in shader binding (GH-58855).
Rendering: GLES2: Fix incorrect buffer upload size in draw_gui_primitive (GH-58150).
Rendering: GLES3: Fix shader state caching when blend shapes used (GH-58808) [regression fix].
Rendering: GLES3: Fix broken normals in meshes with blend shapes (GH-59159) [regression fix].
Rendering: Fix alpha scissor support with depth_draw_opaque (GH-58959).
RichTextLabel: Fix shadow color when text has transparency (GH-59054).
Windows: Fix reporting of DST in OS.get_datetime() (GH-59223).
API documentation updates.
Known incompatibilities
As of now, there are no known incompatibilities with the previous Godot 3.4.x releases. We encourage all users to upgrade to 3.4.4.
If you experience any unexpected behavior change in your projects after upgrading to 3.4.4, please file an issue on GitHub.
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.
The illustration picture is fromBeat Invaders, a gorgeous blend of space shooter and roguelite with an epic soundtrack, developed by Raffaele Picca. It was just released on Steam and it’s a ton of fun, check it out!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-4-5/index.html b/article/maintenance-release-godot-3-4-5/index.html
index fe8945e873..9e627b5fc5 100644
--- a/article/maintenance-release-godot-3-4-5/index.html
+++ b/article/maintenance-release-godot-3-4-5/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde2 August 2022
It’s been a while since our last stable release! And this is not the long anticipated 3.5, nor 4.0, but simply a Godot 3.4.5 maintenance release to fix a handful of issues in the current 3.4 stable branch.
This is a safe and recommended update for all Godot 3.4.x users. It should have no major incidence on your projects, even complex ones in production, if you’re already using 3.4.4-stable.
Notable changes that motivate this release include:
Increase Android target API level to 31 to match Google Play requirements for new apps as of August 2022.
Update mbedtls and zlib libraries to fix security vulnerabilities.
Ignore support of S3TC compression format on mobile devices to ensure the use of ETC2 for GLES3 (fixes issues with Meta Quest 2 after a recent system update).
When upgrading to 3.4.5 for projects using Android custom builds, you have to manually set the “Target Sdk” option to 31 in your export preset. For new presets, this is the new default value.
Android: Fix crash when trying to paste non-text data from clipboard (GH-60563).
Animation: Fix looping issue in AnimationNodeStateMachinePlayback with “At End” switch mode (GH-60247).
Audio: Instance audio streams before AudioServer::lock() call (GH-59413).
Audio: Fix crash in AudioServer when switching audio devices with different audio channels count (GH-59778).
Buildsystem: Fix creating VS solutions with SCons 4.4.0 (GH-63722).
C#: Avoid modifying csproj globbing includes on remove (GH-59521).
C#: Fix Transform.Translated method affecting the original transform (GH-63685).
Core: Fix left aligned integer sign in string formatting (GH-60679).
Editor: Fix popup dialog UI in AnimationTreePlayer editor (GH-60200).
Editor: Fix EditorProperty icon overlapping text with checkbox (GH-58125).
Editor: Fix custom class icon when it inherits from a script (GH-60536).
Editor: Fix UndoRedo in Gradient editor (GH-60401).
Editor: Fix crash when editing pinned StyleBox (GH-61071).
Editor: Fix GridMap cursor showing the wrong mesh (GH-58624).
Editor: Fix incorrect encoding used in error handling functions (GH-61277).
Editor: Fix crash when drag-reordering array elements in the inspector (GH-61282).
Editor: Fix scene tree dock focus after using “Add Child Node” button (GH-61964).
GDScript: Fix editor undo history for function name autocompletion (GH-60231).
GDScript: Fix autocompletetion showing class names with an underscore (GH-62731).
GUI: FileDialog: Fix support for changing directory in user:// and res:// modes (GH-59838).
GUI: GraphEdit: Fix toggling minimap using the minimap_enabled property (GH-57239).
GUI: GraphEdit: Fix valid connections types being reversed (GH-60124).
GUI: Label: Fixed leading spaces pushing text outside autowrap boundary (GH-60233).
GUI: LineEdit: Fix clear button position for asymmetric StyleBox (GH-61496).
GUI: RichTextLabel: Fix implementation of remove_line() (GH-60618).
Linux: Properly check for fullscreen toggle made through the Window Manager (GH-62543).
Physics: Skip compound shapes without child shapes in SpaceBullet::recover_from_penetration() (GH-59864).
Rendering: GLES2: Unpack blend shape arrays when necessary (GH-60829).
Rendering: GLES3: Unbind vertex buffer before calculating blend shapes (GH-60832).
Rendering: GLES3: Ignore support for S3TC texture compression on Android and iOS devices (GH-62909).
Few devices support this compression while they all support ETC2. Godot exports ETC2 by default and doesn’t take into account that mobile devices could need S3TC.
Rendering: Portals: Force full check on adding moving object (GH-61523).
UWP: Fix GDNative DLLs not being included on export (GH-61262).
Thirdparty libraries: zlib/minizip 1.2.12, mbedTLS 2.28.1, CA certificates from 2022-03-31, SDL GameControllerDB from 2022-07-15.
API documentation updates.
Known incompatibilities
As of now, there are no known incompatibilities with the previous Godot 3.4.x releases. We encourage all users to upgrade to 3.4.5.
If you experience any unexpected behavior change in your projects after upgrading to 3.4.5, please file an issue on GitHub.
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.
The illustration picture is fromBLASTRONAUT, a gorgeous exploration and mining game set in a vast procedurally generated alien world, developed by Perfoon. It was just released on Steam as Early Access and it’s an absolute blast, check it out!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-5-1/index.html b/article/maintenance-release-godot-3-5-1/index.html
index db6bc1a3d0..a423347872 100644
--- a/article/maintenance-release-godot-3-5-1/index.html
+++ b/article/maintenance-release-godot-3-5-1/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde28 September 2022
We released Godot 3.5 in early August, and like any release, there are few rough edges to iron out which warrant making maintenance “patch” releases (3.5.x). Such maintenance releases focus on fixing bugs and not on integrating new features. This helps guarantee that the overall production readiness of the stable branch keeps increasing.
So this 3.5.1 release fixes a number of regressions that users reported after the release, as well as various other fixes to pre-existing bugs and usability improvements.
This is a safe and recommended update for all Godot 3.5.x users. It should have no major incidence on your projects, even complex ones in production, if you’re already using 3.5-stable.
Thirdparty libraries: libpng 1.6.38, GameControllerDB from 2022-09-18.
API documentation updates.
Known incompatibilities
As of now, there are no known incompatibilities with the previous Godot 3.5.x releases. We encourage all users to upgrade to 3.5.1.
If you experience any unexpected behavior change in your projects after upgrading to 3.5.1, please file an issue on GitHub.
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.
The illustration picture is fromDome Keeper, an innovative roguelike survival miner with gorgeous artwork, developed by Bippinbits and published by Raw Fury. It was just released on Steam and the first players seem to love it, check it out!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-5-2/index.html b/article/maintenance-release-godot-3-5-2/index.html
index fdb14dfcf5..2c9b621ba2 100644
--- a/article/maintenance-release-godot-3-5-2/index.html
+++ b/article/maintenance-release-godot-3-5-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde8 March 2023
We’ve just released Godot 4.0 after 3+ years of intense development! This is the start of the Godot 4 journey, and there is still need for a few iterations for the 4.x branch to be as stable and reliable as the existing 3.5 branch.
As such, it’s natural that existing Godot 3.5 users would prefer to stay on that version for a while, and we’re determined to provide them with bugfix releases. This 3.5.2 maintenance release fixes a handful of issues which have been solved in the past few months in parallel to Godot 4.0 development, and could be backported to the 3.5 branch. Nothing fancy, but a welcome upgrade from 3.5.1.
This is a safe and recommended update for all Godot 3.5.x users. It should have no major impact on your projects, even complex ones in production, if you’re already using 3.5.1-stable.
The illustration picture is fromLumencraft, a top-down, roguelike shooter with base building and tower defense elements. It is developed by 2Dynamic Games, and recently published its full 1.0 public release with a single-player Story mode, and a lot of gameplay improvements. You can find the game on Steam, Epic Games Store, GOG, and the Mac App Store.
UWP: Fix app crash when updating clipboard (GH-73126).
UWP: Fix build with Google ANGLE not supporting EGL_ANGLE_DISPLAY_ALLOW_RENDER_TO_BACK_BUFFER (GH-73127).
Windows: Fix handling of some dead key combinations using Unicode char instead of Virtual key (GH-66314).
Windows: Fix Alt Gr getting stuck after Right Alt-Tab (GH-71730).
Windows: Fix Xbox Series controller detected as 2 devices (GH-71784).
Thirdparty libraries: libpng 1.6.39, libwebp 1.2.4, mbedtls 2.28.2, miniupnpc 2.2.4, nanosvg from 2022-11-21, recast from 2022-11-26, stb_vorbis 1.22, zlib/minizip 1.2.13, CA root certificates from 2022-10-21, GameControllerDB from 2023-02-27.
API documentation updates.
Known incompatibilities
As of now, there are no known incompatibilities with the previous Godot 3.5.x releases. We encourage all users to upgrade to 3.5.2.
If you experience any unexpected behavior change in your projects after upgrading to 3.5.2, please file an issue on GitHub.
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 thank you 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 via PayPal or Patreon.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-3-5-3/index.html b/article/maintenance-release-godot-3-5-3/index.html
index ef2f5f4f72..9908ad8710 100644
--- a/article/maintenance-release-godot-3-5-3/index.html
+++ b/article/maintenance-release-godot-3-5-3/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde25 September 2023
Long time no see, Godot 3.5! While our development focus since Godot 4.0 in March has been to release new 4.x versions at a steady pace (with Godot 4.1 in July, and Godot 4.2 scheduled for November), we’re not forgetting about users who are still using Godot 3.5.
Everyone seemed pretty happy with the 3.5.2 release. In the 6 months since the 3.5.2 release, hundreds of games have been released with this version. But there are still a number of issues that are worth addressing in that branch, including notably some improvements for platform support such as targeting Android 13 by default. Also, we’re still working on the upcoming Godot 3.6 feature release, which should soon reach the release candidate stage.
This is a safe and recommended update for all Godot 3.5.x users. It should have no major impact on your projects, even complex ones in production, if you’re already using 3.5.2-stable.
The illustration picture is fromHauma, a deduction visual novel with a noir story set in Munich. It was developed in Godot 3.5 by SenAm Games and published by Assemble Entertainment. It was released on Steam a couple of weeks ago, so you can play it right now and enjoy this deep story with a gorgeous comic-inspired art direction.
Changes
See the curated changelog for a selection of some of the main changes since Godot 3.5.2. We now also have a great interactive changelog you can use to review the changes since the previous release, with convenient links to the relevant PRs on GitHub.
Here are the main changes since 3.5.2-stable:
2D: TileSet: Fix resizing collision shape when vertex is outside the tilesheet (GH-73218).
2D: Notify child controls when BackBufferCopy’s rect changed (GH-74282).
2D: Fix AnimatedSprite normal map loading (GH-80406).
2D: Fix TouchScreenButton not redrawn when texture changes (GH-81100).
Rendering: Fix shadows when using 2 directional lights (GH-74539).
Thirdparty: libwebp 1.3.2, mbedtls 2.28.4, tinyexr 1.0.7, CA certificates from June 2023, SDL GameControllerDB from 2023-09-23.
API documentation updates.
Known incompatibilities
As of now, there are no known incompatibilities with the previous Godot 3.5.x releases. We encourage all users to upgrade to 3.5.3.
If you experience any unexpected behavior change in your projects after upgrading to 3.5.3, please file an issue on GitHub.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-302/index.html b/article/maintenance-release-godot-302/index.html
index 7682f0dfe0..0b30a2af36 100644
--- a/article/maintenance-release-godot-302/index.html
+++ b/article/maintenance-release-godot-302/index.html
@@ -5,7 +5,7 @@
HP van Braam4 March 2018
This is a fairly small release but still something to be excited about! We found some small issues with the 3.0.1 release that we’ve decided were worth releasing a 3.0.2 for, the most important fix being that it’s now again possible to run an individual scene of a project that does not have a main scene set. Rémi also found the reason why tooltips were disappearing for some users, a bug that we’ve had for a long time.
We also have some love for C# users in this release: There was a regression using transforms from C#, and the commits that caused them have been reverted. Godot will now also no longer crash if you have a .mono directory created by an older release. This should make the C# workflow a lot better from now on.
As usual you can go directly to our Download page to download the new release. Both the itch.io and Steam distributions have been updated.
Our release schedule for the stable releases are somewhat dictated by the severity of issues we find and fix. However, we don’t plan to do weekly releases as a rule. Unless another important problem or regression is found, we expect to release 3.0.3 some time near the end of March.
I’d also like to thank all of our wonderful and outrageously attractive contributors for their work on 3.0.2!
What’s new in this release
Here are some of the highlights of this release. See the full changelog for details.
Mono: We now display stack traces for inner exceptions.
Mono: Bundle mscorlib.dll with Godot to improve portability.
Fixed issues
Here are some of the highlights of this release. See the full changelog for details.
Running a scene from a project with a main scene now works again (regression in 3.0.1).
Correct line spacing in RichTextLabel (regression in 3.0.1).
TextureProgress now correctly displays when progress > 62 (regression in 3.0.1).
The editor no longer complains about using an enum from an autoloaded resource (regression in 3.0.1).
Pressing Escape no longer closes unexpected subwindows (regression in 3.0.1).
Fix spelling of apply_torque_impulse() and deprecate the misspelled method.
Gizmos are now properly hidden on scene load if the object they control is hidden.
Remove spurious errors when using a PanoramaSky without textures.
Show tooltips in the editor when physics object picking is disabled.
Fix a serialization bug that could cause tscn files to grow very large.
Do not show the project manager unless no project was found at all.
The animation editor time offset indicator no longer ‘walks’ when resizing the editor.
Allow creation of an in-tscn file GDScript function even if the filename suggested already exists.
Mono: Godot no longer crashes when opening a project created with an older release.
Mono: Fix builds of tools=no builds.
Mono: Fix transformation regression since 3.0.1
Android: We now require GLESv3 support in the manifest.
Android: Fix intermittent audio driver crash.
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.2
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.
The illustration picture is courtesy of Carter Anderson (@cart_cart), who is making a game called ‘High Hat’ using Godot.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-0-1/index.html b/article/maintenance-release-godot-4-0-1/index.html
index 7bbc9c71fc..23e6c4241b 100644
--- a/article/maintenance-release-godot-4-0-1/index.html
+++ b/article/maintenance-release-godot-4-0-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov20 March 2023
Just three weeks ago we published Godot 4.0, the biggest body of work Godot contributors have managed to produce in the engine’s entire history. A backlog of bugs and enhancements comes with that territory, and we’ve been working hard and fast on the most critical fixes during that time. On some smaller and easy-to-implement enhancements too!
The result of this work is Godot 4.0.1, the first patch release for Godot 4, available now! This version addresses several conditions for crashes and freezes, improves the project converter, and updates the engine documentation and translations. All these improvements will also be available in the future 4.1 release later this year. And as Godot contributors continue their work on Godot 4.1, some more fixes and improvements will trickle down to future 4.0.x releases.
One notable change in Godot 4.0.1 that is worth a dedicated mention is related to the project manager. We have received several reports of users accidentally creating a new Godot project in their user directory, which has led to unfortunate issues. The most critical of these issues is an accidental deletion of the entire user directory when deleting a project from the project manager. We will be revising the UI and UX of the related features, but to offer an immediate solution, we have removed the ability to create projects in a non-empty folder (and in home/documents folders specifically). We have also disabled the ability to delete project files alongside the removal of the project from the project list.
The illustration picture is from a new, fairytale-like demo scene created by Raffaele Picca with Godot 4.0 —Lost Desert Temple. Raffaele plans to release it as an open source project, so follow him on Twitter to make sure you don’t miss that. And if you’re visiting GDC this week, come by the Godot booth! You can find Raffaele there and chat about his use of the engine, as well as play a session ofBeat Invaders!
As of now, there are no known incompatibilities with Godot 4.0. We encourage all users to upgrade to 4.0.1.
If you experience any unexpected behavior change in your projects after upgrading to 4.0.1, please file an issue on GitHub.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-0-2/index.html b/article/maintenance-release-godot-4-0-2/index.html
index 542d8ab018..bf998dc5c6 100644
--- a/article/maintenance-release-godot-4-0-2/index.html
+++ b/article/maintenance-release-godot-4-0-2/index.html
@@ -6,7 +6,7 @@
Yuri Sizov4 April 2023
The development of Godot 4.1 is starting to pick up steam — after a long, productive, but also exhausting month of March. Godot has received a lot of attention and love during the GDC and the meetup at GitHub, and it’s time to put all that feedback to good use. We will soon resume our regular preview releases that you have learned to enjoy during the later stages of the Godot 4.0 development.
In the meantime, Godot contributors have spent this month working on fixes and improvements for existing 4.0 users to enjoy and benefit from. Two weeks ago we have released 4.0.1, and it’s time for the second patch release of the bunch — 4.0.2! Our focus is still on the more critical issues and smaller usability improvements that are safe to publish right now. 4.0.1 has also introduced a couple of unfortunate issues for macOS and Windows users, which are now addressed as well.
In this release we also aim to improve the experience of Android developers. This includes bumping the target Android SDK version to 33. If you are using third-party libraries and plugins with your projects, this may enable some configuration options and checks in them, which were ignored in previous versions.
The illustration picture for this release showcasesProtonGraph— an experimental node-based tool for procedural content generation, made by HungryProton. Originally created in Godot 3, it is now powered by Godot 4.0, utilizing the brand-new multiwindow support! Follow HungryProton on social, where they share progress reports and more experiments, such as Counter-Strike-2-like volumetric smoke effect.
XR: Enable access to the Valve Index grip force sensors (GH-74787).
XR: Check hardware sRGB conversion when an sRGB target is used (GH-74892).
XR: Fix typo in OpenXR pose orientation check (GH-74928).
Thirdparty: Update mymindstorm/setup-emsdk to v12 (GH-75339).
API documentation updates.
Known incompatibilities
As of now, there are no known incompatibilities with previous Godot 4.0.x releases. We encourage all users to upgrade to 4.0.2.
If you experience any unexpected behavior change in your projects after upgrading to 4.0.2, please file an issue on GitHub.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-0-3/index.html b/article/maintenance-release-godot-4-0-3/index.html
index 06d2ad9c96..be5f682a01 100644
--- a/article/maintenance-release-godot-4-0-3/index.html
+++ b/article/maintenance-release-godot-4-0-3/index.html
@@ -6,7 +6,7 @@
Yuri Sizov19 May 2023
With the Godot 4.1 release on the horizon, contributors have been hard at work on major and exciting improvements to the engine. But we appreciate that many of you would like to have your experience a little less exciting and a bit more stable when using Godot 4 in production. To that end, we try to backport as many useful fixes as we can to improve your workflows, and the new Godot 4.0.3 release is the result of these efforts.
Almost every area was touched upon with bugfixes and stability improvements. This includes multiple crashes and glitches eliminated in constructive solid geometry (CSG), GDScript language server, importing of assets, and all things related to rendering and visuals. Several reported platform-specific crashes and freezes were addressed, especially on Android and Windows. And of course there were improvements to the overall user experience and documentation. The latter received a massive bump in completeness thanks to a serious effort from Calinou, who updated a lot of descriptions in the rendering API.
The illustration picture for this release comes from theGodot Juicecourse by MrEliptik. It’s a great primer on adding juicy visual effects to your Godot 4 projects from the creator of Dashpong, and you can be sure it’s based on practical experience! It’s available on itch.io and Udemy.
Changes
94 contributors made 234 pull-requests (or 244 commits) as a part of this release. See the curated changelog for a list of most notable differences, or browse our interactive changelog for a complete list of changes with links to relevant PRs and commits.
Here are the main changes since 4.0.2-stable:
2D: Fix RemoteTransform2D could fail to update AnimatableBody2D’s position or rotation (GH-75487).
Import: Expose more compression formats in Image and fix compress check (GH-76014).
Import: Fix animation silhouette using incorrect index (GH-76499).
Import: Use DXT1 when compressing PNGs with RGB format (GH-76516).
Input: Fix guide button detection with XInput and Xbox Series controllers (GH-73200).
Input: Fix the issue preventing dragging in the 2D editor (GH-75113).
Input: Fix keycode/physical keycode mix up on web (GH-75738).
Navigation: Expose NavigationAgent path postprocessing and pathfinding algorithm options (GH-75326).
Navigation: Fix NavigationObstacles not being added to avoidance simulation (GH-75756).
Navigation: Fix NavigationMesh baking for HeightMapShape (GH-76212).
Particles: Properly calculate lifetime_split for particles (GH-73313).
Particles: Translate inactive GPUParticles3D particles to -INF (GH-75162).
Particles: Fix “error X3708: continue cannot be used in a switch” in HTML export (GH-75795).
Particles: Use angle_rand to calculate base_angle in particles process material (GH-75999).
Physics: Warn when a concave polygon is assigned to ConvexPolygonShape2D (GH-56671).
Physics: Fix typo bug in convex-convex separating axis test (GH-75835).
Porting: Android: Allow concurrent buffering and dispatch of input events (GH-76399).
This change should fix reports of ANRs (Application Not Responding) that some users have experienced with Godot 4.0. Please test it thoroughly to make sure that it solves your issues without regression.
Porting: Android: Fix double tap & drag on Android (GH-76791).
Porting: Android: Downgrade Android gradle plugin to version 7.2.1 (GH-76325).
Porting: Android: Fix issue with resizing the display when using the compatibility renderer (GH-76464).
Porting: iOS: Fix loading of GDExtension dylibs auto converted to framework (GH-76510).
Porting: Linux: Ensure WindowData minimized/maximized are mutually exclusive (GH-76868).
Porting: Linux: Don’t use udev for joypad hotloading when running in a sandbox (GH-76961).
Porting: Windows: Fix clipboard relying on focused window (GH-73878).
Porting: Windows: Cleanup COM library initialization/uninitialization (GH-75881).
This change may fix some of the crashes that happen on project startup. If you were affected before, please give it a try.
Rendering: Fix GLES3 rendering on Android studio emulator (GH-74945).
Rendering: Fix interpolation of R0 for metallic and calculation of the Fresnel Shlick term in SSR (GH-75368).
Rendering: Use MODELVIEW_MATRIX when on double precision (GH-75462).
Rendering: Ensure that depth write state is updated before transparent pass in OpenGL3 renderer (GH-75968).
Rendering: Fix issues with Vulkan layout transitions (GH-76315).
Rendering: Fix breakages of volumetric fog on Voxel GI changes (GH-76437).
Rendering: Use proper UV in cubemap downsampler raster (GH-76692).
This fixes reflections when using the mobile renderer.
Shaders: Fix crashes caused due to missing type specifier in visual shader editor (GH-75809).
Shaders: Fix rotation issue with NODE_POSITION_VIEW shader built-in (GH-76109).
Shaders: Fix Shader Preprocessor line numbering when disabled (GH-76479).
Thirdparty library updates: astcenc 4.4.0, doctest 2.4.11, mbedtls 2.28.3, thorvg 0.9.0, CA certificates from March 2023.
As well as many improvements to the documentation.
Some changes previously available in 4.0.3 release candidates have been reverted.
Editor: Improve the UX of ViewportTexture in the editor (GH-64388).
This change introduced some new issues, so we rolled it back with the intent to make it available in a future 4.0.x release once it has been better tested and polished.
Editor: Make EditorToaster’s handler thread-safe (GH-71670).
This change requires further fixes which are not safe for a patch release, so we rolled it back and intend for this to only be available in Godot 4.1.
Known incompatibilities
As of now, there are no known incompatibilities with previous Godot 4.0.x releases. We encourage all users to upgrade to 4.0.3.
If you experience any unexpected behavior change in your projects after upgrading to 4.0.3, please file an issue on GitHub.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-0-4/index.html b/article/maintenance-release-godot-4-0-4/index.html
index 771437bb0d..509c5efc5c 100644
--- a/article/maintenance-release-godot-4-0-4/index.html
+++ b/article/maintenance-release-godot-4-0-4/index.html
@@ -6,7 +6,7 @@
Yuri Sizov3 August 2023
It has been a busy few months since the release of Godot 4.0.3, the previous stable version of the 4.0 branch. And while some of the developers took the opportunity to migrate their projects to the latest release of Godot 4.1.1 or even to try our experimental builds of Godot 4.2, many others chose to pin the version and stick to it for the sake of stability.
And so it’s our goal to improve said stability as long as we can manage it. Godot 4.0.4 contains a multitude of changes — addressing reported issues, performance problems and some frictions in the usability department. It also adds some of the missing documentation, and corrects a few mistakes in existing descriptions.
One important change in this release is a security fix for a potential denial of service when using ENet. If your project uses ENetMultiplayerPeer or the low-level ENetConnection, then we strongly recommend updating to this version. Thanks to Facundo Fernández for reporting this vulnerability. A patch has been submitted to the upstream ENet repository as well.
The illustration picture used for this release is fromSky Runner— a speed running game by Leon Stansfield where your goal is simple: get from point A to point B… across a set of sky islands with some tricks up your sleeve. It’s being made with Godot 4 and you get try out the demo on itch.io right now! You should also follow Leon on Twitter or Mastodon for updates and other demos and experiments that he creates with Godot.
Changes
72 contributors made 158 pull-requests (or 166 commits) as a part of this release. See the curated changelog for a list of most notable differences, or browse our interactive changelog for a complete list of changes with links to relevant PRs and commits.
Here are the main changes since 4.0.3-stable:
2D: Don’t create bones from empty scene (GH-77473).
As of now, there are no known incompatibilities with previous Godot 4.0 releases. We encourage all users to upgrade to 4.0.4.
If you experience any unexpected behavior change in your projects after upgrading to 4.0.4, please file an issue on GitHub.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-1-1/index.html b/article/maintenance-release-godot-4-1-1/index.html
index 3863904968..f0f53bb51a 100644
--- a/article/maintenance-release-godot-4-1-1/index.html
+++ b/article/maintenance-release-godot-4-1-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov17 July 2023
The release of Godot 4.1 was just a couple of weeks ago and we are ready for the first maintenance release — addressing some of the bugs and annoyances that have slipped into the stable build.
Deciding where to draw the line and mark a release as stable is a tricky thing. On the one hand, there are always unresolved issues. But on the other, not every issue is critical enough to block all other improvements and fixes from shipping. With our current release management plan we put the effort into reducing the number of changes the closer we are to the planned release date, as this ensures we don’t get an unexpected breakage or regressions. Contributors, however, remain determined to improve Godot, so by the time the first maintenance release comes around, we have plenty of goodies to include!
Some of the most important changes in this release include:
Fix for a crash due to an infinite loop in AnimationStateMachine (GH-79141). It was a gnarly issue because it was easy to trigger with a bare minimum configuration. Now circular dependencies are correctly detected preventing infinite looping.
Command-line export of C#/.NET projects should no longer drop random files (GH-79173). Your exports may have had arbitrary resources missing (not C# scripts, but images, for instance), if you were exporting your project with CLI. This should no longer happen.
Custom export options which you can define with an EditorExportPlugin are now correctly restored on the editor restart (GH-79025). Previously the usability of this freshly added feature was limited due to data loss between sessions.
For Linux users there is a potential fix for freezes when interacting with menus on Wayland (GH-79143). This was a hard to identify and debug issue, but our local Wayland enthusiasts managed to pinpoint the likely cause and validate that the unwanted behavior was addressed.
The illustration picture used in this announcement comes fromGunforged— a 2D roguelite shooter where, you’ve guessed it, construct your weaponry from a huge number of different parts. The game is being made by Firebelley with Godot 4 using its excellent C# language support, and is planned to be released later this year. But no need to wait, because you can play a demo on Steam right now! You can also subscribe to Firebelley on YouTube, where they share tutorials and devlogs.
Changes
48 contributors made 83 pull-requests (or 87 commits) as a part of this release. See the curated changelog for a list of most notable differences, or browse our interactive changelog for a complete list of changes with links to relevant PRs and commits.
Here are the main changes since 4.1-stable:
2D: Improve string drawing in the tiledata editor (GH-78522).
2D: Make sure the shortcut key respects the context in TileSetAtlasSourceEditor (GH-78920).
3D: Fix Camera3D project_* methods not accounting for frustum offset (GH-75806).
3D: Fix 3D viewport grid disappearing on scene tab changes (GH-78694).
Animation: Fix infinite loop state check in AnimationStateMachine (GH-79141).
Animation: Add 3.x compatibility for animation loop mode (GH-79155).
Animation: Fix tween_property on Basis to properly update its value (GH-79426).
Buildsystem: Linux: Allow unbundling brotli to use system library (GH-79101).
C#: Update the RiderPathLocator to support the JetBrains Toolbox 2.0 (GH-78832).
C#: Compare symbol names without null flow state (GH-79094).
Rendering: Clear specular buffer if sky mode is canvas and screen space effects are used (GH-78624).
Rendering: Fix threading bug in Vulkan rendering device (GH-78794).
Rendering: Take eye offset into account for depth in StandardMaterial3D (GH-79049).
Shaders: Fix invalid shader compilation when using hint_normal_roughness_texture in mobile backend (GH-78839).
Shaders: Fix using uint suffix at the hex number declaration in shaders (GH-78906).
Shaders: Fix shader language float literal precision truncation (GH-78972).
Shaders: Fix comments and indentation in .gdshaderinc files (GH-79158).
As well as many improvements to the documentation.
One previously accepted change was reverted in this release due to regressions:
GUI: Revert “Fix focus loss of non-exclusive AcceptDialog with close_on_escape” (GH-79084).
Known incompatibilities
As of now, there are no known incompatibilities with the Godot 4.1 release. We encourage all users to upgrade to 4.1.1.
If you experience any unexpected behavior change in your projects after upgrading to 4.1.1, please file an issue on GitHub.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-1-2/index.html b/article/maintenance-release-godot-4-1-2/index.html
index ba28a95d07..dbc704420d 100644
--- a/article/maintenance-release-godot-4-1-2/index.html
+++ b/article/maintenance-release-godot-4-1-2/index.html
@@ -7,7 +7,7 @@
The regression fix (GH-83088) was applied directly to the export templates archive, so users who downloaded 4.1.2 export templates prior to October 11, 2023 should re-download them if they intend to export projects to iOS with Xcode 14 or earlier.
Aside from the above, there are no known incompatibilities with previous Godot 4.1.x releases. We encourage all users to upgrade to 4.1.2.
If you experience any unexpected behavior change in your projects after upgrading to 4.1.2, please file an issue on GitHub.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-1-3/index.html b/article/maintenance-release-godot-4-1-3/index.html
index 8227091492..78ae4e3807 100644
--- a/article/maintenance-release-godot-4-1-3/index.html
+++ b/article/maintenance-release-godot-4-1-3/index.html
@@ -10,7 +10,7 @@
Make a Donation
The illustration picture used in this announcement is fromMeowing Point— a point-and-click game by Francisco Martinez, where your job is to pet petrified cats to bring them back to life. The game started as a Godot 3 project and was later ported over to Godot 4. You can get it right now on itch.io or Steam! Make sure to follow Francisco on Twitter.
Changes
76 contributors made 128 pull-requests (or 133 commits) as a part of this release. See the curated changelog for a list of most notable differences, or browse our interactive changelog for a complete list of changes with links to relevant PRs and commits.
Here are the main changes since 4.1.2-stable:
2D: Allow using floating-point bone sizes and outline widths in the 2D editor (GH-79434).
2D: Convert TileSet Atlas Merge input images to RGBA8 to match output, if needed (GH-80943).
2D: Fix TileMap editor so that pressing control deselects cells correctly (GH-81925).
Rendering: Vulkan: Fix multithreaded compute list and GPU particle processing (GH-79849).
XR: Fix GPUParticles3D on the Meta Quest 2 with OpenGL renderer (GH-83756).
Thirdparty: mbedTLS 2.18.5, zlib/minizip 1.3.
Thirdparty: Sync controller mappings DB with SDL2 community repo.
As well as many improvements to the documentation.
Known incompatibilities
As of now, there are no known incompatibilities with previous Godot 4.1.x releases. We encourage all users to upgrade to 4.1.3.
If you experience any unexpected behavior change in your projects after upgrading to 4.1.3, please file an issue on GitHub.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-2-1/index.html b/article/maintenance-release-godot-4-2-1/index.html
index 6bf00238c4..340f77ebc8 100644
--- a/article/maintenance-release-godot-4-2-1/index.html
+++ b/article/maintenance-release-godot-4-2-1/index.html
@@ -10,7 +10,7 @@
Make a Donation
The illustration picture used in this announcement is fromVoice of Flowers, a metroidvania that takes great inspiration from Mario games, developed in Godot 4 by Tomasz Chabora (KoBeWi) – one of Godot’s most profilic maintainers! You can wishlist the game on Steam, play the latest demo on itch.io, and follow development on Discord and Twitter.
Changes
42 contributors submitted around 74 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Here is the complete list of changes in this release:
2D: Fix UV editor not using texture transform (GH-84076).
2D: Fix generating terrain icon with certain image formats (GH-84507).
2D: Keep scene tiles even if the TileMap is invisible (GH-85753).
As of now, there are no known incompatibilities with previous Godot 4.2.x releases. We encourage all users to upgrade to 4.2.1.
If you experience any unexpected behavior change in your projects after upgrading to 4.2.1, please file an issue on GitHub.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/maintenance-release-godot-4-2-2-and-4-1-4/index.html b/article/maintenance-release-godot-4-2-2-and-4-1-4/index.html
index 1decc897cc..9c09ebeda8 100644
--- a/article/maintenance-release-godot-4-2-2-and-4-1-4/index.html
+++ b/article/maintenance-release-godot-4-2-2-and-4-1-4/index.html
@@ -15,7 +15,7 @@
Make a Donation
The illustration picture used in this announcement is fromRAM: Random Access Mayhem, a top-down roguelike shooter where you take control of diverse robotics enemies. RAM won the Audience Choice award at the IGF 2024! You can wishlist it on Steam and try your hand at the demo, as well as follow the developers on Twitter.
Highlights of 4.2.2
150+ contributors submitted more than 400 improvements for this release, which makes it pretty significant as far as patch releases go. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
Here’s a short selection of some of the most relevant changes.
Improved command line export pipeline
A lot of users use CI/CD pipelines such as GitHub Actions or GitLab CI to export their game to all their supported platforms automatically. This implies checking out the source repository of the project, and running Godot from the command line (in so-called “headless” mode, i.e. no graphical display) to perform the export with the --export-release or --export-debug commands.
For a long time now, users have been struggling with some associated issues, such as:
Source repositories typically don’t include the .godot folder with imported resources, so before exporting, the editor needs to run once (still in headless mode) to properly import everything, generate the GDScript class_name cache, etc. This is now much easier to do thanks to a new --import command which does exactly that and then exits, without having to jump through hoops (GH-90431). This command is also implied in --export-release/--export-debug, so you don’t even need to call it explicitly unless you want to (e.g. to run unit tests before exporting).
The “headless” mode of Godot for command-line use relies on a no-op rendering backend which implements the API without requiring an actual GPU and display to run their logic. Some scaffolding was missing there to properly support MultiMesh data and shader parameters, which should now be fixed too (GH-87390, GH-87392).
The exit code is now properly set when the command line export fails, so your scripts can react accordingly (GH-89234).
Fixed audio crackling issues on Windows
A now infamous issue (GH-75109) has been affecting a number of Godot users on Windows with more advanced audio setups, which caused seemingly random audio crackling or distortion issues. This was particularly bad as it also affected published Godot 4 games, which could be quite annoying for players.
Thanks to a lot of testing and experimentation by the community, the issue was finally fixed in Godot’s WASAPI driver (GH-89283), and the fix is now included in 4.2.2 and 4.1.4.
Workaround for some types of “corrupted scene” load errors
We are well aware that a lot of users routinely run into issues when refactoring their project by renaming or moving files around. There are multiple reasons for these errors, some which have been fixed already in the 4.3 dev branch, and we will backport what we can to also address the most egregious problems in 4.2 too.
One such improvements is to allow loading scenes with missing external resources (due to having moved them around, especially from outside Godot) instead of reporting the scene as corrupted (GH-85159, GH-90269). This isn’t perfect, but should already help significantly when this happens.
Fixes to animation features after the move to AnimationMixer in 4.2
The Godot 4.2 release had a major refactoring of AnimationPlayer and AnimationTree on top of a common AnimationMixer base class, to share the base implementation for many common features. There were still some regressions we didn’t have time to solve before the 4.2 release, but work continued afterwards. A number of those issues are now being fixed in 4.2.2, and old bugs have also been fixed at the same time. Please check the “Animation” category of the interactive changelog for details.
And a lot more!
There are many other important changes! We strongly suggest giving the interactive changelog a good read, especially in areas which are particularly relevant for your projects. Here’s a few more noteworthy focus areas:
Android: Target SDK changed to API level 34 (Android 14) (GH-87346).
Animation: Many fixes to animation features after the move to AnimationMixer in 4.2.
C#: Fixed duplicate key issue on reload (GH-87838), and many other C# bugs.
Documentation: A metric ton of class reference improvements!
Editor: Improve 3D visualization of origin lines (GH-83895) and Curve3D-related debug information (GH-83698).
Editor: Fix editor profiler script function sort order (GH-87661).
GDScript: Faster LSP message processing to use with external editors (GH-89284), as well as many code completion improvements.
Import: Fixed multiple issues with mesh compression (GH-88738).
Rendering: Fix Volumetric Fog VoxelGI updates (GH-86023).
Rendering: Significantly improve the speed of shader compilation in compatibility backend (GH-87553).
Thirdparty: Mbed TLS 2.28.8, ThorVG 0.12.10.
Highlights of 4.1.4
Around 100 contributors submitted more than 200 improvements for this release, which makes it pretty significant as far as patch releases go. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
As mentioned above, for 4.1.4 we’ve been more conservative with what we cherry-pick. The original 4.1 release is almost one year old, and so its branch is starting to drift significantly away from the main development branch (4.3) and the latest stable (4.2). Likewise, users who are still using 4.1.x are now quite familiar with what works and what doesn’t, and we want to be cautious not to introduce regressions.
So 4.1.4 includes mostly documentation updates, but also a subset of the fixes listed above. We also cherry-picked some changes which were included in 4.2-stable already, and have now been sufficiently validated by a lot of user testing. Here are some highlights:
Android: Fix potential crash when pressing the “Back” button (GH-84414), and respect the setting to disable the splash screen (GH-84491).
Animation: Fix setting animation save paths on import breaking on Windows (GH-90003).
Audio: Fix audio crackling issues on Windows (GH-89283).
Core: Fix for the infamous slot >= slot_max error affecting exported projects (GH-85280).
Documentation: Also a bazillion class reference improvements!
Export: Fix reporting exit code when command line export fails (GH-89234).
GDScript: Allow LSP to process multiple messages per poll (GH-89284).
iOS: Enable Storyboard launch screen by default (GH-89336).
Porting: Re-disable C++ exceptions which had been wrongly enabled for Android, iOS, and Web builds in a previous patch release (GH-84328).
Rendering: Significantly improve the speed of shader compilation in compatibility backend (GH-87553).
Thirdparty: Mbed TLS 2.28.8.
Known incompatibilities
As of now, the 4.2.2 release has no known incompatibilities with previous Godot 4.2.x releases. We encourage all users to upgrade to 4.2.2. Likewise for 4.1.4 with respect to previous 4.1.x releases.
If you experience any unexpected behavior change in your projects after upgrading to either new release, please file an issue on GitHub.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/major-update-for-visual-shader-in-godot-3-2/index.html b/article/major-update-for-visual-shader-in-godot-3-2/index.html
index 1e32b1161a..fdbde2b667 100644
--- a/article/major-update-for-visual-shader-in-godot-3-2/index.html
+++ b/article/major-update-for-visual-shader-in-godot-3-2/index.html
@@ -8,7 +8,7 @@
or the dedicated Wikipedia article.
Boolean node
The Boolean node was not exposed to the visual shaders until now. They can be converted to Scalar or Vector to represent 0 or 1 and (0, 0, 0) or (1, 1, 1) respectively. This property can be used to enable or disable some effect parts by one click.
Conditional nodes
The If node allows you to setup a vector which will be returned after performing comparison between a and b. There are three vectors which can be returned: a == b (in that case the tolerance parameter is provided as a comparison threshold – by default it is equal to the minimal value, e.g. 0.00001), a > b and a < b.
The Switch node returns a vector if the boolean condition is true or false. Boolean was introduced above. If you convert a vector to a true boolean, all components of the vector should be above zero.
Grayscale and Sepia nodes
These are useful effects which have been added to ColorFunc (a container for such effects), so there is no need to create them manually.
Per-component multiplication modes for TransformMult
Derivative nodes
These nodes are Fragment specific, and cannot be used in the Vertex mode context. They are put under the Special category tab and divided into ScalarDerivativeFunc and VectorDerivativeFunc.
Testing these changes
All the above improvements have been made in Godot’s master branch (the development branch for the future Godot 3.2). As of this writing, you have to build the compile the master branch from GitHub or use one of the nightly builds provided by community members to test it.
That’s all for now, in the future new types of nodes can be easily added to this new system (especially after Vulkan has been implemented), thanks to the magnificent possibilities provided by Godot’s design!
-
+
\ No newline at end of file
diff --git a/article/major-update-visual-shaders-godot-3-2-part-2/index.html b/article/major-update-visual-shaders-godot-3-2-part-2/index.html
index ffea96d1c1..480c523328 100644
--- a/article/major-update-visual-shaders-godot-3-2-part-2/index.html
+++ b/article/major-update-visual-shaders-godot-3-2-part-2/index.html
@@ -9,7 +9,7 @@
Be careful not to use it too frequently since it may significantly decrease the shader performance.
Default UV parameter for Texture
The Texture node’s uv input port no longer requires to be connected to a UV node - it is used internally by default!
TextureUniformTriplanar
This TextureUniformTriplanar node is available only in Spatial shaders in the fragment function. Parameters weights and pos are overrides by default. It’s a big, complex function as you can see in the generated code panel.
Sampler type
The Sampler type was most recently added, to help developers with handling texture samplers. Internally, it is a name reference to an existing uniform or pre-defined sampler input.
The texture uniforms get a new port that returns it. To use it, you can connect it to a Texture, Expression or custom node with the allowed port. If you connect it to a Texture node, the new SamplerPort option must be used to handle the input from the sampler.
Since it’s just a name reference and shaders cannot pass them to local variables, the Expressions can accept sampler but cannot return them (at least for now).
I’ve also added predefined samplers such as ScreenTexture, Depth or Texture (Texture2D for CanvasItem shader type).
They can be used with custom nodes or Texture:
Summary
Godot provides an awesome layer for graphics developers, and with provided changes it can do many new things in an easier and better way. For 4.0, I hope to continue enjoying myself and make shader fun more accessible by providing new enchancements and feature proposals.
If you like my work and want to support me, I’m happy to receive donations (see relevant options on my GitHub profile).
Thanks Arkology for providing examples of custom visual shader nodes. You can download his VisualShader plugin on GitHub.
-
+
\ No newline at end of file
diff --git a/article/make-2d-games-godot-last-day-kickstarter/index.html b/article/make-2d-games-godot-last-day-kickstarter/index.html
index 87b4616fa1..b8863a74d7 100644
--- a/article/make-2d-games-godot-last-day-kickstarter/index.html
+++ b/article/make-2d-games-godot-last-day-kickstarter/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest20 June 2017
This article is from June 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.
We’re in the last few hours of Make 2D Games with Godot on Kickstarter. It’s been a resounding success. It came out a lot better than our most optimistic guesses, with more than 4 times the initial goal. And it’s not done just yet! There’s a few hours left.
There are 2 sides to the project: on the one hand, the backers get a premium course. On the other hand, the campaign also funds a lot of free content. Both as in free speech, and in free beer.
During the Kickstarter, I produced a new tutorial almost every day. The playlist features 28 Godot tutorials, with a few more coming this week. There’s already 15 open source example projects to go along with them on Github.
Before we talk about the contributions, let’s gather for a closing livestream tomorrow, starting at 11AM CEST. I’ll give a GDscript demo, and take some time to answer your questions afterwards.
Contributions to the official documentation
Before the campaign, we discussed what Godot’s docs needed the most with Akien, and where I could help. A fair part of the Kickstarter’s budget will be used to bring better content for all Godot users:
The official demos are incomplete for a part, and often pretty rough. Code examples are an excellent way to get into an engine. So we will bring you improved sample demos, designed to teach you important aspects of the engine.
The Step by Step tutorial series is good, but we want it to be great. We’ll discuss what needs to be changed with all the contributors, and I’ll be in charge of the new version.
Everyone will get an introduction to the new 3D renderer in Godot 3. I don’t have experience programming 3-D games, but I did start as a 3D artist. I will cover everything that’s visual in nature, in video. The series will be available both on Gdquest and to download and share freely, as an official training series.
The entire game from the Kickstarter project will be open source, commented, available as part of the official demos. We’re currently missing a full game example that tries to show the best practices. I’ll work hard to provide it.
On top of that, I will share the tools I create for the needs of the course. There again, open source (game art template, editor plugin, useful scripts…).
The schedule
The entire project is going to take a year. Maybe more. As a puny human, I can only tackle one task at the time, so you will need to be patient! As the campaign went so much better than anticipated, I don’t even know myself all there is to do: the backers will vote for more than a dozen bonus topics to cover, on top of the planned course. I will prepare a rough schedule after the backers voted, around mid-July.
-
+
\ No newline at end of file
diff --git a/article/making-shaders-more-accessible/index.html b/article/making-shaders-more-accessible/index.html
index 4bb526473f..ebfffcaf0e 100644
--- a/article/making-shaders-more-accessible/index.html
+++ b/article/making-shaders-more-accessible/index.html
@@ -5,7 +5,7 @@
Juan Linietsky6 October 2016
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.
About shaders
For most game developers, shaders are this scary monster that presents itself with such a complexity that it seems out of reach. In reality, shaders are quite simple by default and just get more complex the more you add to them.
To explain the idea of how shaders work, let’s consider a very simple shader for drawing a sprite to the screen. Our sprite is 32x32 pixels in size, and it must be drawn at some position. (Disclaimer: This is not intended as a tutorial but just to give you an idea about how things work if you don’t).
The following OpenGL code sends the sprite to the shader for drawing:
OpenGL Commands
As you can see:
Vertices / UVs are sent via attributes.
Configuration parameters are sent via uniforms.
Textures are simply bound to bind points starting from 0, and the bind point number is sent via attributes too.
After calling glDrawArrays, the vertex program (also called vertex shader in DirectX terminology) is executed once per vertex (we are sending 4 vertices). Each vertex is a pair of floats (we configured this via glVertexAttribPointer()).
Vertex Program
This code no longer runs in the CPU, in fact it runs on the GPU! Again, it is executed per vertex. The output of the vertex program must fit in a “box” of size -1 to +1 in X, Y and Z. The vertices become primitives (in this case, a triangle fan, two triangles that are drawn as a quad) and any primitive that goes beyond the -1 to +1 range is clipped. As such, this is called “Clip Space”.
All we need to know is that we must convert the screen coordinates (for a screen size of 1024x768) to this space, so the natural way of doing this is:
Divide the final coordinate by the screen size
Multiply by 2
Substract (1, 1)
Result is the sprite vertices in the -1 to +1 clip space coordinates.
These triangles are then drawn to the screen (remember, again the screen can be of any size, but OpenGL will respresent it in the -1 .. +1 range for drawing).
For each pixel drawn to the screen, OpenGL will interpolate the outputs that were generated from the vertex program and use them to fill the triangle. In this case, the UV coordinate (for reading the texture). This process is done in the fragment program (pixel shader in DirectX terminology).
Fragment Program
In the fragment program, the input is the UV coordinate (interpolated), and the output the screen color. We use the sprite texture uniform to read the sprite pixels.
As you can see it’s not really that complex.
Shaders in Godot
Of course, if you are working on a game there is a lot more things going on. Vertices have to be transformed in 3D space, and there are many features the engine provides for you such as:
Taking care of normals, tangent arrays, etc.
Transforming geometry by skeletons
Performing lighting, normalmapping, shadowmapping
Properly drawing the shader in base and additive passes of forward rendering, deferred, shadow, etc. (many configurations)
This gets quite messy. Don’t believe me? This is how long Godot’s default 3D shader for GLES 2.0 is:
It’s about 1300 lines of code, you can read all of it here.
Truth is, however, that far most of the times a programmer wants to write a shader, it only intends to change a few parameters such as how the texture is drawn, changing colors, material properties, etc. Because of this, Godot comes with a simplified shader language (very loosely based on OpenGL ES 2.0 shading language). Users can write the vertex, fragment and lighting shader using a lot of pre-existing information.
As an example, to draw a sprite with a texture in Godot, only this is required:
Just that, and Godot takes care of the sprite transform, applying light and shadows to it, sending vertices, etc. It’s much, much simpler and the reason people use game engines in the first place :).
Why not GLSL, HLSL, CG?
A question that comes up often is why did Godot choose not use an existing shader language. There are a few very clear reasons regarding why we went the current way:
We wanted the shaders to be easy to write. Removing GLSL stuff such as attributes, color buffer management, etc. (which Godot already takes care of) makes the language more coherent.
We wanted complete control over the code generation. Other game engines force you to write shaders yourself for different rendering passes (such as deferred, forward base, forward addition, shadow, pre-z pass, etc). In Godot, the shader is written only once and the different versions of code are generated on the fly from the parse tree, transparently.
We don’t want users specifying how the shader must be drawn (e.g. render queue position, render type such as alpha or opaque, etc.). Godot detects if certain variables are written to e.g. alpha and does the queue and render pass management automatically.
The result of this is that shaders always work as intended, with no surprises.
Shaders in Godot 3.0
A lot of developers, however, complained about the Godot shader syntax being too limited. As a result, for Godot 3.0 we did the following changes:
The language now supports most of the GLSL 3.0 shader specification, and uses OpenGL datatypes and functions.
Shaders are now a single file, so they can be saved to text to the filesystem.
Shaders will also now provide hints, so the exported parameters are easier to edit.
The shader editor provides full code completion and argument hinting, making writing them a breeze!
-
+
\ No newline at end of file
diff --git a/article/meet-community-fosdem-and-godotcon-2019/index.html b/article/meet-community-fosdem-and-godotcon-2019/index.html
index ca8872eb8a..c9c29f6507 100644
--- a/article/meet-community-fosdem-and-godotcon-2019/index.html
+++ b/article/meet-community-fosdem-and-godotcon-2019/index.html
@@ -6,7 +6,7 @@
We will be distributing and selling some goodies (T-Shirts, stickers) and most importantly presenting our favourite engine and some games to the FOSDEM visitors. More than 8,000 visitors are awaited, and we hope that many will be impressed by Godot 3.x and the games made with it!
There might be Godot-related talks, but we are still waiting for a confirmation from the FOSDEM organizers (the event is increasingly popular and they have hundreds of talk proposals to choose from).
The FOSDEM is a great opportunity to discover new projects from top-notch free software contributors. It will also be the occasion to meet other Godot users and contributors, at our stand or around a few Belgian beers :)
Practical infos (location, schedule, etc.): See FOSDEM.org and our Events page.
GodotCon Brussels 2019
Two days in a crowded event is not enough! To get more time together to actually discuss our projects, learn new things and discover engine features together, we are organizing a 2-day event focused on Godot right after the FOSDEM (on Monday 4 and Tuesday 5).
Registrations are just starting, but given the recent growth of the community we expect around 100 attendees (we had ~60 last year); we’ll size things accordingly so we need you to register as fast as possible to help us with the organization.
There will soon be a Call for Proposals so that everyone can propose a talk, a workshop or any kind of activity that we could do during those two days. Last year was a big success, and we expect the new GodotCon to be even better, both due to the higher number of attendees and the impressive growth of the engine since the 3.0 release!
The exact venue is still to be determined, as soon as we have a good overview about our numbers.
Edit: The venue will be Ludus Académie, Quai du Commerce 48, Brussels.
And since four days IRL is still not enough when we’re working together remotely all over the year, we’re adding a third event just before FOSDEM dedicated to getting things done. This contributor sprint will be primarily intended for existing engine and documentation contributors, so that we can work on current topics together, review Pull Requests, discuss the roadmap, etc. We will also welcome users who aren’t contributors yet but would like to get involved, be it with C++ engine contributions, documentation writing or the creation of other teaching materials (demos, courses, etc.).
Having this sprint before FOSDEM will allow us to some work on the engine before the GodotCon, so that core contributors are fully available to GodotCon attendees afterwards.
The venue is still to be determined. Depending on our numbers it might be the same as the GodotCon venue, or a smaller one.
Edit: The venue will be Ludus Académie, Quai du Commerce 48, Brussels.
-
+
\ No newline at end of file
diff --git a/article/meet-community-fosdem-and-godotcon-2020/index.html b/article/meet-community-fosdem-and-godotcon-2020/index.html
index 6c74ca3804..f7b648b594 100644
--- a/article/meet-community-fosdem-and-godotcon-2020/index.html
+++ b/article/meet-community-fosdem-and-godotcon-2020/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde5 December 2019
This article is from December 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 year 2019 is coming to an end, and it’s time for us to start planning our 2020 events. As usual, core contributors and community members will meet at and around the FOSDEM in Brussels, in particular at the GodotCon on Mon 3 and Tue 4 February 2020.
Like last year, we will have three events next to each other:
Godot Sprint on Thu 30 and Fri 31 January 2020, where core contributors meet to work together, exchange on all kinds of topics related to the Godot project: technical proposals, roadmap for future releases and common work, community management, etc. Everyone interested in Godot’s development is welcome to attend, but be aware that it’s primarily too technical-oriented work days for contributors.
FOSDEM 2020 on Sat 1 and Sun 2 February 2020, where we have a Godot stand where you can meet community members, buy a Godot T-shirt or get free goodies like stickers or metal pins. For the first time, some of us will also organize a Game Development devroom on Sat 1, with a series of talks about Free and Open Source game development tools and games. If you missed our CFP posted a couple of months ago, you still have a few days to submit talk proposals (but be quick, we’re already past our planned deadline but we still have a few slots we can allocate).
GodotCon Brussels 2020 on Mon 3 and Tue 4 February 2020, which is our convention for all members of the Godot community, with talks, demos and workshops of interesting projects. For examples of the kind of talks that we have at the GodotCon, you can check the schedules of past events (Poznań 2018, Brussels 2019, Poznań 2019). See below for our Call for Participations to propose your own talk.
Like previous years, the venue for Godot Sprint and GodotCon will be Ludus Académie, Quai du Commerce 48, Brussels (OpenStreetMap). Thanks to them for hosting us once again!
The FOSDEM takes place at the ULB (Université Libre de Bruxelles) as usual.
As in previous years, many core engine developers will be there (including our lead developer Juan Liniestky coming from Argentina for the event), so it should be a great time to discuss all things Godot.
Information overload, what’s for me?
If you’re lost among the three events listed above, GodotCon on Mon 3 and Tue 4 February 2020 is what you should be looking into. It’s our main event for all Godot users. And if you’re coming to Brussels for GodotCon, you might as well swing by the FOSDEM to learn about many Free and Open Source projects, including Godot.
Where do I sign up?
All three events are free of charge for everyone, and for the FOSDEM you do not even need to register: just show up and say hi at the Godot stand!
For the Godot Sprint and GodotCon however, registration is mandatory as we need to know how many persons will be there to find appropriate venues in Brussels. To help us with the organization, we ask that you register as soon as possible.
The Events page on this website is the reference if you need up-to-date information on the events (both before and during the event).
Call for participations for GodotCon
Over the coming weeks, we encourage all Godot users who plan to attend GodotCon to send us proposals for talks or workshops that you would like to give. Just like Godot itself, the GodotCon is an event made for and by Godot users, so we need you to propose content that will make it a great event for all attendees.
We’re 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 or workshop is fine too if the topic is worth it :)
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)
Technical requirements (whether you need a projector, with or without sound, etc.)
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.
For inspiration, feel free to review the schedules of past events for a glimpse at the kind of activities that we usually have (Poznań 2018, Brussels 2019, Poznań 2019).
Looking forward to meeting some of you in Brussels!
-
+
\ No newline at end of file
diff --git a/article/meet-community-godotcon-poznan-2018/index.html b/article/meet-community-godotcon-poznan-2018/index.html
index 42571b96f2..88398decaa 100644
--- a/article/meet-community-godotcon-poznan-2018/index.html
+++ b/article/meet-community-godotcon-poznan-2018/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 August 2018
This article is from August 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.
After our GodotCon in Brussels in February 2018, we’re preparing a new Godot Convention (GodotCon), this time in Poznań, Poland on Wed 10 & Thu 11 October 2018.
We need speakers for the event; contact me (Rémi) if you’d like to be one.
Contact me if you want a discount code for Game Industry Conference passes (also in Poznań right after GodotCon).
Our lead developer Juan Linietsky is coming to Europe again from Argentina as a speaker for the Game Industry Conference (GIC) on 11-14 October 2018 in Poznań. We’re taking this opportunity to organize a Godot-related side-event to GIC on the 10 & 11 October on the same premises.
As we mostly communicate online in the Godot community, including among core engine developers, such an event is a great opportunity to meet IRL to get to know each other better, discuss and work on the engine as well as various community and game projects.
This is an international event, and as such we invite all Godot users and contributors within a reasonable distance of Poland to join us there! We’re looking forward to meet the European Godot community again, and especially those of Central and Eastern Europe who may not have been able to attend the previous GodotCon in Brussels, Belgium.
Practical information
See our Events page for the details and pratical information, including links to relevant GIC pages with travel information. The Events page will be updated as we get more details about the event, especially regarding the speakers and schedule (see call for participation below).
The GodotCon will be free of charge, but we ask you to register via this form so that we know who to expect, and how many attendees will be there.
Our GodotCon is graciously hosted as a side-event of GIC, which will start on the evening after GodotCon. Juan will be giving a talk there, and we might also propose a Godot workshop. You are encouraged to attend GIC after GodotCon and meet thousands of game and engine developers. For that event the entry is paid, but we have 40% discount codes for the developer and business passes for GodotCon attendees, contact me (remi at godotengine · org) if you are interested.
Call for participations
We now have a date, a venue, and several core developers and engine users registered for a great event in Poznań – 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 round table between experienced developers, or a talk about your own Godot project, the tricks you’re using in your workflow, etc. 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 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 a big room so we could run a long workshop on one end of the room while shorter talks happen on the other end.
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)
Technical requirements (whether you need a projector, with or without sound, etc.)
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 contributors: This is your event, and we really want to see as many of you as possible to discuss current engine development topics live. We put some funds aside to cover reasonable travel expenses for events, and that could include you. If you would like to attend this GodotCon but it doesn’t fit in your budget, contact me and we’ll see on a case by case basis if we can help cover your travel costs (please get in touch with me before buying anything though, to get confirmation that we will cover some or all of your costs).
-
+
\ No newline at end of file
diff --git a/article/meet-community-godotcon-poznan-2019/index.html b/article/meet-community-godotcon-poznan-2019/index.html
index 510e7d5c5e..9a6dd5fc7e 100644
--- a/article/meet-community-godotcon-poznan-2019/index.html
+++ b/article/meet-community-godotcon-poznan-2019/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde23 July 2019
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.
We organize two Godot community events in the week leading to the Game Industry Conference (GIC) in Poznań, Poland: a new Godot Sprint for engine contributors on October 14 & 15, 2019 and a GodotCon for all users on October 16 & 17, 2019.
All GodotCon attendees are also encouraged to stay for the rest of the week (October 17 to October 20) for the actual Game Industry Conference, where our lead developer Juan Linietsky (reduz) will be a speaker, as well as the Poznań Game Arena (PGA) in the same venue, where many game studios demo their projects, including a number of indie developers using Godot.
We already had three GodotCons (short for Godot Conference) in Brussels (2017, 2018 and 2019) and once in Poznań (2018) over the past few years. GodotCon is an event for all Godot community members, both curious newcomers and power users, to meet other users and contributors to the engine and exchange knowledge and experience. We typically have talks and workshops during the two days, and those who wish so also hang out together for dinner in the evenings.
Like last year, our event is graciously hosted as a side event of the Game Industry Conference, which will start with a nice party on the last evening of the GodotCon (October 17). The venue will be the MTP Poznań Expo, which is located centrally in the city and is also the venue for the (much bigger) GIC and PGA events.
If you are interested in meeting fellow Godot users and many of the engine’s core contributors, we strongly recommend that you join us at GodotCon. Last year was a lot of fun, and we expect this new edition to be even better :)
Godot Sprint - Oct 14 & 15, 2019
The Godot Sprint, which we had for the first time last February in Brussels, is another two-day event dedicated to engine contributors. As we usually work together online and discuss via IRC or GitHub, we use opportunities like Godot Sprint to finally talk together IRL, which lets us discuss a number of technical topics and reach consensus much faster.
So this event is mostly meetings focusing on specific contribution-related topics, such as the development roadmap, how to improve our workflows, onboarding of new contributors, as well as many technical topics which are of interest to the attendees.
And of course this is a great opportunity to get to know each other better, which also greatly improves our ability to contribute efficiently towards common goals and make Godot an ever greater engine.
If you’re not a contributor yet but would like to become one, or are curious about a community-driven FOSS project operates, you are welcome to attend the Godot Sprint too.
The venue is yet to be confirmed, but might also be at the MTP or nearby.
Practical information
See our Events page for the details and pratical information, including links to relevant GIC pages with travel information. The Events page will be updated as we get more details about the event, especially regarding the speakers and schedule (see call for participation below).
Both the GodotCon and Godot Sprint have free entry, but we ask you to register via this form so that we know who to expect, and how many attendees will be there.
The venue for GodotCon is the MTP Poznań Expo, same place as the GIC. Godot Sprint might also be there or within walking distance. We encourage you to book travel and accommodation as soon as possible. Any location in downtown Poznań should be either within walking distance or a short tramway ride of the MTP.
Call for participations
Over the coming weeks, we encourage all Godot users who plan to attend GodotCon to send us proposals for talks or workshops that you would like to give. Just like Godot itself, the GodotCon is an event made for and by Godot users, so we need you to propose content that will make it a great event for all attendees.
We’re 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 30 min talk or workshop is fine too if the topic is worth it :)
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)
Technical requirements (whether you need a projector, with or without sound, etc.)
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.
For inspiration, feel free to review the schedules of the pasttwo events for a glimpse at the kind of activities that we usually have.
-
+
\ No newline at end of file
diff --git a/article/meet-godot-engine-representatives-gdc-2020/index.html b/article/meet-godot-engine-representatives-gdc-2020/index.html
index 0249eb9088..b7bd6e55fd 100644
--- a/article/meet-godot-engine-representatives-gdc-2020/index.html
+++ b/article/meet-godot-engine-representatives-gdc-2020/index.html
@@ -5,7 +5,7 @@
Juan Linietsky10 February 2020
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.
Next month it will be time for GDC yet again! The project leadership will be attending the event for meetings and we are starting to build our schedule for GDC 2020.
If you would like to meet with us, please let us know (write to contact at godotengine · org) so we can reserve a slot for you for meeting, go for lunch, dinner or a coffee!
It is not certain this year whether there will be official Godot activities during GDC as we did not have a lot of time to organize so, if you want to meet with us, it is recommended you just contact us directly.
Of course, if we end up organizing an event in the end, we will post about it as soon as possible.
-
+
\ No newline at end of file
diff --git a/article/meet-godot-representatives-gdc-2019/index.html b/article/meet-godot-representatives-gdc-2019/index.html
index bed1e23b76..b5deb3d81a 100644
--- a/article/meet-godot-representatives-gdc-2019/index.html
+++ b/article/meet-godot-representatives-gdc-2019/index.html
@@ -5,7 +5,7 @@
Juan Linietsky20 February 2019
This article is from February 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.
Another year, another GDC! This year, many of us core developers will be attending GDC in representation of the project to meet with companies interested in knowing more about Godot (or just meeting with us).
If you want to meet with us during GDC, please drop us a mail to contact at godotengine · org and we will attempt to schedule a meeting.
For Godot users, we will soon be announcing our very own Godot party during GDC!
-
+
\ No newline at end of file
diff --git a/article/meet-nodes-godot-event-paris/index.html b/article/meet-nodes-godot-event-paris/index.html
index 40ea7d4ff5..eeb817401d 100644
--- a/article/meet-nodes-godot-event-paris/index.html
+++ b/article/meet-nodes-godot-event-paris/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 March 2017
This article is from March 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.
Get ready to Meet the Nodes in person: we are organising a Godot event on Saturday 22 April 2017 in Paris, where many Godot developers will be giving talks, lead workshops or just be available to discuss the engine and game development!
It’s worth noting that our lead dev Juan Linietsky (reduz) will be present too, which is a great opportunity for our European community to finally meet him in person.
The event will be hosted by Mozilla at their Paris Space (16 Bis Boulevard Montmartre, Paris 75009, France), starting at 9 am and running up to 7 pm.
There is no entrance fee, but to ease the organisation we’d like you to fill this form if you plan to join us, so that we know how many people to expect. See our events page for up-to-date information about the event.
Schedule and activities
The detailed schedule will be announced in the coming weeks, but you can already be sure that we will make this event interesting for both curious beginners and advanced Godot users - so even if you’ve never heard of Godot before landing on this blog post, do not hesitate to join us to discover this awesome free and open source game engine and its community!
This event will be partly talks and partly workshop, and we will set up the space so that everyone can sit at a table and have access to a power socket - so don’t hesitate to bring your laptop so that you can discover Godot directly by testing it, or do more advanced stuff with fellow community members if you are already familiar with the engine.
Call for papers
We would like to invite Godot users and contributors, as well as developers working on game development related topics (e.g. WebAssembly) to propose talks that they could give during the event.
The expected talk duration would likely be 20 min plus 10 min Q&A, but feel free to propose something else that you think would be more fitting, we will be relatively flexible.
To propose a talk or a workshop, send an email to our contact address with the following information:
Name, nickname (if relevant)
Talk title
Abstract
Anything else that you think would be relevant
The deadline for applications is Monday 17 April, so don’t wait too long :)
The Mozilla Space is fully equiped with everything we could likely wish for, including a video projector, audio setup, recording and streaming setup. If you would have more specific needs though, feel free to tell us about it and we will see what is possible.
-
+
\ No newline at end of file
diff --git a/article/meet-us-fosdem-2017-and-godotcon/index.html b/article/meet-us-fosdem-2017-and-godotcon/index.html
index ba07be4af9..e6fc99a7a7 100644
--- a/article/meet-us-fosdem-2017-and-godotcon/index.html
+++ b/article/meet-us-fosdem-2017-and-godotcon/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde18 January 2017
This article is from January 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.
Hear, hear! Dwellers of the Old Continent or the far lands beyond the great seas, heed our call! Lackeys and subjects of the great Godot will be there to meet you in the royal city of Brussels, Belgium from Feb IV to Feb VII, MMXVII AD.
In other words, you will have the opportunity to meet Godot contributors and users at two upcoming events in Brussels, Belgium:
The former is the major European event focusing on Free and Open Source Software (FOSS). Godot will have a stand there where we will be distributing and selling some goodies (T-Shirts, mugs, stickers) and most importantly presenting our favourite engine to the FOSDEM visitors. More than 8,000 visitors are awaited, this should give Godot a better visibility in the international open source community.
The FOSDEM is a great opportunity to discover new projects (see the stands) and attend great talks (see the schedule) from top-notch free software contributors. It will also be the occasion to meet other Godot users and contributors, at our stand or around a few Belgian beers :) There are already 22 members of our community from all over Europe who told us that they will attend the event!
Practical infos (location, schedule, etc.): See FOSDEM.org and our Events page.
GodotCon Europe 2017
Two days in a crowded event is not enough! To get more time together to actually discuss our projects, learn new things and work together on the engine, we are organizing a 2-day event specifically about Godot right after the FOSDEM (on Monday 6 and Tuesday 7).
We currently have 21 registered attendants too (more or less the same as for the FOSDEM, though with a few differences) and expect maybe a few additional late deciders, so this should be quite an interesting meetup!
The schedule and acitivites are for now DIY, we will post more details as soon as we have a more precise plan - but the idea is that it will be tailor-made by and for the attendants, so that we can all get the most from those two days.
The event will take place at the Hackerspace Brussels, thanks a lot to the Hackerspace’s volunteers for having us over!
-
+
\ No newline at end of file
diff --git a/article/migrating-animations-from-godot-4-0-to-4-3/index.html b/article/migrating-animations-from-godot-4-0-to-4-3/index.html
index 8e520aab7f..e5c9a55230 100644
--- a/article/migrating-animations-from-godot-4-0-to-4-3/index.html
+++ b/article/migrating-animations-from-godot-4-0-to-4-3/index.html
@@ -18,7 +18,7 @@
Also, Grouped type never stays in the Start state and End state. The Start state of a Grouped type is equal to the next state after the Start state of the state machine as seen by the parent state machine. The End state of a Grouped type is equal to the next state of the state machine in the parent state machine. In other words, those transitions are replaced by the parent state machine transitions.
In short, a more direct representation of the above diagram is equivalent to the following:
Note that currently StateMachine does not have user-controllable indexes for connections and cannot have multiple Start/End states, so Grouped StateMachine is limited to having only one input/output. This limitation may be removed in the future by StateMachine enhancements.
NodeOneShot / NodeTransiton / StateMachineTransition - Break Loop at End
In the 4.1 StateMachine rework, we made the AnimationNode have an infinite-length remain time in a loop and for StateMachines with unpredictable endings as a hack. We did this becauses the old AnimationNode only returned the remaining time after the processing but there was no information there about whether it was looping or not. This change was necessary to prevent unintended animation interruptions for consistency, but it removed the existing behavior of breaking the loop at AtEnd and doing a Transition.
In 4.3, the AnimationNode time progression has been reworked significantly to propagate semantic time information. Now a BreakLoopAtEnd option has been added for use cases where the loop is broken by AtEnd.
This option makes it easier to implement things like AtEnd transitions after several loops.
NodeAnimation - Custom Timeline
As a byproduct of the time progression reworking, it is now possible to adjust the period and length of the animation in the AnimationNode.
This should help to solve problems with synchronization of foot step animation when blending walking and sideways walking animations, or walking and running animations.
The future of the animation feature
Compared to the Godot 3 code, you can see that almost all of the code has been rewritten in the animation area.
I have focused mostly on reworking and stabilizing features from Godot 3 that were unstable or not well-defined. I expect that such fundamental rework will be settled in 4.3, allowing us to focus on adding more features from now on.
I already have several proposals that I have written myself, but I am also interested in some proposals that have come from the community, so I hope to pick up on those as well.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/mir-godot-habla-dein-language-desormais/index.html b/article/mir-godot-habla-dein-language-desormais/index.html
index b8affd8299..f52e3695a1 100644
--- a/article/mir-godot-habla-dein-language-desormais/index.html
+++ b/article/mir-godot-habla-dein-language-desormais/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 May 2016
This article is from May 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.
It is generally accepted that, for programming, a certain knowledge of the Latin alphabet and a small understanding of the English language is needed. From there, there is a long distance to go before being fluent in the language.
We understand that, as such, there is a huge amount of programmers, from beginners to very talented developers, who would benefit enormously from using Godot in their native language. Moreover, Godot is a great tool for teamwork and is thus used by artists and game designers which might not even master the basic notions that programmers must know.
Internationalization of the editor
To stop this unfair retribution of individuals who rightfully believe they have better things to do than becoming fluent at English, we have added internationalization support to Godot!
Only French is supported as of this writing (in the git master branch), and we are still in a testing phase, but we are open to as many languages as you can contribute!
If you believe you are fluent in your own language (because some of us clearly are not), and want to help your comrades by submitting a translation, let us know!
How to help?
The internationalization system in Godot is based on the well-established gettext/PO files workflow, though with a tailor-made parsing and integration of the translated strings that does not rely on gettext.
Edit (June 2016): The following section is no longer relevant, as we now manage Godot translations on Hosted Weblate. Please contribute your changes there, and the Godot core developers will handle syncing them with the git repository every now and then.
The strings to translate are all referenced in the tools.pot template. This template can be used to generate an empty PO file (e.g. pt_BR.po for Brazilian Portuguese) using gettext or a PO edition tool:
With gettext: msginit -i tools.pot -o pt_BR.po
With a PO edition tool such as Poedit, you can just load the tools.pot file and it will let you generate a language PO file from it.
You can then edit the newly created PO file with your favorite text editor (fill-in the msgstr entries, trying to respect the same formatting as in the msgid source strings), or with Poedit or a similar tool (which provide nice facilities for PO edition, such as translation memory).
Feel free to get in touch with other members of the community to work on your translation as a team. Once you’re happy with it (even if only partially translated, if you want other contributors to pick up the work), make a pull request on the GitHub repository with your PO file in tools/translations/.
If you build the editor from source with your PO file in the correct folder, it should pick it up and extract the translated strings to display them in the editor!
Troubleshooting
Note that this is a pretty new development in the master branch, and won’t be backported to the current stable 2.0 branch. There are still various issues that have to be handled regarding internationalization (e.g. proper right-to-left languages support, Unicode font for languages that need it, etc.).
Please report any issue you might see while translating so that we can have a great 2.1 release!
(*) Hello world, Godot speaks your language from now on!
-
+
\ No newline at end of file
diff --git a/article/movie-maker-mode-arrives-in-godot-4/index.html b/article/movie-maker-mode-arrives-in-godot-4/index.html
index f034a48c16..f23ee775eb 100644
--- a/article/movie-maker-mode-arrives-in-godot-4/index.html
+++ b/article/movie-maker-mode-arrives-in-godot-4/index.html
@@ -5,7 +5,7 @@
Hugo Locurcio14 November 2022
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.
The idea of using a game engine for projects other than creating video games is not new. For decades, game engines have been used to create applications, simulations and more. However, with the ever-increasing visual fidelity of their rendering engines, game engines have grown in popularity for situations that demand high-end visuals. These use cases include architecture visualization, cinema, animation and cutscene rendering.
With the addition of non-real-time video recording, Godot opens itself to these new use cases.
What is Movie Maker mode for?
Godot can record non-real-time video and audio from any 2D or 3D project. There are many scenarios where this is useful:
Recording game trailers for promotional use.
Recording cutscenes that will be displayed as pre-recorded videos in the final game. This allows for using higher quality settings (at the cost of file size), regardless of the player’s hardware.
Recording procedurally generated animations or motion design. User interaction remains possible during video recording, and audio can be included as well (although you won’t be able to hear it while the video is recording).
Comparing the visual output of graphics settings, shaders, or rendering techniques in an animated scene.
With Godot’s animation features such as the AnimationPlayer node, Tweeners, particles and shaders, it can effectively be used to create any kind of 2D and 3D animations (and still images).
If you are already used to Godot’s workflow, you may find yourself more productive by using Godot for video rendering compared to Blender. That said, renderers designed for non-real-time usage such as Cycles and Eevee can result in better visuals (at the cost of longer rendering times).
Compared to real-time video recording with tools such as OBS Studio or SimpleScreenRecorder, some advantages of non-real-time recording include:
Use any graphics settings (including extremely demanding settings) regardless of your hardware’s capabilities. The output video will always have perfect frame pacing; it will never exhibit dropped frames or stuttering. Faster hardware will allow you to render a given animation in less time, but the visual output remains identical.
Render at a higher framerate than the video’s target framerate, then post-process to generate high-quality motion blur. This also makes effects that converge over several frames (such as temporal antialiasing, SDFGI and volumetric fog) look better.
What is Movie Maker mode NOT for?
Movie Maker mode is not designed for capturing real-time footage during gameplay.
Players should use something like OBS Studio or SimpleScreenRecorder to record gameplay videos, as they do a much better job at intercepting the compositor than Godot can do using Vulkan or OpenGL natively.
That said, if your game runs at near-real-time speeds when capturing, you can still use this feature (but it will lack audible sound playback, as sound is saved directly to the video file).
Example output
https://www.youtube.com/watch?v=e047PL2KyP4
Using Movie Maker mode
Complete documentation on using this new Movie Maker functionality can be found in the Creating movies page of the Godot documentation.
Also check out the new Playing videos page in the documentation, in case you want to play the videos you’ve recorded using Godot in a project.
Technical implementation
Movie Maker works with the following components:
A class that inherits from the MovieWriter abstract class. This allows custom output formats to be implemented with GDExtension. For example, GDExtension could be used to implement a FFmpeg pipe with Movie Maker mode.
A special-purpose audio driver, which is automatically enabled when using Movie Maker mode. This audio driver is designed to capture the game’s audio output to a buffer, which can then be written to a file (such as an AVI video’s audio channel or a WAV file).
Non-real-time simulation, which is enabled using the --fixed-fps <fps> command line argument. This makes the engine simulate gameplay as fast as possible, with delta always having the same value (regardless of how long it took to render the frame). This feature has been available since Godot 3.0, but Movie Maker automatically makes use of this feature to ensure consistent frame pacing.
Image’s new save_jpg() function, which was added as Movie Maker requires it for MJPEG recording. This complements the existing save_png() function, which is used when recording to PNG + WAV.
Core modifications to allow enabling Movie Maker mode with a command line argument (which is passed by the editor when running the project with Movie Maker mode enabled).
The built-in supported output formats are MJPEG (within an AVI container) and PNG image sequence + WAV file. See Choosing an output format in the documentation for the upsides and downsides of each format.
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.
-
+
\ No newline at end of file
diff --git a/article/mozilla-awards-godot-engine-part-moss-mission-partners-program/index.html b/article/mozilla-awards-godot-engine-part-moss-mission-partners-program/index.html
index 62058ee79c..97b89ff204 100644
--- a/article/mozilla-awards-godot-engine-part-moss-mission-partners-program/index.html
+++ b/article/mozilla-awards-godot-engine-part-moss-mission-partners-program/index.html
@@ -5,7 +5,7 @@
Juan Linietsky22 June 2016
This article is from June 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.
With the advent of new technologies such as Web Sockets, WebAssembly and WebGL 2.0, it is more critical than ever that free and open source tools are available to develop high performance games and applications for these platforms.
The award of USD 20,000 will be received by Software Freedom Conservancy, who acts as Godot’s non-profit home. They will ensure that this award is used to improve Godot to support these new techologies as soon as possible. We will post an update soon when have more information on how this will be done!
-
+
\ No newline at end of file
diff --git a/article/multiplayer-changes-godot-4-0-report-1/index.html b/article/multiplayer-changes-godot-4-0-report-1/index.html
index 23d09550f2..29f625a9bb 100644
--- a/article/multiplayer-changes-godot-4-0-report-1/index.html
+++ b/article/multiplayer-changes-godot-4-0-report-1/index.html
@@ -42,7 +42,7 @@
In this example, we only make 1 rpc(), reducing the network usage and latency. More importantly, we make sure that in each frame, either the client will have the old state, or a fully updated one. This avoids having an inconsistent state where the position is up-to-date but the motion isn’t (or vice versa).
This is just one example which shows a common pitfall in networking.
So, to avoid tricking developers into these common mistakes (which could be unexpected for newcomers), and given the rarity of rset() usage in general, we decided to remove rset(). We really think you won’t miss it in the end, but let us know if you feel you had a strong use case for them. Like most decisions in Godot, this is not set in stone.
Future work
If you feel a bit disappointed from this progress update, keep in mind this was just the ground work for more important changes. We have a few surprises in the works!
There’s the new GDScript syntax for RPCs to talk about, the newly exposed ordered transfer mode, channels, ENet and WebRTC improvements, and even some news about the long-awaited node replication! So stay tuned for more :)
-
+
\ No newline at end of file
diff --git a/article/multiplayer-changes-godot-4-0-report-2/index.html b/article/multiplayer-changes-godot-4-0-report-2/index.html
index d7c27e91ab..431d8a058f 100644
--- a/article/multiplayer-changes-godot-4-0-report-2/index.html
+++ b/article/multiplayer-changes-godot-4-0-report-2/index.html
@@ -39,7 +39,7 @@
When using the ordered transfer mode, be advised you should not send heterogeneous messages over the same channel.
In the code snippet above, we are are designing a game where we don’t mind if the player and enemy states are a bit offsetted in the client. However, we do want each state to only be updated if the received one is newer (hence the “ordered” mode).
In this case, we must use different channels for the 2 RPCs because we want 2 separate orderings. Otherwise, a “players” update could be dropped because a newer “enemies” state has already been received, which is not what we want.
Future work
There are a lot of exciting new things to talk about, from heavy refactoring of the networking classes and exposing most low-level ENet functions, to the high level work done on the new scene replicator. Stay tuned for more :)
-
+
\ No newline at end of file
diff --git a/article/multiplayer-changes-godot-4-0-report-3/index.html b/article/multiplayer-changes-godot-4-0-report-3/index.html
index e48a48e4dd..83e3cb83ba 100644
--- a/article/multiplayer-changes-godot-4-0-report-3/index.html
+++ b/article/multiplayer-changes-godot-4-0-report-3/index.html
@@ -81,7 +81,7 @@
As you can see, setting up a network mesh is harder then setting up an ENet server and client, but it is now possible, and more examples will be added to the demos including a signaling server on the line of the WebRTC one.
WebRTC everywhere!
Speaking of WebRTC, back in July, we released an update to the WebRTC native plugin to finally support all official Godot platforms. This release also updates the WebRTC library to a much newer version (4472).
The latest release is still 3.x-only, but we plan to make a new one supporting Godot 4 soon, along with an update to the 3.x version with some additional features.
Future work
Well, this was probably more boring than usual, but there are a lot of exciting news to talk about, including a new scene replication system, along with the new GDExtension for low level network peers to better integrate third-party networking libraries.
-
+
\ No newline at end of file
diff --git a/article/multiplayer-changes-godot-4-0-report-4/index.html b/article/multiplayer-changes-godot-4-0-report-4/index.html
index f4657a7279..7156c614d4 100644
--- a/article/multiplayer-changes-godot-4-0-report-4/index.html
+++ b/article/multiplayer-changes-godot-4-0-report-4/index.html
@@ -104,7 +104,7 @@
In the same way, properties of child nodes could be set, and custom interpolation techniques implemented.
Future work
As explained, this is an early prototype. A more complete proposal has been created to gather feedback as we work towards a final implementation in the coming months. This includes visual configuration, child node properties support, fine grained spawn control and more.
The coming months will be prety dense of announcements. As always, stay tuned for more!
-
+
\ No newline at end of file
diff --git a/article/multiplayer-in-godot-4-0-scene-replication/index.html b/article/multiplayer-in-godot-4-0-scene-replication/index.html
index c3828851fa..edc233556f 100644
--- a/article/multiplayer-in-godot-4-0-scene-replication/index.html
+++ b/article/multiplayer-in-godot-4-0-scene-replication/index.html
@@ -198,7 +198,7 @@
We can now run the game and test that connecting to a host will correctly spawn the appropriate level and players, give us control of our character, and properly synchronize the object positions.
And that’s it for this long awaited introductory post to the new replication system. More advanced topics like bandwidth optimizations, spawning customized scenes and the visibility system will be discussed in a separate tutorial.
-
+
\ No newline at end of file
diff --git a/article/navigation-server-godot-4-0/index.html b/article/navigation-server-godot-4-0/index.html
index 43f0df91ed..424ef5c2fd 100644
--- a/article/navigation-server-godot-4-0/index.html
+++ b/article/navigation-server-godot-4-0/index.html
@@ -71,7 +71,7 @@
Now you can play the scene, and voilà:
Note: Collision avoidance behavior can be tweaked per agent, by changing the NavigationAgent settings. You can change velocity, time of response to obstacles, and some other useful things.
Conclusion
This was an introduction to the new NavigationServer and NavigationServer2D coming up in Godot 4.0. The integration of these new servers was made possible thanks to the sponsoring of IMVU!
Give it a check, and enjoy use Godot! And don’t hesitate to provide feedback about this new feature, which we can polish further until the actual 4.0 release.
-
+
\ No newline at end of file
diff --git a/article/new-communication-platform-godot-contributors/index.html b/article/new-communication-platform-godot-contributors/index.html
index 3ea8295afb..8aade8f459 100644
--- a/article/new-communication-platform-godot-contributors/index.html
+++ b/article/new-communication-platform-godot-contributors/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde3 February 2021
This article is from February 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.
Godot has many communication platforms used by the community to talk about the engine and their projects: GitHub for development, the Q&A for technical questions, Reddit, Discord, and several others for user discussions, Twitter for announcements, etc.
Up until recently, engine contributors favored the tried and trusted IRC protocol on Freenode as their main chat communication platform, but we are now moving all developer channels to the new Godot Contributors Chat:
Join chat.godotengine.org if you want to follow or participate in engine development discussions.
This new platform is a self-hosted instance of the open source Rocket.Chat communication platform, gratiously hosted and administered by Prehensile Tales on behalf of the Godot project.
Why a new chat platform?
We’ve been using IRC to discuss engine development for several years, but despite being a tried and trusted open source technology with bazillion clients for all platforms, it is lacking in modern features such as:
Persistent login (to see what was discussed while you were offline).
Good moderation features.
Easy-to-setup private channels and group discussions.
Support for Markdown and code blocks.
Easily uploading images.
While we can live without most of those, the difficulty to have persistent login on IRC (you either need to host your own client or bouncer, or pay for a cloud-based client) was a major annoyance for many current and potential contributors, especially with a project spread across all timezones.
Additionally, this new platform provides a centralized place for Godot Engine contributors to talk with each other. When you join the platform, you can browse the list of public channels and join the ones related to topics or teams you want to contribute to. Having everything in one place makes those channels more discoverable, enabling more potential contributors to connect with us.
Priority to open source
While there are many popular proprietary platforms which offer the kind of modern features that we need, Godot is a community-driven open source project, and it is important for us to use and promote open source technology where we can. That’s why we chose to deploy our own instance of Rocket.Chat for this purpose. We also considered other open source team chat options such as Matrix and Mattermost, but Rocket.Chat proved to be the best candidate for our needs in our evaluation.
As we offer Single Sign-On with social OAuth login, and plan to eventually expanded it to other Godot-hosted services such as the Asset Library and the Q&A, we are confident that this new platform should serve us well and be accessible to everyone.
Focused on engine contributions
Finally, we’d like to reiterate that this platform is the communication platform for engine contributors, and not the primary user support community.
Everyone interested in contributing to Godot, be it with code, documentation, bug reports, or general feedback on technical discussions, is very welcome to join us there!
For general user support, sharing projects, and other non contribution-related Godot topics, we keep the many platforms listed on the Community page.
How does it work?
There are many open source clients which you can use to access the platform, either through your browser, or desktop and mobile native apps. See the Home page of the chat platform for some links.
You can read some channels anonymously, but if you want to participate in the discussions, you will have to create an account to log in. You can use pre-existing social logins to authenticate on Godot’s Single Sign-On, such as GitHub, Google, or Discord accounts. Or you can create a local Godot account with your email address.
Once you join the platform, you can visit the Channels Directory for a list of public channels that you might be interested to join. This platform is intended to host channels for all the Godot development teams, and possibly for regional communities too, so most channels are opt-in and will only be visible if you decide to join them. We also have a dedicated channel for #new-contributors which you can join if you’d like to contribute to Godot.
-
+
\ No newline at end of file
diff --git a/article/new-godot-t-shirt-design-call-content/index.html b/article/new-godot-t-shirt-design-call-content/index.html
index 9d78e43df5..6756e59f9d 100644
--- a/article/new-godot-t-shirt-design-call-content/index.html
+++ b/article/new-godot-t-shirt-design-call-content/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde12 December 2019
This article is from December 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.
Every year Godot contributors and users meet at various conferences and events. The biggest one is usually the GodotCon that takes place at the beginning of February in Brussels. During 6 days, there is a Godot development sprint, a Godot conference and finally FOSDEM, one of the biggest open source meetups in Europe. See details and register if you want to join us!
To mark the occasion, we print a new T-shirt design each year. During GodotCon and at our stand in FOSDEM, we sell the T-shirts to raise some funds for the project. As February is approaching, it is time to choose this year’s T-shirt design, and we decided to change things a bit this year. Instead of coming up with something among the core contributors, we want to make this a community effort.
We are starting a call for content to all artists, designers, and users in general that would like to contribute with a design or idea for this year’s shirt. If you ever wanted to contribute to the project but never knew how this can be a great opportunity for you. You can use all the resources in the Godot design repository, but the icons and logos should be used without major modifications.
Sketches, drafts, and ideas are welcome, but final designs are preferable. If you have a really good idea, you can share it on Twitter using the #GodotEngine hashtag and maybe someone loves it and wants to implement it!
You can see examples from the past three years in this post’s banner image (A3 print on T-shirts with color close to the background colors on the previews). As you can see, the first design heavily relied on the brand new node icons that we got at that time, and later designs built on the same idea - but we’re looking for different input and you’re more than welcome to do something unprecedented :)
Requirements
The general requirements for the design are:
5 or fewer colors
Front side only
In a vector format (SVG preferentially)
If you use Godot’s logo in your design, it has to be the current official one with the correct colors. You can find some official resources in the Godot design repository
You can also propose a base T-shirt color, but that will be dependant on the manufacturer’s availability.
How to submit
You can send your finished proposals to artwork at godotengine·org before December 27th. The email must include:
Design(s) in vector format (SVG preferentially)
Chosen license
Author name and optionally email/URL for attribution
We will keep all the design entries in this gallery so everybody can check them out during the process.
Passed the deadline, core contributors will select the design that they find best represents the project for this year. Some of the other designs will be made available too in a public gallery for those who might want to print their own shirt, mug or to make any kind of derivative work (wallpapers, splash screens, etc.). We’ll announce results and share the gallery on this blog around the turn of the year.
-
+
\ No newline at end of file
diff --git a/article/new-showcase-for-projects-made-with-godot/index.html b/article/new-showcase-for-projects-made-with-godot/index.html
index e8b20651f0..fec32922c2 100644
--- a/article/new-showcase-for-projects-made-with-godot/index.html
+++ b/article/new-showcase-for-projects-made-with-godot/index.html
@@ -9,7 +9,7 @@
Aside from the above threshold, there’s no objective acceptance criteria, we’ll be reviewing projects subjectively and selecting the ones which we find are best suited to showcase Godot’s diverse capabilities.
To avoid copyright and trademark issues, we don’t accept fangame submissions unless they’re endorsed by the original copyright/trademark holder.
-
+
\ No newline at end of file
diff --git a/article/next-patreon-goal-help-us-hire-remi-verschelde-akien-full-time/index.html b/article/next-patreon-goal-help-us-hire-remi-verschelde-akien-full-time/index.html
index c58010a332..5ab897aec8 100644
--- a/article/next-patreon-goal-help-us-hire-remi-verschelde-akien-full-time/index.html
+++ b/article/next-patreon-goal-help-us-hire-remi-verschelde-akien-full-time/index.html
@@ -5,7 +5,7 @@
Juan Linietsky8 January 2018
This article is from January 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.
Godot on Patreon
We have been on Patreon since August 2017 and the net result has been overwhelmingly positive, with us reaching our first goal in less than a month and reaching today a generous $6000 of monthly donations!
If you haven’t become our patron yet, please consider it! As you will see in this post, it really makes a difference. If you prefer other donation means, we will hopefully be able to provide alternative platforms soon.
Our goals so far
So far, since the first goal was met (hiring me), I was able to spend a lot more time working on Godot. Most of my new time was used to help existing developers and contributors, as well as helping guide new ones get familiar with the code.
Thanks, in large part, to this, the amount of contributions and active developers skyrocketed and we ended up adding a lot more functions to the upcoming 3.0 (which will be released this month).
The second goal was met recently, and we could hire karroffel, who is the author of GDNative, to continue working on it and also start working on an OpenGL ES 2.0 rendering backend. This new backend will allow Godot 3.1 to recover the high compatibility and performance with every mobile device, low-end PC and WebGL that Godot 2.1 always had.
Default GUI works now! The Editor is using custom materials so it's not looking good currently, but baby steps :) pic.twitter.com/v9VvfeZnS9
Being more versed in 3D programming will also allow karroffel to contribute more to 3D development in general, which is the area we have more difficulty finding contributors for.
Next goal: Hiring Rémi Verschelde (Akien)
Our next step is to get our current project manager Rémi Verschelde to work full-time on Godot, and take on the role of project representative on top of those tasks. And we need your support to reach it, as we’re still $1,500 away from the target!
Rémi started contributing in 2015 and he has become a vital part of Godot’s development these past years. He is our project manager, release manager and leads the triage and documentation teams. He helps coordinate the dozens of monthly contributors, reviewing hundreds of PRs or ensuring that competent developers review them (he merged over 3000 PRs in 3 years), as well as organizing our participation in many FOSS events that take place in Europe.
He is a veteran free software developer and played a big role in setting up the workflows that we use today in Godot’s development, to fully leverage the potential of a FOSS community of passionate users, testers, documentation writers, developers, advocates, etc.
By hiring him, the project will not only gain a full time project manager but also a much-needed project representative.
Project representative
As I wrote many timesbefore, Godot is growing very fast and our community is much larger each year, yet our presence in the video game industry is tiny. Not many big budget games are being made with Godot.
Part of the reason why this happens is that Godot is very new, and games usually take several years to be complete, but the main problem we face is visibility. It’s not that companies are not interested in Godot, it’s just that they simply have never heard of it. The same happens with education institutions and video game industry events, we have zero visibility in there. Even the industry press has never mentioned Godot.
To begin changing this, we need to participate more in industry events, getting to meet more companies, education institutions, press events, etc. For this, we need a project representative, a real human who can be a reference point for the industry to contact. Someone who can speak on behalf of the project, who knows everyone of us working on it.
As much as I would love to do this, my time is better spent programming and helping other developers. I also live in Buenos Aires, so I’m very far away from most of the industry.
Rémi lives in Europe, speaks French, English and German fluently, and knows all of us working on Godot. This is why we (the Godot PLC and other contributors we discussed with) want him to take on this role.
His role as a representative will also include finding and coordinating other representatives around the world, so we can have better presence such as:
Speakers in all industry events
Educators teaching or speaking about Godot at schools and universities
Connections to companies all around the world
Worskhop templates for volunteers in local communities (we need to make them and translate them)
etc.
More presence will also mean more potential sponsoring, so we can improve our cashflow and make sure more of our core contributors can be hired to work on improving Godot.
Help us make this happen by pledging on Patreon or sharing the link to your network! :)
-
+
\ No newline at end of file
diff --git a/article/online-godotcon-2021-schedule/index.html b/article/online-godotcon-2021-schedule/index.html
index 0bc1a7d046..97ca2f3c7d 100644
--- a/article/online-godotcon-2021-schedule/index.html
+++ b/article/online-godotcon-2021-schedule/index.html
@@ -6,7 +6,7 @@
Until then, stay safe!
-
+
\ No newline at end of file
diff --git a/article/online-godotcon-july-2021-call-participation/index.html b/article/online-godotcon-july-2021-call-participation/index.html
index cf74a7c8fc..908dd73f57 100644
--- a/article/online-godotcon-july-2021-call-participation/index.html
+++ b/article/online-godotcon-july-2021-call-participation/index.html
@@ -6,7 +6,7 @@
We are looking forward to see any topic that relates to Godot in some form. You could showcase your project, talk about some nifty tools that you have developed, detail your process for game development with Godot and so on.
We hope to receive again a variety of different topics, from community topics, to art topics, to programming, etc.
When we opened the previous call for participation, we received an astounding amount of very good proposals, most of which we couldn’t fit in the 8 hours schedule that we had planned. It is absolutely fine, and even encouraged, to re-submit your proposal for this GodotCon.
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)
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.
We hope to see you at the event, and may we be able to also organise an in-person conference soon!
-
+
\ No newline at end of file
diff --git a/article/only-two-buttons-dozens-games/index.html b/article/only-two-buttons-dozens-games/index.html
index 21e8baaeca..1cf319afdf 100644
--- a/article/only-two-buttons-dozens-games/index.html
+++ b/article/only-two-buttons-dozens-games/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde16 February 2017
This article is from February 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.
41 games were submitted this time, which is huged compared to our previous two game jams which had respectively 11 entries (March 2016 jam) and 17 entries (June 2016 jam) - it shows how the Godot community is steadily growing!
Following our usual rule, all games submitted to the jam are distributed under free and open source licenses (at least their code and scene files - if unsure about the assets best ask the authors before reusing them), which makes an incredible resource of learning material for beginner and experienced Godot users alike. We all use Godot’s feature in different ways, and reading other developers’ code or scene setup can really help understand the engine and find one’s own “best practices”.
The jam’s theme was Two buttons, which could as usual be interpreted quite freely. Games were rated based on those three criteria:
Use of the theme (“Two buttons”)
Gameplay
Graphics and sound
The average value from those three criteria would then be the overall ranking.
Enough introductory speech, let’s check out the best games from this last jam.
The top 3 games
1st place: Astrid - The Meow Night Shadow, by Trogallart
A great looking 3D runner featuring Astrid, a witch’s cute black cat running on rooftops to fetch her master’s magical stuff.
We were so fond of the game that we used it at our FOSDEM booth to showcase the editor and the fact that yes, you can do 3D games with Godot (it’s not PBR yet, but for a demo it was already quite nice). We had to tweak the game’s difficulty a bit to make it easier to play by forum visitors without having to lose 10 times to get the gist of it ;)
Astrid also ranked first in the Graphics and sound category, so kudos to Mimmi Collin for her artwork and Arnaud Quevedo for the music!
An educational game with neat 3D graphics where the players needs to do math operations only with 2 and 3.
The game’s attention to detail and well thought gameplay seemingly had a great impact on the voters. The Two buttons theme was of course used as best as it could, since the game features two in-game physical buttons which are activated by two input buttons - so game therefore ranked first for the Theme criterion.
Control two cars at the same time using only two buttons, and make sure not to hit other cars on the road! A pretty interesting and challenging concept, as you control each car using a single key, so it’s not your typical driving game!
Now let’s check which are the other games with the highest ranking for each criterion.
Use of the theme
We already saw the best contestants for this criterion, 2 or 3! There are then three games tied for the 2nd place: Two Taps Racer, TBPlane and Tamagowari. All in all most games ranked pretty high on this criterion, it was relatively easy to fit the theme :)
The first place for this criterion goes to ButtButt by Non0w. The gameplay for this one is indeed quite interesting: you can only do two actions at a given time (e.g. go right and jump, or go left and up), and those actions change each time you reach a checkpoint - you therefore need to find the right way to reach the exit with those limited actions.
As mentioned above, Astrid got the award for the best graphics, but there is another gorgeous looking game right behind it with the second position which is definitely worth mentioning: Stargazer, by Novastrike Media.
The art and music were made during the jam and are simply awesome - we hope Novastrike Media will continue working on their jam entry and turn it into a full game!
-
+
\ No newline at end of file
diff --git a/article/onward-new-3d-renderer/index.html b/article/onward-new-3d-renderer/index.html
index b672684767..b015b162c5 100644
--- a/article/onward-new-3d-renderer/index.html
+++ b/article/onward-new-3d-renderer/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 November 2016
This article is from November 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.
As already noticed by those of you who follow the development effort closely, we had a change of roadmap since what was announced when Godot 2.1 was released.
Indeed, we decided to skip the planned 2.2 release and head on directly towards Godot 3.0, the long-awaited upgrade that should bring brand new 2D and 3D renderers based on OpenGL ES 3.0 (mobile) and OpenGL 3.3 (desktop).
Motivation for the change of plans
Going faster
The main motivation for changing the roadmap is to release Godot 3.0 sooner. Within the Godot development team, our priority is always to work on what the community needs most at a given point in time - for the past year and a half, the focus has been on greatly improving the usability of the editor, as well as enhancing the 2D tools. Nowadays, Godot is a great engine for making 2D games, and the interest of the growing community is starting to move on to 3D, with corresponding needs for improvements.
For more than a year, Godot 3.0 has been promised to our users as the version that will bring a new state-of-the-art 3D renderer (albeit compatible with a wide range of graphics drivers, hence our choice for GLES 3.0 instead of Vulkan for the time being), and solve many issues and requests users have formulated regarding the current 3D renderer in Godot 2.1.
By skipping the 2.2 release, we allow ourselves (and mostly Juan, our renderer expert) to avoid a lengthy bug fixing and stabilisation period on 2.x features. We are therefore aiming for a release of Godot 3.0 in early 2017, which would not have been possible if we had to focus on 2.2 right now.
Breaking compatibility with 2.x
The new 3D renderer is the opportunity to do some important refactoring of Godot’s internals. We also want to use this opportunity to revamp, homogenize and enhance some parts of the API, to make Godot 3.0 a solid base for the further development of the engine and of Godot games.
What does this mean for users? Moving from Godot 2.x to Godot 3.0 will require porting the existing projects to take into account the API changes and the new way resources will be setup in 3.0.
We will provide tools to help with the conversion as well as extensive documentation, so do not worry. You can continue (or start) using Godot 2.x already, as most of the API and workflow will still stay the same, so 98% of what you are doing in 2.x will still be relevant in 3.0.
Still, this planned compatibility breakage and new renderer means that some of the main features advertised for Godot 2.2 would be changed substantially in Godot 3.0. In particular, the Visual Scripting feature that is already implemented in the master branch and was planned for 2.2 will be modified before Godot 3.0 is released - so if we were to release 2.2 with it soon, the visual scripts made with that version would not be compatible with Godot 3.0, and thus we want to avoid that people use it in production. Feel free to play with it in the development branch though, we always need feedback on new features!
Using the funds from the MOSS award efficiently
Last but not least, you might know that we were awarded a hefty sum by Mozilla as part of its MOSS Mission Partners program. This award was aimed at helping us improve Godot’s HTML5 export by implementing the brand new WebGL 2.0 and WebAssembly technologies. As the former is basically the same API as GLES 3.0, it’s best for us to work on both of them at the same time, so that we can ensure that GLES 3.0 / GL 3.3 and WebGL 2.0 will behave similarly.
Therefore, we decided, together with our non-profit home Software Freedom Conservancy to hire Juan Linietsky full-time for 6 months to work on the objectives funded by the MOSS award. This encompasses in particular the new renderer that will be done for 3.0, and extensive work on the HTML5 platform that might be done partly for 3.0 and in full for 3.1. As Juan is the project leader and our more prolific contributor, this will enable Godot to grow even faster than it has over the last couple of years.
What about existing 2.2 developments and the transition from 2.x?
You might now wonder what this means for the 2.2 developments you had been waiting for (e.g. C# support, visual scripting, high level multiplayer), and how you will support your 2.1 projects until they can be ported to Godot 3.0.
2.2 features moved to 3.0
All features planned for Godot 2.2 are moved to 3.0, which means that you will have to wait a bit more to use them. If you are critically in need of features like the already-implemented high level multiplayer API, you can use a custom build of the master branch as it is relatively stable. Visual scripting can be used already in the master branch too, but as mentioned above, we advise against using it in production yet. As for C# support, Ignacio is still hard at work on it but his developments haven’t been integrated in the master branch yet - we’ll definitely blog about it when the initial implementation is ready to test.
Extended support for 2.1.x
As for Godot 2.0.x, we plan to make maintenance releases for the 2.1 branch (version 2.1.1 should be released very soon). Due to the expected long waiting period until 3.0 is released and the fact that we’re skipping 2.2, we will be backporting “safe” features (as in, with no or little risk to bring bugs in existing features) to the stable branch. As always, that encompasses many usability improvements, but also brand new features like a new AStar API for pathfinding.
We might also consider support 2.1.x for a little while even after Godot 3.0 is released, to ensure that users can still have a maintained version of Godot if they’re not ready to port their projects to Godot 3.0 on day 1. Still, maintaining stable branches gets increasingly harder as time passes and it diverges with the master branch and development focus, so we can’t promise that bug fixes will be worked on specifically for the 2.1 branch if they are not needed in 3.x.
Support for older GLES 2.0 devices
The current renderer of Godot 2.1.x will be removed as we need to rewrite it completely to best use the possibilities offered by GLES 3.0.
Still, we are aware that on the mobile market, devices limited to GLES 2.0 still make up for an important part of the market share. Therefore, we plan to rewrite a GLES 2.0-compatible renderer based on the GLES 3.0 one - the two should be relatively similar, with the former having naturally less features and worse performance than the latter, but the hardware dictates that.
We intend to support Godot 2.1.x at least up to the release that will bring this new GLES 2.0-compatible renderer; it is not sure yet whether it will be in Godot 3.0 already, or come later in Godot 3.1. With that extended 2.1.x support, we want to make sure that you can distribute your games to the market that you want to target.
Living on the edge
You can already test the current state of the new GLES 3.0 renderer in the gles3 branch on GitHub (right now it only compiles on Linux, but that will be fixed in the near future). Please keep in mind that it’s a work in progress, and at the time of this writing it can’t be considered functional for 3D yet - the 2D renderer using GLES 3.0 should work OK though.
Once the branch is mature enough, it will be merged into the master branch and replace the current GLES 2.0 renderer.
Illustration (full size) courtesy of Jean-Manuel Clémençon from his work-in-progress 3D game in Godot 2.1. This shows the kind of rendering that is possible to achieve with our current GLES 2 renderer – we’re quite eager to see how it will turn out in Godot 3.0!
-
+
\ No newline at end of file
diff --git a/article/open-arpg-and-jrpg-demos-gdquest/index.html b/article/open-arpg-and-jrpg-demos-gdquest/index.html
index 7196cfb217..32ef83cf61 100644
--- a/article/open-arpg-and-jrpg-demos-gdquest/index.html
+++ b/article/open-arpg-and-jrpg-demos-gdquest/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest5 November 2018
This article is from November 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.
Over the past year, I’ve been working on open source demos to help people get the most out of tutorials. I also contributed some to the official Godot demo repositories.
Now I would like to go one step further. Small demos are great at giving you a sense for how some features work, but they can only take you so far: most games are composed of many systems that interact in complex ways. There’s never a single solution on how to structure your code and achieve your creative vision.
That’s why we’re starting to create open game demos at GDquest. We’re going to build larger projects than we did until now, still for educational purposes, and collections of companion tutorials to help you better learn Godot and improve your development and your design skills.
We’ve already open sourced our Zelda-like ARPG demo from our Godot course as a proof-of-concept.
Moving forward, one key idea is to involve you, the community, to get feedback, suggestions, great contributions and code reviews from experienced developers before we start recording tutorials. We want to keep improving the quality of learning material available for Godot.
This is the first project of this kind on GDquest. Please open an issue if anything is not clear on the repository, if we can improve how we communicate around the project, etc.
You can already find two tutorials from this project, funded by our patrons last month:
-
+
\ No newline at end of file
diff --git a/article/open-source-godot-gets-two-years-old/index.html b/article/open-source-godot-gets-two-years-old/index.html
index 5f64e7ed4e..766cd1712a 100644
--- a/article/open-source-godot-gets-two-years-old/index.html
+++ b/article/open-source-godot-gets-two-years-old/index.html
@@ -5,7 +5,7 @@
Juan Linietsky14 February 2016
This article is from February 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.
On a day like today, two years ago Godot was open sourced.
If you compare the current version with what was available back then, the difference is like night and day. I think it’s safe to say that, as an OSS project it improved several times faster (and became several times more awesome) than when it was a closed in-house engine.
This is in large part because there are now several more developers working on it, but the main reason behind this large improvement is because the community feedback has been incredible. All your feedback helped us, developers, to understand how Godot should really be, in contrast to the lone vision of a few guys.
From the day it was opensourced, we tried to shape Godot according to your needs and ideas and this is the result.
So, thanks to all of you, and happy February 14th to all the valentines, the community and Godot!
-
+
\ No newline at end of file
diff --git a/article/opening-github-discussions/index.html b/article/opening-github-discussions/index.html
index f5b9125994..bbb136e91b 100644
--- a/article/opening-github-discussions/index.html
+++ b/article/opening-github-discussions/index.html
@@ -5,7 +5,7 @@
Yuri Sizov18 February 2022
This article is from February 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.
For almost three years we’ve been using the Godot Improvement Proposals (GIP) repository to help track feature suggestions and enhancement ideas for the engine from its users. Over time, the project has accumulated over two thousand open proposal issues. Navigating this sea of ideas is a very hard task for both Godot users and engine maintainers.
If you’re unfamiliar with it, the proposal process consists of three steps. Whenever you encounter a limitation of the engine and there is no practical workaround, you are encouranged to visit the GIP repository and showcase your problem and suggest a resolution. You can either open a new issue, or look through existing ones to support them. The proposal issue is then held for deliberation until a consensus is reached, or it is determined that no consensus can be found. After there is a consensus between participants and agreement among engine developers, the feature can be implemented.
What’s changing
While we initially envisioned rather strict rules for new feature proposals, we ended up allowing users to start more open-ended conversations about existing woes and problems. This approach lacked separation between general ideas and features that are ready to be implemented. In an effort to help organize and streamline the proposal process we are opening the Discussions section in the GIP repository. Discussions, unlike proposal issues, won’t be a subject to strict requirements and rules (but Code of Conduct still applies, of course). Instead, they would provide a space to hold free-form conversations and let ideas blossom before they can be turned into ready-to-implement enhancement proposals.
At the same time, the Issues section of the GIP repository is going to be trimmed. We will go through all the existing proposals to try and determine whether they fit the requirements. If a proposal describes in enough technical detail an existing problem and a good potential solution, and there is a person ready to implement it, it will remain open. Issues that don’t fit proposal requirements will be either moved to the Discussions section, or closed with a suggestion to open a new discussion around that topic. In the end, issues would be a great way to keep track of features that are actually worked on, while discussions would be a platform to form a demand for an improvement or find workarounds for problems users experience in their projects.
In summary, if you have ideas that you’re eager to discuss with the community but which didn’t fit our strict proposal template, feel free to start new discussions! As always, leave your comments and thoughts on either proposal issues or discussions, and vote for ideas you support. This is the main driving force to define the future of the engine, and we couldn’t do it without you!
-
+
\ No newline at end of file
diff --git a/article/optional-typing-gdscript/index.html b/article/optional-typing-gdscript/index.html
index 0e5f234146..9e46fddba2 100644
--- a/article/optional-typing-gdscript/index.html
+++ b/article/optional-typing-gdscript/index.html
@@ -18,7 +18,7 @@
co
Enable type hints for signals.
Add a system to show warnings in the editor. This allows the game developers to catch things that are not invalid but may cause issues.
New instructions for typed code to allow faster execution. This includes avoiding the Variant evaluator and using typed arrays as well.
Further optimizations in the compiling stage to remove redundant instructions, reduce constant expressions to final constant, among other things.
-
+
\ No newline at end of file
diff --git a/article/our-point-click-framework-finally-out/index.html b/article/our-point-click-framework-finally-out/index.html
index ef9dc6b0f3..ae58aee95a 100644
--- a/article/our-point-click-framework-finally-out/index.html
+++ b/article/our-point-click-framework-finally-out/index.html
@@ -5,7 +5,7 @@
Ariel Manzur1 October 2016
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.
A while ago, we had a Kickstarter for The Interactive Adventures of Dog Mendonça & Pizzaboy®, and during the campaign we1 promised to release the framework we had made to develop the game as a standalone package. It took a while to finish the game and find some time to put the framework together and publish it, but it’s finally here :-)
Escoria, a point & click graphic adventure creation framework
Escoria is a set of scripts, template scenes and a dialogue scripting language, which are meant to be used within Godot Engine to create classic graphic adventure games. It’s not a “closed product”, with its own UI and tools, and it’s not a “make your game without programming” solution. It takes advantage of the Godot editor, and it’s intended to be used by a team to make a game, with minimal intervention from the programmer. It is also intended to be “owned” by your team; you will take over the framework, and adapt it to the needs of your games.
Documentation
Because Escoria doesn’t have any kind of wizards or “user friendly” UIs, and it was used to make a full product, it has many features and documentation is important to get anything done. For this reason, after my trip to Gamescom last month, I spent a week with FLOSS Manuals francophone in Rennes, France, creating a manual which explains most of the features of the framework. You can get it here:
I will also try to do separate documents for any missing features, maybe videos demonstrating stuff if requested by the community.
How to get it
You can download the framework from its GitHub page:
https://github.com/godotengine/escoria
The basic package includes a test scene and some basic documentation, so check out the manual for a more in-depth coverage of all the features.
Getting help
Since we don’t know how many people (if any :p) will be using this, we’ll start by using the issue tracker on the GitHub page, and Godot’s Q&A site using the tag escoria.
Have fun!
1 Juan Linietsky and Ariel Manzur, who participated in the development of the project.
-
+
\ No newline at end of file
diff --git a/article/parallax-progress-report/index.html b/article/parallax-progress-report/index.html
index 6382358fc0..2f35a03883 100644
--- a/article/parallax-progress-report/index.html
+++ b/article/parallax-progress-report/index.html
@@ -9,7 +9,7 @@
Increasing the repeat_times will allow for the number of repeats to grow and spread outward, so that you can zoom out and not reveal the magic going on behind the scenes. Eventually, it’d be nice to have a flag to adjust this automatically, but this is a good start! Bear in mind that this repeats all children of the Parallax2D node. If you want only one of the children to repeat, it might be preferable to use the texture_repeat property and Sprite2D’s region to prepare your background.
What else?
Parallax2D is now compatible with BackBufferCopy and CanvasGroup, and you’re also free to rotate the camera without breaking the parallax effect! Upon a few initial tests, we noticed some performance increases as well.
Caveats and future
With any effect that is based on perception, there are some tricky areas (since the entire effect is a trick!). A few of the same drawbacks to ParallaxBackground still apply to Parallax2D. For example, multiple cameras aren’t directly supported. This makes sense because Parallax2D follows the same concept as ParallaxBackground: the textures’ positions are modified directly and move at different speeds relative to the viewport. If you have multiple viewports, the textures can’t move relative to all of them and can’t be in two places at once! Just like in ParallaxBackground, as a workaround, you can clone the Parallax2Ds and place each in a separate viewport.
There’s a known trick you can perform with ParallaxBackground by scaling the entire CanvasLayer up or down to create the impression of depth using the follow_viewport_scale property. This techinque also makes it easier to preview your effect in the editor. This is still available with Parallax2D if you place it in a CanvasLayer, but (just like using it with ParallaxBackground) it has some flaws. It scales both size and speed, which may not be desired, and might not be suitable for some pixel art styles that avoid scaling textures. The better option is to provide an officially-supported way to preview the parallax effect in the editor, and a few contributors have already shown progress on providing this in the form of an add-on or editor tool. Can you believe that? 4.3 isn’t even out yet! The sheer power of this community.
Additionally, even though Parallax2D is a Node2D, you should still take caution when moving or scaling any parent nodes. It can be a delicate effect, so it’s recommended to be cautious in complex setups.
Thanks!
Thanks to those who helped make this feature, especially: MewPurPur for their lightning-fast SVG skills, Mickeon and clayjohn for championing this feature from the get-go, and KoBeWi, AThousandShips, and adamscott for jumping in with detailed reviews and constant questions to make sure it covered all corner cases and was just right… not to mention a dozen others that helped with feedback and testing. I’m Mark DiBarry (a.k.a. Mr. Dink in the Godot community). I’ve been contributing to the Godot engine for the last few years, but this is my first “big feature” contribution. I hope you like it!
Do you see room for improvement or felt the spark of an idea while reading this? We’re always looking for more contributors and would love it if you’d join in. Don’t worry about the size of your first submission; Many of us started with rectifying spelling errors in the docs. We wouldn’t be where we are without the willingness of our community to jump in and get their hands dirty. What are you waiting for?
-
+
\ No newline at end of file
diff --git a/article/patreon-first-goal-achieved/index.html b/article/patreon-first-goal-achieved/index.html
index 0467ca8808..f84c80a22f 100644
--- a/article/patreon-first-goal-achieved/index.html
+++ b/article/patreon-first-goal-achieved/index.html
@@ -6,7 +6,7 @@
Our next goals (set at USD 4,500 and $6,000) will be to hire some of our core developers part time on short contracts (1-3 months) to work on important and demanding features.
Many of our contributors are doing an incredibly good work, but have limited time and resources to dedicate to the project. This will help us advance faster with key goals, while also ensuring that those contributors can improve their expertise on various domains of the engine (scripting languages, rendering, optimization, etc.) and be even more efficient in the future.
By investing some of our funds on such contracts, we can therefore build up a stronger team of core developers who can in their turn share their knowledge with new contributors, sustaining the fast paced growth of our engine.
Apart from pure technical work packages, we are also starting to ponder what we could do to improve both the project management and our public relations. Keep in mind that besides just writing code, there are dozens of new daily issues and pull requests, a triage team, a documentation team, dozens of programmers and hundreds of contributors that need to be organized (and new ones popping up all the time). We also intend to forming groups related to education, local events and helping spread the word about Godot. This project is growing more and more demanding every day!
We aren’t sure yet about how to use our funds to sustain those specific needs, but we’ll keep you posted when we do.
And Godot 3.0 is not even out yet.. don’t even want to think what will happen once it comes out! In any case, it will definitely be fun, so thanks for being part of this awesome adventure with us!!
Spread the word, and have fun with Godot!
BTW, kudos to our new website contributor Paul for the awesome FOSS Patreon widget that he developed for our CMS, October, which you can see live in our menu bar :)
-
+
\ No newline at end of file
diff --git a/article/physics-progress-report-1/index.html b/article/physics-progress-report-1/index.html
index 47846fd8de..e462e363df 100644
--- a/article/physics-progress-report-1/index.html
+++ b/article/physics-progress-report-1/index.html
@@ -8,7 +8,7 @@
There’s still more room for further optimization, but Godot Physics performance has greatly improved in the past few months. This affects all aspects of the physics simulation: broadphase (initial quick overlap test to find pairs), narrowphase (detailed collision tests to generate contacts), and impulse solving (moving rigid bodies based on contact points).
Most of these optimization features will make it to the 3.4 release. Some of these optimizations will be able to be disabled using project settings, to preserve backwards compatibility in the best way possible.
The following describes the main optimizations with more details.
Multi-threaded physics simulation
One of the major coming changes for Godot Physics is the possiblity to make use of multiple CPU cores and run physics simulation tasks in parallel.
This allows the narrowphase and impulse solving to be many times faster. Depending on the number of cores, it can make the overall physics simulation 2 to 3 times faster in certain scenarios.
There are still areas in the physics step that cause bottlenecks and will be addressed over time, but this is a first step to building a modern physics engine that handles more objects and more complex collisions.
The broadphase optimization is based on the work already made by the contributor lawnjelly for Godot 3.3. The contribution brings a new dynamic BVH for 3D physics and rendering (see here for more details).
Now the same spatial partioning is also used for the broadphase in Godot Physics 2D. Both 2D and 3D physics will benefit from the performance improvements.
The dynamic BVH will be used by default for 2D in 3.4 the same way 3D physics does in 3.3. An option in project settings will allow switching back to the old hash grid implementation in case you are running into regressions.
Original pull request for the 3D broadphase: GH-44901
Pull request and performance tests for the 2D broadphase: GH-48314
What’s next?
To get ready for an alpha release of Godot 4.0, I’m going to spend some time reviewing and finalizing needed API changes for physics. Then I will focus most of my attention to bug fixing.
When Godot Physics reaches a state where it’s stable and reliable enough to be used as the default engine in 4.0, it will be time to have a look into adding more features and optimizations that have been on the waiting list for a while.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/platform-state-in-csharp-for-godot-4-2/index.html b/article/platform-state-in-csharp-for-godot-4-2/index.html
index 3921a7df41..f2b9134d87 100644
--- a/article/platform-state-in-csharp-for-godot-4-2/index.html
+++ b/article/platform-state-in-csharp-for-godot-4-2/index.html
@@ -18,7 +18,7 @@
Summary
As a summary, the current platform support as of 4.2 is described in the table below:
Platform
Runtimes supported
Minimum required .NET version
Windows
CoreCLR, Mono, NativeAOT
6.0 (CoreCLR), 7.0 (Mono, NativeAOT)
macOS
CoreCLR, Mono, NativeAOT
6.0 (CoreCLR), 7.0 (Mono, NativeAOT)
Linux
CoreCLR, Mono, NativeAOT
6.0 (CoreCLR), 7.0 (Mono, NativeAOT)
Android
Mono
7.0
iOS
NativeAOT
8.0
Web
-
-
What’s next?
As new releases of .NET become available, platform support gets better. NativeAOT support for mobile platforms is still experimental, and there’s currently no support for the web platform. The .NET 9.0 release is set to include some improvements to NativeAOT and we may see initial support for the web platform. We’ll see what makes it into the release in November 2024.
Using NativeAOT is only one of the ways in which we can add support for more platforms to Godot C# projects, using the Mono runtime is another possibility. For a future Godot release, we want to explore bringing back some of the Mono embedding that was available in Godot 3 as an alternative way to support mobile and web platforms.
Please, give Godot 4.2 a try and let us know if you find any bugs.
-
+
\ No newline at end of file
diff --git a/article/please-help-us-reach-our-second-patreon-goal/index.html b/article/please-help-us-reach-our-second-patreon-goal/index.html
index db12ee37af..89e1367bdd 100644
--- a/article/please-help-us-reach-our-second-patreon-goal/index.html
+++ b/article/please-help-us-reach-our-second-patreon-goal/index.html
@@ -5,7 +5,7 @@
Juan Linietsky22 November 2017
This article is from November 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.
Edit: When this post was written we were slightly below our second goal of $4,500 - thanks to a soon-to-be-announced Platinum sponsor, we already reached this second goal and are well on our way to the third one! More infos on our plans for this third goal soon.
Godot and Patreon so far
Our Patreon campaign for the initial goal (hiring me full-time!) has been a huge success, thanks to the strong support of our community. Because of this, I am able to spend a lot more time working on Godot. One of the (not so apparent) benefits of this is the fact that I had more time to work with other contributors, help them around the engine and spend more time helping them with their contributions. This has resulted in a very significant boost in core developers regularly contributing (and the quality of their submissions).
However, while many of the areas being worked on can be approached reasonably by contributors in their free time, several remain where (at this point) more dedicated developer time would be highly beneficial to advance the project faster.
Our next planned hire
If you help us reach our next Patreon goal (and exceed it, as we need a certain margin of safety), we plan to hire karroffel part-time. She’s the brilliant mind behind what is probably one of the best additions in 3.0, GDNative. Thanks to her work, it’s possible to do all sorts of amazing things, such as:
Develop using C++ for all platforms without recompiling the engine.
Bind Godot to all sort of cool external libraries and frameworks (like Steam, SQLite, mobile SDKs, etc.) without recompiling the engine (and which can be simply downloaded from our asset library).
Extend Godot to support VR, custom audio and video codecs, etc. without having to ship that support by default.
Provide add-in support for dozens more of scripting languages, such as real Python, Nim, D, Kotlin, and more!
As a lot of new additions to Godot are based on her work, we need her fully focused on making it work as good as possible.
But this is not all. karroffel will also have a second area of responsibility.
More hands in rendering
While, as mentioned above, we are slowly getting more external developers to help, there is an area where we are having a high amount of difficulty finding contributors. This is rendering.
Almost all the rendering work has been done by me. While rendering is only a small part of Godot (no more than 5% of the engine), it’s one of the most complex areas.
Render engineers are few and one of the most valued positions in the game industry (and yes, I’m tired of turning down juicy job offers for companies all around the world just because I love working on Godot for all of you :P).
The few experienced developers in these areas are working for big companies and under strict contracts, non competes and NDAs, so it’s very difficult for them to lend a hand even if they wanted.
As we failed over time to find this type of contributor, karroffel will work on becoming an additional rendering engineer for the project. I will mentor her as best as I can. Her first task will be to create an OpenGL ES 2.0 renderer for Godot 3.1.
This will make Godot work properly again on older hardware and mobile devices (where 2.1 works great, but 3.0 is slow), because the new renderer is too high-end for them.
Afterwards, karroffel will help improve the existing 2D and 3D renderers, as well as contemplating future platforms (such as Vulkan).
We are counting on you!
Being able to hire karroffel will give us a very immediate boost in productivity, given so many users and developers depend on the work she is doing. Eventually the plan is to do more hires in other areas, so we can have several core developers working full or part-time (which is common in other open source projects of this kind).
-
+
\ No newline at end of file
diff --git a/article/plugins/index.html b/article/plugins/index.html
index 2951418dea..589e80f386 100644
--- a/article/plugins/index.html
+++ b/article/plugins/index.html
@@ -6,7 +6,7 @@
We have begun implementing this in the form of plugins. Support is experimental on GitHub HEAD but there should be enough resources to get to work.
EditorPlugin
Plugins are created in Godot by extending the EditorPlugin class. Feel free to check out the built-in documentation of this class for information on what can be done:
To configure the plugin, both a script inheriting this class and a config file (plugin.cfg) must be located in your project at the following location:
addons/[plugin_name]/plugin.cfg
addons/[plugin_name]/plugin_script.gd
There will be more information about how to create such files, but for now you can check some demos:
To enable plugins, go to the Project Settings window. There will be a new section “Plugins” where you can see the installed plugins and enable/disable them:
Future
This feature is a work in progress. We need your help to make it better! We know there is still a large surface of the editor API not directly accessible, so if you have plugin ideas that can’t be done with the current API let us know and we’ll try to improve it. Please submit a GitHub issue requesting such functions.
Our goal is that, once this API is stable, this wil be a fundamental part of the new asset sharing system present in Godot 2.1.
-
+
\ No newline at end of file
diff --git a/article/preparing-gdc-2018/index.html b/article/preparing-gdc-2018/index.html
index f31af1f97c..0d3fec761c 100644
--- a/article/preparing-gdc-2018/index.html
+++ b/article/preparing-gdc-2018/index.html
@@ -6,7 +6,7 @@
presentation with key points about the project, explain why Godot can be a suitable technology for their needs, and which clear advantages it has over similar, proprietary technologies.
Meeting in person is an excellent way to strengthen bonds, and to allow the developers we meet to later get in touch with us for anything they might need.
We need your help for this to happen
While we can use existing tools such as GDC website, Linkedin, Twitter, etc. to reach developers, nothing beats word of mouth to efficiently reach a critical mass.
If you know devs, producers, decisionmakers, etc. (or you ar such person) in a company that is attending GDC this year, and if you believe they might be interested in hearing more about Godot (and meeting personally with core developers), please ask them to meet with us! If they like the idea, please send them my way and do an e-mail introduction to me (juan AT godotengine DOT org).
Pretty demo material
We also need pretty material to show at GDC. I’ve seen plenty of beautiful games being made with both Godot 2 and Godot 3. If you can create a 15 seconds clip of your game (in 1920x1080 max) and send it to: “contact AT godotengine DOT org” we will be eternally grateful.
Beers
Will you be going to GDC and want to get together for beers? Of course also contact me about that (mail above).
-
+
\ No newline at end of file
diff --git a/article/progress-report-april-may-2017/index.html b/article/progress-report-april-may-2017/index.html
index ff2b4ebc3c..1636acabed 100644
--- a/article/progress-report-april-may-2017/index.html
+++ b/article/progress-report-april-may-2017/index.html
@@ -8,7 +8,7 @@
AR/VR features
For the past few months Bastiaan (Mux213) and Andreas (Hinsbart) have gone through a few prototypes to get their head around implementing AR and VR into Godot - first with a main focus on VR. The early prototypes were based on the OpenVR SDK and they ended up with a working system that rendered properly to a Vive HMD (head monitoring device) and enable tracking the Vive controllers. They’ve since been working on building a new server implementation into Godot that would allow them to make this more moduler and implement different AR and VR SDKs into Godot without needing too many changes in the game being built (if any). This server implementation also attempts to hide as much of the complexity of implementing stereoscopic rendering to the HMDs.
Whenever possible, the interface to the AR or VR SDKs will be integrated into the core AR/VR server to provide a native solution usable out of the box even on mobile devices. But for some of the larger SDKs such as OpenVR Andreas has been hard at work using GDNative to make it possible to deliver the implementations separate from the core product.
Bastiaan and Andreas’ main focus currently remains with the OpenVR SDK allowing them to use Godot with SteamVR - that interface will likely be available in the upcoming alpha build. Once that is up and running, they will start moving on to supporting some of the other SDKs such as the Oculus SDK, and some of the mobile SDKs.
3D freelook navigation mode
Marc (Zylann) has implemented a freelook mode for the 3D editor viewport, which can be triggered by hold the right mouse button. It allows to navigate through the scene with FPS-like controls (WASD) and will be pretty useful to get a better view of your 3D levels. Be sure to test it and give your feedback on the usability when we release the alpha build, so that it can be perfected before the stable release.
Here’s a video showing an early version of the freelook mode (it was since improved further):
UWP support in the 2.1 branch
Back in 2016 George (vnen) implemented support for UWP, the Universal Windows Platform, which allows to deploy to the Windows Store, the Windows Phone and the Xbox One. Shortly after, Juan began implementing the new renderer and the UWP platform code was broken, so this platform did not get much attention up to now (it will of course be fixed for Godot 3.0).
As some users expressed interest in the platform, George backported the UWP code from the master branch to the 2.1 branch (for legacy reasons the platform is still called “WinRT” there) - it still needs some testing and polishing, but it should be possible to deploy games to UWP with the upcoming Godot 2.1.4, or at the latest with 2.1.5. More on this once we are actually confident that it works :)
Script editor enhancements
Paul (Paulb23) is back with script editor enhancement! The so-called “colour guy” who did a lot of work on syntax highlighting in the script editor now brought us optional space-based indentation (Python users will love that!), an edit tool to convert casing, a quick access list to recent scripts and most importantly, a new panel that list member variables and methods of a given script and allows to quickly focus them.
Other noteworthy contributions
There were tons of other changes by many contributors, including a lot of bug fixes and enhancements to the new features of Godot 3.0. Some noteworthy changes include:
iPhone MFI gamepad support and other macOS and iOS improvements (BastiaanOlij)
Networking fixes (Faless)
Various core and rendering changes (RandomShaper)
Various core/math/compression changes (tagcup)
Thirdparty splitting and exhaustive licensing documentation (akien)
All in all, the progress is great and we continue to get impressed by our growing community of both users and contributors!
When will we get Godot 3.0?
Godot 3.0 is coming along pretty nicely, and though its development is taking longer than we initially planned back in Fall 2016, it’s all for the better. The many compatibility changes that we had the opportunity to make over the last 9 months will make Godot 3.0 more consistent and easy to use.
Still, as we often repeat it to newcomers, please continue using Godot 2.1.x until the 3.0 branch is ready - we speak a lot of compatibility changes but the workflow stays very similar, and the vast majority of what you will learn using Godot 2.1.x will be reusable 1:1 in the future branch. It will be the same engine, just better.
Okay, but when do we get the alpha build?
When it’s ready™. There has been a lot of progress on many blocking bugs lately, which we track in a dedicated issue. We expect to be ready for an alpha release in ca. 2 weeks, so stay tuned :)
By then we will consider 3.0 feature complete, and we should stop breaking compatibility every other day. Count likely two months of testing and bugfixing and we should be ready to release the stable version, probably some time in August.
-
+
\ No newline at end of file
diff --git a/article/progress-report-state-of-particles/index.html b/article/progress-report-state-of-particles/index.html
index 15b33b289e..c98558c2e4 100644
--- a/article/progress-report-state-of-particles/index.html
+++ b/article/progress-report-state-of-particles/index.html
@@ -10,7 +10,7 @@
Various particle effects created by community members to help test the rework. Credits go to Thibaud, Calinou, and myself, QbieShay
And what about CPUParticles?
CPU particles have been maintained alongside GPU particles for a long time, but it’s becoming harder and harder to keep feature parity, especially after big changes such as the ones described above. CPU particles were added at the time of the GLES2 renderer in Godot 3, which did not have the capability to support GPU particles. Godot 4 has Vulkan and GLES3 renderers, both of which support GPU particles. This makes it hard to justify maintaining four separate nodes in two different languages (GLSL and C++).
Because of that, we now see the CPUParticles as a lower-end, simpler alternative to GPU particles, instead of a CPU-based, 1-to-1 fallback option. It’s likely that no more features will be added to CPUParticles, though we still welcome PRs that bring them to parity with the GPU ones. We recommend migrating your effects to GPUParticles. To help you with the migration, a converter from CPU particles to a GPU equivalent was added.
From Godot 4.2 onwards, new features for CPUParticles will not be accepted unless they have a counterpart in GPUParticles. However, contributions to bring CPU particles to feature parity are welcome.
The future development
For now, development around particles will remain focused on fixing bugs that may have gotten past the review. While a lot of people tested the PR, there still can be lesser used features and edge cases with issues. Thanks to everyone who helped with the development and testing! It was a huge undertaking and it wouldn’t be possible without every single one of you <3
I will be taking time to assess the current needs of the VFX pipeline in Godot. My goal, first and foremost, is to enable an artist-friendly workflow. This means reducing the number of technicalities and “gotchas” that Godot currently puts in front of technical artists. In no specific order, here are a couple of things currently on my mind: visual shader support for process materials, additional visual shader nodes, and more spawn options for particles. You can check the VFX and Techart wishlist on GitHub for more information on what’s in the works.
Note that there’s currently no contributor specifically hired to work on particles, therefore I cannot promise any timeline for all this planned work. All those things depend on how much time I can dedicate to Godot and how much time other contributors can offer for this area as well.
If you would like to help with the development of these features, please, consider supporting the project financially! More funding allows us to sponsor volunteer contributors and better respond to technical demands of project users.
-
+
\ No newline at end of file
diff --git a/article/progress-report-web-export-in-4-3/index.html b/article/progress-report-web-export-in-4-3/index.html
index a290222428..476699f7e5 100644
--- a/article/progress-report-web-export-in-4-3/index.html
+++ b/article/progress-report-web-export-in-4-3/index.html
@@ -10,7 +10,7 @@
Godot Engine developers chat.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community.
If you’d like to support the project financially and help us secure our future hires, you can do so using the Godot Development Fund platform managed by the Godot Foundation. There are also several alternative ways to donate which you may find more suitable.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-3-2-3-rc-3/index.html b/article/release-candidate-3-2-3-rc-3/index.html
index 57fa1f4810..a5bed8fe02 100644
--- a/article/release-candidate-3-2-3-rc-3/index.html
+++ b/article/release-candidate-3-2-3-rc-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde31 July 2020
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.
Here’s a third Release Candidate for the upcoming Godot 3.2.3 release. Please help us test it to ensure that no new regressions have slipped through code review and testing.
Note: The previous 3.2.3 RC 2 was actually not built from the intended commit, and reflected the same changeset as RC 1. Tests made on RC 2 are still valid and useful, but did not help validate the very latest commits, hence this third release candidate. The changes new in this build are thus the ones made between RC 1 and RC 3.
If all goes well, the 3.2.3-stable release should happen later this week when I’m back from holidays :)
Changes
Android: Fix Return key events in LineEdit & TextEdit on Android (GH-40469).
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).
GLES3: Fix OpenGL error when generating radiance (GH-40558).
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).
HTML5: Implement HTML5 cancel/ok button swap on Windows (GH-40755).
IK: Fixed SkeletonIK not working with scaled skeletons (GH-39803).
LineEdit: Add option to disable virtual keyboard for LineEdit (GH-40588).
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 RC 3. 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 RC 3).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-3-2-rc-4/index.html b/article/release-candidate-3-2-rc-4/index.html
index 03ebc00ba1..9159c402fc 100644
--- a/article/release-candidate-3-2-rc-4/index.html
+++ b/article/release-candidate-3-2-rc-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde27 January 2020
We’re now very close to the final 3.2 stable release! To validate the last changes done over the weekend before actually releasing the new version, he’s a (likely) final Release Candidate. If no new critical regression is found with this build, 3.2 stable should be more or less the same.
Over 350 issues have been fixed in January alone, bringing the 3.2 version to a very good standard.
Notable changes since RC 3:
Editor: Fixed Inspector update when a node is renamed, which made shader editor disappear on errors (GH-35526).
GLES2: Fix Softbody always spawns from world center (GH-35495).
GLES3: Add project setting for max irradiance size (GH-35561).
Mono: Fix C# preprocessor infinite loop and incorrect parsing of #if! (GH-35524).
Mono: Fix _update_exports possible crash with Reference types (GH-35527).
PathFollow: Fix regression with looping starting at non-0 position (GH-35515).
Thirdparty: mbedtls: Update to upstream version 2.16.4 (security bugfix) (GH-35596).
Documentation and translation updates.
For those following our dev snapshots closely, 63 commits have been merged since 3.2 RC 3 last Friday. This release is built from commit 9daaa12.
Disclaimer
IMPORTANT: This is a release candidate build, which means that it is not suitable yet for use in production, nor for press reviews of what Godot 3.2 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 not finalized yet, but you can refer to the detailed changelog now included in the master branch.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this release.
The latest branch of the documentation includes details on many of the new 3.2 features and API.
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 build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.6.0.161 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Bug reports
We’re now down to a handful of issues which are still short-listed for 3.2, but unlikely to be fixed in time for the release. We’ll keep them on the priority list for an upcoming 3.2.1 maintenance release in a few weeks.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 RC 4. 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.1.x no longer works in 3.2).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-3-5-rc-2/index.html b/article/release-candidate-3-5-rc-2/index.html
index cf8ce94164..aee6bbb6e4 100644
--- a/article/release-candidate-3-5-rc-2/index.html
+++ b/article/release-candidate-3-5-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde24 May 2022
The upcoming Godot 3.5 is now considered feature complete, and has received a lot of bugfixes and improvements over the past weeks thanks to all the testers and developers who reported and fixed issues. It’s now time to move to the Release Candidate stage so that we can release 3.5-stable for all users.
At this stage we need people to test this release (and potential follow-up RCs) on as many codebases as possible, to make sure that we catch non-obvious regressions that might have gone unnoticed until now. If you run into any issue, please make sure to report it on GitHub so that we can know about it and fix it!
This RC 2 includes a few important changes that will require particular testing - the RC stage is typically too late to do such changes, but they were either self-contained or critical enough for exceptions to be made:
Windows binaries are now built on Fedora 36 instead of Fedora 35, which seems to fix a GCC regression that would trigger crashes (GH-51070, GH-61176).
A long-standing Bullet regression has finally been fixed (GH-56801), solving issues with KinematicBody collisions on edges (e.g. seen as small bumps between tiles on a GridMap). The fix seems relatively safe but this will require heavy testing to make sure it doesn’t regress - if you have 3D games using Bullet physics, please try this RC 2 and report any issue.
New Label3D (GH-61276) and TextMesh (GH-61281) nodes have been backported from Godot 4.0. They’re self-contained so there’s little risk of regression, but please test them thoroughly anyway.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020! And then a lot of old and new navigation issues have been fixed by smix8 and Pawel Lampe (Scony).
The new NavigationServer adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime. The whole API is now a lot more flexible than it used to be.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in the updated docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New Label3D and TextMesh backported from Godot 4.0 (GH-61276, GH-61281)
Long awaited, Godot now provides a Label3D node out of the box to display text in 3D scenes. And for more advanced use cases, there is now also TextMesh to generate 3D meshes from font glyphs, so you can add Word Art to your scenes ;)
Both features were implemented by our text rendering expert bruvzg in the master branch for Godot 4.0, and backported to 3.5. They were merged late in the release process (3.5 RC 2) but should be quite self-contained and thus not impact the stability of other features. Be sure to test them and report any bug or inconvenience with the implementation.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5.
And more!
3D: Add Label3D node and Sprite3D material render priority (GH-61276).
3D: Add TextMesh and expose dynamic font vector outlines (GH-61281).
Android: Initial port of the Godot editor (GH-57747).
Android: Fix flickering issues with low processor mode (GH-59606).
Fixes a lot of issues with KinematicBody collisions at the intersection between meshes when using Bullet. This was merged fairly late (3.5 RC 2), please make sure to test it.
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.179 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release candidate. 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.4.x no longer works in this 3.5 RC).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-1-1-rc-1/index.html b/article/release-candidate-godot-3-1-1-rc-1/index.html
index 8f91aef89a..c415b109a6 100644
--- a/article/release-candidate-godot-3-1-1-rc-1/index.html
+++ b/article/release-candidate-godot-3-1-1-rc-1/index.html
@@ -5,7 +5,7 @@
HP van Braam23 April 2019
Welcome to the first release candidate of what will shortly become Godot 3.1.1-stable. After the release of 3.1-stable about a month and a half ago we didn’t sit on our laurels. No sirre, not at all! Many bugs were fixed, improvements made, and documentation was written.
With the -stable releases we offer you the backwards compatible changes and bugfixes. However in this release we had to break some compatibility with networking due to a security issue. See below for details.
Please test this release with your existing projects and as usual: Any breakage of existing projects after upgrading is a bug, unless noted in the Known incompatibilities section of this blog post. If we somehow missed something please report a bug.
I invite you, dear reader, to take a moment to close your eyes and silently thank all of the awesome people who helped make this release a reality. If you too would like to be thanked by a multitude of Internet people join us in fixing bugs, writing documentation, and/or reporting bugs!
Changelog
A security issue was reported and fixed. This change does add some API to Godot in case you need to be able to deserialize Object data. Please see This PR for details. If you do not use networking in your project you should not be affected. However GDNative ABI was changed so any native plugins need to be rebuilt for 3.1.1.
New menu options for the Sprite editor: “Convert to Mesh2D”, “Convert to Polygon2D”, “Create CollisionPolygon2D Sibling” and “Create LightOccluder2D Sibling”.
And many more small quality of life improvements and bugfixes. See the full changelog below for details. The 3.1-stable release blog post will also have some more details about changes made.
Below we describe the known incompatibilities with previous releases in this cycle.
Known incompatibilities with Godot 3.1
Due to a security fix the GDNative ABI has changed. If you use GDNative modules in your project they will need to be rebuilt from source.
Godot no longer automatically decodes Objects when using high level multiplayer. If you do want your client or server to do this it is now necessary to explicitly allow it. See this PR for details.
Previously on Android OS.get_unique_id() would return the static value for Secure.ANDROID_ID. This was a bug and now an actually unique ID is returned. If you were using the unique ID for encryption purposes you must now also check the original static value or your users may lose access to any encrypted (save) data.
Known bugs in Godot 3.1.1 RC 1
Documentation hyperlinks not working properly [GH-27983]
Button layout changed compared to 3.1.0-stable [GH-28335]
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-1-2-rc-1/index.html b/article/release-candidate-godot-3-1-2-rc-1/index.html
index 230c35877d..5b6aae655f 100644
--- a/article/release-candidate-godot-3-1-2-rc-1/index.html
+++ b/article/release-candidate-godot-3-1-2-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde13 November 2019
It’s been over 6 months since Godot 3.1.1-stable, so the upcoming 3.1.2 release is both long overdue and accordingly packed with important bug fixes and enhancements.
We intended to have 3.1.x releases more regularly (every other month or so), but our release manager for the stable branches, HP, has been quite busy the past few months and thus less available for Godot contributions. So now that the 3.2 pipeline is well oiled (see 3.2 beta 1), I’m going back to the stable branches to provide new releases. I also plan to release 3.0.7 in coming weeks for those of you who are still using the 3.0 branch for specific projects.
As we cherry-picked close to 400 commits to the 3.1 branch since 3.1.1-stable, extensive testing is necessary to ensure that no regression crept in under disguise of a bugfix. This is why we publish this release candidate for 3.1.2 to gather test reports from the community.
Release branches
Before checking the changelog for this release, a short clarification on the release branches that we use for those not familiar with Godot’s versioning.
Our next stable branch, developing the Git master branch, is Godot 3.2. This version is currently in beta and should become stable within a few weeks. Most of the devblogs published since the 3.1 release cover features which have been merged in the master branch and will be included in Godot 3.2.
In parallel, we also work in the vulkan branch on version 4.0 which will come sometime next year with Vulkan support. We increase the “major” version number (3 to 4) as there will be some compatibility breakage.
Our current maintained stable branches are 3.1 (latest release 3.1.1), 3.0 (latest 3.0.6) and 2.1 (latest 2.1.6). Each of those branches is tracked separately in a Git branch, where we cherry-pick relevant commits from the master branch for future maintenance releases. The upcoming 3.1.2 release is thus going to be a maintenance release for the 3.1 branch, with the same feature set that 3.1 already had, but less bugs and some usability and documentation enhancements.
So if you’re looking for the latest and greatest, check 3.2 beta 1, but if you have game in production using Godot 3.1.1, you might be interested in upgrading to 3.1.2 and helping us test this release candidate.
Changes
As mentioned, this release includes close to 400 new commits, with many bug fixes, usability enhancements and documentation improvements. You can read the complete changelog for details. Below are a few selected highlights:
Animation: Fixes for onion skinning support of Skeleton2D (GH-29109).
And many more bug fixes and usability enhancements all around the engine!
You can also see the full changelog since 3.1.1-stable on GitHub, split in two parts as the web view is limited to 250 commits: part 1 and part 2. This release candidate is built from commit bfd993b.
Note: For more details on specific areas, you can use git log on a local clone of the Godot repository. Use the syntax git log 3.1.1-stable..3.1 <path> to get the list of changes since 3.1.1-stable on a given path. For example git log 3.1.1-stable..3.1 scene/gui/ would list all changes impacting the Control nodes.
Downloads
As always, you will find the binaries for your platform on our mirrors:
Please test this version thoroughly on your existing 3.1.1 projects, and make sure to report any regression that you may notice. 400 commits is a lot, and the 3.1 branch is not tested as thoroughly as the master branch outside releases such as this one, so there is a lot of surface for potential regressions (yet, there shouldn’t be any game breaking issue, so it’s safe to test it on existing projects and revert back to 3.1.1 if there’s any problem).
Known incompatibilities
Below we describe the known incompatibilities with previous releases in this cycle.
Known incompatibilities with Godot 3.1
Due to a security fix the GDNative ABI has changed. If you use GDNative modules in your project they will need to be rebuilt from source.
Godot no longer automatically decodes Objects when using high level multiplayer. If you do want your client or server to do this it is now necessary to explicitly allow it. See this PR for details.
Previously on Android OS.get_unique_id() would return the static value for Secure.ANDROID_ID. This was a bug and now an actually unique ID is returned. If you were using the unique ID for encryption purposes you must now also check the original static value or your users may lose access to any encrypted (save) data.
Known incompatibilities with Godot 3.1.1
CPUParticles2D: The “Lifetime” draw order was reversed. GH-29558 fixes it, but if you relied on the previous wrong order, you would have to work it around.
RigidBody(2D): The can_sleep variable was not properly initialized (regression in 3.1). GH-32767 fixes it, but it might impact your project if you relied on the previous incorrect initialization.
GLES2: Some of the many bug fixes listed above may lead to changes in the visuals of your project (especially around lighting/shadows). Be sure to report anything that you would consider a regression.
macOS: Key mappings for KEY_BRACELEFT and KEY_BRACERIGHT were inverted. GH-28185 fixes this bug, so check your code in case you relied on these values matching the wrong keys.
If you spot any other difference in your projects, please notify us so that we can list it here (even if it’s a good change/bugfix, it’s worth documenting it so that all users are aware).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-1-rc-1/index.html b/article/release-candidate-godot-3-1-rc-1/index.html
index 3061aecebb..ba231f378e 100644
--- a/article/release-candidate-godot-3-1-rc-1/index.html
+++ b/article/release-candidate-godot-3-1-rc-1/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog.
The documentation’s latest branch include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page 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 MSbuild installed to use the Mono build.
Important: Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 RC. 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, and can eventually be included in 3.1.x patch releases.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-1-rc-2/index.html b/article/release-candidate-godot-3-1-rc-2/index.html
index b0eac7814a..7031b9bec7 100644
--- a/article/release-candidate-godot-3-1-rc-2/index.html
+++ b/article/release-candidate-godot-3-1-rc-2/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog.
The documentation’s latest branch include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page 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 MSbuild installed to use the Mono build.
Important: Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 RC. 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, and can eventually be included in 3.1.x patch releases.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-1-rc-3/index.html b/article/release-candidate-godot-3-1-rc-3/index.html
index c8e68711cd..d0e3fb4a40 100644
--- a/article/release-candidate-godot-3-1-rc-3/index.html
+++ b/article/release-candidate-godot-3-1-rc-3/index.html
@@ -6,7 +6,7 @@
In the meantime, you can read the preliminary changelog.
The documentation’s latest branch include details on many of the new 3.1 features.
Downloads
The download links are not featured on the Download page 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 MSbuild installed to use the Mono build.
Important: Windows binaries are now signed by Prehensile Tales B.V., the company of our release manager HP van Braam. You can trust this signature and accept any warning that Windows may issue due to the novelty of this certificate. As more users accept it, the certificate will be recognized as trusted for future releases.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.1 RC. 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, and can eventually be included in 3.1.x patch releases.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-1-rc-1/index.html b/article/release-candidate-godot-3-2-1-rc-1/index.html
index bf095b07fb..b5266b6da1 100644
--- a/article/release-candidate-godot-3-2-1-rc-1/index.html
+++ b/article/release-candidate-godot-3-2-1-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde22 February 2020
Godot 3.2 was released a few weeks ago as a major update to our free and open source engine, bringing close to one year of development to our users.
Since then, work has begun in Godot’s master branch to merge the preliminary Vulkan support and start the rework of the engine internals that we had planned over the past two years. All this work is for our future Godot 4.0 and will not be included in maintenance 3.2.x releases to preserve compatibility and stability.
But the 3.2 branch is not forgotten, and many fixes to 3.2 issues have been merged in the master branch and cherry-picked (backported) to the 3.2 branch for future maintenance releases. This includes some fixes to regressions (things that worked in 3.1.x but broke in 3.2) which should help everyone safely port their projects from 3.1 to 3.2.
118 commits have been cherry-picked to the 3.2 branch, and it’s now time for a Release Candidate of what could become Godot 3.2.1 as our first maintenance release.
Highlights
There are no huge changes planned in this release, but mostly a focus on fixing some blocking regressions and important bugs, such as:
Android: Fix double tap pressed event regression (GH-35701).
Some new/improved features are planned further down the road for the 3.2.x releases, but the focus for 3.2.1 is on stability and fixing regressions.
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 build (C# support + all the above). You need to have MSBuild and .NET Framework 4.7 installed to use the Mono build. Relevant parts of Mono 6.6.0.161 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.2.1 RC 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.1.x or 3.2 no longer works in 3.2.1 RC 1).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-1-rc-2/index.html b/article/release-candidate-godot-3-2-1-rc-2/index.html
index 45d838a3ff..723d48a330 100644
--- a/article/release-candidate-godot-3-2-1-rc-2/index.html
+++ b/article/release-candidate-godot-3-2-1-rc-2/index.html
@@ -6,7 +6,7 @@
I planned to have 3.2.1-stable already released by now, but I was sidetracked by the refactoring work which is happening in the master branch for Godot 4.0 :-)
Since RC 1, a couple regressions have been fixed, and a few additional bug fixes, documentation updates and usability enhancements have been included. We now publish Godot 3.2.1 RC 2 to validate those additional changes. 53 new commits have been cherry-picked to the 3.2 branch, for a total of 171 commits since the 3.2-stable release.
Highlights
There are no huge changes planned in this release, but mostly a focus on fixing some blocking regressions and important bugs, such as:
Android: Fix double tap pressed event regression (GH-35701).
Some new/improved features are planned further down the road for the 3.2.x releases, but the focus for 3.2.1 is on stability and fixing regressions.
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 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.161 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.2.1 RC 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.1.x or 3.2 no longer works in 3.2.1 RC 2).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-2-rc-1/index.html b/article/release-candidate-godot-3-2-2-rc-1/index.html
index 934177cd64..c459513abe 100644
--- a/article/release-candidate-godot-3-2-2-rc-1/index.html
+++ b/article/release-candidate-godot-3-2-2-rc-1/index.html
@@ -9,7 +9,7 @@
In the upcoming Godot 4.0, this bug was fixed with a more comprehensive approach which prevents dangling Variant pointers in both release and debug builds.
Other changes
Apart from those major features, there are close to 700 cherry-picks (beta 1, beta 2, beta 3, beta 4, RC 1) for bug fixes and enhancements which have been merged since Godot 3.2.1. Here are some highlights:
2D: Expose the cell_size affecting VisibilityNotifier2D precision (GH-38286).
2D: Add MODULATE builtin to canvas item shaders (GH-38432).
Android: Reimplementation of the GodotPayment plugin using the Google Play Billing library (GH-39034).
Note: Breaks compatibility slightly, but the Android plugin re-architecture already did so. See GH-39034 for usage instructions, docs will be updated before the 3.2.2 release.
AStar: Implements estimate_cost/compute_cost for AStar2D (GH-37039).
AStar: Make get_closest_point() deterministic for equidistant points (GH-39409).
Audio: Fix volume interpolation in positional audio nodes (GH-37279).
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.2 RC 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 RC 1).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-2-rc-2/index.html b/article/release-candidate-godot-3-2-2-rc-2/index.html
index 3e6f38e095..bc36c8d5a6 100644
--- a/article/release-candidate-godot-3-2-2-rc-2/index.html
+++ b/article/release-candidate-godot-3-2-2-rc-2/index.html
@@ -6,7 +6,7 @@
In the upcoming Godot 4.0, this bug was fixed with a more comprehensive approach which prevents dangling Variant pointers in both release and debug builds.
Other changes
Apart from those major features, there are over 750 cherry-picks (beta 1, beta 2, beta 3, beta 4, RC 1, RC 2) for bug fixes and enhancements which have been merged since Godot 3.2.1. Here are some highlights:
2D: Expose the cell_size affecting VisibilityNotifier2D precision (GH-38286).
2D: Add MODULATE builtin to canvas item shaders (GH-38432).
Android: Reimplementation of the GodotPayment plugin using the Google Play Billing library (GH-39034).
Note: Breaks compatibility slightly, but the Android plugin re-architecture already did so. See GH-39034 for usage instructions, docs will be updated before the 3.2.2 release.
AStar: Implements estimate_cost/compute_cost for AStar2D (GH-37039).
AStar: Make get_closest_point() deterministic for equidistant points (GH-39409).
Audio: Fix volume interpolation in positional audio nodes (GH-37279).
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.2 RC 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.1 no longer works in 3.2.2 RC 2).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-2-rc-3/index.html b/article/release-candidate-godot-3-2-2-rc-3/index.html
index 6547185b7f..274fbe085f 100644
--- a/article/release-candidate-godot-3-2-2-rc-3/index.html
+++ b/article/release-candidate-godot-3-2-2-rc-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde22 June 2020
The upcoming Godot 3.2.2 is turning out to be quite feature-packed and we’ve been taking the time to iterate with four beta snapshots and two release candidates (RC).
This new RC 3 build fixes a couple recent regressions. It’s now considered release-ready, so unless new regressions are reported in coming days, we plan to release 3.2.2-stable in a day or two.
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.
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.
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 in this build. Our main batching architecture lawnjelly has already done a lot of groundwork to implement the batching in GLES3 too, but we will start evaluating these changes for the 3.2.3 release.
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 (note that settings used until 3.2.2 beta 4 have been renamed in preparation for the addition of GLES3 batching, see this Pull Request). 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 change). 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.
Other changes
Apart from those major features, there are over 750 cherry-picks (beta 1, beta 2, beta 3, beta 4, RC 1, RC 2, RC 3) for bug fixes and enhancements which have been merged since Godot 3.2.1. Here are some highlights:
2D: Expose the cell_size affecting VisibilityNotifier2D precision (GH-38286).
2D: Add MODULATE builtin to canvas item shaders (GH-38432).
Android: The GodotPayments plugin was moved to an external first-party plugin using the Google Play Billing library (GH-39034).
Note: Breaks compatibility for users of this plugin, but it’s easy to adapt your code. See the migration guide in the documentation, and the new repository for the godot-google-play-billing plugin.
AStar: Implements estimate_cost/compute_cost for AStar2D (GH-37039).
AStar: Make get_closest_point() deterministic for equidistant points (GH-39409).
Audio: Fix volume interpolation in positional audio nodes (GH-37279).
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.2 RC 3. 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 RC 3).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-2-rc-4/index.html b/article/release-candidate-godot-3-2-2-rc-4/index.html
index 494bfed669..f6221432d9 100644
--- a/article/release-candidate-godot-3-2-2-rc-4/index.html
+++ b/article/release-candidate-godot-3-2-2-rc-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde25 June 2020
Yet another release candidate for Godot 3.2.2, including a few new bugfixes that warrant some testing before we can confidently tag it as 3.2.2-stable.
I won’t list all the changes in 3.2.2 again, so please refer to the 3.2.2 RC 3 blog post for details.
If all goes well, I intend to release 3.2.2-stable in a day or two (Famous Last Words™).
Downloads
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.2 RC 4. 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 RC 4).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-3-rc-1/index.html b/article/release-candidate-godot-3-2-3-rc-1/index.html
index 148d597f17..7ce0ce1cf7 100644
--- a/article/release-candidate-godot-3-2-3-rc-1/index.html
+++ b/article/release-candidate-godot-3-2-3-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde24 July 2020
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.
Here’s a Release Candidate for the upcoming Godot 3.2.3 release. Please help us test it to ensure that no new regressions have slipped through code review and testing.
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).
GLES3: Fix OpenGL error when generating radiance (GH-40558).
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).
LineEdit: Add option to disable virtual keyboard for LineEdit (GH-40588).
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 RC 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 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-3-rc-2/index.html b/article/release-candidate-godot-3-2-3-rc-2/index.html
index ae95f7e69e..0470b76070 100644
--- a/article/release-candidate-godot-3-2-3-rc-2/index.html
+++ b/article/release-candidate-godot-3-2-3-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 July 2020
A new 3.2.3 RC 3 will be released to validate the above commits and a few additional ones.
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.
Here’s a second Release Candidate for the upcoming Godot 3.2.3 release. Please help us test it to ensure that no new regressions have slipped through code review and testing.
If all goes well, the 3.2.3-stable release should happen later this week.
Changes
Android: Fix Return key events in LineEdit & TextEdit on Android (GH-40469).
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).
GLES3: Fix OpenGL error when generating radiance (GH-40558).
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).
HTML5: Implement HTML5 cancel/ok button swap on Windows (GH-40755).
IK: Fixed SkeletonIK not working with scaled skeletons (GH-39803).
LineEdit: Add option to disable virtual keyboard for LineEdit (GH-40588).
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 RC 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.1 or 3.2.2 no longer works in 3.2.3 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-3-rc-4/index.html b/article/release-candidate-godot-3-2-3-rc-4/index.html
index a607ccd8b5..134d050921 100644
--- a/article/release-candidate-godot-3-2-3-rc-4/index.html
+++ b/article/release-candidate-godot-3-2-3-rc-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde21 August 2020
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.
Here’s a fourth Release Candidate for the upcoming Godot 3.2.3 release. Please help us test it to ensure that no new regressions have slipped through code review and testing.
Changes
Android: Fix Return key events in LineEdit & TextEdit on Android (GH-40469).
Android: Add option to enable high precision float in GLES2 (GH-33646).
C#: New csproj style with backport of Godot.NET.Sdk (GH-41408).
Note: This change breaks forward compatibility, C# projects opened in 3.2.3 will no longer work with 3.2.2 or earlier. Backup your project files before upgrading.
GDScript: Auto completion enhanced for extends and class level identifier (GH-41318).
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).
GLES3: Fix OpenGL error when generating radiance (GH-40558).
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).
HTML5: Implement HTML5 cancel/ok button swap on Windows (GH-40755).
IK: Fixed SkeletonIK not working with scaled skeletons (GH-39803).
LineEdit: Add option to disable virtual keyboard for LineEdit (GH-40588).
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 RC 4. 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 RC 4).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-3-rc-5/index.html b/article/release-candidate-godot-3-2-3-rc-5/index.html
index b4c676a06b..ebdc5dfb85 100644
--- a/article/release-candidate-godot-3-2-3-rc-5/index.html
+++ b/article/release-candidate-godot-3-2-3-rc-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde2 September 2020
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.
Here’s a fifth Release Candidate for the upcoming Godot 3.2.3 release. Please help us test it to ensure that no new regressions have slipped through code review and testing.
The main differences with the previous RC 4 are C# fixes following the backport of the csproj and Godot.NET.Sdk changes (including fixing a potential editor crash when exporting projects with RC 4).
Changes
Android: Fix Return key events in LineEdit & TextEdit on Android (GH-40469).
Android: Add option to enable high precision float in GLES2 (GH-33646).
C#: New csproj style with backport of Godot.NET.Sdk (GH-41408).
Note: This change breaks forward compatibility, C# projects opened in 3.2.3 will no longer work with 3.2.2 or earlier. Backup your project files before upgrading.
GDScript: Auto completion enhanced for extends and class level identifier (GH-41318).
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).
GLES3: Fix OpenGL error when generating radiance (GH-40558).
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).
HTML5: Implement HTML5 cancel/ok button swap on Windows (GH-40755).
IK: Fixed SkeletonIK not working with scaled skeletons (GH-39803).
iOS: Fix possible crash on exit when leaking translation remappings (GH-41635).
LineEdit: Add option to disable virtual keyboard for LineEdit (GH-40588).
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 RC 5. 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 RC 5).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-3-rc-6/index.html b/article/release-candidate-godot-3-2-3-rc-6/index.html
index eaf78a2cc8..7efecd186d 100644
--- a/article/release-candidate-godot-3-2-3-rc-6/index.html
+++ b/article/release-candidate-godot-3-2-3-rc-6/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde9 September 2020
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.
Here’s a sixth Release Candidate for the upcoming Godot 3.2.3 release. Please help us test it to ensure that no new regressions have slipped through code review and testing.
The main differences with the previous RC 5 are C# fixes following the backport of the csproj and Godot.NET.Sdk changes.
3.2.3 is taking its time to reach stable, but we want to ensure that it’s the best release for use in production by all Godot users.
Changes
Android: Fix Return key events in LineEdit & TextEdit on Android (GH-40469).
Android: Add option to enable high precision float in GLES2 (GH-33646).
C#: New csproj style with backport of Godot.NET.Sdk (GH-41408).
Note: This change breaks forward compatibility, C# projects opened in 3.2.3 will no longer work with 3.2.2 or earlier. Backup your project files before upgrading.
GDScript: Auto completion enhanced for extends and class level identifier (GH-41318).
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).
GLES3: Fix OpenGL error when generating radiance (GH-40558).
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).
HTML5: Implement HTML5 cancel/ok button swap on Windows (GH-40755).
IK: Fixed SkeletonIK not working with scaled skeletons (GH-39803).
iOS: Fix possible crash on exit when leaking translation remappings (GH-41635).
LineEdit: Add option to disable virtual keyboard for LineEdit (GH-40588).
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].
Networking: Fix UDPServer and DTLSServer on Windows compatibility (GH-40374).
Particles: Fix 2D Particle velocity with directed emission mask (GH-41145).
PathFollow3D: Fix repeated updates of PathFollow3D Transform (GH-40197).
Physics: Better damping implementation for Bullet rigid bodies (GH-39084).
Note: This makes the behavior of the GodotPhysics and Bullet backends consistent, and more user-friendly with Bullet. If you’re using damping with the Bullet backend, you may need to adjust some properties to restore the behavior from 3.2.2 or earlier (see GH-42051).
Physics: Trigger broadphase update when changing collision layer/mask (GH-39895).
Physics: Fix laxist collision detection on one way shapes (GH-39880).
Physics: Properly pass safe margin on initialization (fixes jitter in GodotPhysics backend) (GH-40377).
Project Settings: Enable file logging by default on desktops to help with troubleshooting (GH-40121).
Project Settings: Fix overriding compression related settings (GH-40340).
Rendering: Fixed images in black margins (GH-37475).
Rendering: Allow nearest neighbor lookup when using mipmaps (GH-40523).
Rendering: Properly calculate Polygon2D AABB with skeleton (GH-40869).
RichTextLabel: Fix RichTextLabel fill alignment regression (GH-40081) [regression fix].
RichTextLabel: Fix center alignment bug (GH-40892).
Script editor: Don’t open dominant script in external editor (GH-40735).
Shaders: Fix specular render_mode for Visual Shaders (GH-41536).
Sprite3D: Use mesh instead of immediate for drawing Sprite3D (GH-39867).
SkeletonIK: Fix calling reload_goal() when starting IK with start(true) (GH-40768).
TileSet: Fix potential crash when editing polygons (GH-40560).
Tree: Fix crash when hovering columns after removing a column (GH-41876) [regression fix].
Windows: DirectInput: Use correct joypad ID (GH-40927).
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 RC 6. 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 RC 6).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-4-rc-1/index.html b/article/release-candidate-godot-3-2-4-rc-1/index.html
index ade16ca397..52d4b80453 100644
--- a/article/release-candidate-godot-3-2-4-rc-1/index.html
+++ b/article/release-candidate-godot-3-2-4-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 January 2021
After 4 months of development it’s time to aim for the 3.2.4 stable release to bring the numerous new features and even more important bug fixes to all Godot users.
So here’s a first Release Candidate to get broader testing of everything that has been iterated upon in the past 6 beta builds.
New dynamic BVH for rendering and the GodotPhysics backends.
If you experience a regression in either physics or rendering, you can try these Project Settings to revert back to the previous Octree-based approach and possibly fix the issue. In either case, be sure to report the problem on GitHub.
HTML5: Use internal implementation of the Gamepad API (GH-45078).
Input: Add mouse event pass-through support for the game window (GH-40205).
Input: Add support for buttons and D-pads mapped to half axes (GH-42800).
Input: Add driving joystick type to windows joystick handling (GH-44082).
iOS: Add support for iOS plugins, with a similar interface to Android plugins (GH-41340).
You can read the updated documentation on godot-docs#4213, until it’s merged and included in the 3.2 documentation.
Previously built-in iOS features like ARKit, camera support, GameCenter, ICloud and InAppStore modules are now first-party plugins which can be installed from godot-ios-plugins. The relevant documentation will soon be updated to be clarify their usage with 3.2.4-stable.
iOS: Fix multiple issues with PVRTC import, disable ETC1 (GH-38076).
iOS: Add touch delay value to project settings (GH-42457).
iOS: Fixes to keyboard input, including better IME support (GH-43560).
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.114 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 RC 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 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-4-rc-2/index.html b/article/release-candidate-godot-3-2-4-rc-2/index.html
index 04d6b3de2b..41e43e5124 100644
--- a/article/release-candidate-godot-3-2-4-rc-2/index.html
+++ b/article/release-candidate-godot-3-2-4-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde12 February 2021
Godot 3.2.4 is shaping up nicely, and a number of issues have been fixed since the first Release Candidate two weeks ago. So it’s now time for a RC 2 build to give it another round of testing before the stable release!
And rejoice macOS users, this release is the first to have the Godot editor binary signed and notarized. Thanks to Prehensile Tales for signing it on behalf of the Godot contributors. (Note: Only the “standard” build is signed for now.)
New dynamic BVH for rendering and the GodotPhysics backends.
If you experience a regression in either physics or rendering, you can try these Project Settings to revert back to the previous Octree-based approach and possibly fix the issue. In either case, be sure to report the problem on GitHub.
Android: Update logic to sign prebuilt APKs with apksigner instead of jarsigner, as required for Android API 30 (GH-44645).
Audio: Add MP3 loading and playback support (GH-43007).
Buildsystem: Add production=yes option to set optimal options for production builds (GH-45679).
Users making custom builds should use this option which is equivalent to use_lto=yes debug_symbols=no use_static_cpp=yes.
Note for Linux builds: use_static_cpp=yes and udev=yes are now the default values, so you need libudev and libstdc++-static development packages to build in optimal conditions.
HTML5: Use internal implementation of the Gamepad API (GH-45078).
HTML5: Tons of fixes all around to better support the Web editor :)
Input: Add mouse event pass-through support for the game window (GH-40205).
Input: Add support for buttons and D-pads mapped to half axes (GH-42800).
Input: Add driving joystick type to windows joystick handling (GH-44082).
Input: Add support for new SDL gamecontroller keywords (used e.g. by PS5 controller) (GH-45798).
iOS: Add support for iOS plugins, with a similar interface to Android plugins (GH-41340).
You can read the updated documentation on godot-docs#4213, until it’s merged and included in the 3.2 documentation.
Previously built-in iOS features like ARKit, camera support, GameCenter, ICloud and InAppStore modules are now first-party plugins which can be installed from godot-ios-plugins. The relevant documentation will soon be updated to be clarify their usage with 3.2.4-stable.
iOS: Fix multiple issues with PVRTC import, disable ETC1 (GH-38076).
iOS: Add touch delay value to project settings (GH-42457).
iOS: Fixes to keyboard input, including better IME support (GH-43560).
This breaks compat but is not enabled by default for existing projects (see project setting physics/common/enable_pause_aware_picking). It will be enabled by default for new projects created with 3.2.4.
Rendering: Add fast approximate antialiasing (FXAA) to Viewport (GH-42006).
Rendering: Disable lights for objects with baked lighting (GH-41629).
Rendering: Add option for snapping 2D transforms to whole coordinates, for pixel art motion (GH-43554).
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.114 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 RC 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 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-4-rc-3/index.html b/article/release-candidate-godot-3-2-4-rc-3/index.html
index 68f1cbc436..dae3880201 100644
--- a/article/release-candidate-godot-3-2-4-rc-3/index.html
+++ b/article/release-candidate-godot-3-2-4-rc-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde23 February 2021
Godot 3.2.4 is shaping up nicely, and a number of issues have been fixed since the second Release Candidate. A few late features have also been included because they were too good to keep waiting (such as improved Inspector subresource editing and node copy-paste support). So it’s now time for a RC 3 build to give it another round of testing before the stable release!
As a reminder, since 3.2.4 RC 2 we now have signed and notarized macOS binaries. (Note: Only the “standard” build is signed for now.)
New dynamic BVH for rendering and the GodotPhysics backends.
If you experience a regression in either physics or rendering, you can try these Project Settings to revert back to the previous Octree-based approach and possibly fix the issue. In either case, be sure to report the problem on GitHub.
Android: Update logic to sign prebuilt APKs with apksigner instead of jarsigner, as required for Android API 30 (GH-44645).
Audio: Add MP3 loading and playback support (GH-43007).
Audio: Fix pops in play() for spatial audio players (GH-46151).
Audio: Add AudioEffectCapture to access the microphone in real-time (GH-45593).
Buildsystem: Add production=yes option to set optimal options for production builds (GH-45679).
Users making custom builds should use this option which is equivalent to use_lto=yes debug_symbols=no use_static_cpp=yes.
Note for Linux builds: use_static_cpp=yes and udev=yes are now the default values, so you need libudev and libstdc++-static development packages to build in optimal conditions.
HTML5: Use internal implementation of the Gamepad API (GH-45078).
HTML5: Tons of fixes all around to better support the Web editor :)
HTML5: Refactored and simplified HTML page template (GH-46200).
Input: Add mouse event pass-through support for the game window (GH-40205).
Input: Add support for buttons and D-pads mapped to half axes (GH-42800).
Input: Add driving joystick type to windows joystick handling (GH-44082).
Input: Add support for new SDL gamecontroller keywords (used e.g. by PS5 controller) (GH-45798).
iOS: Add support for iOS plugins, with a similar interface to Android plugins (GH-41340).
You can read the updated documentation on godot-docs#4213, until it’s merged and included in the 3.2 documentation.
Previously built-in iOS features like ARKit, camera support, GameCenter, ICloud and InAppStore modules are now first-party plugins which can be installed from godot-ios-plugins. The relevant documentation will soon be updated to be clarify their usage with 3.2.4-stable.
iOS: Fix multiple issues with PVRTC import, disable ETC1 (GH-38076).
iOS: Add touch delay value to project settings (GH-42457).
iOS: Fixes to keyboard input, including better IME support (GH-43560).
This breaks compat but is not enabled by default for existing projects (see project setting physics/common/enable_pause_aware_picking). It will be enabled by default for new projects created with 3.2.4.
Physics: Implement CollisionPolygonmargin property for Bullet (GH-45855).
Physics: Implement Cylinder support in GodotPhysics3D (GH-45854).
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.114 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 RC 3. 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 RC 3).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-4-rc-4/index.html b/article/release-candidate-godot-3-2-4-rc-4/index.html
index b7de502203..0aa9fa78a5 100644
--- a/article/release-candidate-godot-3-2-4-rc-4/index.html
+++ b/article/release-candidate-godot-3-2-4-rc-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde9 March 2021
Godot 3.2.4 is going to be incredibly feature-packed, and we’re taking the time necessary to ensure that it will also be stable. That’s why we’re releasing a fourth Release Candidate now, focused mostly on fixing issues reported against the previous RC 3. Thanks to all pre-release testers who help us find and debug regressions!
Things should now be in a pretty good shape and we hope to be able to release 3.2.4 stable soon™.
For macOS, both the standard and Mono editor builds are now signed and notarized! Thanks to Prehensile Tales for the certificate and the work on the infrastructure.
After a lot of testing and additional work, we decided that the new 2D snapping features weren’t working as we want them to yet, so they has been reverted in 3.2.4 RC 4. We’re working on providing equivalent functionality through an addon so that we can iterate faster, and see if we can find solutions which satisfy most common use cases. Stay tuned for more info!
Note that the project settings from the rendering/quality/2d section have now been moved to rendering/2d, so if you used any of those, you will need to re-enable them under the new section in 3.2.4.
New dynamic BVH for rendering and the GodotPhysics backends.
If you experience a regression in either physics or rendering, you can try these Project Settings to revert back to the previous Octree-based approach and possibly fix the issue. In either case, be sure to report the problem on GitHub.
Android: Update logic to sign prebuilt APKs with apksigner instead of jarsigner, as required for Android API 30 (GH-44645).
Audio: Add MP3 loading and playback support (GH-43007).
Audio: Fix pops in play() for spatial audio players (GH-46151).
Audio: Add AudioEffectCapture to access the microphone in real-time (GH-45593).
Buildsystem: Add production=yes option to set optimal options for production builds (GH-45679).
Users making custom builds should use this option which is equivalent to use_lto=yes debug_symbols=no use_static_cpp=yes.
Note for Linux builds: use_static_cpp=yes and udev=yes are now the default values, so you need libudev and libstdc++-static development packages to build in optimal conditions.
HTML5: Use internal implementation of the Gamepad API (GH-45078).
HTML5: Tons of fixes all around to better support the Web editor :)
HTML5: Refactored and simplified HTML page template (GH-46200).
HTML5: Add PWA support to the editor page (GH-46796).
Import: New editor to configure default import presets (GH-46354).
Import: Fixed lossy_quality setting for ETC import (GH-44682).
See the linked PR for details, high lossy_quality values will now incur significantly longer import times (but correspondingly higher quality).
Input: Add mouse event pass-through support for the game window (GH-40205).
Input: Add support for buttons and D-pads mapped to half axes (GH-42800).
Input: Add driving joystick type to windows joystick handling (GH-44082).
Input: Add support for new SDL gamecontroller keywords (used e.g. by PS5 controller) (GH-45798).
iOS: Add support for iOS plugins, with a similar interface to Android plugins (GH-41340).
You can read the updated documentation on godot-docs#4213, until it’s merged and included in the 3.2 documentation.
Previously built-in iOS features like ARKit, camera support, GameCenter, ICloud and InAppStore modules are now first-party plugins which can be installed from godot-ios-plugins. The relevant documentation will soon be updated to be clarify their usage with 3.2.4-stable.
iOS: Fix multiple issues with PVRTC import, disable ETC1 (GH-38076).
iOS: Add touch delay value to project settings (GH-42457).
iOS: Fixes to keyboard input, including better IME support (GH-43560).
This breaks compat but is not enabled by default for existing projects (see project setting physics/common/enable_pause_aware_picking). It will be enabled by default for new projects created with 3.2.4.
Physics: Implement CollisionPolygonmargin property for Bullet (GH-45855).
Physics: Implement Cylinder support in GodotPhysics3D (GH-45854).
Physics: Allow CollisionObject to show collision shape meshes (GH-45783).
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.114 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 RC 4. 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 RC 4).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-4-rc-5/index.html b/article/release-candidate-godot-3-2-4-rc-5/index.html
index b7ed5db48e..d911b4a745 100644
--- a/article/release-candidate-godot-3-2-4-rc-5/index.html
+++ b/article/release-candidate-godot-3-2-4-rc-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde13 March 2021
Godot 3.2.4 is going to be incredibly feature-packed, and we’re taking the time necessary to ensure that it will also be stable. We had a fourth Release Candidate a few days ago which got good testing and helped surface various bugs, many of which have been fixed. So we’re now making a RC 5 build to keep iterating fast and make sure that the bug fixes work as expected. Thanks to all pre-release testers who help us find and debug regressions!
Things should now be in a pretty good shape and we hope to be able to release 3.2.4 stable soon™.
For macOS, both the standard and Mono editor builds are now signed and notarized! Thanks to Prehensile Tales for the certificate and the work on the infrastructure.
Have a look at the previous 3.2.4 RC 4 release announcement for a detailed list of the main changes in the upcoming 3.2.4 release.
For this RC 5 build specifically, see the changes since the previous RC 4 build. Most changes are regression and bug fixes. Thanks to all testers for their reports!
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.114 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 RC 5. 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 RC 5).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-rc-1/index.html b/article/release-candidate-godot-3-2-rc-1/index.html
index db425764cf..f7fd3aa9dc 100644
--- a/article/release-candidate-godot-3-2-rc-1/index.html
+++ b/article/release-candidate-godot-3-2-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde17 January 2020
At long last, Godot 3.2 is nearing completion and we are happy to publish this first Release Candidate, to encourage a broad testing of what should become Godot 3.2-stable in coming days.
Small release grown big
Godot 3.2 was intended to be a “small” release, bringing the usual share of usability improvements over the previous version but no major new feature work, as the upcoming 4.0 with Vulkan support and many new rendering features and refactoring was already in the pipeline. We even intended to release it mid-2019, but as always in software development, and even more so in community-driven open source one, we were overly optimistic :)
But the longer development time for 3.2 was good. It’s packed with lots of new, important features, and an impressive amount of bug fixes – over 6000 commits by close to 450 contributors! Before moving on to the vulkan branch, Juan had time to develop quite a few cool features, and the rest of the contributors have been incredibly busy implement all sorts of things and fixing close to 2000 issues! Godot 3.2 will be much more mature than 3.1 in all aspects, and a great landing point for developers who intend to ship games with the 3.x branch (if porting to 4.0 proves too risky/difficult).
Now, I’m teasing, but I don’t have release notes describing the highlights for you just yet – hopefully the coming week gives me some free time to draft those in time for the final release ;)
For those following our dev snapshots closely, 187 commits have been merged since 3.2 beta 6 last week. This release is built from commit ba7aca4.
Disclaimer
IMPORTANT: This is a release candidate build, which means that it is not suitable yet for use in production, nor for press reviews of what Godot 3.2 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 not written yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.6.0.161 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Bug reports
While we greatly reduced the number of bug reports in the 3.2 milestone the past two weeks, there are still a couple hundred that we are aware of. Many of those issues will end up not being considered critical for the 3.2 release and pushed back to later milestones.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 3.1.x no longer works in 3.2 RC 1).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-rc-2/index.html b/article/release-candidate-godot-3-2-rc-2/index.html
index 560645f7e3..f6a06aa8fc 100644
--- a/article/release-candidate-godot-3-2-rc-2/index.html
+++ b/article/release-candidate-godot-3-2-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde20 January 2020
At long last, Godot 3.2 is nearing completion and we are happy to publish this second Release Candidate, to encourage a broad testing of what should become Godot 3.2-stable in coming days.
The first RC build last Friday appeared to be problematic for some users with the GLES3 backend, as calculations for the irradiance map were taking too much time for some drivers (leading to a GPU hang). This is now fixed by reducing the complexity of the calculations, while still slightly improving quality.
Notable changes since RC 1:
Core: Fix ClassDB API portability for API hash calculation (GH-35326) (fixes false positive “Core API hash mismatch” error on C# debug builds).
Editor: Speed up starting time by optimizing editor theme generation ().
GLES3: Reduce complexity of irradiance map generation (GH-35302).
For those following our dev snapshots closely, 61 commits have been merged since 3.2 RC 1 last Friday. This release is built from commit ba7aca4.
Disclaimer
IMPORTANT: This is a release candidate build, which means that it is not suitable yet for use in production, nor for press reviews of what Godot 3.2 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 not finalized yet, but you can refer to the detailed changelog that our contributor Hugo Locurcio is maintaining.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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 build (C# support + all the above). You need to have MSBuild installed to use the Mono build. Relevant parts of Mono 6.6.0.161 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Bug reports
While we greatly reduced the number of bug reports in the 3.2 milestone the past weeks, there are still a hundred that we are aware of. Many of those issues will end up not being considered critical for the 3.2 release and pushed back to later milestones.
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
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.1.x no longer works in 3.2).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-2-rc-3/index.html b/article/release-candidate-godot-3-2-rc-3/index.html
index 969fff67b2..fa0338ec91 100644
--- a/article/release-candidate-godot-3-2-rc-3/index.html
+++ b/article/release-candidate-godot-3-2-rc-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde24 January 2020
At long last, Godot 3.2 is nearing completion and we are happy to publish this third Release Candidate, to encourage a broad testing of what should become Godot 3.2-stable in coming days.
The second RC build on Monday fared fairly well and had no new regression. Various important fixes have been made since, so this third release candidate will allow to validate them and ensure that 3.2 stable can be released with confidence :)
Notable changes since RC 2:
Android: Virtual keyboard now respects LineEdit max length (GH-35438).
Core/Editor: Various memory leaks fixed.
Editor: Fix import of AtlasTextures with semi-transparent pixels (GH-35363).
GLES3: Fix invalid value for GL_TEXTURE_MAG_FILTER (typo in RC 2 bugfix) (GH-35437).
Linux: Fix key events not always releasing when framerate drops (GH-35440).
Mono: Default to net47 for new projects (GH-35473).
Object: Make sure we know when deleting an emitting object (GH-35423).
Rendering: Fix shadow culling with orthogonal camera and wrong VIEWPORT_SIZE shader builtin (GH-35406).
Tween: Fixed Tween::start with pending updates (GH-35452).
Documentation and translation updates.
For those following our dev snapshots closely, 118 commits have been merged since 3.2 RC 2 last Monday. This release is built from commit 8a7a216.
Disclaimer
IMPORTANT: This is a release candidate build, which means that it is not suitable yet for use in production, nor for press reviews of what Godot 3.2 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 not finalized yet, but you can refer to the detailed changelog now included in the master branch.
Our past devblogs should also give you an idea of the main highlights of the upcoming release. Note that the Vulkan port outlined in Juan’s latest posts is developed in a separate branch for Godot 4.0, and is not included in this 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.2 features.
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:
Classical build (GDScript, GDNative, VisualScript). Note: UWP templates are missing from this build.
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.161 are included in this build.
IMPORTANT: Make backups of your Godot 3.1 projects before opening them in any 3.2 development build.
Bug reports
We’re now down to a handful of issues which we still consider critical enough for 3.2. Some of them might be fixed before 3.2 stable, and the rest will be postponed to be fixed in a later release (e.g. 3.2.1).
As a tester, you are encouraged to open bug reports if you experience issues with 3.2 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.
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.1.x no longer works in 3.2).
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-1-rc-1/index.html b/article/release-candidate-godot-3-3-1-rc-1/index.html
index 613bfe44c5..0e3c101195 100644
--- a/article/release-candidate-godot-3-3-1-rc-1/index.html
+++ b/article/release-candidate-godot-3-3-1-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde10 May 2021
We released Godot 3.3 a couple of weeks ago, and feedback so far has been pretty good! But like with any major milestone, there are some bugs which are worth addressing with low-risk maintenance releases to further improve the experience for all Godot users.
The upcoming Godot 3.3.1, like all future 3.3.x releases, focuses purely on bug fixes, and aims to preserve compatibility. This Release Candidate should help us validate the fixes done so far, and ensure that the release is ready to publish. As there is no new feature and only bug fixes, this RC 1 should be as stable as 3.3-stable and can be used in production if you need one of the fixes it includes.
Animation: Fix skinning initialization in MeshInstance when loaded from thread (GH-48217).
Batching: Fix light pass modulate, a potential crash, and polygon rotation from vertex shader (GH-48151, GH-48125, GH-48457)).
Buildsystem: Various compilation fixes for some platforms/compilers, and Linux packaging fixes.
Core: Expose Shape.get_debug_mesh() to the scripting API (GH-48316).
Editor: Fix race condition in font preview generation which could lock the editor on first edit (GH-48308).
Editor: Allow negative contrast values in the editor theme settings (GH-48540).
HTML5: Fix build with Emscripten 2.0.17+ (GH-48320).
HTML5: Fix target_fps when window loses focus (GH-48543).
Lightmapper: Add support for ARM64 architecture for the raycaster (Apple M1, Linux aarch64) (GH-48455).
Note that the denoiser is still not available on this architecture.
Lightmapper: Fixes to environment energy (GH-48089).
Linux: Fix 32-bit builds’ compatibility with older libstdc++. The builds should be compatibility with Ubuntu 16.04 LTS and any other distribution published since 2016.
LSP: Update the filesystem for changed scripts, fixes issues with new named classes (GH-47891).
macOS: Update Info.plist to clarify that the minimum required version is now macOS 10.12 (due to use of C++14 features).
Networking: Fix socket poll timeout on Windows (GH-48203).
Physics: Create CollisionObject debug shapes using VisualServer (GH-48588).
SkeletonIK: Fix root bones being twisted incorrectly when rotated (GH-48251).
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:
Note: UWP export templates are missing from this build, will be re-added in the next build.
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.122 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3.1 RC 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.3 no longer works in 3.3.1 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-1-rc-2/index.html b/article/release-candidate-godot-3-3-1-rc-2/index.html
index 9538f73e5b..33184be548 100644
--- a/article/release-candidate-godot-3-3-1-rc-2/index.html
+++ b/article/release-candidate-godot-3-3-1-rc-2/index.html
@@ -6,7 +6,7 @@
* Note that the denoiser is still not available on this architecture.
Lightmapper: Fixes to environment energy (GH-48089).
Linux: Fix 32-bit builds’ compatibility with older libstdc++. The builds should be compatibile with Ubuntu 16.04 LTS and any other distribution published since 2016.
Linux: Handle having no sinks in the PulseAudio driver (GH-48706).
LSP: Update the filesystem for changed scripts, fixes issues with new named classes (GH-47891).
macOS: Update Info.plist to clarify that the minimum required version is now macOS 10.12 (due to use of C++14 features).
Networking: Fix socket poll timeout on Windows (GH-48203).
Physics: Create CollisionObject debug shapes using VisualServer (GH-48588).
SkeletonIK: Fix root bones being twisted incorrectly when rotated (GH-48251).
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:
Note: UWP export templates are missing from this build, will be re-added in the next build.
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.122 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3.1 RC 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.3 no longer works in 3.3.1 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-3-rc-1/index.html b/article/release-candidate-godot-3-3-3-rc-1/index.html
index 7e4fd66f86..1f39824cf4 100644
--- a/article/release-candidate-godot-3-3-3-rc-1/index.html
+++ b/article/release-candidate-godot-3-3-3-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde4 August 2021
While we’re busy working on both the upcoming Godot 4.0 and 3.4 releases (with a dev snapshot for 3.4 beta 2 available now), we still cherry-pick important bug fixes to the 3.3 branch regularly for maintenance releases (see our release policy).
Godot 3.3.2 was released in May, and a number of useful fixes have been queued in the 3.3 branch since then, so now’s a good time to push them in production.
As there is no new feature and only bug fixes, this RC 1 should be as stable as 3.3.2-stable and can be used in production if you need one of the fixes it includes.
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:
Note: UWP export templates are missing from this build, will be re-added in the next build.
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.122 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3.3 RC 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.3 no longer works in 3.3.3 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-3-rc-2/index.html b/article/release-candidate-godot-3-3-3-rc-2/index.html
index ee37979212..1faec8b0e3 100644
--- a/article/release-candidate-godot-3-3-3-rc-2/index.html
+++ b/article/release-candidate-godot-3-3-3-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde16 August 2021
While we’re busy working on both the upcoming Godot 4.0 and 3.4 releases (with a dev snapshot for 3.4 beta 3 available now), we still cherry-pick important bug fixes to the 3.3 branch regularly for maintenance releases (see our release policy).
Godot 3.3.2 was released in May, and a number of useful fixes have been queued in the 3.3 branch since then, so now’s a good time to push them in production.
As there is no new feature and only bug fixes, this RC 2 should be as stable as 3.3.2-stable and can be used in production if you need one of the fixes it includes.
A notable change in 3.3.2 RC 2 is that the Android builds now target API level 30as required by Google Play, and have partial support for Android scoped storage. The minimum API level has also been increased from 18 to 19.
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:
Note: UWP export templates are missing from this build, will be re-added in the next build.
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.122 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3.3 RC 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.3 no longer works in 3.3.3 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-4-rc-1/index.html b/article/release-candidate-godot-3-3-4-rc-1/index.html
index 1434d57208..ea8e60dfe8 100644
--- a/article/release-candidate-godot-3-3-4-rc-1/index.html
+++ b/article/release-candidate-godot-3-3-4-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde29 September 2021
While we’re busy working on both the upcoming Godot 4.0 and 3.4 releases (with a dev snapshot for 3.4 beta 5 available now), we still cherry-pick important bug fixes to the 3.3 branch regularly for maintenance releases (see our release policy).
Godot 3.3.3 was released a month ago, and a handful of important fixes have been queued in the 3.3 branch since then. Most notably, users of the GDScript LSP in Visual Studio Code have been experiencing crashes in 3.3.3, which are fixed in this new Godot 3.3.4 RC 1.
Note: Version numbers can be confusing with three branches worked on in parallel - this release is 3.3.4, i.e. a maintenance update to the 3.3 branch. This is not the upcoming 3.4 feature release.
As there is no new feature and only bug fixes, this RC 1 should be as stable as 3.3.3-stable and can be used in production if you need one of the fixes it includes.
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:
Note: UWP export templates are missing from this build, will be re-added in the next build.
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.122 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3.4 RC 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.3 no longer works in 3.3.4 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-rc-6/index.html b/article/release-candidate-godot-3-3-rc-6/index.html
index 14269a2270..f172804c8e 100644
--- a/article/release-candidate-godot-3-3-rc-6/index.html
+++ b/article/release-candidate-godot-3-3-rc-6/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde19 March 2021
But aside from the name change, it’s still the same release. Our last testing build was 3.2.4 RC 5 and so this new Release Candidate is named 3.3 RC 6. The version change doesn’t mean that we’re reopening the branch for new features, and so Godot 3.3 is very close to its stable release.
We still need a good round of testing on this new build to ensure that everything works as we want it before we make this the new stable branch (which will supersede the current 3.2.3 stable version).
New dynamic BVH for rendering and the GodotPhysics backends.
If you experience a regression in either physics or rendering, you can try these Project Settings to revert back to the previous Octree-based approach and possibly fix the issue. In either case, be sure to report the problem on GitHub.
Android: Update logic to sign prebuilt APKs with apksigner instead of jarsigner, as required for Android API 30 (GH-44645).
Audio: Add MP3 loading and playback support (GH-43007).
Audio: Fix pops in play() for spatial audio players (GH-46151).
Audio: Add AudioEffectCapture to access the microphone in real-time (GH-45593).
Buildsystem: Add production=yes option to set optimal options for production builds (GH-45679).
Users making custom builds should use this option which is equivalent to use_lto=yes debug_symbols=no use_static_cpp=yes.
Note for Linux builds: use_static_cpp=yes and udev=yes are now the default values, so you need libudev and libstdc++-static development packages to build in optimal conditions.
HTML5: Use internal implementation of the Gamepad API (GH-45078).
HTML5: Tons of fixes all around to better support the Web editor :)
HTML5: Refactored and simplified HTML page template (GH-46200).
HTML5: Add PWA support to the editor page (GH-46796).
Import: New editor to configure default import presets (GH-46354).
Import: Fixed lossy_quality setting for ETC import (GH-44682).
See the linked PR for details, high lossy_quality values will now incur significantly longer import times (but correspondingly higher quality).
Input: Add mouse event pass-through support for the game window (GH-40205).
Input: Add support for buttons and D-pads mapped to half axes (GH-42800).
Input: Add driving joystick type to windows joystick handling (GH-44082).
Input: Add support for new SDL gamecontroller keywords (used e.g. by PS5 controller) (GH-45798).
iOS: Add support for iOS plugins, with a similar interface to Android plugins (GH-41340).
You can read the updated documentation on godot-docs#4213, until it’s merged and included in the 3.2 documentation.
Previously built-in iOS features like ARKit, camera support, GameCenter, ICloud and InAppStore modules are now first-party plugins which can be installed from godot-ios-plugins. The relevant documentation will soon be updated to be clarify their usage with 3.3-stable.
iOS: Fix multiple issues with PVRTC import, disable ETC1 (GH-38076).
iOS: Add touch delay value to project settings (GH-42457).
iOS: Fixes to keyboard input, including better IME support (GH-43560).
This breaks compat but is not enabled by default for existing projects (see project setting physics/common/enable_pause_aware_picking). It will be enabled by default for new projects created with 3.3.
Physics: Implement CollisionPolygonmargin property for Bullet (GH-45855).
Physics: Implement Cylinder support in GodotPhysics3D (GH-45854).
Physics: Allow CollisionObject to show collision shape meshes (GH-45783).
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.114 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3 RC 6. 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.3 RC 6).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-rc-7/index.html b/article/release-candidate-godot-3-3-rc-7/index.html
index 4e8a1b1993..0fa533c499 100644
--- a/article/release-candidate-godot-3-3-rc-7/index.html
+++ b/article/release-candidate-godot-3-3-rc-7/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde30 March 2021
In case you missed the recent news, we decided to change our versioning for Godot 3.x and rename the upcoming version 3.2.4 to Godot 3.3, thereby starting a new stable branch. Check the dedicated blog post for details.
This 7th Release Candidate fixes a number of regressions which had been introduced since 3.2.3. Nearly all critical regressions have now been fixed, so we should be able to release Godot 3.3 stable in the near future.
If you haven’t tried 3.3 RC builds yet, now would be a great time to do it to help us ensure everything upgrades smoothly from 3.2.3 to 3.3.
New dynamic BVH for rendering and the GodotPhysics backends.
If you experience a regression in either physics or rendering, you can try these Project Settings to revert back to the previous Octree-based approach and possibly fix the issue. In either case, be sure to report the problem on GitHub.
Android: Update logic to sign prebuilt APKs with apksigner instead of jarsigner, as required for Android API 30 (GH-44645).
Audio: Add MP3 loading and playback support (GH-43007).
Audio: Fix pops in play() for spatial audio players (GH-46151).
Audio: Add AudioEffectCapture to access the microphone in real-time (GH-45593).
Buildsystem: Add production=yes option to set optimal options for production builds (GH-45679).
Users making custom builds should use this option which is equivalent to use_lto=yes debug_symbols=no use_static_cpp=yes.
Note for Linux builds: use_static_cpp=yes and udev=yes are now the default values, so you need libudev and libstdc++-static development packages to build in optimal conditions.
HTML5: Use internal implementation of the Gamepad API (GH-45078).
HTML5: Tons of fixes all around to better support the Web editor :)
HTML5: Refactored and simplified HTML page template (GH-46200).
HTML5: Add PWA support to the editor page (GH-46796).
Import: New editor to configure default import presets (GH-46354).
Import: Add “Keep” import mode to keep files as-is and export them (GH-47268).
Import: Fixed lossy_quality setting for ETC import (GH-44682).
See the linked PR for details, high lossy_quality values will now incur significantly longer import times (but correspondingly higher quality).
Input: Add mouse event pass-through support for the game window (GH-40205).
Input: Add support for buttons and D-pads mapped to half axes (GH-42800).
Input: Add driving joystick type to windows joystick handling (GH-44082).
Input: Add support for new SDL gamecontroller keywords (used e.g. by PS5 controller) (GH-45798).
iOS: Add support for iOS plugins, with a similar interface to Android plugins (GH-41340).
You can read the updated documentation on godot-docs#4213, until it’s merged and included in the 3.2 documentation.
Previously built-in iOS features like ARKit, camera support, GameCenter, ICloud and InAppStore modules are now first-party plugins which can be installed from godot-ios-plugins. The relevant documentation will soon be updated to be clarify their usage with 3.3-stable.
iOS: Fix multiple issues with PVRTC import, disable ETC1 (GH-38076).
iOS: Add touch delay value to project settings (GH-42457).
iOS: Fixes to keyboard input, including better IME support (GH-43560).
This breaks compat but is not enabled by default for existing projects (see project setting physics/common/enable_pause_aware_picking). It will be enabled by default for new projects created with 3.3.
Physics: Implement CollisionPolygonmargin property for Bullet (GH-45855).
Physics: Implement Cylinder support in GodotPhysics3D (GH-45854).
Physics: Allow CollisionObject to show collision shape meshes (GH-45783).
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.122 are included in this build. (Note: Previous builds used Mono 6.12.0.114.)
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3 RC 7. 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.3 RC 7).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-rc-8/index.html b/article/release-candidate-godot-3-3-rc-8/index.html
index b8959df2a9..c5aee04b4e 100644
--- a/article/release-candidate-godot-3-3-rc-8/index.html
+++ b/article/release-candidate-godot-3-3-rc-8/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde7 April 2021
In case you missed the recent news, we decided to change our versioning for Godot 3.x and rename the upcoming version 3.2.4 to Godot 3.3, thereby starting a new stable branch. Check the dedicated blog post for details.
Here’s another Release Candidate for Godot 3.3! Keeping this post short as there wasn’t much change, just a handful of fixes - refer to the 3.3 RC 7 post for details on new features.
We’re pretty confident about this candidate (Famous Last Words™) so if no new regression is found, the next build should hopefully be the stable release! If you haven’t tried 3.3 RC builds yet, now would be a great time to do it to help us ensure everything upgrades smoothly from 3.2.3 to 3.3.
Compared to the previous RC 7 build, this release fixes a few regressions in GDNative, rendering, GodotPhysics (BVH), and Android JNI threads. It also fixes the GLES2 fallback option for HTML5 exports.
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.122 are included in this build. (Note: Builds prior to 3.3 RC 7 used Mono 6.12.0.114.)
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3 RC 8. 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.3 RC 8).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-3-rc-9/index.html b/article/release-candidate-godot-3-3-rc-9/index.html
index d53bf9dee7..aa16c91ed3 100644
--- a/article/release-candidate-godot-3-3-rc-9/index.html
+++ b/article/release-candidate-godot-3-3-rc-9/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde14 April 2021
In case you missed the recent news, we decided to change our versioning for Godot 3.x and rename the upcoming version 3.2.4 to Godot 3.3, thereby starting a new stable branch. Check the dedicated blog post for details.
Here’s another Release Candidate for Godot 3.3! Keeping this post short as there wasn’t much change, just a handful of fixes - refer to the 3.3 RC 7 post for details on new features.
We’re pretty confident about this candidate (Famous Last Words™) so if no new regression is found, the next build should hopefully be the stable release (yes, we said that for RC8 too)! If you haven’t tried 3.3 RC builds yet, now would be a great time to do it to help us ensure everything upgrades smoothly from 3.2.3 to 3.3.
Compared to the previous RC 8 build, this release fixes a few issues with: 2D batching, SkeletonIK root bone rotation, Android plugin API and splash screen, various crash fixes.
For 2D rendering, we’re also re-adding some testing options which were used in earlier betas to allow users to test different scenarios which may impact performance for some OpenGL drivers (especially on Windows and macOS). See GH-47864 for details. For the legacy render path (non-batching), we’re changing a flag to GL_STREAM_DRAW which seems to give significant FPS gains on some test cases. Please report if you see any suspicious FPS drop in RC9 compared to RC8!
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.122 are included in this build. (Note: Builds prior to 3.3 RC 7 used Mono 6.12.0.114.)
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.3 RC 9. 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.3 RC 9).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-1-rc-1/index.html b/article/release-candidate-godot-3-4-1-rc-1/index.html
index 8a68b56bf4..7a2b997fb1 100644
--- a/article/release-candidate-godot-3-4-1-rc-1/index.html
+++ b/article/release-candidate-godot-3-4-1-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde26 November 2021
Godot 3.4 was released earlier this month, and it went fairly smoothly! Many thanks to all the contributors who worked on it, including all testers who tried beta and RC releases to ensure that the 3.4-stable branch would be an easy and worthwhile upgrade path for all users.
No software release is perfect though, so there will always be some things to iron out, which is why we usually provide maintenance releases for stable branches, focusing on bugfixing and preserving compatibility (see our release policy). A number of fixes have been queued already in the 3.4 branch for Godot 3.4.1, so here’s a first release candidate to validate them.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4.1 RC 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.4 no longer works in 3.4.1 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-1-rc-2/index.html b/article/release-candidate-godot-3-4-1-rc-2/index.html
index 5bab7e146b..7e63d4773a 100644
--- a/article/release-candidate-godot-3-4-1-rc-2/index.html
+++ b/article/release-candidate-godot-3-4-1-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde8 December 2021
Godot 3.4 was released a month ago, and it went fairly smoothly! Many thanks to all the contributors who worked on it, including all testers who tried beta and RC releases to ensure that the 3.4-stable branch would be an easy and worthwhile upgrade path for all users.
No software release is perfect though, so there will always be some things to iron out, which is why we usually provide maintenance releases for stable branches, focusing on bugfixing and preserving compatibility (see our release policy). A number of fixes have been queued already in the 3.4 branch for Godot 3.4.1, so here’s a new release candidate to validate them.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4.1 RC 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.4 no longer works in 3.4.1 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-1-rc-3/index.html b/article/release-candidate-godot-3-4-1-rc-3/index.html
index 73e9e7cdf6..5fba2a3712 100644
--- a/article/release-candidate-godot-3-4-1-rc-3/index.html
+++ b/article/release-candidate-godot-3-4-1-rc-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 December 2021
Godot 3.4 was released a month ago, and it went fairly smoothly! Many thanks to all the contributors who worked on it, including all testers who tried beta and RC releases to ensure that the 3.4-stable branch would be an easy and worthwhile upgrade path for all users.
No software release is perfect though, so there will always be some things to iron out, which is why we usually provide maintenance releases for stable branches, focusing on bugfixing and preserving compatibility (see our release policy). A number of fixes have been queued already in the 3.4 branch for Godot 3.4.1, so here’s a new release candidate to validate them.
This RC 3 notably adds a change for the terminal handling on Windows to work around a design limitation of Windows 11’s new default Windows Terminal (GH-54076). Please test it on Windows (any version) to confirm that editing a project from the project manager, and running a project from the editor, both work fine.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4.1 RC 3. 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.4 no longer works in 3.4.1 RC 3).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-3-rc-1/index.html b/article/release-candidate-godot-3-4-3-rc-1/index.html
index 74df7e2031..b99518b878 100644
--- a/article/release-candidate-godot-3-4-3-rc-1/index.html
+++ b/article/release-candidate-godot-3-4-3-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde3 February 2022
In parallel to our work on Godot 3.5 (with a first beta) and 4.0 (and finally alpha 1!), we backport important fixes to the stable 3.4 branch for use in production.
A number of such fixes have been queued since the 3.4.2 release, so we’re getting ready to release Godot 3.4.3, and this first Release Candidate is your chance to help us validate it.
As usual, you can try it live with the online version of the Godot editor updated for this release. Edit: Or not, there’s a regression for the web editor in this build (GH-57592). This will be fixed in the next build.
Changes
Here are some of the main changes since 3.4.2-stable:
Android: Fix relative keystore paths on Android exporter with custom build (GH-56676).
Animation: Expose AnimationNodeOneShot::mix_mode as a property (GH-37945).
C#: Allow configuring Mono debugger agent with command line arguments (GH-56835).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4.3 RC 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 earlier 3.4.x releases no longer works in 3.4.3 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-3-rc-2/index.html b/article/release-candidate-godot-3-4-3-rc-2/index.html
index 0d17912a8c..29f911ac77 100644
--- a/article/release-candidate-godot-3-4-3-rc-2/index.html
+++ b/article/release-candidate-godot-3-4-3-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde17 February 2022
In parallel to our work on Godot 3.5 (with a first beta) and 4.0 (now at alpha 2!), we backport important fixes to the stable 3.4 branch for use in production.
A number of such fixes have been queued since the 3.4.2 release, so we’re getting ready to release Godot 3.4.3, and this second Release Candidate is your chance to help us validate it.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4.3 RC 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 earlier 3.4.x releases no longer works in 3.4.3 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-4-rc-1/index.html b/article/release-candidate-godot-3-4-4-rc-1/index.html
index c9fbf3f9f9..6d18258dd3 100644
--- a/article/release-candidate-godot-3-4-4-rc-1/index.html
+++ b/article/release-candidate-godot-3-4-4-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde8 March 2022
This Release Candidate adds a handful of fixes, including several regression fixes. Please make sure to test it on your projects and to report any issue, so that we can release 3.4.4 stable in the coming days.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Note: The Windows builds are signed, but the certificate expired recently. We’re working on having it renewed, this should be fixed in time for 3.4.4 stable.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4.4 RC 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 earlier 3.4.x releases no longer works in 3.4.4 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-4-rc-2/index.html b/article/release-candidate-godot-3-4-4-rc-2/index.html
index eb32053df8..087d5053d7 100644
--- a/article/release-candidate-godot-3-4-4-rc-2/index.html
+++ b/article/release-candidate-godot-3-4-4-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde16 March 2022
This Release Candidate adds a handful of fixes, including several regression fixes. Please make sure to test it on your projects and to report any issue, so that we can release 3.4.4 stable in the coming days.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Notes:
The Windows builds are signed, but the certificate expired recently. The 3.4.4 stable builds should be signed with a new certificate.
The macOS editor builds are signed but not notarized. The 3.4.4 stable builds should be notarized again.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4.4 RC 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 earlier 3.4.x releases no longer works in 3.4.4 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-5-rc-1/index.html b/article/release-candidate-godot-3-4-5-rc-1/index.html
index b87b720ee8..053eb895aa 100644
--- a/article/release-candidate-godot-3-4-5-rc-1/index.html
+++ b/article/release-candidate-godot-3-4-5-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde19 July 2022
While Godot 3.5 is nearing a stable release, we still want to provide relevant bug fixes to users of the current 3.4 stable branch who might not be ready to upgrade right away. It’s been a long time since the release of Godot 3.4.4, and there are a few important fixes coming up in Godot 3.4.5.
This Release Candidate is intended to help validate those fixes and make sure that Godot 3.4.5 is ready to publish.
Notable changes that motivate this release include:
Increase Android target API level to 31 to match Google Play requirements for new apps as of August 2022.
Update mbedtls and zlib libraries to fix security vulnerabilities.
Ignore support of S3TC compression format on mobile devices to ensure the use of ETC2 for GLES3 (fixes issues with Meta Quest 2 after a recent system update).
When upgrading to 3.4.5 for projects using Android custom builds, you have to manually set the “Target Sdk” option to 31 in your export preset. For new presets, this is the new default value.
Android: Fix crash when trying to paste non-text data from clipboard (GH-60563).
Animation: Fix looping issue in AnimationNodeStateMachinePlayback with “At End” switch mode (GH-60247).
Audio: Instance audio streams before AudioServer::lock() call (GH-59413).
Audio: Fix crash in AudioServer when switching audio devices with different audio channels count (GH-59778).
C#: Avoid modifying csproj globbing includes on remove (GH-59521).
Core: Fix left aligned integer sign in string formatting (GH-60679).
Editor: Fix popup dialog UI in AnimationTreePlayer editor (GH-60200).
Editor: Fix EditorProperty icon overlapping text with checkbox (GH-58125).
Editor: Fix custom class icon when it inherits from a script (GH-60536).
Editor: Fix UndoRedo in Gradient editor (GH-60401).
Editor: Fix crash when editing pinned StyleBox (GH-61071).
Editor: Fix GridMap cursor showing the wrong mesh (GH-58624).
Editor: Fix incorrect encoding used in error handling functions (GH-61277).
Editor: Fix crash when drag-reordering array elements in the inspector (GH-61282).
Editor: Fix scene tree dock focus after using “Add Child Node” button (GH-61964).
GDScript: Fix editor undo history for function name autocompletion (GH-60231).
GDScript: Fix autocompletetion showing class names with an underscore (GH-62731).
GUI: FileDialog: Fix support for changing directory in user:// and res:// modes (GH-59838).
GUI: GraphEdit: Fix toggling minimap using the minimap_enabled property (GH-57239).
GUI: GraphEdit: Fix valid connections types being reversed (GH-60124).
GUI: Label: Fixed leading spaces pushing text outside autowrap boundary (GH-60233).
GUI: LineEdit: Fix clear button position for asymmetric StyleBox (GH-61496).
GUI: RichTextLabel: Fix implementation of remove_line() (GH-60618).
Linux: Properly check for fullscreen toggle made through the Window Manager (GH-62543).
Physics: Skip compound shapes without child shapes in SpaceBullet::recover_from_penetration() (GH-59864).
Rendering: GLES2: Unpack blend shape arrays when necessary (GH-60829).
Rendering: GLES3: Unbind vertex buffer before calculating blend shapes (GH-60832).
Rendering: GLES3: Ignore support for S3TC texture compression on Android and iOS devices (GH-62909).
Few devices support this compression while they all support ETC2. Godot exports ETC2 by default and doesn’t take into account that mobile devices could need S3TC.
Rendering: Portals: Force full check on adding moving object (GH-61523).
UWP: Fix GDNative DLLs not being included on export (GH-61262).
VisualScript: Fix copy paste issue in the editor (GH-54629).
VisualScript: Fix zoom handling in editor when jumping to functions (GH-60016).
Windows: Fix String.http_escape() non-standard behavior with MinGW (GH-61655).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4.5 RC 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 earlier 3.4.x releases no longer works in 3.4.5 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-rc-1/index.html b/article/release-candidate-godot-3-4-rc-1/index.html
index 021f28432d..b514cde7ab 100644
--- a/article/release-candidate-godot-3-4-rc-1/index.html
+++ b/article/release-candidate-godot-3-4-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde19 October 2021
The upcoming Godot 3.4 release will provide a number of new features which have been backported from the 4.0 development branch (see our release policy for details on the various Godot versions). With this first Release Candidate, we completely freezes feature development, and comes after a long series of beta builds to fix a number of bugs reported against previous builds (as well as against previous stable branches).
If you already reviewed the changelog for beta 6, you can skip right to the differences between beta 6 and RC 1. Notable changes are in-editor class reference translations (so far Chinese (Simplified), Spanish, and some French), some new rendering features (high quality glow mode, 3D point light attenuation option), and a number of C# marshalling fixes.
Rendering: Add new 3D point light attenuation as an option (GH-52918).
Rendering: Import option to split vertex buffer stream in positions and attributes (GH-46574).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Shaders: Add support for structs and fragment-to-light varyings (GH-48075).
Translation: Add support for translating the class reference (GH-53511).
Viewport: Add a 2D scale factor property (GH-52137).
VisualScript: Improve and streamline VisualScriptFuncNodes CallSetGet (GH-50709).
Windows: Fix platform file access to allow file sharing with external programs (GH-51430).
All these need to be thoroughly tested to ensure that they work as intended in the upcoming 3.4-stable.
Changes
Here’s a curated changelog with links to the relevant pull requests for details. The list is not exhaustive and will be completed in the future to include more noteworthy changes.
Note that some of the changes in 3.4 have already been backported and published in Godot 3.3.1 and 3.3.2, and therefore they were not listed here again. You can refer to the changelogs of those maintenance releases for details on what you might have missed since 3.3-stable.
Android: Add partial support for Android scoped storage (GH-50359).
This also means we’re now targeting API level 30 as required to publish new apps on Google Play.
Android: Add initial support for Play Asset Delivery (GH-52526).
Android: Improve input responsiveness on underpowered Android devices (GH-42220).
Android: Add GDNative libraries to Android custom Gradle builds (GH-49912).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4 RC 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.3.3 or earlier no longer works in this build).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-rc-2/index.html b/article/release-candidate-godot-3-4-rc-2/index.html
index 2788527985..114f06410d 100644
--- a/article/release-candidate-godot-3-4-rc-2/index.html
+++ b/article/release-candidate-godot-3-4-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde27 October 2021
The upcoming Godot 3.4 release will provide a number of new features which have been backported from the 4.0 development branch (see our release policy for details on the various Godot versions). With this second Release Candidate, we have frozen feature development and are nearly ready to release the stable version.
As usual, you can try it live with the online version of the Godot editor updated for this release. This Web editor now also supports using a WebGL 2 context (i.e. GLES3 renderer).
Highlights
The main changes coming in Godot 3.4 and included in this release candidate are:
Android: Add partial support for Android scoped storage (GH-50359).
This also means we’re now targeting API level 30 as required to publish new apps on Google Play.
Android: Add initial support for Play Asset Delivery (GH-52526).
Android: Improve input responsiveness on underpowered Android devices (GH-42220).
Rendering: Add new 3D point light attenuation as an option (GH-52918).
Rendering: Import option to split vertex buffer stream in positions and attributes (GH-46574).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Shaders: Add support for structs and fragment-to-light varyings (GH-48075).
Translation: Add support for translating the class reference (GH-53511).
Viewport: Add a 2D scale factor property (GH-52137).
VisualScript: Improve and streamline VisualScriptFuncNodes CallSetGet (GH-50709).
Windows: Fix platform file access to allow file sharing with external programs (GH-51430).
All these need to be thoroughly tested to ensure that they work as intended in the upcoming 3.4-stable.
Changes
Here’s a curated changelog with links to the relevant pull requests for details. The list is not exhaustive and will be completed in the future to include more noteworthy changes.
Note that some of the changes in 3.4 have already been backported and published in Godot 3.3.1 and 3.3.2, and therefore they were not listed here again. You can refer to the changelogs of those maintenance releases for details on what you might have missed since 3.3-stable.
Android: Add partial support for Android scoped storage (GH-50359).
This also means we’re now targeting API level 30 as required to publish new apps on Google Play.
Android: Add initial support for Play Asset Delivery (GH-52526).
Android: Improve input responsiveness on underpowered Android devices (GH-42220).
Android: Add GDNative libraries to Android custom Gradle builds (GH-49912).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4 RC 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.3.3 or earlier no longer works in this build).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-4-rc-3/index.html b/article/release-candidate-godot-3-4-rc-3/index.html
index 8bd9daf62e..880357f542 100644
--- a/article/release-candidate-godot-3-4-rc-3/index.html
+++ b/article/release-candidate-godot-3-4-rc-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde2 November 2021
The upcoming Godot 3.4 release will provide a number of new features which have been backported from the 4.0 development branch (see our release policy for details on the various Godot versions). With this third Release Candidate, we have frozen feature development and are nearly ready to release the stable version.
If you already reviewed the changelog for RC 2, you can skip right to the differences between RC 2 and RC 3. It’s short, as we mainly fixed a few new and old regressions, as well as input issues caused by changes in macOS Monterey.
As usual, you can try it live with the online version of the Godot editor updated for this release. This Web editor now also supports using a WebGL 2 context (i.e. GLES3 renderer).
Highlights
The main changes coming in Godot 3.4 and included in this release candidate are:
Android: Add partial support for Android scoped storage (GH-50359).
This also means we’re now targeting API level 30 as required to publish new apps on Google Play.
Android: Add initial support for Play Asset Delivery (GH-52526).
Android: Improve input responsiveness on underpowered Android devices (GH-42220).
Rendering: Add new 3D point light attenuation as an option (GH-52918).
Rendering: Import option to split vertex buffer stream in positions and attributes (GH-46574).
RichTextLabel: Fix auto-wrapping on CJK texts (GH-49280).
Shaders: Add support for structs and fragment-to-light varyings (GH-48075).
Translation: Add support for translating the class reference (GH-53511).
Viewport: Add a 2D scale factor property (GH-52137).
VisualScript: Improve and streamline VisualScriptFuncNodes CallSetGet (GH-50709).
Windows: Fix platform file access to allow file sharing with external programs (GH-51430).
All these need to be thoroughly tested to ensure that they work as intended in the upcoming 3.4-stable.
Changes
Here’s a curated changelog with links to the relevant pull requests for details. The list is not exhaustive and will be completed in the future to include more noteworthy changes.
Note that some of the changes in 3.4 have already been backported and published in Godot 3.3.1 and 3.3.2, and therefore they were not listed here again. You can refer to the changelogs of those maintenance releases for details on what you might have missed since 3.3-stable.
Android: Add partial support for Android scoped storage (GH-50359).
This also means we’re now targeting API level 30 as required to publish new apps on Google Play.
Android: Add initial support for Play Asset Delivery (GH-52526).
Android: Improve input responsiveness on underpowered Android devices (GH-42220).
Android: Add GDNative libraries to Android custom Gradle builds (GH-49912).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.158 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.4 RC 3. 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.3.3 or earlier no longer works in this build).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-1-rc-1/index.html b/article/release-candidate-godot-3-5-1-rc-1/index.html
index 43b473dc52..b5ef0b31e0 100644
--- a/article/release-candidate-godot-3-5-1-rc-1/index.html
+++ b/article/release-candidate-godot-3-5-1-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde2 September 2022
We released Godot 3.5 one month ago, and like any release, there are few rough edges to iron out which warrant making maintenance “patch” releases (3.5.x).
A number of issues have been fixed already, so we’re having a look at preparing the 3.5.1 update, starting with this Release Candidate for users to help us validate those fixes and make sure that Godot 3.5.1 is ready to publish.
Please give it a try if you can. It should be as safe to use as 3.5-stable is, but we still need a significant number of users to try it out and report how it goes to make sure that the few changes in this update are working as intended and not introducing new regressions.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.5.1 RC 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.5 or earlier 3.4.x releases no longer works in 3.5.1 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-1-rc-2/index.html b/article/release-candidate-godot-3-5-1-rc-2/index.html
index 39e55bdf82..29f92aef9b 100644
--- a/article/release-candidate-godot-3-5-1-rc-2/index.html
+++ b/article/release-candidate-godot-3-5-1-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde21 September 2022
We released Godot 3.5 in early August, and like any release, there are few rough edges to iron out which warrant making maintenance “patch” releases (3.5.x).
We’ve had successful testing of a first Release Candidate for 3.5.1, and a few more fixes got backported in the meantime so let’s have another round of testing before publishing 3.5.1 stable.
Please give it a try if you can. It should be as safe to use as 3.5-stable is, but we still need a significant number of users to try it out and report how it goes to make sure that the few changes in this update are working as intended and not introducing new regressions.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with 3.5.1 RC 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.5 or earlier 3.4.x releases no longer works in 3.5.1 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-2-rc-1/index.html b/article/release-candidate-godot-3-5-2-rc-1/index.html
index 834568ddbe..fca28016b4 100644
--- a/article/release-candidate-godot-3-5-2-rc-1/index.html
+++ b/article/release-candidate-godot-3-5-2-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde15 December 2022
All contributors are incredibly busy working on Godot 4.0, which is having weekly beta releases (currently beta 8, beta 9 likely tomorrow). Some of us are also doing significant work to prepare a first beta release of Godot 3.6, which will likely the last feature release in the 3.x series (expected to be finalized after the 4.0 release).
But we’re not forgetting about the current stable branch, Godot 3.5, which had its first stable release in early August, and a first maintenance release in late September.
Since then, quite a few bugfixes have been queued in the 3.5 branch, so it’s time to wrap up a new 3.5.2 maintenance release. But first, let’s validate that those changes do not introduce regressions with a Release Candidate.
Please give it a try if you can. It should be as safe to use as 3.5.1-stable is, but we still need a significant number of users to try it out and report how it goes to make sure that the few changes in this update are working as intended and not introducing new regressions.
Windows: Fix handling of some dead key combinations using Unicode char instead of Virtual key (GH-66314).
Windows: Fix Directory make_dir() choking on “..” (GH-66467).
Thirdparty libraries: libwebp 1.2.4, miniupnpc 2.2.4, nanosvg from 2022-11-21, Recast from 2022-11-26, stb_vorbis 1.22, CA root certificates from 2022-10-21, GameControllerDB from 2022-12-07.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.5.1, 3.5, or earlier 3.4.x releases no longer works in 3.5.2 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-2-rc-2/index.html b/article/release-candidate-godot-3-5-2-rc-2/index.html
index b7a05cc818..a2e357f827 100644
--- a/article/release-candidate-godot-3-5-2-rc-2/index.html
+++ b/article/release-candidate-godot-3-5-2-rc-2/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde12 January 2023
While all contributors are on the deck working to finalize the Godot 4.0 release (currently at beta 11), some of us are still backporting important bugfixes to the current stable branch, Godot 3.5.
It had its first stable release in early August, and a first maintenance release in late September, and so far so good, most users seem to be pretty happy with 3.5.1.
But since then, quite a few bugfixes have been queued in the 3.5 branch, so it’s time to wrap up a new 3.5.2 maintenance release. We had a first Release Candidate on December 15, and after fixing one regression and backporting a few other fixes, it’s time for a second RC build to validate the update.
Please give it a try if you can. It should be as safe to use as 3.5.1-stable is, but we still need a significant number of users to try it out and report how it goes to make sure that the few changes in this update are working as intended and not introducing new regressions.
Windows: Fix handling of some dead key combinations using Unicode char instead of Virtual key (GH-66314).
Windows: Fix Directory make_dir() choking on “..” (GH-66467).
Thirdparty libraries: libwebp 1.2.4, miniupnpc 2.2.4, nanosvg from 2022-11-21, Recast from 2022-11-26, stb_vorbis 1.22, zlib/minizip 1.2.13, CA root certificates from 2022-10-21, GameControllerDB from 2022-12-07.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.5.1, 3.5, or earlier 3.4.x releases no longer works in 3.5.2 RC 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-3-rc-1/index.html b/article/release-candidate-godot-3-5-3-rc-1/index.html
index c1a16c0a72..4c695fc588 100644
--- a/article/release-candidate-godot-3-5-3-rc-1/index.html
+++ b/article/release-candidate-godot-3-5-3-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde8 September 2023
It’s been a while since our previous maintenance release for Godot 3! While the development focus is on the Godot 4 branches, we’re still making steady progress towards the Godot 3.6 feature release, currently in beta phase. But we also need occasional updates to the current 3.5 branch which is used in production by many.
The main purpose of this release is to provide updated Android export templates which target API level 33 (Android 13), which is a requirement for new apps and updates on Google Play since August 2023. It also includes a number of other platform-specific fixes which may be relevant for published games, notably around gamepad input and audio.
Please give it a try if you can. It should be as safe to use as 3.5.2-stable is, but we still need a significant number of users to try it out and report how it goes to make sure that the few changes in this update are working as intended and not introducing new regressions.
See the curated changelog for a selection of some of the main changes since Godot 3.5.2. We now also have a great interactive changelog you can use to review the changes since the previous beta, with convenient links to the relevant PRs on GitHub.
Here are the main changes since 3.5.2-stable:
2D: TileSet: Fix resizing collision shape when vertex is outside the tilesheet (GH-73218).
2D: Notify child controls when BackBufferCopy’s rect changed (GH-74282).
2D: Fix AnimatedSprite normal map loading (GH-80406).
2D: Fix TouchScreenButton not redrawn when texture changes (GH-81100).
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not 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.5.2 or earlier no longer works in 3.5.3 RC 1).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-rc-1/index.html b/article/release-candidate-godot-3-5-rc-1/index.html
index fe7c906b67..1b06d035f7 100644
--- a/article/release-candidate-godot-3-5-rc-1/index.html
+++ b/article/release-candidate-godot-3-5-rc-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde18 May 2022
The upcoming Godot 3.5 is now considered feature complete, and has received a lot of bugfixes and improvements over the past weeks thanks to all the testers and developers who reported and fixed issues. It’s now time to move to the Release Candidate stage so that we can release 3.5-stable for all users.
At this stage we need people to test this release (and potential follow-up RCs) on as many codebases as possible, to make sure that we catch non-obvious regressions that might have gone unnoticed until now. If you run into any issue, please make sure to report it on GitHub so that we can know about it and fix it!
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020!
This adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in the updated docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5 beta.
And more!
Android: Initial port of the Godot editor (GH-57747).
Android: Fix flickering issues with low processor mode (GH-59606).
Rendering: Add support for saving multiple Images in BakedLightmap (GH-58102).
Rendering: Bind mesh merging functionality in MeshInstance (GH-57661).
Rendering: GLES2: Unpack blend shape arrays when necessary (GH-60829).
Rendering: GLES3: Unbind vertex buffer before calculating blend shapes (GH-60832).
Rendering: Portals: Show gridmaps using global mode (GH-60851).
Rendering: Fix viewport with transparent background changed to solid black if enabling FXAA or debanding (GH-54585).
Shaders: Many improvements backported from master (GH-56794).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.178 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release candidate. 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.4.x no longer works in this 3.5 RC).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-rc-3/index.html b/article/release-candidate-godot-3-5-rc-3/index.html
index 6453e65f25..ee98c211fd 100644
--- a/article/release-candidate-godot-3-5-rc-3/index.html
+++ b/article/release-candidate-godot-3-5-rc-3/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde1 June 2022
The upcoming Godot 3.5 is now considered feature complete, and has received a lot of bugfixes and improvements over the past weeks thanks to all the testers and developers who reported and fixed issues. We are now at the Release Candidate stage, finalizing everything so that we can release 3.5-stable for all users.
At this stage we need people to test this release (and potential follow-up RCs) on as many codebases as possible, to make sure that we catch non-obvious regressions that might have gone unnoticed until now. If you run into any issue, please make sure to report it on GitHub so that we can know about it and fix it!
This RC 3 fixes a number of recent regressions and older bugs. Notably, it fixes some rendering regressions with transparent materials, and crashing iOS templates and Web editor build in RC 2.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020! And then a lot of old and new navigation issues have been fixed by smix8 and Pawel Lampe (Scony).
The new NavigationServer adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime. The whole API is now a lot more flexible than it used to be.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in the updated docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New Label3D and TextMesh backported from Godot 4.0 (GH-61276, GH-61281)
Long awaited, Godot now provides a Label3D node out of the box to display text in 3D scenes. And for more advanced use cases, there is now also TextMesh to generate 3D meshes from font glyphs, so you can add Word Art to your scenes ;)
Both features were implemented by our text rendering expert bruvzg in the master branch for Godot 4.0, and backported to 3.5. They were merged late in the release process (3.5 RC 2) but should be quite self-contained and thus not impact the stability of other features. Be sure to test them and report any bug or inconvenience with the implementation.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5.
And more!
3D: Add Label3D node and Sprite3D material render priority (GH-61276).
3D: Add TextMesh and expose dynamic font vector outlines (GH-61281).
Android: Initial port of the Godot editor (GH-57747).
Android: Fix flickering issues with low processor mode (GH-59606).
Fixes a lot of issues with KinematicBody collisions at the intersection between meshes when using Bullet. This was merged fairly late (3.5 RC 2), please make sure to test it.
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.179 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release candidate. 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.4.x no longer works in this 3.5 RC).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-rc-4/index.html b/article/release-candidate-godot-3-5-rc-4/index.html
index 441911ecea..f5d97c9bd7 100644
--- a/article/release-candidate-godot-3-5-rc-4/index.html
+++ b/article/release-candidate-godot-3-5-rc-4/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde17 June 2022
The upcoming Godot 3.5 is now considered feature complete, and has received a lot of bugfixes and improvements over the past weeks thanks to all the testers and developers who reported and fixed issues. We are now at the Release Candidate stage, finalizing everything so that we can release 3.5-stable for all users.
At this stage we need people to test this release (and potential follow-up RCs) on as many codebases as possible, to make sure that we catch non-obvious regressions that might have gone unnoticed until now. If you run into any issue, please make sure to report it on GitHub so that we can know about it and fix it!
This RC 4 fixes a number of recent regressions and older bugs. Notably, this fixes a potential crash on Windows 11 on scenes using specific fonts. It also significantly refactors the new navigation system to make it closer to the version in Godot 4.0, and provide the missing features that 3.5 users would require to use it fully.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that on the first run materials may look a bit different for a second or two, but there should no longer be compilation lags. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020! Then smix8 took over the custody of this area, fixing a lot of bugs and improving the feature set greatly, with the help of Pawel Lampe (Scony).
The new NavigationServer adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime. The whole API is now a lot more flexible than it used to be.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in the updated docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New Label3D and TextMesh backported from Godot 4.0 (GH-61276, GH-61281)
Long awaited, Godot now provides a Label3D node out of the box to display text in 3D scenes. And for more advanced use cases, there is now also TextMesh to generate 3D meshes from font glyphs, so you can add Word Art to your scenes ;)
Both features were implemented by our text rendering expert bruvzg in the master branch for Godot 4.0, and backported to 3.5. They were merged late in the release process (3.5 RC 2) but should be quite self-contained and thus not impact the stability of other features. Be sure to test them and report any bug or inconvenience with the implementation.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5.
And more!
3D: Add Label3D node and Sprite3D material render priority (GH-61276).
3D: Add TextMesh and expose dynamic font vector outlines (GH-61281).
Android: Initial port of the Godot editor (GH-57747).
Android: Fix flickering issues with low processor mode (GH-59606).
Fixes a lot of issues with KinematicBody collisions at the intersection between meshes when using Bullet. This was merged fairly late (3.5 RC 2), please make sure to test it.
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.179 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release candidate. 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.4.x no longer works in this 3.5 RC).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-rc-5/index.html b/article/release-candidate-godot-3-5-rc-5/index.html
index 23e0d990e5..46f04b2b23 100644
--- a/article/release-candidate-godot-3-5-rc-5/index.html
+++ b/article/release-candidate-godot-3-5-rc-5/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde27 June 2022
The upcoming Godot 3.5 is now considered feature complete, and has received a lot of bugfixes and improvements over the past weeks thanks to all the testers and developers who reported and fixed issues. We are now at the Release Candidate stage, finalizing everything so that we can release 3.5-stable for all users.
At this stage we need people to test this release (and potential follow-up RCs) on as many codebases as possible, to make sure that we catch non-obvious regressions that might have gone unnoticed until now. If you run into any issue, please make sure to report it on GitHub so that we can know about it and fix it!
For this RC 5, we decided to include two fairly important Android PRs which had recently been finalized, as they are important to fulfill Google Play requirements for the near future: full Android scoped storage support, and upgrading the buildsystem from NDK r21 to NDK r23. They’re fairly big changes to include at RC stage but we think it’s really worth having in 3.5, so we’ll need your help to test Android export templates in this build and confirm that they work as expected.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that the first time a material is used under certain conditions (types of lights, shadowing enabled or not, etc.) rendering may be slower for a second or two, but the slowdown will not be nearly as bad as the typical hiccup caused by classic synchronous compilation. On the most powerful devices it may be even unnoticeable. Please test this thoroughly and let us know how it performs on your projects.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020! Then smix8 took over the custody of this area, fixing a lot of bugs and improving the feature set greatly, with the help of Pawel Lampe (Scony).
The new NavigationServer adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime. The whole API is now a lot more flexible than it used to be.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in the updated docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New Label3D and TextMesh backported from Godot 4.0 (GH-61276, GH-61281)
Long awaited, Godot now provides a Label3D node out of the box to display text in 3D scenes. And for more advanced use cases, there is now also TextMesh to generate 3D meshes from font glyphs, so you can add Word Art to your scenes ;)
Both features were implemented by our text rendering expert bruvzg in the master branch for Godot 4.0, and backported to 3.5.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5.
And more!
3D: Add Label3D node and Sprite3D material render priority (GH-61276).
3D: Add TextMesh and expose dynamic font vector outlines (GH-61281).
Android: Initial port of the Godot editor (GH-57747).
Android: Add full support for Android scoped storage (GH-51815).
Android: Upgrade Android NDK to r23 LTS (GH-61692).
Android: Fix flickering issues with low processor mode (GH-59606).
Fixes a lot of issues with KinematicBody collisions at the intersection between meshes when using Bullet. This was merged fairly late (3.5 RC 2), please make sure to test it.
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release candidate. 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.4.x no longer works in this 3.5 RC).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-rc-6/index.html b/article/release-candidate-godot-3-5-rc-6/index.html
index 3d9752f830..134cfe1c41 100644
--- a/article/release-candidate-godot-3-5-rc-6/index.html
+++ b/article/release-candidate-godot-3-5-rc-6/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde8 July 2022
The upcoming Godot 3.5 is now considered feature complete, and has received a lot of bugfixes and improvements over the past weeks thanks to all the testers and developers who reported and fixed issues. We are now at the Release Candidate stage, finalizing everything so that we can release 3.5-stable for all users.
At this stage we need people to test this release (and potential follow-up RCs) on as many projects as possible, to make sure that we catch non-obvious regressions that might have gone unnoticed until now. If you run into any issue, please make sure to report it on GitHub so that we can know about it and fix it!
This RC 6 has a few notable changes compared to the previous build:
In RC 4, async shader compilation and caching was enabled by default on desktop, but several users reported issues with it on some hardware. We switched it back to disabled by default for all platforms. You can enable it in the Project Settings (rendering/gles3/shaders/shader_compilation_mode).
In 3.4, input accumulation was mistakenly turned off, and we only realized this regression after 3.4 had had multiple maintenance releases. In this build we turned it back on by default, which should be beneficial for most projects, aside from those that need very precise input (multiple mouse motion events per frame). You can toggle it with Input.set_use_accumulated_input().
Fixes to Android scoped storage support added in RC 5.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that the first time a material is used under certain conditions (types of lights, shadowing enabled or not, etc.) rendering may be slower for a second or two, but the slowdown will not be nearly as bad as the typical hiccup caused by classic synchronous compilation. On the most powerful devices it may be even unnoticeable. Please test this thoroughly and let us know how it performs on your projects.
This feature is disabled by default, and can be enabled in the Project Settings.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020! Then smix8 took over the custody of this area, fixing a lot of bugs and improving the feature set greatly, with the help of Pawel Lampe (Scony).
The new NavigationServer adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime. The whole API is now a lot more flexible than it used to be.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in the updated docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New Label3D and TextMesh backported from Godot 4.0 (GH-61276, GH-61281)
Long awaited, Godot now provides a Label3D node out of the box to display text in 3D scenes. And for more advanced use cases, there is now also TextMesh to generate 3D meshes from font glyphs, so you can add Word Art to your scenes ;)
Both features were implemented by our text rendering expert bruvzg in the master branch for Godot 4.0, and backported to 3.5.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5.
And more!
3D: Add Label3D node and Sprite3D material render priority (GH-61276).
3D: Add TextMesh and expose dynamic font vector outlines (GH-61281).
3D: Add process_mode property to InterpolatedCamera (GH-41402).
Android: Initial port of the Godot editor (GH-57747).
Android: Add full support for Android scoped storage (GH-51815).
Android: Upgrade Android NDK to r23 LTS (GH-61692).
Android: Fix flickering issues with low processor mode (GH-59606).
Fixes a lot of issues with KinematicBody collisions at the intersection between meshes when using Bullet. This was merged fairly late (3.5 RC 2), please make sure to test it.
Physics: Bullet: Do not set gravity and damping when Custom Integrator is enabled (GH-62708).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release candidate. 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.4.x no longer works in this 3.5 RC).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-rc-7/index.html b/article/release-candidate-godot-3-5-rc-7/index.html
index 9f2d92a636..686003e3f6 100644
--- a/article/release-candidate-godot-3-5-rc-7/index.html
+++ b/article/release-candidate-godot-3-5-rc-7/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde22 July 2022
The upcoming Godot 3.5 is now considered feature complete, and has received a lot of bugfixes and improvements over the past weeks thanks to all the testers and developers who reported and fixed issues. We are now at the Release Candidate stage, finalizing everything so that we can release 3.5-stable for all users.
At this stage we need people to test this release (and potential follow-up RCs) on as many projects as possible, to make sure that we catch non-obvious regressions that might have gone unnoticed until now. If you run into any issue, please make sure to report it on GitHub so that we can know about it and fix it!
This RC 7 has a few notable changes compared to the previous build:
Fix accumulated input handling on iOS.
Fix a regression with file copy performance on Android.
Ignore support for S3TC texture compression on Android and iOS devices in GLES3 (already done since 3.4 for GLES2).
Add global_translation and global_rotation to Spatial.
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that the first time a material is used under certain conditions (types of lights, shadowing enabled or not, etc.) rendering may be slower for a second or two, but the slowdown will not be nearly as bad as the typical hiccup caused by classic synchronous compilation. On the most powerful devices it may be even unnoticeable. Please test this thoroughly and let us know how it performs on your projects.
This feature is disabled by default, and can be enabled in the Project Settings.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020! Then smix8 took over the custody of this area, fixing a lot of bugs and improving the feature set greatly, with the help of Pawel Lampe (Scony).
The new NavigationServer adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime. The whole API is now a lot more flexible than it used to be.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in the updated docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New Label3D and TextMesh backported from Godot 4.0 (GH-61276, GH-61281)
Long awaited, Godot now provides a Label3D node out of the box to display text in 3D scenes. And for more advanced use cases, there is now also TextMesh to generate 3D meshes from font glyphs, so you can add Word Art to your scenes ;)
Both features were implemented by our text rendering expert bruvzg in the master branch for Godot 4.0, and backported to 3.5.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5.
And more!
2D: Fix Camera2D position not updating correctly (GH-63084).
2D: Fix CanvasItem not exiting its canvas group on canvas exit (GH-63234).
3D: Add Label3D node and Sprite3D material render priority (GH-61276).
3D: Add TextMesh and expose dynamic font vector outlines (GH-61281).
3D: Add process_mode property to InterpolatedCamera (GH-41402).
3D: Add global_translation and global_rotation to Spatial (GH-63058).
Android: Initial port of the Godot editor (GH-57747).
Android: Add full support for Android scoped storage (GH-51815).
Android: Upgrade Android NDK to r23 LTS (GH-61692).
Android: Fix flickering issues with low processor mode (GH-59606).
GDNative: Add Core API 1.3 with methods: Dictionary.merge(), Pool*Arrayhas() and sort(), PoolStringArray.join(), Stringjoin(), num_uint64() and num_uint64_capitalized().
GDScript: Fix variable type inference on release (GH-57851).
GDScript: Don’t coerce default values to the export hint type (GH-58686).
GDScript: Enable method type information on release builds (GH-59793).
GDScript: Fix autocompletion showing core class names with an underscore (GH-62731).
GDScript: LSP: Fix wrong parentheses for function call autocompletion (GH-59482).
Fixes a lot of issues with KinematicBody collisions at the intersection between meshes when using Bullet. This was merged fairly late (3.5 RC 2), please make sure to test it.
Physics: Bullet: Do not set gravity and damping when Custom Integrator is enabled (GH-62708).
Physics: Fix the calculation of the angular velocity (GH-63190).
Rendering: Add support for saving multiple Images in BakedLightmap (GH-58102).
Rendering: Bind mesh merging functionality in MeshInstance (GH-57661).
Rendering: GLES2: Unpack blend shape arrays when necessary (GH-60829).
Rendering: GLES3: Ignore support for S3TC texture compression on Android and iOS devices (GH-62909).
Few devices support this compression while they all support ETC2. Godot exports ETC2 by default and doesn’t take into account that mobile devices could need S3TC.
Rendering: GLES3: Unbind vertex buffer before calculating blend shapes (GH-60832).
Rendering: Portals: Show gridmaps using global mode (GH-60851).
Rendering: Fix viewport with transparent background changed to solid black if enabling FXAA or debanding (GH-54585).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release candidate. 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.4.x no longer works in this 3.5 RC).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-5-rc-8/index.html b/article/release-candidate-godot-3-5-rc-8/index.html
index 68d2d588b3..12aa45b8e4 100644
--- a/article/release-candidate-godot-3-5-rc-8/index.html
+++ b/article/release-candidate-godot-3-5-rc-8/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde28 July 2022
The upcoming Godot 3.5 is now considered feature complete, and has received a lot of bugfixes and improvements over the past weeks thanks to all the testers and developers who reported and fixed issues. We are now at the Release Candidate stage, finalizing everything so that we can release 3.5-stable for all users.
At this stage it’s really close to stable, we just had a few more regression fixes merged since the previous build that warrant another build for testing:
A long awaited solution to shader compilation stuttering on OpenGL, courtesy Pedro J. Estébanez (RandomShaper)!
This new system uses an “ubershader” (big shader supporting all features, slow but compiled on startup) to fill in for all shaders initially while the more efficient and material-specific shaders get compiled asynchronously, and cached for future runs.
This means that the first time a material is used under certain conditions (types of lights, shadowing enabled or not, etc.) rendering may be slower for a second or two, but the slowdown will not be nearly as bad as the typical hiccup caused by classic synchronous compilation. On the most powerful devices it may be even unnoticeable. Please test this thoroughly and let us know how it performs on your projects.
This feature is disabled by default, and can be enabled in the Project Settings.
Add NavigationServer with obstacle avoidance using RVO2 (GH-48395)
Jake Young (Duroxxigar) backported the refactored and much improved navigation system that Andrea Catania (AndreaCatania) implemented for Godot 4.0 back in 2020! Then smix8 took over the custody of this area, fixing a lot of bugs and improving the feature set greatly, with the help of Pawel Lampe (Scony).
The new NavigationServer adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime. The whole API is now a lot more flexible than it used to be.
The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide a lot more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4.
In Godot, while physics runs at a fixed tick rate, frames can actually display at a wide variety of frame rates, depending on the player’s hardware. This can lead to a problem, when the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, giving unsightly jitter.
Thanks to lawnjelly’s expertise, you will now find a sweet new option hidden in the project settings. Switch on physics/common/physics_interpolation, and Godot will now automatically interpolate objects on rendered frames so they look super smooth.
In order to benefit you should be moving your objects and running your game logic in _physics_process(). This ensures your game will run the same on all machines. Full details are available in the updated docs.
Fixed timestep interpolation is 3D only for now, but watch this space as we plan to add 2D support after initial feedback and bugfixing on the 3D version.
Following on from the addition of OccluderShapeSphere in 3.4, lawnjelly now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad.
You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view.
Two years ago (!), thebestnom started working on an Android port of the Godot editor (GH-36776). Since the Godot editor is built with Godot itself, it wasn’t too difficult to imagine compiling the editor for Android with some buildsystem changes. But a lot of work was needed to actually make this compiled version work decently on an Android device, with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop.
With a lot of testing from interested users, things progressed slowly but steadily, and our Android maintainer Fredia Huya-Kouadio (m4gr3d) put the finishing touches to get this work merged for Godot 3.5 (GH-57747). The current version doesn’t have a lot of mobile specific changes, so it’s only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we’re interested in your feedback and ideas son how to make the Godot experience more mobile friendly!
From now on you’ll find builds of the Android editor as <godot_version>_android_editor.apk in the download repository. Note that builds are currently not signed, so you will get a warning on install. Give it a try!
With helpful input from contributors Dan Edwards (Gromph) and Péter Magyar (Relintai), Fredia was also able to fix the low processor usage mode on Android (GH-59606), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life.
New Label3D and TextMesh backported from Godot 4.0 (GH-61276, GH-61281)
Long awaited, Godot now provides a Label3D node out of the box to display text in 3D scenes. And for more advanced use cases, there is now also TextMesh to generate 3D meshes from font glyphs, so you can add Word Art to your scenes ;)
Both features were implemented by our text rendering expert bruvzg in the master branch for Godot 4.0, and backported to 3.5.
New SceneTreeTween backported from Godot 4.0 (GH-60581)
Tomasz Chabora (KoBeWi) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Early testers so far seemed to like, and Haoyu Qiu (timothyqiu) decided to backport the feature to Godot 3.5 as SceneTreeTween (to keep the pre-existing Tween and thus preserve compatibility). So you now have two separate Tween implementations and can use to keep using the original 3.x one, or adopt the new API from 4.0.
To help with the common task of accessing specific nodes from scripts, Juan Linietsky (reduz) added the concept of “scene unique names” for nodes in the master branch (GH-60298), and Tomasz backported it for 3.5. Nodes with a scene unique name can be referenced easily within their scene using a new % name prefix, like so: get_node("%MyUniqueNode"). This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things.
Add push, pull, fetch and improved diff view to VCS UI (GH-53900)
What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official Git integration plugin. Check out the Releases page for the latest 2.x plugin release supporting Godot 3.5.
And more!
2D: Fix Camera2D position not updating correctly (GH-63084).
2D: Fix CanvasItem not exiting its canvas group on canvas exit (GH-63234).
3D: Add Label3D node and Sprite3D material render priority (GH-61276).
3D: Add TextMesh and expose dynamic font vector outlines (GH-61281).
3D: Add process_mode property to InterpolatedCamera (GH-41402).
3D: Add global_translation and global_rotation to Spatial (GH-63058).
Android: Initial port of the Godot editor (GH-57747).
Android: Add full support for Android scoped storage (GH-51815).
Android: Upgrade Android NDK to r23 LTS (GH-61692).
Android: Fix flickering issues with low processor mode (GH-59606).
Export: Return 0 exit code when command line export succeeds with warnings (GH-62907).
GDNative: Add Core API 1.3 with methods: Dictionary.merge(), Pool*Arrayhas() and sort(), PoolStringArray.join(), Stringjoin(), num_uint64() and num_uint64_capitalized().
GDScript: Fix variable type inference on release (GH-57851).
GDScript: Don’t coerce default values to the export hint type (GH-58686).
GDScript: Enable method type information on release builds (GH-59793).
GDScript: Fix autocompletion showing core class names with an underscore (GH-62731).
GDScript: LSP: Fix wrong parentheses for function call autocompletion (GH-59482).
Fixes a lot of issues with KinematicBody collisions at the intersection between meshes when using Bullet. This was merged fairly late (3.5 RC 2), please make sure to test it.
Physics: Bullet: Do not set gravity and damping when Custom Integrator is enabled (GH-62708).
Physics: Fix the calculation of the angular velocity (GH-63190).
Rendering: Add support for saving multiple Images in BakedLightmap (GH-58102).
Rendering: Bind mesh merging functionality in MeshInstance (GH-57661).
Rendering: GLES2: Unpack blend shape arrays when necessary (GH-60829).
Rendering: GLES3: Ignore support for S3TC texture compression on Android and iOS devices (GH-62909).
Few devices support this compression while they all support ETC2. Godot exports ETC2 by default and doesn’t take into account that mobile devices could need S3TC.
Rendering: GLES3: Unbind vertex buffer before calculating blend shapes (GH-60832).
Rendering: Portals: Show gridmaps using global mode (GH-60851).
Rendering: Fix viewport with transparent background changed to solid black if enabling FXAA or debanding (GH-54585).
VisualShader: Add hints and default values to the uniform nodes (GH-56466).
Windows: Improve console handling and execute (GH-55987).
This changes the editor console handling to be like on Unix systems (Linux and macOS). So Godot doesn’t open with a console by default, but you can see console output if you start it from a console yourself. You can create a batch script or shortcut to automatically start Godot from a console as in previous releases.
Mono build (C# support + all the above). You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.182 are included in this build.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release candidate. 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.4.x no longer works in this 3.5 RC).
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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-3-6-rc-1/index.html b/article/release-candidate-godot-3-6-rc-1/index.html
index fc8d638e6e..7b47df3143 100644
--- a/article/release-candidate-godot-3-6-rc-1/index.html
+++ b/article/release-candidate-godot-3-6-rc-1/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript, GDNative, and VisualScript.
.NET build includes support for C#, as well as GDScript, GDNative, and VisualScript.
You need to have dotnet CLI or MSBuild installed to use the Mono build. Relevant parts of Mono 6.12.0.198 are included in this build.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 3.x releases no longer works in this release).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-1-rc-1/index.html b/article/release-candidate-godot-4-0-1-rc-1/index.html
index b4a599fb81..75934aad1c 100644
--- a/article/release-candidate-godot-4-0-1-rc-1/index.html
+++ b/article/release-candidate-godot-4-0-1-rc-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov15 March 2023
Two weeks ago we have published the biggest release in the history of Godot — Godot 4.0. It marked the beginning of a new journey for the engine and its users, like yourself. And as is the case with every new beginning, some problems have been reported, some points of frictions have been identified, and so fixes and improvements are in order.
For the time being we are primarily focusing on changes that address critical issues (such as crashes and regressions), as well as small self-contained fixes to various parts of the engine and documentation improvements. This allows us to publish this patch release quickly and with a lot of confidence that it doesn’t introduce new problems and regressions in the process. As such, we are starting directly with a Release Candidate.
Please give it a try if you can. It should be safe to migrate your existing projects to 4.0.1, but to make sure of that we need your help testing the changes. If there are no significant regressions reported with release candidates, a stable version is going to be published soon. Don’t forget to always make backups when moving versions, even minor. Better yet, prefer using a version control system, such as Git, and commit a version of your project before the migration.
Highlights
This release candidate includes some changes which may interest a lot of users:
Multiple conditions for crashes and freezes have been addressed throughout the editor and the engine.
The project converter has been improved with new renames and corrections to its behavior around various scripting statements.
Numerous improvements to the documentation and translations.
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0, but no longer works in 4.0.1 RC 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-1-rc-2/index.html b/article/release-candidate-godot-4-0-1-rc-2/index.html
index a9fa33cea1..31eddded2b 100644
--- a/article/release-candidate-godot-4-0-1-rc-2/index.html
+++ b/article/release-candidate-godot-4-0-1-rc-2/index.html
@@ -6,7 +6,7 @@
Yuri Sizov17 March 2023
The first patch release of Godot 4 is almost ready. Following on the heels of the biggest release in the history of Godot, 4.0.1 is focused on the most critical issues, as well as smaller usability improvements that we can fit with confidence they will not introduce any new problems and regressions. A couple of days ago we released the first Release Candidate, and it’s already the time for another preview, with the stable release being just around the corner.
Please give it a try if you can. It should be safe to migrate your existing projects to 4.0.1, but to make sure of that we need your help testing the changes. If there are no significant regressions reported with release candidates, a stable version is going to be published soon. Don’t forget to always make backups when moving versions, even minor. Better yet, prefer using a version control system, such as Git, and commit a version of your project before the migration.
Highlights
This release candidate includes some changes which may interest a lot of users:
You can no longer create new projects in non-empty folders, as well as your OS-specific user/home folder. We also removed the ability to delete local files when removing a project from the project list (GH-74974).
Both of these functionalities are situationally useful, but also create many opportunities for undesirable side-effects. We had several reports from users accidentally creating projects in their home directory and making the editor import everything stored there, as well as others who accidentally deleted their entire user directory. This makes these functionalities too dangerous to leave as is, and we would prefer to revisit them when we can make a better UI that prevents such accidents.
The illustration picture is fromLumberyard Bistro, a demo scene originally created by the Amazon Lumberyard team in 2017 (Creative Commons CC-BY 4.0) and then ported to Godot 4.0 by Logan Preshaw. You can learn more about the process and get the scene on GitHub, and you can follow Logan on Twitter. The picture also features human models from Renderpeople, not included with the demo.
What’s new
See the full changelog on GitHub for an overview of all changes since 4.0.1-rc1 (13 commits – excluding merge commits ― from 11 contributors).
Some of the most notable feature changes in this update are:
Editor: Fix MultiNodeEdit not cleared after deleting nodes (GH-74795).
Editor: Disallow creating a project in the Home or Documents folder (GH-74964).
Editor: Fix error when opening Inspector’s dots menu (GH-74974).
Input: Fix InputEventConfigurationDialog modifies original event (GH-74858).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0, but no longer works in 4.0.1 RC 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-2-rc-1/index.html b/article/release-candidate-godot-4-0-2-rc-1/index.html
index a6b0186286..da2642608e 100644
--- a/article/release-candidate-godot-4-0-2-rc-1/index.html
+++ b/article/release-candidate-godot-4-0-2-rc-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov31 March 2023
This March was all about GDC for the majority of Godot maintainers. We had a blast hosting multiple Godot game developers and talking to people in the community and industry about our little open source engine! We have a lot to tell you about the future of Godot, and we have a lot of plans for the work that needs to be done. Be sure to keep an eye on this blog and our social accounts for more news and stories to come.
While the conference and the events around it were happening, the development of the engine itself didn’t stop for a day! Thanks to tireless contributors we have released Godot 4.0.1 two weeks ago, and now we are getting ready to release a second patch release. With it we keep focusing on the immediate issues, crashes, and smaller usability improvements, that can be safely made available to you right now.
As this is a Release Candidate, we don’t expect any new problems and encourage you to give it a try. It should be safe to migrate your existing projects to 4.0.2, but to make sure of that we need your help testing the changes. If there are no significant regressions reported with release candidates, a stable version is going to be published soon. Don’t forget to always make backups when moving versions, even minor. Better yet, prefer using a version control system, such as Git, and commit a version of your project before the migration.
Highlights
This release candidate includes some changes which may interest a lot of users:
macOS users have been experiencing editor crashes when trying to save scenes with a key combination or from the top menu, which has now been fixed (GH-75254).
There were several reports on Windows of the editor randomly ignoring keys after alt-tabbing or pressing the Win key; this has also been fixed (GH-75172).
The Android platform has received a number of improvements, including support for SDK 33 (Android 13) (GH-75203).
The engine will no longer try to load unsupported compressed texture formats in exported projects (GH-74684).
The illustration picture is from3D Balls Pool— one of many playable demos made by the team at GDQuest to showcase the new features of Godot 4. You have probably seen many of them in the Godot 4.0 release post. The entire collection is available on GitHub, and you can download it, learn how it all works, and play around yourself! The GDQuest folks also produce quality YouTube tutorials and professional courses for Godot.
What’s new
See the full changelog on GitHub for an overview of all changes since 4.0.1-stable (92 commits – excluding merge commits ― from 50 contributors).
Some of the most notable feature changes in this update are:
2D: Use 8×8 default grid size for TextureRegion and 2D polygon editors (GH-73685).
2D: Fix preview rendering and transform calculations in the tiles editor (GH-74982).
2D: Fix ENTER_CANVAS / VISIBILITY_CHANGED notification order when CanvasItem enters tree (GH-75238).
2D: Fix a crash in the tiles editor when merging atlases (GH-75361).
2D: Don’t allow selecting nodes without owner in the editor (GH-75492).
3D: Fix GridMap signal cell_size_changed disconnect error (GH-74890).
Android: Use the new API for virtual keyboard height detection on Android, bugfix for old API (GH-74398).
Android: Configure maven central snapshot versions for the Godot Android library (GH-74470).
Android: Add “filesRoot” path to Android provider paths xml (GH-74673).
Android: Fix directory access when the running app has the All files access permission (GH-75146).
Android: Bump the target SDK version to 33 (Android 13) (GH-75203).
Animation: Update property keying state without a full Inspector rebuild (GH-74564).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0, but no longer works in 4.0.2 RC 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-3-rc-1/index.html b/article/release-candidate-godot-4-0-3-rc-1/index.html
index 3a27436f3a..ee5644bd99 100644
--- a/article/release-candidate-godot-4-0-3-rc-1/index.html
+++ b/article/release-candidate-godot-4-0-3-rc-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov27 April 2023
The development of Godot 4.1 is going strong, with many performance improvements, new features, and usability enhancements in the works. An early preview of the upcoming minor release is available now, and we can’t wait to show you more of what’s cooking in the weeks to come.
Godot has strong foundations, and this means that many improvements can be done without breaking compatibility. Thanks to that, we’ve been able to release 2 patch releases for Godot 4.0 so far, with the latest one being published just 3 weeks ago. And now it’s time for the third one, Godot 4.0.3. With patch releases for stable versions of the engine our focus is on the immediate issues, crashes, and smaller usability improvements, that can be safely made available to you right now.
This is a Release Candidate to help us finalize the release before going live. We don’t expect any new problems and encourage you to give it a try. It should be safe to migrate your existing projects to 4.0.3, but to make sure of that we need your help testing the changes. If there are no significant regressions reported with release candidates, a stable version is going to be published soon. Don’t forget to always make backups when moving versions, even minor. Better yet, prefer using a version control system, such as Git, and commit a version of your project before the migration.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about included changes.
The illustration picture is fromAnimation Retargeting— one of many playable demos made by the team at GDQuest to showcase the new features of Godot 4. You have probably seen many of them in the Godot 4.0 release post. The entire collection is available on GitHub, and you can download it, learn how it all works, and play around yourself!
What’s new
67 contributors made 149 pull-requests (or 154 commits) since Godot 4.0.2. We now have a great interactive changelog you can use to review all these changes more extensively, with convenient links to the relevant PRs on GitHub.
Some of the most notable feature changes in this update are:
2D: Fix RemoteTransform2D could fail to update AnimatableBody2D’s position or rotation (GH-75487).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.0.x releases, but no longer works in 4.0.3 RC 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-3-rc-2/index.html b/article/release-candidate-godot-4-0-3-rc-2/index.html
index a7764216d9..78fef52ee2 100644
--- a/article/release-candidate-godot-4-0-3-rc-2/index.html
+++ b/article/release-candidate-godot-4-0-3-rc-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde12 May 2023
The development of Godot 4.1 is going strong, with many performance improvements, new features, and usability enhancements in the works. An early preview of the upcoming minor release is available now, and we can’t wait to show you more of what’s cooking in the weeks to come.
Godot has strong foundations, and this means that many improvements can be done without breaking compatibility. Thanks to that, we’ve been able to release 2 patch releases for Godot 4.0 so far, with the latest one being published in early April. And now it’s time for the third one, Godot 4.0.3. With patch releases for stable versions of the engine our focus is on the immediate issues, crashes, and smaller usability improvements, that can be safely made available to you right now.
This is a Release Candidate to help us finalize the release before going live. We don’t expect any new problems and encourage you to give it a try. It should be safe to migrate your existing projects to 4.0.3, but to make sure of that we need your help testing the changes. If there are no significant regressions reported with release candidates, a stable version is going to be published soon. Don’t forget to always make backups when moving versions, even minor. Better yet, prefer using a version control system, such as Git, and commit a version of your project before the migration.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about included changes.
If you use the Godot editor port on Android, you might be interested in joining our closed testing group, to get access to such 4.0.x release candidates and 4.1 development snapshots through the Play Store. Your tests are very important for us to bring it closer to production ready for all Android users.
The illustration picture is fromOut For Delivery, a Ludum Dare 53 jam game by Groundwater Studio, developed with Godot 4.0. You can play the game on the Ludum Dare website and follow the team on itch.io, which plans to develop it further. The game source code is also available on GitHub.
What’s new
43 contributors made 70 commits since Godot 4.0.3 RC 1. We now have a great interactive changelog you can use to review all these changes more extensively, with convenient links to the relevant PRs on GitHub.
Some of the most notable feature changes in this update are:
GUI: Fix right click in selection of additional caret (GH-76472).
Import: Fix animation silhouette using incorrect index (GH-76499).
Import: Use DXT1 when compressing PNGs with RGB format (GH-76516).
Import: gltf: Permit sparse accessors without a bufferView (GH-76875).
Porting: Android: Allow concurrent buffering and dispatch of input events (GH-76399).
This change should fix reports of ANRs (Application Not Responding) that some users have experienced with Godot 4.0. Please test it thoroughly to make sure that it solves your issues without regression.
Porting: Android: Fix double tap & drag on Android (GH-76791).
Porting: iOS: Fix loading of GDExtension dylibs auto converted to framework (GH-76510).
Porting: Linux: Ensure WindowData minimized/maximized are mutually exclusive (GH-76868).
Porting: Linux: Don’t use udev for joypad hotloading when running in a sandbox (GH-76961).
Porting: Windows: Support long path in file access (GH-76739).
Rendering: Fix GLES3 rendering on Android studio emulator (GH-74945).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.0.x releases, but no longer works in 4.0.3 RC 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-4-rc-1/index.html b/article/release-candidate-godot-4-0-4-rc-1/index.html
index c2c0baa6bc..cd3d0458ec 100644
--- a/article/release-candidate-godot-4-0-4-rc-1/index.html
+++ b/article/release-candidate-godot-4-0-4-rc-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov21 July 2023
We are committed to providing support for multiple minor versions of Godot at the same time, as long as we have the capacity to do the work and there are fixes that can be safely backported. So even if your project cannot be migrated to Godot 4.1 right now, we still want to share with you some positive changes.
It has been a few weeks since the release of Godot 4.0.3, which means it’s high time for the next maintenance version! As is always the case with patch releases, 4.0.4 is focused on stability and bug fixes, as well as adding missing documentation. One important change in this release is a security fix for a potential denial of service when using ENet:
If your project uses ENetMultiplayerPeer or the low-level ENetConnection, then we strongly recommend updating to this version once it is released as stable. Be sure to test the build right now to prepare and have a smooth transition. Thanks to Facundo Fernández for reporting this vulnerability. A patch has been submitted to the upstream ENet repository as well.
This is a Release Candidate, which means that we don’t expect regressions or new major issues. Please give it a good test if you are currently using Godot 4.0 in your project. Unless a critical problem is discovered, a stable release will follow RC 1 shortly. Remember to always make backups when changing engine version, or better yet, prefer using a version control system, such as Git, to have a safety net in cases of data corruption or loss.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is from a game calledSunken Shadows. It’s a 32-bit first person roguelike created by a team of Milan Gruner and friends with Godot 4. Fight aquatic creatures with your trusty knife which doubles as a grappling hook, and learn what lurks down below! You can get the game, currently in development, from itch.io. And make sure to follow Milan for more updates, or just to chat, on Twitter or Mastodon.
What’s new
72 contributors submitted almost 160 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Below are the most notable changes:
2D: Don’t create bones from empty scene (GH-77473).
If you have relied on the previous behavior of this method, this change may lead to unexpected issues. You can fix them by replacing calls to get_bone_global_pose_no_override(bone) with get_bone_global_pose(get_bone_parent(bone)) * get_bone_pose(bone), which should give you the same value as before.
This change may be reverted before going stable as behavioral changes, even to fix bugs, are out of scope for maintenance releases for this very reason.
Standard build includes support for GDScript and GDExtension.
.NET 6 build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.0.x releases, but no longer works in 4.0.4 RC 1).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-rc-1/index.html b/article/release-candidate-godot-4-0-rc-1/index.html
index 02f297a2e6..ec8c9a30be 100644
--- a/article/release-candidate-godot-4-0-rc-1/index.html
+++ b/article/release-candidate-godot-4-0-rc-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov8 February 2023
This has been a long road, but the exciting times are upon us! Thanks to our excellent contributors and our brave volunteer beta testers we are reaching the biggest milestone in the history of Godot so far. We are about to release Godot 4.0 stable. We are very proud of how it has shaped up, the features and enhancements that have been implemented, and most of all, we are proud to have collected such a brilliant team of talented individuals who have carried this major release on their wide and mighty shoulders.
But before we can cut the ribbon and break out the champagne, there are still a few preview releases we must go through, to establish, with your help, that we are truly ready. What you can expect from the next couple of weeks is the same cadence of official builds, aiming to minimize the iteration time between fixing bugs and checking for regressions. We will no longer make any breaking changes or include further enhancements. New features will have to wait for Godot 4.1 later this year. Instead, we will be coming down on the last critical issues we want to be resolved before we ship the first stable release of Godot 4.
There certainly will be remaining bugs, and your experience won’t be as frictionless as it is in the current stable version of Godot 3. It will take time to get to the same level of polish, but hopefully less time than before, thanks to our extended team of developers, and also new members learning about Godot only now and sharing their valuable feedback.
We are committed to evolving the engine further, and hope to see more of your amazing Godot projects soon!
Highlights
As we keep iterating from previous beta releases, these release notes are focused on the most recent changes (since beta 17). If you’re interested in what major features ship with Godot 4.0, check out our blog post for beta 1. Stay tuned for more articles about new features as we get closer to the stable version.
This release candidate includes some big changes which may interest a lot of users:
A large number of invalid behaviors is now correctly validated and reported in GDScript files (GH-72608). This includes some behaviors that previously appeared as working correctly but were never actually supported by the engine (such as override/shadowing of the engine’s native methods). You can turn errors into warnings, or disable them completely if you need to.
CanvasGroup nodes will no longer appear darker than they should due to an incorrect shading logic (GH-72695).
The remaining reported cases of sub-resources IDs being shuffled without user input should now be resolved (GH-72257). While the issue should be fixed, this is not the final solution to the problem. We will continue improving the underlying systems in future versions of Godot to avoid this kind of situation.
A list of all global scripted classes can now be accessed with a new method, ProjectSettings.get_global_class_list() (GH-71665). This method provides the information about your custom classes, which you cannot fetch from ClassDB, and previously had to parse from the project file, or a cache file.
Under certain conditions, namely when particles were involved, stepping through the debugger might have been extremely slow and unresponsive. This should now be fixed (GH-72827).
Translation resources have been reorganized to reduce their impact on the size of the main repository (GH-70623). We have also finished setting up the Weblate platform for Godot 4, so translation efforts can begin!
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is fromSophia’s Rainbow, an upcoming open-source 3D platformer controller demo. It’s being created in Godot 4.0 beta by GDQuest, and you can check out their existing tutorials and projects in the meantime.
What’s new
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 beta 17 (136 commits – excluding merge commits ― from 53 contributors).
The first Release Candidate concludes the beta stage, and thus it still includes a few API changes which may impact your Godot 4 projects. See the list of PRs with the breaks compat label for details.
Some of the most notable feature changes in this update are:
Android: Rename Godot’s ‘custom build’ to ‘gradle build’ to better reflect the underlying build process (GH-72552).
Requires .NET SDK 6.0 or 7.0 installed in a standard location. .NET 7.0 support was recently merged and requires testing, please report any issue you experience with either version.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
You will likely see this list reduced drastically over the coming days as we continue to re-triage those issues and postpone the ones that are not critical for the 4.0 release.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release, there are going to be compatibility-breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-rc-2/index.html b/article/release-candidate-godot-4-0-rc-2/index.html
index 0b977ca054..315c999e10 100644
--- a/article/release-candidate-godot-4-0-rc-2/index.html
+++ b/article/release-candidate-godot-4-0-rc-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde14 February 2023
The Godot 4.0 release is mere days away! We’ve had a first release candidate last week, and since then our contributors have been fully focused on fixing regressions and critical bugs to ensure that the upcoming 4.0 release will be a great foundation to build upon.
The Production team has been hard at work assessing the remaining PRs and issues in the 4.0 milestone, pushing non-critical or risky changes to the 4.1 milestone, or prioritizing what could actually still be done so close to the release. Astute watchers of the 4.0 milestone’s completion ratio will have noticed a significant increase, but that doesn’t mean that all issues are being solved. Some will be fixed in time for 4.1, and cherry-picked for 4.0.x maintenance releases along the way.
Regardless of which milestone our contributors assign to your issues, be sure to keep reporting any major or minor problem you’re having with 4.0 RC 2! Your test reports at this stage are critical for us to assess whether we can finally stamp the current development branch as “stable” and release it to all platforms.
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture for this article is fromMaster of Chess, an upcoming chess player management game by BRANE. It’s being developed with Godot 4.0, and you can follow development on Twitter and wishlist it on Steam.
What’s new
As usual, this blog post only details the most recent changes since the last build, 4.0 RC 1. If you’re interested in what major features ship with Godot 4.0, check out our blog post for beta 1.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 RC 1 (136 commits – excluding merge commits ― from 72 contributors).
Some of the most notable feature changes in this update are:
2D: Fix random placement behavior in TileMap editor (GH-61411).
Import: Set Default compression to VRAM uncompressed for LightmapGI (GH-73136).
This fixes a perceived regression where lightmaps starting being compressed to BPTC, which is slow. You should remove the .import files for your baked lightmaps generated with beta 17 or RC 1 if you want to apply this automatically (or change the compression option in the Import tab). Compressing lightmaps is recommended to optimize memory usage once you’re happy with the results, though note that RC 2 still has a known issue exporting BPTC compressed files, which will be fixed in RC 3.
Requires .NET SDK 6.0 or 7.0 installed in a standard location. .NET 7.0 support was recently merged and requires testing, please report any issue you experience with either version.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Exporting BPTC compressed textures (notably HDR textures with EXR format) is not working in this build (GH-72856). The issue has been identified and a fix will be included in 4.0 RC 3 (GH-73286).
OpenGL windows with a keep stretch mode can show graphics artefacts in the bars outside the viewport (GH-71799). This also has a fix queued for 4.0 RC 3 already (GH-73300).
You will likely see this list reduced drastically over the coming days as we continue to re-triage those issues and postpone the ones that are not critical for the 4.0 release.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release, there are going to be compatibility-breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-rc-3/index.html b/article/release-candidate-godot-4-0-rc-3/index.html
index 98bc960dc2..1ce4e6d030 100644
--- a/article/release-candidate-godot-4-0-rc-3/index.html
+++ b/article/release-candidate-godot-4-0-rc-3/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde21 February 2023
For this release candidate we picked a calm, relaxing illustration picture, because that’s what all contributors need now after months and months of hard work to finalize this release. What’s currently in this third release candidate is pretty much what 4.0 stable will be. With all the amazing new features that we’ve often described on this blog and on social media, and with all the remaining bugs and usability issues that we want to iron out for future 4.x releases.
Open source software works best with a release early, release often strategy, and after more than 3 years of foundational work on Godot 4.0, we’re eager to move back to faster paced release cycles to iterate quickly on the more modern and flexible architecture that we’ve built for this major branch. So don’t expect the imminent 4.0 release to be a silver bullet – it will be a stable base for us to build upon, and a good start for you to start developing new projects which will mature alongside Godot 4.x.
You can also try the Web editor (early testing, it’s still slow and unstable).
The illustration picture is from a video tutorial by StayAtHomeDev for making an endless ocean scene with Godot 4.0. StayAtHomeDev make a lot of great Godot content on their YouTube channel, including This Week in Godot, a weekly highlight of cool Godot projects.
What’s new
As usual, this blog post only details the most recent changes since the last build, 4.0 RC 2. If you’re interested in what major features ship with Godot 4.0, check out our blog post for beta 1.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 RC 2 (139 commits – excluding merge commits ― from 68 contributors).
Some of the most notable feature changes in this update are:
2D: Add dash and step size checks to draw_dashed_line() (GH-73444).
This change involves a slight compatibility breakage for the behavior of the is operator. It now requires a type known as compile time, so it’s not possible to use it to check if two variables have the same type. For this, use typeof() or the new is_instance_of() function.
GDScript: Fix error passing null Object argument to functions with typed arguments (GH-73544).
GDScript: Make global scope enums accessible as types (GH-73590).
GUI: Fix multiple window/input issues with ColorPicker (GH-72764).
GUI: Make label sizing algorithm more robust (GH-73343).
GUI: Fix TabBar not redrawing on locale change (GH-73349).
GUI: Fix width determination of non-trimmed, non-wrapped labels (GH-73426).
Import: Ensure that generated import IDs are unique (GH-69810).
Requires .NET SDK 6.0 or 7.0 installed in a standard location. .NET 7.0 support was recently merged and requires testing, please report any issue you experience with either version.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
You will likely see this list reduced drastically over the coming days as we continue to re-triage those issues and postpone the ones that are not critical for the 4.0 release.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release, there are going to be compatibility-breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-rc-4/index.html b/article/release-candidate-godot-4-0-rc-4/index.html
index e5e299a78c..ae25358b91 100644
--- a/article/release-candidate-godot-4-0-rc-4/index.html
+++ b/article/release-candidate-godot-4-0-rc-4/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde23 February 2023
As the stable release is imminent, release candidates become more frequent to validate the last minutes fixes we had to make. This fourth release candidate includes a number of important fixes which we decided to include, and which require heavy testing to ensure that the bugs and regressions that they aim to fix are solved, without introducing new regressions.
The illustration picture is from a demo of the Photo mode add-on developed by Godot contributor Hugo Locurcio for Godot 4.0. It uses CC0 models and textures from PolyHaven.
What’s new
As usual, this blog post only details the most recent changes since the last build, 4.0 RC 3. If you’re interested in what major features ship with Godot 4.0, check out our blog post for beta 1.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 RC 3 (49 commits – excluding merge commits ― from 26 contributors).
Some of the most notable feature changes in this update are:
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Game using HDR texture crashes when exported (texture_format/bptc defaults to false) (GH-73789).
This is a configuration issue, you can set texture_format/bptc to true in your PC export presets, and disable texture_format/no_bptc_fallbacks. The defaults settings will be fixed for the next build.
You will likely see this list reduced drastically over the coming days as we continue to re-triage those issues and postpone the ones that are not critical for the 4.0 release.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release, there are going to be compatibility-breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-rc-5/index.html b/article/release-candidate-godot-4-0-rc-5/index.html
index 49316d73dc..93f238a753 100644
--- a/article/release-candidate-godot-4-0-rc-5/index.html
+++ b/article/release-candidate-godot-4-0-rc-5/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde24 February 2023
It’s been a busy week! We had our third and fourth release candidates on Tuesday and Thursday with a lot of bugfixes, and one regression slipped by! So it’s already time for RC 5 to solve that, as well as a few other major issues which got fixed in the past 24 hours.
The illustration picture is fromThunder Blood, an upcoming twin-stick roguelike shooter developed by Oddlife in Godot 4.0. Follow them on Twitter for updates!
What’s new
As usual, this blog post only details the most recent changes since the last build, 4.0 RC 4. If you’re interested in what major features ship with Godot 4.0, check out our blog post for beta 1.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 RC 4 (15 commits – excluding merge commits ― from 11 contributors).
Some of the most notable feature changes in this update are:
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
One of the changes in this RC was found to introduce a regression for @tool scripts, which can lead to corrupt .tres files for custom resources (GH-73905). This will be fixed for the next RC.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release, there are going to be compatibility-breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-0-rc-6/index.html b/article/release-candidate-godot-4-0-rc-6/index.html
index 988a9e6900..4282d88a4e 100644
--- a/article/release-candidate-godot-4-0-rc-6/index.html
+++ b/article/release-candidate-godot-4-0-rc-6/index.html
@@ -7,7 +7,7 @@
You’re also very welcome to report non-showstopper issues, you’ll probably see us put them in the 4.1 or 4.x milestones, but it helps to have them tracked as early as they’re noticed.
The illustration picture is from a demo scene by Wojtek Pe, showcasing various 3D features of Godot 4.0. Follow them on Twitter and YouTube for more cool Godot 4 devlogs, tutorials, and demos.
What’s new
As usual, this blog post only details the most recent changes since the last build, 4.0 RC 5. If you’re interested in what major features ship with Godot 4.0, check out our blog post for beta 1.
See the changelog on GitHub, or the list of merged PRs, for an overview of all changes since 4.0 RC 5 (22 commits – excluding merge commits ― from 15 contributors).
Some of the most notable feature changes in this update are:
C#: Check if a class is a singleton using the Core name (GH-73882).
Core: Make max() and min() global functions only accept numbers (GH-73881).
Core: Identity compare objects by id, not by pointers (GH-73892).
Core: Fix crash when playing audio-less Theora videos in VideoStreamPlayer (GH-73958).
Core: Fix deadlock in cyclic resource load (GH-73988).
Editor/GUI: Revert “Reordering emitted signals in PopupMenu” and fix editor selection issue in the safer way (GH-73885).
GDScript: Initialize all defaults beforehand in implicit constructor (GH-73899).
GDScript: Fix conversions from native members accessed by identifier (GH-73915).
GDScript: Revert “GDScript: Fix groups and categories been seen as members” (GH-73933).
The reverted commit introduced a bug where it creates spurious entries for member information, potentially damaging scene files (GH-73905).
GDScript: Fix address type for coroutine results (GH-73964).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.0 milestone.
Bug reports
As a tester, you are encouraged to open bug reports if you experience issues with this release. 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.
As in any major release, there are going to be compatibility-breaking changes. However, we still try to provide a migration path for your projects. If you experience a regression without a known migration path or workaround, do not hesitate to report it.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-1-rc-1/index.html b/article/release-candidate-godot-4-1-1-rc-1/index.html
index ec077135f5..8a50b25877 100644
--- a/article/release-candidate-godot-4-1-1-rc-1/index.html
+++ b/article/release-candidate-godot-4-1-1-rc-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov12 July 2023
It was a busy weekend in the Godot-land, as the newly released Godot 4.1 was being viewed, tested, and tried by thousands of developers. The annual GMTK Game Jam by the popular YouTube channel Game Maker’s Toolkit did help quite a lot in that regard! Of course, where there is a lot of users, there is also a lot of highly appreciated reports and suggestions. Plus we had some ready to go from before 4.1 was sealed and shipped.
As always with the first maintenance release (also known as “patch release”) the focus is on quickly addressing urgent concerns and issues, possible regressions and crashes, as well as some aliasing in various workflows. Some of the most important changes include:
Fix for a crash due to an infinite loop in AnimationStateMachine (GH-79141). It was a gnarly issue because it was easy to trigger with a bare minimum configuration. Now circular dependencies are correctly detected preventing infinite looping.
Command-line export of C#/.NET projects should no longer drop random files (GH-79173). Your exports may have had arbitrary resources missing (not C# scripts, but images, for instance), if you were exporting your project with CLI. This should no longer happen.
Custom export options which you can define with an EditorExportPlugin are now correctly restored on the editor restart (GH-79025). Previously the usability of this freshly added feature was limited due to data loss between sessions.
For Linux users there is a potential fix for freezes when interacting with menus on Wayland (GH-79143). This was a hard to identify and debug issue, but our local Wayland enthusiasts managed to pinpoint the likely cause and validate that the unwanted behavior was addressed.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article showcases six amazing entries from the recent GMTK Game Jam, — all made with Godot! Give them a try, leave a comment to the developer, and, of course, consider giving them your vote ❤️ Many more game developers chose Godot for this game jam, so make sure to check the full list of entries and support your fellow creators. Games illustrated in the cover image are as follows:
Yeti Upsetti— a reimagination of classic SkiFree; made with Godot 4.1.
Making the Gamelets you make game design decisions and suffer the consequences; powered by Godot 3.5.1.
Tama-Get-Out!makes you fill the shoes of a pocket pet; developed in Godot 4.1.
Levelrinth— a puzzle platformer where you are the level; created with Godot 4.1.
poki— a creative puzzle game that lets you reconstruct levels before solving them; made with Godot 4.1.
Video Editor’s Toolkitmakes you responsible for creating a video covering GMTK Game Jam 2023; developed in Godot 3.5.2.
What’s new
46 contributors submitted over 70 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Below are the most notable changes:
2D: Improve string drawing in the tiledata editor (GH-78522).
2D: Make sure the shortcut key respects the context in TileSetAtlasSourceEditor (GH-78920).
3D: Fix Camera3D project_* methods not accounting for frustum offset (GH-75806).
3D: Fix 3D viewport grid disappearing on scene tab changes (GH-78694).
Animation: Fix infinite loop state check in AnimationStateMachine (GH-79141).
Animation: Add 3.x compatibility for animation loop mode (GH-79155).
Buildsystem: Linux: Allow unbundling brotli to use system library (GH-79101).
C#: Update the RiderPathLocator to support the JetBrains Toolbox 2.0 (GH-78832).
C#: Compare symbol names without null flow state (GH-79094).
Standard build includes support for GDScript and GDExtension.
.NET 6 build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in the 4.1 release, but no longer works in 4.1.1 RC 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-2-rc-1/index.html b/article/release-candidate-godot-4-1-2-rc-1/index.html
index 0a60f4a5b9..38364ce127 100644
--- a/article/release-candidate-godot-4-1-2-rc-1/index.html
+++ b/article/release-candidate-godot-4-1-2-rc-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov22 September 2023
We have had quite a pause since Godot 4.1.1 — two months without a new patch release (blame the summer break!). So it’s long overdue we have one, starting of course with a release candidate to validate that everything is in order and no new changes introduce regressions.
Godot 4.1.2 contains a number of stability improvements, addressing crashes related to threading, editor features, networking, GUI, and rendering. A significant bug related to allocations of plain objects has been fixed as well, which should improve performance and memory usage, especially at scale (GH-81037). There are also a number of performance fixes in GUI nodes, such as Tree and RichTextLabel, which make parts of the editor UI more responsive (GH-79325, GH-80857). Several optimizations have been made to rendering backends as well.
We have received reports of issues with saving projects on the web platform, and this release resolves these issues (GH-79866), as well as a few other platform-specific bugs. Another important problem fixed in 4.1.2 is doubled input events coming from gamepads when using Steam Input (GH-76045). And as always there is a bunch of smaller, but no less crucial changes and updates!
Maintenance releases are expected to be safe for an upgrade, but we recommend to always make backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article comes fromFisk— an open world survival horror game with Lovecraftian vibes currently being developed by Kristian Nilsen with Godot 4. (It usesQodotfor creating geometry, by the way, which deserves its own shoutout!) You can follow Kristian on Twitter for more updates and you can download Fisk today from its website.
What’s new
56 contributors submitted around 150 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release. Below are the most notable changes:
2D: Fix Camera2D crash when edited scene root is null (GH-79645).
2D: Fix CanvasModulate logic for modulating the canvas (GH-79747).
3D: Fix VoxelGI saving VoxelGIData as a built-in file when prompted to save to an external file (GH-78772).
3D: Change property hint range for camera attributes exposure multiplier (GH-79138).
3D: Fix Curve3D baking up vectors for nontrivial curves (GH-81885).
Animation: Fix Animation::subtract_variant for affine transforms (GH-79279).
Animation: Fix AnimationNodeTransition with negative time scale (GH-79403).
Animation: Remove animation tracks with correct indices (GH-81651).
Standard build includes support for GDScript and GDExtension.
.NET 6 build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.1.x releases, but no longer works in 4.1.2 RC 1).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-3-rc-1/index.html b/article/release-candidate-godot-4-1-3-rc-1/index.html
index 85091da743..3e663b0b4d 100644
--- a/article/release-candidate-godot-4-1-3-rc-1/index.html
+++ b/article/release-candidate-godot-4-1-3-rc-1/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET 6 build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0 or 7.0 installed in a standard location.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.1.x releases, but no longer works in 4.1.3 RC 1).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-4-and-4-2-2-rc-1/index.html b/article/release-candidate-godot-4-1-4-and-4-2-2-rc-1/index.html
index 7b58ba53e4..c5176bbb52 100644
--- a/article/release-candidate-godot-4-1-4-and-4-2-2-rc-1/index.html
+++ b/article/release-candidate-godot-4-1-4-and-4-2-2-rc-1/index.html
@@ -15,7 +15,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by these releases.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases no longer works).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-4-and-4-2-2-rc-2/index.html b/article/release-candidate-godot-4-1-4-and-4-2-2-rc-2/index.html
index ae441090f6..4f7afaf1a4 100644
--- a/article/release-candidate-godot-4-1-4-and-4-2-2-rc-2/index.html
+++ b/article/release-candidate-godot-4-1-4-and-4-2-2-rc-2/index.html
@@ -15,7 +15,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by these releases.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases no longer works).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-4-and-4-2-2-rc-3/index.html b/article/release-candidate-godot-4-1-4-and-4-2-2-rc-3/index.html
index 4153c37e38..0574ac2ecd 100644
--- a/article/release-candidate-godot-4-1-4-and-4-2-2-rc-3/index.html
+++ b/article/release-candidate-godot-4-1-4-and-4-2-2-rc-3/index.html
@@ -15,7 +15,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by these releases.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases no longer works).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-rc-1/index.html b/article/release-candidate-godot-4-1-rc-1/index.html
index 20c15e1bc1..a1d6601cd9 100644
--- a/article/release-candidate-godot-4-1-rc-1/index.html
+++ b/article/release-candidate-godot-4-1-rc-1/index.html
@@ -6,7 +6,7 @@
Yuri Sizov27 June 2023
Godot 4.1 is shaping up to be ready right on schedule. Since the release of beta 3 we have identified all remaining regressions, thanks in a large part to your reports and extensive testing, and with the necessary fixes implemented we are publishing the first Release Candidate today.
This is a great opportunity to give the new version of the engine a try. As the name suggests, a release candidate represents a build that we consider stable but want to be absolutely sure before making it official — with your help. If there are no significant regressions reported with release candidates, a stable version of Godot 4.1 is going to be published soon.
This release contains a number of improvements compared to Godot 4.0 published earlier this year. Some systems have also been reworked, which means projects that rely on those need to be updated. However, for most games and apps made with 4.0 it should be safe to migrate to 4.1. Don’t forget to always make backups when moving versions, even minor. Better yet, prefer using a version control system, such as Git, and commit a version of your project before the migration.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is fromKatana Dragon— an action RPG developed by Tsunoa Games with Godot 4. When the game releases you will be able to venture into a charming voxel world to explore dungeons, avoid traps, and solve puzzles! Follow the development of the game on Twitter so you don’t miss the release date.
What’s new
41 contributors submitted around 70 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
There is a number of major changes in Godot 4.1, and you can read more about them in our earlier announcement. Below are the most notable changes compared to 4.1 beta 3:
2D: Fix click-selecting Sprites with repeated texture (GH-78566).
2D: Tilemaps: Fix tile resizing towards atlas boundary (GH-76152).
2D: Tilemaps: Update indices after removing custom data layers (GH-78492).
C#: Fix editor integration breaking and causing error spam when reloading assemblies fails (GH-75533).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.1 milestone.
Some notable issues are still tracked for a potential fix before 4.1-stable:
The processing order for internal and normal node processing was mistakenly changed, causing issues such as GH-77548. You can help us test GH-78745 to validate that it solves the issue without further regression.
The editor output dock doesn’t update its scrollbar properly in some cases (GH-78434). A potential solution is identified but we’re not sure yet that it’s safe to include in 4.1 at this late stage given the risk of regression.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 RC 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-rc-2/index.html b/article/release-candidate-godot-4-1-rc-2/index.html
index 399cf5acd3..4142b10132 100644
--- a/article/release-candidate-godot-4-1-rc-2/index.html
+++ b/article/release-candidate-godot-4-1-rc-2/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde30 June 2023
Godot 4.1 is shaping up to be ready right on schedule. Over the course of the beta testing phase, and with our first Release Candidate a few days ago, we identified and fixed a number of regressions, i.e. recently introduced bugs that would worsen the experience compared to Godot 4.0. Now we’re fairly confident that we’ve handled most of those, and the remaining issues we’re tracking will likely be deferred to a fix in future 4.1.x maintenance releases.
That is to say, this RC 2 should be the one – if no major regression is identified in coming days, we’ll go ahead and release 4.1 stable, and reopen the development cycle for 4.2, which is scheduled for a release in November 2023. Please keep reporting issues that you encounter with the RC, even if you don’t think they’re critical – while triaging them, we might prioritize them for early on in the 4.2 development cycle, and backport the fixes to 4.1.x.
This release contains a number of improvements compared to Godot 4.0 published earlier this year. Some systems have also been reworked, which means projects that rely on those need to be updated. However, for most games and apps made with 4.0 it should be safe to migrate to 4.1. Don’t forget to always make backups when moving versions, even minor. Better yet, prefer using a version control system, such as Git, and commit a version of your project before the migration.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is fromSkies above the Great War, a hybrid of dogfighting action and grand strategy set during the First World War. It is developed by Puntigames with Godot 4. You can check out their ongoing Kickstarter campaign, wishlist the game on Steam, watch the trailer on YouTube, and follow development on their Discord.
What’s new
11 contributors submitted 15 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
There is a number of major changes in Godot 4.1, and you can read more about them in our earlier announcement. Below are the most notable changes compared to 4.1 RC 1:
2D: Fix crash with failed compatibility tiles (GH-78796).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.1 milestone.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 RC 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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-1-rc-3/index.html b/article/release-candidate-godot-4-1-rc-3/index.html
index 15361464b4..093dfdd853 100644
--- a/article/release-candidate-godot-4-1-rc-3/index.html
+++ b/article/release-candidate-godot-4-1-rc-3/index.html
@@ -6,7 +6,7 @@
Rémi Verschelde4 July 2023
Godot 4.1 is shaping up to be ready right on schedule. Over the course of the beta testing phase, and with our first two Release Candidates last week, we identified and fixed a number of regressions, i.e. recently introduced bugs that would worsen the experience compared to Godot 4.0. Now we’re fairly confident that we’ve handled most of those, and the remaining issues we’re tracking will likely be deferred to a fix in future 4.1.x maintenance releases.
Our contributors managed to fix a few more critical regressions during the testing phase of RC 2, which justified making a third release candidate to validate those changes. If all goes well, we should be on track for a 4.1 release in a few days. Please keep reporting issues that you encounter with the RC, even if you don’t think they’re critical – while triaging them, we might prioritize them for early on in the 4.2 development cycle, and backport the fixes to 4.1.x.
This release contains a number of improvements compared to Godot 4.0 published earlier this year. Some systems have also been reworked, which means projects that rely on those need to be updated. However, for most games and apps made with 4.0 it should be safe to migrate to 4.1. Don’t forget to always make backups when moving versions, even minor. Better yet, prefer using a version control system, such as Git, and commit a version of your project before the migration.
Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.
The illustration picture for this article is fromBravest Coconut, a classic action adventure game following Coco the cat, with brain teasing puzzles to solve. The game is developed by Nathan Hoad (Twitter, Mastodon) and Lilly Piri (Twitter, Mastodon) using Godot 4. Nathan also makes Godot plugins such as Dialogue Manager, and publishes devlogs and Godot tutorials on YouTube.
What’s new
10 contributors submitted 11 improvements for this release. You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
There is a number of major changes in Godot 4.1, and you can read more about them in our earlier announcement. Below are the most notable changes compared to 4.1 RC 2:
C#: Fix NodePaths completion error for not calling from main thread (GH-78928).
Core: Fix management of safe-for-nodes flag in ResourceLoader and WorkerThreadPool (GH-78974).
Core: Workaround resource loading crashes due to buggy TLS (GH-78977).
Editor: Fix node selection not handled correctly at launch (GH-78980).
GDExtension: Fix GDVIRTUAL_NATIVE_PTR by adding missing VariantInternalAccessor specializations (GH-78971).
Requires .NET SDK 6.0 or 7.0 installed in a standard location.
Known issues
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a list of known bugs in the 4.1 milestone.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in 4.0.x, but no longer works in 4.1 RC 3).
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-2-1-rc-1/index.html b/article/release-candidate-godot-4-2-1-rc-1/index.html
index 3d8d01cc04..b138e096d6 100644
--- a/article/release-candidate-godot-4-2-1-rc-1/index.html
+++ b/article/release-candidate-godot-4-2-1-rc-1/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases no longer works in this release).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-2-rc-1/index.html b/article/release-candidate-godot-4-2-rc-1/index.html
index 454006fd1f..fab7dd6e47 100644
--- a/article/release-candidate-godot-4-2-rc-1/index.html
+++ b/article/release-candidate-godot-4-2-rc-1/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
There are currently no known issues introduced by this release.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this release).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-2-rc-2/index.html b/article/release-candidate-godot-4-2-rc-2/index.html
index 229531287e..dd57961a41 100644
--- a/article/release-candidate-godot-4-2-rc-2/index.html
+++ b/article/release-candidate-godot-4-2-rc-2/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
.NET build requires .NET SDK 6.0, 7.0, or 8.0 installed in a standard location.
To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the .csproj file.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
We are aware of some regressions which still affect this release candidate, but which we may not be able to solve in time for the stable release. They’re still tracked as high priority and should be fixed soon in 4.2.x maintenance releases.
TileMap editing performance on macOS got significantly worse when using the ANGLE backend for the Compatibility renderer (GH-84591). We have good hunches for what causes the issue but it will take some time to solve properly. In the meantime, you can change the rendering/gl_compatibility/driver.macos project setting to opengl3 instead of the new default opengl3_angle to restore the 4.1 behavior if you are affected by this regression.
Capture tracks in animations no longer work after the unification of the AnimationPlayer and AnimationTree processing in AnimationMixer (GH-83166). This feature was specific to AnimationPlayer and was lost in the refactoring. We’re evaluating what’s needed to restore this feature.
Another animation issue with audio clips starting at negative times no longer playing back (GH-85088). This should be easy to workaround until we restore that functionality.
With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this release).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-3-rc-1/index.html b/article/release-candidate-godot-4-3-rc-1/index.html
index c4597daf6d..f834c189f3 100644
--- a/article/release-candidate-godot-4-3-rc-1/index.html
+++ b/article/release-candidate-godot-4-3-rc-1/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
During the Release Candidate stage, we focus exclusively on solving showstopping regressions (i.e. something that worked in a previous release is now broken, without workaround). You can have a look at our current list of regressions and significant issues which we aim to address before releasing 4.3. This list is dynamic and will be updated if we discover new blocking issues after more users start testing the RC snapshots.
With every release, we are aware that there are going to be various issues which have already been reported but haven’t been fixed yet, due to limited resources. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-3-rc-2/index.html b/article/release-candidate-godot-4-3-rc-2/index.html
index e15f0e2925..f709608626 100644
--- a/article/release-candidate-godot-4-3-rc-2/index.html
+++ b/article/release-candidate-godot-4-3-rc-2/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
During the Release Candidate stage, we focus exclusively on solving showstopping regressions (i.e. something that worked in a previous release is now broken, without workaround). You can have a look at our current list of regressions and significant issues which we aim to address before releasing 4.3. This list is dynamic and will be updated if we discover new blocking issues after more users start testing the RC snapshots.
With every release, we are aware that there are going to be various issues which have already been reported but haven’t been fixed yet, due to limited resources. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-candidate-godot-4-3-rc-3/index.html b/article/release-candidate-godot-4-3-rc-3/index.html
index 19754175dd..1134fa83f0 100644
--- a/article/release-candidate-godot-4-3-rc-3/index.html
+++ b/article/release-candidate-godot-4-3-rc-3/index.html
@@ -10,7 +10,7 @@
Make a Donation
Standard build includes support for GDScript and GDExtension.
.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.
If you want to test the new Windows ARM64 builds, you will now find them listed in the usual download page.
While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.
Known issues
During the Release Candidate stage, we focus exclusively on solving showstopping regressions (i.e. something that worked in a previous release is now broken, without workaround). You can have a look at our current list of regressions and significant issues which we aim to address before releasing 4.3. This list is dynamic and will be updated if we discover new blocking issues after more users start testing the RC snapshots.
With every release, we are aware that there are going to be various issues which have already been reported but haven’t been fixed yet, due to limited resources. See the GitHub issue tracker for a complete list of known bugs.
Bug reports
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/release-management-4-0-and-beyond/index.html b/article/release-management-4-0-and-beyond/index.html
index 6860b340cb..268af7b1cf 100644
--- a/article/release-management-4-0-and-beyond/index.html
+++ b/article/release-management-4-0-and-beyond/index.html
@@ -7,7 +7,7 @@
Rest assured, we plan to publish bugfix releases quickly and regularly (as we have with the Alphas and Betas). So you can expect versions 4.0.1, 4.0.2, etc. to come shortly after the nominal “4.0-stable” release.
4.x release cycle
To alleviate pressure on contributors and to avoid delays, starting with version 4.1, we aim to have quicker release cycles for feature updates (4.1, 4.2, etc., i.e. “4.x” releases). The plan is to start with a fixed period of merging new features, then transition to a short period where we only merge bug fixes, then release and return to merging features again.
Some features may miss the window for merging, and will be postponed until the next version. But due to quicker iteration times the wait would be much shorter for users, and for contributors — their work won’t go stale. We believe this will help us maintain momentum and ensure that the engine stabilizes quickly (a special thank you to Miguel de Icaza for your insight and encouragement that led us to this decision). At this point we are unsure exactly how long the release cycle will be, you can expect we will experiment a bit to see what works best for contributors.
4.1 will focus on stability, performance improvements, and usability
Early in the 4.0 development cycle, we caught ourselves saying “X feature won’t make it into 4.0, but it will be in 4.1”. Please read such statements as saying “will be in 4.x”. Our decision to focus on quick iteration and stability means we can’t promise new features in any particular release. Features will be included in the next release after they are finished. This also means we will not be delaying releases in order to add “just one more feature”.
The state of 4.0
We are still in the beta phase, and development is more focused than ever on stabilizing Godot 4.0 for release. We are now releasing weekly betas to get faster feedback on our bug fixes.
At the time of the Godot 4.0 release, version 3.5 will remain the much more stable and battle-tested option. We advise users who desire a more stable, bug-free experience to continue using 3.5 until Godot 4 has been more widely tested and the team has had a chance to fix the highest priority bugs that will inevitably arise. Users with ambitious projects that depend on the new features in 4.0 can of course start using it as soon as it releases, while keeping in mind that there might be some roadblocks which will be lifted in the early 4.x releases.
We will release 4.0 when we believe it is ready to be used in production, not when it is perfect. It will not be perfect, and it doesn’t have to be. But it will lay down the foundation for all our future work, and with your help it might get a little bit closer to what we envision as the Godot 4.
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.
-
+
\ No newline at end of file
diff --git a/article/release-management-4-1/index.html b/article/release-management-4-1/index.html
index 00f1b4e50d..f502b553d9 100644
--- a/article/release-management-4-1/index.html
+++ b/article/release-management-4-1/index.html
@@ -5,7 +5,7 @@
Clay John20 April 2023
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.
Now that Godot 4.0 is out and we have all returned from GDC we can finally take the time to solidify our release management plan for the 4.x releases (starting with 4.1). In our earlier blog post on the matter, we mentioned that we would like to shift to smaller, more regular releases.
During the 3.x development cycle we noticed two concerning trends:
Contributors were crunching shortly before planned releases to add big features to those releases as they expected the next release would be a long ways away. This created a “now or never” mentality that led to us optimistically merging PRs that were not ready.
Our “feature freeze” periods ended up being quite long as we often had a lot of big features crammed in quickly towards the end, and we continued to merge risky changes during our feature freeze period.
Our hope is to avoid both of these issues with our new approach to release management. We want to decrease the stress felt by both contributors and maintainers as we approach releases. We also want to be more cautious about merging big changes.
To address these concerns our plan is to shorten the release cycle and provide clear dates in advance. At the same time, we want to organize releases into two phases: the feature merging phase and the bug fixing phase. At the conclusion of the bug fixing phase we will release a new minor version and repeat the process.
Feature Merging Phase
The current plan is for the feature merging phase to be approximately 3 months long. For 4.1, this would mean it will cover March, April, and May 2023. During the feature merging phase we will gladly merge all pull requests that are ready to be merged and are approved by the relevant teams. This includes new features, regular bug fixes, and riskier bug fixes that we wouldn’t merge during the bug fixing phase.
Our goal is to reduce the pressure to get big changes merged “in time for the next release”. Since the next release will always be only a few months away, we can safely defer merging until the following release to give contributors time to properly implement and test new features. We hope this will enable us to have significantly shorter bug fixing phases.
For reference, Godot 4.0 had a 6 month “feature freeze” where we tried to avoid merging new features or especially risky bugs. This period was difficult for everyone and we would like to avoid such long periods of feature freeze in the future.
During the feature merging phase we will also cherry-pick safe bug fixes back to the current stable release (e.g. 4.0.x, 4.1.x, etc.).
We plan on releasing regular “dev snapshot” builds during the feature merging phase to assist users in testing and contributors in bisecting regressions. We encourage users to test out these dev snapshots on non-production projects to give us early feedback on new features. Similar to the 4.0-alphas, we expect to provide dev snapshots every 2 weeks or so with the frequency increasing as we approach the bug fixing phase.
Bug Fixing Phase
The current plan is for the bug fixing phase to be approximately 1 month long. For 4.1, we plan for the bug fixing phase to cover the month of June with our anticipated release of 4.1 being the end of June 2023.
We expect this time period will need tweaking as we see how much dedicated bug fixing time we need to stabilize after 3 months of feature merging.
To contrast this with our 3.x workflow, we tended to release minor versions once per year or so. Each release came with a feature freeze period with an indeterminate length, but usually several months.
During the bug fixing phase we plan on releasing weekly beta builds and eventually RC builds as we did in the latter part of 4.0’s development. Testing of beta builds will be highly encouraged as we want to spot and fix regressions quickly.
Godot 4.2
If the above goes well and we release Godot 4.1 by the end of June we will target the end of October for releasing 4.2. Naturally, if the release of 4.1 is delayed, our estimate for 4.2 will be delayed as well as we will still ensure we maintain our 3 month feature merging and 1 month bug fixing phases.
Since this is a new process, don’t be surprised if we make adjustments to the plan as we go along. We are still trying to figure out what sort of process works best with our contributors and our users. On that note, we appreciate feedback so please make sure to share your pain points so we can make this release process work for everyone.
Long Term Support of Stable Releases
If we follow the above schedule, we will be making around 3 minor releases per year. We expect that it will quickly become difficult to cherry-pick safe bug fixes back to all previous minor releases. In the Godot 3.x cycle we restricted cherry-picking to only the latest minor release and we only updated older releases when needed to fix critical issues.
We intend to minimize breaking changes in the 4.x release cycle, ideally there will be little reason to remain on older minor releases. However, we still want to ensure that users on older releases benefit from compatible bug fixes for as long as possible.
Right now we are unsure how many versions we can maintain in tandem. For now, we are committed to providing 4.0.x releases as we work on 4.1. Once 4.1 releases and our development focus shifts to 4.2, we will likely continue providing 4.0.x and 4.1.x releases with safe bug fixes. Once 4.2 releases we will be re-evaluating how many version back we can go with bug fix releases. At that point, development of 4.0.x may stop.
As always, we welcome feedback from the community and will be keeping a close eye on how many projects choose to remain on 4.0.x. If many projects choose to remain on 4.0.x, then that will influence how long we continue to provide 4.0.x releases.
Godot 3.6
We have just released the first beta for Godot 3.6 and we plan on releasing the stable version in the next few months. As the main focus of contributors is on Godot 4 and beyond, the development process for Godot 3 is becoming slower. As such, we don’t have an exact release date in mind, but we will be continuing to merge pull requests into the 3.x branch and will release 3.6 when it is ready.
Once we release 3.6, we don’t intend to make another minor release in the 3.x series. We will continue releasing 3.6.x bug fix updates for as long as we receive contributions to 3.6.
Godot 5.0?
We have not started planning for Godot 5.0 yet. Our hope is to continue developing Godot 4.x for many years. Instead of planning for breaking changes we will work diligently to add new features without breaking compatibility. We believe the foundation we laid with 4.0 will make this much more tolerable than it was previously.
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 thank you 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.
-
+
\ No newline at end of file
diff --git a/article/rendering-acyclic-graph/index.html b/article/rendering-acyclic-graph/index.html
index f73f7df633..43778b2820 100644
--- a/article/rendering-acyclic-graph/index.html
+++ b/article/rendering-acyclic-graph/index.html
@@ -5,7 +5,7 @@
Darío Banini16 February 2024
Darío, the author of this article, is a new face around this blog who was hired by W4 Games last summer to start contributing to the project. His work was kindly sponsored and donated to the Godot Engine project by W4 Games. You can find more of his contributions to the engine in his GitHub profile.
Since the introduction of Godot 4, RenderingDevice has been the backbone of the Forward+ and Mobile renderers. Making APIs that are both easy to use and flexible enough to cover all the features users want in a game engine is a very difficult task. The high level of detail expected by APIs like Vulkan or Direct3D 12 compared to their predecessors is worthy of a few blog posts of its own. This article will try to keep the topic as brief as possible to focus on the problems solved within Godot instead.
With the goal of reducing the difficulty of the development of the new renderers and allowing the GPU to parallelize work more effectively, the automatic construction of a directed acyclic graph (DAG) during rendering has been introduced at the lowest levels of the engine. This change is already merged in the main development branch of Godot and should be part of the 4.3 release. The introduction of the graph will bring both performance improvements and various bug fixes for issues that were very difficult to investigate. For example, after the graph was merged it was discovered that MSAA with SSAO will no longer cause artifacts in AMD Polaris (#61415), despite no effort being spent towards developing a specific fix for the problem.
No changes are expected from users whatsoever. If you’re one of the few people who have written code that uses RenderingDevice, there’s no need to worry either: while the API has changed slightly, all of the methods just require less information than before. What level of performance improvement you see will very much depend on the contents of your project. For example, GPU particle systems will get massive improvements, while more standard scenes that use post-processing will see some frametime reduction in the ballpark of around 5% to 15%. On top of that, the Godot developers will have a much easier time improving the performance of the renderers in the near future.
If you’re interested in the details of how this was achieved, keep on reading.
Background
Understanding the problem space is crucial to do a deep dive into the technical decisions that were made. Dealing with an existing codebase for a general engine that had thousands of lines written on top of an existing API imposes many restrictions on what sort of changes are allowed. Flaws introduced in the early stages of design can have long-term effects on the development of a big project. This was very much the case with some of the key decisions taken for the RenderingDevice abstraction, its coupling to Vulkan and the negative results on the rest of the codebase. The good news is it’s never too late to go back to the drawing board. reduz laid out the plans for this redesign during the end of 2023 and the team got to work on how to make it a reality.
Vulkan
There’s a few Vulkan concepts that must be understood before digging into why RenderingDevice was designed the way it was for Godot 4 and the difficulties it encountered along the way.
Command buffers
Recording work for the GPU and submitting it for execution is a very explicit operation in Vulkan. Command buffers (or command lists in D3D12) are the objects where all the recorded work is stored that that will executed at a later point on the GPU. These buffers can grow as much as the user desires and they won’t be run until they’re submitted for execution to a command queue. This implies it’s essentially possible to record from multiple sources, even multiple threads, and submit the work to the GPU once it’s ready with proper synchronization.
Render passes
Drawing something with Vulkan requires a lot of information upfront in the form of a “render pass”: an object that contains references to the textures that the GPU will use as targets, their initial and final states (texture memory layouts) and much more. This is a stark contrast from older APIs like OpenGL or even D3D12, where the render target can be changed during command recording and does not require the creation of an object ahead of time. While a render pass is active, there are also various restrictions on what operations can be recorded on the command buffer. The render pass must end before being allowed to use all types of operations again.
Barriers
The biggest change compared to previous APIs is that synchronization between commands is no longer automatically deduced by the driver and instead must be manually implemented by the programmers using Vulkan. If you want to read more about this topic in detail, I highly recommend Hans-Kristian’s blog post about Vulkan Synchronization and reading the official Vulkan documentation. To keep the article short, a very basic explanation is provided below.
The order of execution of the recorded commands inside a command buffer is NOT guaranteed to complete in the order they were submitted: the GPU can reorder these commands in whatever order it thinks is best to complete the job as quickly as possible. To compensate for this, the programmer must manually insert synchronization barriers in the command buffer that allow specifying in detail which commands should be completed or started by specifying the scope before and after. The scope includes multiple concepts such as the execution stage (e.g. drawing, compute, transfer), the type of access (e.g. read or write) and the affected memory regions (globally, buffers or textures). On top of that, barriers are capable of transitioning textures from one memory layout to another, which is a requirement to be able to use textures in different commands optimally.
A barrier can establish a dependency between commands by specifying a synchronization scope.
Beginners will have a hard time understanding this mechanism, but even experts or hardware vendors are not safe from making mistakes. A run of the Vulkan Validation Layers in synchronization mode will reveal multiple issues on most Godot projects or even commercial games available in the market. These are among the most frustrating issues to understand as they won’t even appear consistently depending on hardware vendor or hardware speed. Since eliminating these problems was one of the main goals behind the introduction of the acyclic graph, extensive use was made of these validation tools to ensure that no synchronization errors remained.
RenderingDevice
RenderingDevice is the abstraction on which the Forward+ and Mobile renderers in Godot were built. It exposes an interface that provides a reasonable level of control over the GPU in a way that is not as fine-grained as Vulkan or D3D12 but is also not as “stateful” as OpenGL. More of the rendering state needs to be defined in advance, and the chances of causing an error by leaking state from one previous command to the next are significantly reduced.
The commands exposed by this class are what you usually expect out of a rendering API: creating resources, copying, clearing, drawing, dispatching compute work, etc. However, the point of interest is how both rendering geometry and compute passes are organized. Godot already has the concept of “draw lists” and “compute lists”: essentially batches of commands describing what to do inside a render pass or a compute pass. The one-to-one correlation between lists and passes is very important, as it significantly reduced the number of nodes an automatic graph would have to create.
Draw lists and compute lists are considered a single unit of work in the rendering pipeline.
While Rendering Device attempted to hide many of the difficulties that Vulkan introduced, there are a few that slipped through that made writing rendering code for Godot 4 more difficult than anticipated.
Draw list actions
Just as draw lists were naturally mapped to render passes, so too was the fact that the start and end action had to be specified for the textures associated with them. These actions cover operations such as loading the contents of a texture, discarding it or clearing it with a specific color. There’s plenty of performance to be gained by choosing the optimal option in each render pass. However, due to some internal design decisions, the introduction of a CONTINUE action was made that doesn’t actually exist in Vulkan. This action essentially meant “the previous draw list is compatible and the texture should not be transitioned to a different state”. For an engine like Godot, which must provide a lot of optional post-processing effects and drawing layers, this proved to be a maintenance nightmare, ending in a ton of branching in the code that was not very easy to follow and prone to mistakes.
Draw list storage textures
Since the device doesn’t know if the result of a draw list will be used in a compute pass later, it was necessary to specify which textures needed to transition to the “storage” memory layout at the end of the render pass. Storage is the layout required for modifying textures directly from compute passes. From the point of view of an outsider to Godot, there was no clear reason why this had to be part of the API, but when analyzing the implementation it was evident it was introduced to deal with the barrier transitions required by Vulkan. In turn, this delegated the responsibility to the programmer to keep track of whether the textures would be used later in the compute passes in order to handle them efficiently.
Draw and compute list overlap
Draw lists and compute lists were allowed to specify whether they can “overlap” during execution. This is a very vague argument that depends on whether the programmer correctly understands whether the render and compute work aren’t dependent on each other and could realistically run in parallel. With no real way to validate this, this flag essentially meant “turn it on and hope for the best” as it simply skipped some synchronization steps that the default behavior enforced. Once again, making use of this feature introduced some issues in the codebase where it would require tracking whether parallel work was being submitted or not: components like GI could make use of this optimization, but whether the feature is used or not depends on what that the user has enabled in the scene.
Barrier mask
While RenderingDevice does not provide explicit access to barriers, a lot of methods would allow specifying a bit mask to define which stages of the pipeline the command must synchronize with. However, this was probably one of the most misused masks in the existing rendering code as its implementation wasn’t even consistent in most methods. In one instance, a variable that wasn’t a bitmask at all was accidentally casted as one and passed to a rendering method.
By default, most commands will just specify that all work that comes afterwards must be executed after the current command has finished. As expected, this results in Godot issuing an extreme amount of barriers “just in case” as it has no knowledge of what might be requested afterwards. Godot’s strategy essentially boils down to issuing barriers to make sure no future work executes before the current command finishes, unless the programmer using RenderingDevice specifies the barrier mask. Again, that means the developer must have exact knowledge of everything that comes next, and in turn, caused another round of maintenance issues. Therefore, this feature is rarely used and the default behavior is preferred, resulting in lower performance.
Hindsight is 20/20
The problems raised here may not have sounded so bad in the planning stages of Godot 4, but they clearly became increasingly difficult to solve as more rendering code was written on top of it. Being tasked with writing driver-level work in addition to refactoring the entire engine in many areas is a very difficult task, especially when new APIs have a much steeper learning curve. Many frameworks and engines have iterated on their solutions to deal with the new amount of work expected by Vulkan, and it was time for Godot to try to address this problem again.
Solution
Preparation
Solving the problems identified above does not actually require the introduction of an acyclic graph: inserting synchronization barriers and performing dependency tracking is entirely possible without applying this technique. This was actually debated internally for a while, but it was determined that if the engine was able to reorder commands, it’d allow for grouping them more effectively between the mandatory synchronization points and would result in better performance.
However, being able to reorder commands meant that an intermediate step had to be introduced where commands were recorded into an auxiliary structure that could be reordered and then converted to the corresponding native API commands. One possibility was encoding the Vulkan command arguments into the auxiliary buffer, but that approach meant the entire graph structure and logic would need to be implemented for every other backend as well. Therefore, it was deemed it’d be necessary for Pedro to work on his pull request that introduces an abstract interface for all the supported graphic APIs, including Vulkan, D3D12 and Metal in the near future. Thanks to this change, it was possible to use a single abstract API to encode commands into the auxiliary buffer.
The initial redesign was laid out in reduz’s draft, which was largely inspired by Pavlo Muratov’s “Organizing GPU Work with Directed Acyclic Graphs” and showed the possibility of how the concept could be applied to Godot’s existing design. Not everything stated in the document made it into the final version: in fact, the changes to RenderingDevice were much less severe than initially indicated and the interface remained largely compatible. While the article that was used as inspiration includes a very detailed algorithm in how to implement multi-queue submission by using the graph, the team made the decision to cut this idea short and stick to a single command queue to begin with, as the difficulty of the task would come from building the graph automatically and would already take a significant amount of development time.
Acyclic graph
The unique aspect of the implemented graph is that its construction is completely invisible to the programmer using RenderingDevice. Commands requested from the class are logged internally and each command maintains an adjacency list that is updated as new dependencies are detected. Since these adjacencies only work one way and older commands cannot depend on future commands, it is virtually impossible for cyclic dependencies to form (hence the “acyclic” part of the graph). While a graph can be constructed in many ways, a list of vertices and an adjacency list are sufficient. Render commands play the role of vertices, and commands store the indices of their adjacent commands.
The rendering operations of a frame and their dependencies represented as a graph.
An important decision that was made to allow this structure to scale more effectively is that each instance of a draw list or a compute list are considered as one node in the graph. There is no benefit to allowing reordering within these structures and Godot already has a clear concept of what these lists are used for. Games often draw a lot of geometry, but they don’t create tons of render passes per frame, as that doesn’t result in efficient use of the GPU. To put it in numbers, one of the benchmark scenes used during testing could easily reach hundreds of thousands of nodes if each individual command was recorded into the graph. Making the distinction to correlate render passes to individual nodes brought this number down to about 300 nodes per frame. Operating with a graph of this scale was a very good sign that the performance overhead would be very small.
Once all commands for the frame have been recorded, a topological sort is performed on the graph to get an ordered list of commands. During this step the “levels” of the commands are detected to determine how they can be grouped and where synchronization points (barriers) should be introduced. All commands belonging to a particular level in the graph can be executed in parallel as no dependencies have been detected between them, meaning that no barriers are required until the next level is reached. This sorting step is where the magic behind the performance gains happens.
After sorting, all commands that belong to the same level can be executed in any order, resulting in multiple possible command sequences.
One important detail that resulted in frametime reductions during this step was to take into account the type of command as a sorting factor: grouping together operations based on whether they were related to copying data, drawing or compute dispatches provided some noticeable increases in performance. While the exact reason behind this has not been determined, it seems likely that GPUs prefer to change the type of pipeline they need to use within a command buffer as little as possible.
While the concept of using a structure like a graph and using sorting algorithms might sound like the most daunting part of the task due to the level of abstraction involved, it is the dependency tracking and adjacency list detection during command recording where most problems arise. The relationships shown in the diagrams above were not specified by the programmer using RenderingDevice: they must be detected automatically based on how the resources were used in the frame, and this turned out to be no small task due to some particular details of how Godot works.
Resource tracking
The resources used by RenderingDevice in Godot are buffers or textures. While these are separate objects at the lower level depending on the API being used, the graph considers them both as one to share much of the logic during implementation. However, a distinction will be made later when texture slices are introduced, which is something Godot uses quite a bit in various parts of its rendering code. Textures also have the additional requirement that they need to make layout transitions to be ready for use in different commands, while buffers don’t need to do this at all.
Whenever a resource is created, a new “tracker” structure is introduced to store the information relevant to the graph construction during command recording. The tracker holds references to which commands are writing or reading from the resource and modifies these lists accordingly as more commands are recorded. It also stores a “usage” variable that indicates what the current use of the resource is at the time of recording. Usages are both classified as “read” or “read-write” operations, and which one is used has strong implications for how dependencies between commands will be detected. For example, a command that reads from Resource A can be executed in parallel with another command that reads from Resource A, but that will not be valid if the other command can write to Resource A. In this case, a dependency is inserted between the two commands to ensure that the first command can finish reading the resource correctly before the next command modifies it.
The tracker holds the current usage of a resource and determines whether it is necessary to perform a transition based on the type of command that references it.
Textures also have a particular requirement: changing the usage implies a memory layout transition even if it’s just for read-only operations. For example, there’s different layouts for a texture being used as the source of a copy operation and for a texture being used for sampling in a shader. While this distinction might not necessarily be true at the hardware level, it is actually possible to witness texture corruption if these transitions are not performed correctly depending on the GPU’s architecture (AMD is really good for testing these out!). Therefore, any change in usage when textures are involved is usually considered a write operation as most of them require a particular layout. This introduces some dependencies between commands that might not be very obvious but are completely required for the operations to work correctly: continuing with the previous example, it’s not possible to use the optimal memory layout for copying a texture and sampling it in a shader in parallel, even if both are read-only operations.
Dependency tracking
Since the graph construction is automatic and there’s no input from the programmer in how the adjacency lists of the graph must be built, it’s up to RenderingDevice to use the resource trackers to figure out the dependencies between commands. While the final implementation is a bit more complex due to the introduction of texture “slices” (which is covered in another chapter), the main idea behind the algorithm is pretty straightforward.
When a command uses a resource as read-only, a reference to the command is stored in a list in the resource tracker. A reference to the command is placed on the adjacency list of the last operation that wrote to the resource.
When a command uses a resource as read-write, a reference to the command is stored the resource tracker, replacing the previous one and clearing the list of commands that were reading from the resource. A reference to the command is placed on the adjacency list of all operations that were either reading or writing to the resource.
An exception is made for textures: if an operation must change the type of usage, the operation is considered as if it’s writing to the resource because a memory layout transition is required. It does not matter if both operations are read-only: a write dependency will be established regardless. This is worth keeping in mind as the graph considers the operations to be dependent if the texture’s usage changes often.
Animated example of how dependency tracking is used to build the graph. Blue and red represent how the command modifies the lists inside the trackers and green indicates which values it reads from to build the adjacency list.
Older operations are discarded from the tracker’s lists to avoid increasing them endlessly and causing performance bottlenecks in the process. As write operations can’t be done in parallel and no information is known about the range of data that is modified (a potential future improvement), then it’s only necessary to store a reference to one command at all times. This system requires more detailed tracking once texture slices are later introduced, but the strategy remains largely the same.
One interesting thing to note here is that Godot can leverage the information provided by SPIRV-reflect to identify the usage of some resources as read-only even if their layout allows write operations. For example, the storage memory layout is required to be able to write to a texture directly so it is considered as a write usage by default. However, if the GLSL shader uses the readonly qualifier on the binding, then the graph will consider it as a read operation.
Immutable resources
Resource tracking can quickly become a performance bottleneck as the solution does not scale effectively to games with large amounts of resources. If every single buffer or texture used in a frame must be tracked and checked for dependencies during recording, that can quickly balloon out of proportion. But there is a simple first step to reduce this problem: not everything needs to be tracked as most resources in a game are usually static (e.g. terrain or buildings). An internal benchmark scene from W4 Games showed this to be true pretty quickly, as the amount of trackers went down from over 20 thousand to less than a thousand after ignoring all static resources.
But Godot doesn’t currently know what resources are static. Users can modify these resources freely at any time, even from GDScript! Resources are not considered to be immutable or marked as such during the import process. Other engines typically mark nodes as static for additional optimizations, but Godot avoids this concept to keep the engine easy to use and not overwhelm beginners with settings whose purpose they may not yet understand. This turned out to be a big problem that was debated internally for a while, as introducing a new “immutable” attribute was the most attractive option with the downside that it would mean a lot of extra work for end users.
Complex game scenes often contain a lot of static geometry. Tracking these resources generates a lot of overhead without any real benefit.
Fortunately, a quick solution was found that allowed trackers to be greatly reduced without the need for user intervention: during resource creation, a couple of flags are checked to see if a tracker should be created or not. If the resource is created with some initial data and no explicit flags are set for modification, then it is considered to be read-only and no tracker is created for it. If at some point an operation attempts to modify the resource, a full synchronization is introduced in the graph and the tracker is created. Synchronization is required because it’s not possible to know which commands in the frame were reading from the resource beforehand. Full synchronization implies all previous commands must be adjacent to the command that created the resource tracker, so the graph degrades to the behavior of the previous version of Godot on that particular command for one frame. This was considered to be an acceptable and very minor performance degradation that bypassed the need to introduce the “immutable” flag to the engine.
Texture slices
No good tale is complete without its villain. This was the most painful omission from the initial design and it proved to be the hardest part of dependency tracking and texture layout transitioning that required to be solved. As a matter of fact, it might not even be solved completely yet as new edge cases that had to be fixed popped up even after the graph was merged!
While textures are most commonly associated with containing two dimensions, it is possible to create two extra dimensions that further complicate their use: mipmap levels and array layers. Mipmaps are commonly used to create a chain of smaller versions of the texture that the filtering process can use to improve the image quality (see Anisotropic filtering). A general use case for array layers is to simply create a texture with the same dimensions multiple times and then reference a particular layer within a shader. Godot makes plenty of use out of these extra dimensions, even combining the use of both at the same time for some effects.
This usually doesn’t pose any additional trouble if the engine sticks to using a texture during commands in only one particular way, but the problem does not stop there: Godot can and will use different parts of the same texture for completely different purposes, even within the same command. This is possible because RenderingDevice can create “shared” textures from slices. While the original texture may only have one resource tracker, all shared slices are considered different textures with their own resource trackers that can be referenced independently in commands. A common use case is mipmap creation: a lower level mipmap of the texture can be set as the render target, while a higher resolution level is used for sampling, effectively creating the chain of mipmaps from the texture’s highest quality level.
The anatomy of a cubemap texture that uses both mipmaps and array layers. Godot can create slices of a texture that reference only a range of its subresources.
Tracking texture slices effectively required the implementation of a set of strict rules to verify that the programmer using the RenderingDevice does not perform operations with undefined behavior.
The tracker for the “parent” texture holds a “dirty list” of slices that have a different memory layout from the one used by the parent.
It is never possible for slices on the dirty list to overlap. In fact, these ranges are represented as 2D rectangles, which is pretty fun way to represent the problem visuallly!
The tracker for a texture slice holds a reference to its parent and a flag to identify whether it is present on the dirty list or not.
It is not possible for one command to use slices of the same texture that overlap, as this can lead to undefined behavior. This restriction is applied even if their usage is the same.
If the parent texture is used in a command directly, all slices in the dirty list will be reverted to the usage of the parent by “normalizing” the texture to one memory layout. It is not possible to use slices with a different usage during this step.
Slices present in the dirty list can also be normalized and removed individually if a new command wants to use a slice that would overlap with their dirty region. Since it’s not possible for slices to overlap in the same command, this operation can always be performed safely if the slice being normalized was used in an older command.
Dependency tracking is performed strictly with the tracker associated to the parent texture of a slice and not the slice’s tracker, as this usually leads to the safest behavior.
While these rules do not guarantee an optimal solution, it is not common for Godot to perform these operations on every frame, and the potential linearization of the commands is an acceptable performance hit to keep tracking as simple as possible. One point in particular that was discussed a lot was whether to resort to tracking usage individually per mipmap level and array layer, but such a decision would result in a system that wouldn’t scale at all in the long run if large texture arrays with multiple mipmaps are used.
Results
While this is something that is not usually measured, it’s worth remembering one of the main reasons behind the graph was to simplify the maintenance of the rendering code for the team. The problems identified at the start clearly meant there was a lot of code that would get deleted from the rendering pipeline. While the PR might not have ended up in the net negative due to a lot of code being isolated in the graph’s class along with debugging utilities, around ~2,500 lines of code were removed from the implementation of RenderingDevice, the Forward+ renderer and the Mobile renderer.
The other major benefit is that a lot of hard to identify bugs that were caused due to synchronization bugs are now potentially fixed. As pointed out before, the MSAA with SSAO issue was resolved as a side effect. Problems like this one proved to be extremely hard to fix as Godot developers would require the particular set of hardware and the right scenarios for the defects to trigger. With the graph sufficiently complete and unable to cause these synchronization problems, the possibility of introducing errors of this kind disappears.
GPU performance
The results are generally positive. No performance regressions have been identified in any scene as far as GPU performance is concerned, and in virtually most scenarios an improvement can be expected depending on their contents.
Results gathered from running various projects with an NVIDIA GeForce RTX 3090 Ti at 1920x1080. Higher is better.
Legend of the Nuku Warriors: Internal demo scene by W4 Games.
The biggest gains by far could be identified in projects with multiple GPU particle systems, where the execution can now take place in parallel wherever it’s possible. A dedicated particles benchmark makes this difference much more obvious.
Results gathered from running the benchmark with NVIDIA GeForce RTX 3090 Ti. Higher is better.
The introduction of the acyclic graph to Godot does not come free. As the need to serialize commands into an intermediate buffer is introduced along with graph construction, dependency tracking, and sorting, the CPU must bear the brunt of the work. However, the results are not what most developers would expect. From profiling where the CPU spent most of its time during a frame in the benchmark scene, the following was discovered:
Graph construction and topological sorting don’t even account for more than 1% of the CPU time of the frame. The node count is usually too low to have a significant effect.
Nearly 30% of the CPU time was consumed entirely by Vulkan API calls (~20%) and serialization of the commands into the draw list (~10%). This corresponds to the fact this scene has a massive amount of objects being drawn with a large amount of omni lights that can cast shadows.
For now, the conclusion would seem to be that the graph itself cannot impact the scene significantly as far as CPU overhead is concerned, but the requirement to serialize large draw lists seems to simply exacerbate an existing problem: Godot needs better mechanisms to merge draw calls and avoid binding an excessive number of index buffers and unique vertices for everything in the scene. The good news is that this regression can potentially be mitigated or even improved in the short term with secondary command buffers (or a suitable replacement).
Secondary command buffers
As mentioned before, the new APIs enable the possibility of recording to command buffers from multiple threads. Secondary command buffers are an interesting subset of command buffers that aren’t capable of recording all types of commands and are intended to be inserted inside a render pass issued in a primary command buffer. This is actually an ideal application for draw lists, since their contents do not need to be reordered, but their location in the primary command buffer is determined during the topological sorting step of the graph. Therefore, they enable the possibility of recording in parallel and ahead of time the largest draw lists of the frame. And they actually get good results! In the benchmark scene, the CPU time spent in the frame is actually reduced compared to 4.2 thanks to overlapping most of the cost from calling the Vulkan API and delegating it to background worker threads. The graph finally gives Godot the keys to using multithreading for rendering!
So why is this not enabled in master yet? It seems that secondary command buffers can run into some strange issues on different hardware and are not as widely supported as they should be. During testing an issue was found in NVIDIA GPUs where the editor window would just go completely blank if secondary buffers were used under certain conditions. Apparently it wouldn’t be the smartest decision to rely on this feature and expect it to work correctly on most platforms. However, if you want to experiment with it yourself the code is currently present behind a compilation macro. The code will automatically enable multithreaded recording when the draw lists are determined to be large enough to be suitable and will result in a real reduction in CPU times in demanding scenes, provided the user has enough CPU cores to handle it.
An alternative being evaluated is to record multiple primary command buffers instead and chain them together when the frame ends. However, submitting a command buffer for execution has a fixed cost that isn’t insignificant according to hardware vendors, so some consideration must be given to creating different command buffers only when the benefit outweighs the cost.
Future work
With the introduction of the directed acyclic graph and with a few more abstraction rewrites coming down the line, the engine will now have access to even more optimizations that can be implemented in the future.
Multiple queues
Pavlo Muratov’s article that was used as the main inspiration behind this change contains a very interesting proposal in how to submit and synchronize GPU work across the multiple queues exposed by the hardware. Godot could potentially leverage these extra queues (e.g. dedicated compute queues), to be more explicit about what work should be executed in parallel. Finding paths that could be executed in parallel in the graph would require some elaborate detection of the dependencies between the commands, the possible paths that are independent and where the synchronization points need to be placed.
A heavily simplified example of a potential multiqueue submission scheme that could be detected by the graph. Many portions of the compute work in Godot could be processed while other parts of the rendering pipeline are busy.
As pointed out before when talking about using primary command buffers as an alternative to secondary command buffers, command queue submissions are not free: there must be a good balance between partitioning work to be executed in parallel when compared to just submitting everything into a single command queue.
MSAA resolves
Multisample anti-aliasing (MSAA) is a feature that requires explicit commands to “resolve” the result of the anti-aliasing into a texture that can be used by other steps in the rendering pipeline. The anti-aliased result is not actually computed during the time of drawing but either when a resolve command is issued or a render pass defines a resolve operation in a subpass.
It’s not possible for Godot to know if something will draw again to the target, so it must resolve the result manually when it needs to sample the resource.
With how flexible of an engine Godot is, determining where this step should go can be very tricky: the operation should be placed only when it’s absolutely necessary or as part of the last render pass that draws to the MSAA texture. This is an area that the graph could aim to resolve automatically by simplifying the implementation of MSAA in the renderers and lead to further performance improvements. Reducing the amount of resolve operations to the minimum and the bandwidth required for MSAA could be very beneficial for the Mobile renderer in particular.
Since the graph can detect if the render pass is the last one in the frame, it can automatically insert a resolve in the render pass, saving lots of bandwidth in the process.
Graph visualization
While this wouldn’t provide a direct benefit to end users, building a visualizer for the graph could help the Godot developers have a clear overview of the rendering pipeline of a given frame and identify bottlenecks more easily. During development, a few compute passes were identified that weren’t being parallelized correctly due to implementation errors. For example, GPU particle systems were binding an unused buffer for write operations even if they never wrote to it, which led to the commands being identified as being dependent of each other due to having to synchronize with the potential “write” performed by the previous system.
Due to an implementation error, even after implementing the graph, the execution of the particle systems was mostly linear, as they all reused the same temporary buffer for reading and writing.
After fixing the error by assigning each system their own buffers, the graph automatically reordered and executed the particle systems in parallel, leading to huge gains in performance.
While a more obvious case like this one was identified since it did not meet expectations at first, there could be more subtle instances of this behavior yet to be found in the codebase that could be easily exposed by building better debugging tools.
Conclusions
While the use of a directed acyclic graph for rendering is not a brand new technique, the approach used by Godot is quite novel in many ways. The simplicity of the API exposed by RenderingDevice no longer comes at the cost of rendering performance: the developer is guaranteed they’ll get efficient use of the GPU and it can only get better from here. As the engine aims to be as general purpose as possible and maintain its ease of use, a lot of alternatives had to be discarded until the right approach was found. This is a long-term technical investment that will pay off by reducing the cost of maintenance and unlocking new strategies for optimization in the long run.
An automatic approach ensures that despite the project being open source and modified by many different people, they no longer need complete awareness of how the entire rendering pipeline works to modify it. This will also be very beneficial when PRs like rendering effects are merged, which introduce the ability to add post-processing steps where the Godot renderer will be completely unaware of all dependencies the hook may require. The extra validation introduced by recording commands to the graph has also exposed existing implementation errors, resulting in either bug fixes or even performance improvements.
Debugging is the weak point of this approach: when dealing with native Vulkan or D3D12 code, it can be very tough to produce a usable backtrace as the context that generated the commands is long gone by the time they’re translated from the auxiliary buffer to the native API calls. It is advised to build very good debugging tools that register as much information as possible to aid in the process. This is one area where the existing implementaton must be improved upon.
Considering how little abstraction the graph requires, it is entirely possible to apply this approach to other projects that don’t use Godot at all. The implementation of the technique has been kept as isolated and general purpose as possible, affecting very little of the rest of the Godot codebase except for removing code that is no longer required. Following this approach turned out to be very important, as being able to change the implementation of the graph itself or disable it completely was vital to debugging any problems introduced by implementation errors. While there are no plans to make this a general-purpose library, it could be a very interesting idea to integrate this mechanism into a generic rendering framework.
Look forward to testing this feature out in the 4.3-dev snapshots and future releases! Please let us know if you have any issues so they can be fixed in time for the first stable release.
-
+
\ No newline at end of file
diff --git a/article/rendering-priorities-4-1/index.html b/article/rendering-priorities-4-1/index.html
index 73dc2c8683..a3abf895bf 100644
--- a/article/rendering-priorities-4-1/index.html
+++ b/article/rendering-priorities-4-1/index.html
@@ -5,7 +5,7 @@
Clay John18 April 2023
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.
Now that Godot 4.0 is out, we have had the chance to think about our priorities for 4.1. In particular, we have been discussing how our intention for 4.0 was to create a stable base to build upon. The rendering internals have been totally overhauled and many new features have been added. Leading up to the betas we focused on getting everything implemented. In other words, some features are still lacking polish and optimization. We are confident that the current state of the rendering internals gives us a lot of room to grow, but we are aware that we have a lot of work to do to get stability and performance in line with our goals and with user expectations.
As explained earlier we are aiming to have a quicker release cycle and we expect to release 4.1 later this year. The engine-wide focus for 4.1 will be on stability, usability, and performance.
Priorities
Below I list some of our top priorities on the rendering team for Godot 4.1 along with a brief description. These are presented in no particular order and are grouped based on whether they relate to performance improvements, stability, or usability.
Please note these priorities are aspirational: we hope to have all of the following finished in time for 4.1, but we may not. Rest assured work will continue and anything that doesn’t make it into 4.1 will make it into subsequent releases.
Also note that we will still be merging and reviewing feature PRs and bug fixes not listed on this page. This list is intended to communicate what the maintainers will be prioritizing and what we hope volunteers prioritize too. If you are interested in contributing to the rendering side of Godot, but none of these topics are interesting to you or if you feel something else should have higher priority, please contribute anyway.
Performance
Identify bottlenecks in 3D rendering (i.e. main scene shader)
Right now, when profiling rendering on both mobile and desktop, we notice that the depth-only passes (depth prepass and shadow pass) are taking much longer than they should. The opaque pass also appears slower than it should, even in less complex scenes. While most users are noticing overall performance improvements with Godot 4.0, we suspect that performance should be even better.
Early profiling indicates that we have a bottleneck in the vertex shader (which may explain why the issue exists in depth-only passes as well) which is likely memory-bound. Typical solutions to a memory-bound vertex shader include reducing VGPR usage to improve occupancy, reducing the amount of data accessed by the vertex shader, and improving vertex shader access patterns to ensure we are not thrashing the cache.
Assigned:Bastiaan and Clay have been looking into this and we welcome anyone else who would also like to help.
Time slicing DirectionalLight3D shadows
DirectionalLight3D shadows are camera-dependent. Unfortunately, this means they have to update every frame. When rendering shadows with 4 splits, this creates an awful lot of draw calls and work for the GPU each frame. Our plan is to add optional “time slicing” to allow updating further splits less frequently. For example, splits 3 and 4 could alternate frames to update. This will reduce the overall work submitted to the GPU each frame. If implemented well, this can be done without a noticeable quality loss.
Assigned:Bastiaan will be looking into this within the coming weeks.
Background pipeline compilation
Some of you may be familiar with the infamous Vulkan pipeline compilation stall. This happens when Godot loads a new shader and needs to compile all the related pipelines. This makes loading times longer than they need to be and can lead to frame time hiccups where shaders are loaded dynamically at runtime. For Godot 4.1, we want to move pipeline compilation to a background thread so that it can be done asynchronously from regular rendering and can avoid hiccups at runtime.
Assigned: Currently no one is tasked with this, but it is something we would like to have finished for 4.1.
Stability
BUGS
Users are doing a great job reporting bugs and making reproducible test cases. We will be fixing as many bugs as we can and we ask that all contributors do the same.
Assigned: No one is assigned to this. We should all be doing our part and fixing as many bugs as possible.
Proper multi-threading in the RenderingDevice
Currently the RenderingDevice isn’t properly thread-safe (our usage of it is though). In some places it is overly restrictive, while in others it isn’t restrictive enough. We need to remove the restrictions where they are unnecessary and implement proper locking in places that can’t be made thread-safe.
This work is necessary to ensure that users don’t run into threading bugs as they make more advanced use of the RenderingDevice API. It is also necessary to implement background pipeline compilation as described above.
Godot 4.0 shipped with a low-end focused renderer which targets OpenGL 3.3 / OpenGL ES 3.0 / WebGL 2 devices. The GL Compatibility renderer (as we call it) is written with low-end and mobile devices in mind and should run much more efficiently on those devices than the GLES3 renderer in Godot 3.x.
As mentioned in an earlier post, we had time to finish the 2D renderer, but did not have time to finish the 3D renderer. For 4.1, we would like to finish the 3D renderer.
Assigned:Clay will be responsible to ensure this work is done before 4.1 releases, but contributions are welcome in the meantime.
FSR 2.2 / TAA improvements
We would like to implement FSR 2.2 to replace our current TAA solution. FSR 2.2 is a more fully-featured Temporal AntiAliasing and upscaling solution than our current TAA and should work better in most situations, while also allowing the option to improve performance with upscaling.
At the same time, we will be integrating many of our effects (SSAO, SSR, shadows, etc.) with TAA so that quality is automatically improved when TAA is enabled. To be clear, this will not impact the quality of these effects when TAA is disabled. We still intend for all effects to be usable without TAA. This will just enhance these effects when TAA is used.
Assigned:Clay will be working on this, but can pass responsibility over to someone who is motivated and has the time to work on it sooner.
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.
-
+
\ No newline at end of file
diff --git a/article/rendering-priorities-january-2024/index.html b/article/rendering-priorities-january-2024/index.html
index 96f35c3ad6..81b8039745 100644
--- a/article/rendering-priorities-january-2024/index.html
+++ b/article/rendering-priorities-january-2024/index.html
@@ -5,7 +5,7 @@
Clay John16 January 2024
We released Godot 4.2 on November 30, 2023 with many exciting features and countless fixes and improvements. Godot 4.2 is starting to look like what we had envisioned for Godot 4. Accordingly, we are spending more time thinking and talking about what the future holds for the rendering team.
At GodotCon this year I spoke about new features that the rendering team would like to see implemented in the future. While not all of these features will make it in, it’s a pretty good overview of what we are thinking and talking about.
Also, a reminder for those interested in contributing, the rendering team meets weekly and all are welcome to join the meetings (calender link).
The below are the priorities we identified in July 2023 with a short description of their current state.
Performance
Split Dynamic/Static Light3D shadows (on hold)
This work has been put on hold for the time being. We haven’t been able to implement it in a way that sufficiently improves performance enough to justify the additional complexity to users’ workflow and to our codebase. We intend to return to this in the future.
Background pipeline compilation (in progress)
This remains a high priority and has only been pushed back due to other foundational work on the RenderingDevice backend.
We completed this and it was included in the 4.2 release! As a reminder, this optimization decreases shader compilation time for most 3D materials and should result in faster startup times and less stuttering in many games.
Proper multi-threading in the RenderingDevice (in progress)
This was delayed due to foundational work on the RenderingDevice backend. But the work is currently underway and is showing promising results already!
Usability
GL Compatibility renderer - 3D (in progress)
We added shadows to the compatibility renderer in time for 4.2, as well as many other smaller features and improvements. We have already merged support for MSAA, lightmaps, and 3D scaling for 4.3 and will continue adding the remaining features. We aim to support Glow, ReflectionProbes, and post-process adjustments as soon as possible.
We merged FSR 2.2 during the 4.2 dev cycle as well as a host of other TAA enhancements. We have kept our current TAA as it has less of a performance impact and can be useful when you aren’t using upscaling. Our goal is to continue improving the performance and appearance of our TAA solution to offer a cheaper alternative to FSR 2.2.
Others
4.2 also brought a lot of exciting changes. Among them:
Optional ANGLE backend to support low-end devices (GH-72831)
For more information, check out the “Rendering, particles, and shaders” section of the 4.2 release blog post.
Current priorities
Below I list some of the top priorities identified by the rendering team. These priorities are:
Acyclic render graph optimization (GH-84976) (merged for 4.3)
This is both an optimization and a feature. The Acyclic Render Graph (ARG) is a tool to automatically record and re-order rendering commands in the RenderingDevice backend. This is extremely beneficial for 2 reasons: 1) it enables optimizations that are otherwise not possible in a general purpose renderer, and 2) it simplifies the RenderingDevice API to make it much easier to use (this benefits us and users who use the RenderingDevice API directly). So far this PR has shown promising performance improvements on a range of devices and especially when many particle systems are in use.
Direct3D 12 rendering driver (GH-70315) (merged for 4.3)
In December we merged support for a D3D12 rendering driver. This is the GPU backend of choice for Windows devices. Currently users need to compile Godot from source to include support for D3D12, but we are investigating ways that we could provide D3D12 support out of the box.
Metal rendering driver (in progress)
Recently Stuart Carnie began work on a Metal backend for Godot. The work is significantly underway and is already showing a lot of promise. A Metal backend will allow us to massively improve the user experience on Apple devices (both iOS and macOS), including fixing outstanding bugs and improving performance.
RenderingDeviceDriver refactor (GH-83452) (merged for 4.3)
In preparing the D3D12 rendering driver, Pedro noticed that a significant amount of code needed to be shared between the Vulkan implementation of RenderingDevice and the D3D12 implementation of RenderingDevice. He proposed that we divide RenderingDevice into two pieces: 1) an API-agnostic layer that contains all the shared code, and 2) a thin layer that only includes API-specific code (the RenderingDeviceDriver). This has allowed us to save thousands of lines of duplicate code which will make porting to new platforms easier (e.g. Metal, WebGPU) and will make maintaining our current backend easier.
Rendering hooks are our way of allowing users to insert custom RenderingDevice code in-between draw passes in the built-in renderer. This paves the way for many custom effects that rely on accessing internal resources or that take place during rendering. Particularly, this will open up a channel to create custom post-processing effects. The implementation is still quite low-level and requires using the RenderingDevice API directly, but we consider this a first step in allowing users much greater control over rendering.
After initially writing SDFGI, Juan had many ideas to improve it which we discussed at length. He captured his ideas in a handy slideshow which we shared publicly in November 2022. Juan has now begun work on those ideas and they led him to a slightly different approach to GI, using the Hierarchical Digital Differential Analyzer (HDDA) algorithm instead of Signed Distance Fields (SDF). Accordingly, we will be renaming SDFGI to “Dynamic GI” to make the name independent of the algorithm used. The settings will change slightly in this refactor, but both performance and quality will increase. The end goal is to provide settings that will make this run fast enough for use on integrated graphics cards.
Conclusion
A lot has happened since our last update. Notably we have made a lot of improvements to our rendering backend that pave the way for further features and enhancements while improving performance and stability. Our development effort is starting to shift towards new features that unblock current users who want to push Godot a little bit further, but we are still focused on improving the current set of features.
Please keep in mind that this is simply a list of things the rendering team deems high priority. Both the rendering team and interested contributors can and will continue to work on other tasks.
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors in their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/rendering-priorities-july-2023/index.html b/article/rendering-priorities-july-2023/index.html
index 3d5cec0e58..1f0a5702cf 100644
--- a/article/rendering-priorities-july-2023/index.html
+++ b/article/rendering-priorities-july-2023/index.html
@@ -5,7 +5,7 @@
Clay John9 August 2023
Note: This article was written a few weeks before it was published which is why it references July 2023 while it was published in August 2023. The information within is accurate for both July and August 2023.
Now that 4.1 is out and in the hands of users, it is time for the rendering team to re-evaluate our priorities and set our sights on the future of Godot development. Overall, our priorities are not changing much from what we identified in our April 2023 progress report.
As we anticipated, we were unable to finish all of our priorities in time for 4.1. In part this was due to the short timeframe (we made the post on April 18, and entered feature freeze on June 8), but it was also the result of spending more time fixing bugs than we planned (hooray for fixed bugs!) and a few key changes taking much longer than expected, notably: GLES3 3D shadows, and time slicing DirectionalLight3D shadows.
Support
As a quick reminder before jumping into the meat of this article, Godot is a non-profit, open source game engine developed by hundreds of contributors in their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
I want to address what I consider to be a failure of communication in the last rendering priorities post. The previous post was not clear about whether it was a roadmap for 4.1, or if it was a list of things that were important to the rendering team. While the content of the post said not to expect everything to be done for 4.1, the title made it sound like everything on the list was planned to be finished for 4.1. My intention in writing the post was not to promise anything for 4.1, but rather to highlight things that the rendering team is currently working on (and it just so happened that 4.1 would be the next release). Going forward, I hope to be more clear that the list of priorities is not tied into any specific release.
Similarly, as a reminder that even when we have a feature ready or nearly ready before a release window, the feature still may be delayed to a subsequent release if more testing is needed, or if contributors identify issues with the feature before it is merged. That is to say, even if we say we will have a feature ready before a particular release, it only means that the Pull Request will be made before the release, we can’t promise that any change will make it into the next release until that change is actually merged into the engine.
Below I list some of the top priorities identified by the rendering team along with a brief description. These are presented in no particular order and are grouped based on whether they relate to performance improvements, stability, usability, or a new topic, customization. Many of these items are carried forward from the last post. We hope some of these will make it into 4.2, but we can’t promise anything.
Performance
1. Split Dynamic/Static Light3D shadows
This is, in part, a carry-over from the last post. At first our idea was to add time slicing to DirectionalLight3D shadows only. But once implemented, we noticed significant visual artifacts when objects moved in splits where time slicing was active. Accordingly, we realized that we would need to split static and dynamic shadow maps for this optimization to work well and look acceptable.
Bastiaan worked super hard on this and had both systems nearly ready for 4.1, but unfortunately didn’t complete the work in time to be included with 4.1’s release as more testing is needed. We expect this work will be merged soon and will be available for testing and feedback prior to 4.2’s release. We ended up needing to introduce a few more settings than expected, so we really need community feedback to make sure the system is intuitive and helpful.
September 2023 edit: In testing we have identified performance issues that stop us from merging this work. Accordingly, this will not make it into 4.2. The work is ongoing and hopefully we will have something we are happy with ready for a later release.
2. Background pipeline compilation
This is also a carry-over from the last post. We still would like to implement this ASAP. 4.1 introduced pipeline caching which further helps reduce stalls from pipeline compilation. Background pipeline compilation will help further reduce stalls.
3. Shader compilation groups
This is a new priority which was identified as necessary foundational work before we implement background pipeline compilation.
Essentially, right now when we compile shaders we compile all possible variations of the shader that may be composed at run time. For 4.0 we drastically reduced the number of possible variations. And now the variations that are left come from a few dynamic global settings, in particular TAA, XR, Lightmaps, screen-space reflections (for a total of 16 permutations).
For many games only one of the 16 permutations will be used. With this change, we will compile and cache only the shader versions of the settings in use, then compile the others as needed. This should reduce shader compilation time by a factor of about 1/8. To be clear, this is shader compilation time not pipeline compilation time which means it will help improve load times, not runtime stutters (as shaders are compiled when the material is loaded, not when the material first appears in the scene).
Stability
1. Fixing Bugs
Please continue to help reduce the number of bugs in the engine by contributing bug fixes, and contributing issue reports with clear, reproducible test projects. We made huge strides on fixing bugs in 4.1 and we hope that following releases maintain the same increase in quality.
2. Proper multi-threading in the RenderingDevice
Another carry-over. As a reminder, this comes from the fact that our RenderingDevice API mostly uses mutexes to ensure proper thread safety across the API surface. In practice this limits our ability to take advantage of Vulkan’s ability to be accessed from multiple threads and introduces unnecessary synchronization, resulting in worse than optimal performance. This is a restriction we want to lift as soon as possible to ensure that we can optimize the RenderingDevice-based renderers as much as possible.
Usability
1. GL Compatibility renderer - 3D
This is something I really hoped to have finished in 4.1, but didn’t make it in time. I finished 3D shadows shortly before the feature freeze window, but felt the implementation needed more performance profiling and testing before being merged, so this work has been delayed.
Finishing the GL Compatibility renderer remains a top priority for the rendering team.
2. FSR 2.2 and TAA improvements
This was the closest thing to a new feature in the previous blog post and, of the topics, was the most aspirational. We really want to have FSR 2.2 implemented in the engine soon and we would like to implement the corresponding enhancements that come with using FSR.
Customization
We also have plans to expose more RenderingDevice features to the scripting API. This is work that was originally planned for 4.0 that did not make the cut in time. Then we delayed it as we wanted the team to focus on bugs. Now we are finally taking the time to expose the things that need exposing so that advanced users can really take advantage of the customized rendering possibilities offered by the RenderingDevice.
The first addition is the TextureRD resource family, which are versions of Textures that are formed from an internal RD resource. This will allow users to share custom RD-created textures with the main Godot rendering pipeline. In particular, users can implement custom rendering to a surface, then display that surface using a regular GDShader.
We are also investigating exposing mesh surface data in the same way, as well as providing access to internal buffers, like the MultiMesh buffer, the Skeleton buffer, etc.
Conclusion
Please remember that this is merely a list of things that the rendering teams feels are priorities. Both the rendering team and interested contributors can and will continue to work on other tasks.
-
+
\ No newline at end of file
diff --git a/article/rendering-priorities-september-2024/index.html b/article/rendering-priorities-september-2024/index.html
index 72a9e2d7da..e0de1645ec 100644
--- a/article/rendering-priorities-september-2024/index.html
+++ b/article/rendering-priorities-september-2024/index.html
@@ -5,7 +5,7 @@
Clay John23 September 2024
It’s time again to update everyone on the activities of the rendering team. We have been hard at work fixing countless bugs and improving the renderer. Now that 4.3 is out, we have taken the chance to re-assess our priorities.
Get Involved
As a reminder, we are always in need of more help. The rendering team is very small and none of us are working on the renderer full-time. If you are interested in helping out, please consider joining the #rendering channel on chat.godotengine.org, joining the weekly meetings that place, or just opening a pull request!
In addition to the priorities listed here, you can get started contributing by fixing bugs. We have been categorizing bugs by complexity and priority in the new Rendering Issue triage project to make it easier for new contributors to discover bugs that need attention.
For a less organized overview on rendering priorities, you can also check out the 4.x Rendering Roadmap Github project. This project lists a lot of the long term tasks we would like to do that don’t fit nicely in bug reports or in the blog post format. If you are performance-minded, there are also plenty of potential performance optimizations described in that project.
Update on Previous Priorities and 4.3
The below are the priorities we identified in the last rendering priorities blog post. Some of these come from earlier blog posts as well. We are happy to report that almost all priorities from the previous posts are either finished, or ready to merge.
Background pipeline compilation + Proper multi-threading in the RenderingDevice (GH-90400) (Ready to merge)
This work was finished during the 4.3 dev cycle, but we deferred merging it to 4.4 because of its size and complexity. As a reminder, this PR implements the concept of an “ubershader” which is basically a version of the shader that contains all features and is compiled at load time. We pair the ubershader with the ability to compile specialized shader pipelines in the background. This way when we draw a new object, instead of freezing and waiting for the pipeline to compile, we fallback on the ubershader and compile the specialized shader in the background.
The early results are very promising. We are seeing reduced load times for large games as well as a reduction in shader pipeline compilation stutter when objects are seen for the first time. In fact, so far we are seeing no shader pipeline compilation stutters at run-time.
BUGS (in progress, always)
We fixed over 300 rendering related bugs in 4.3! We expect to fix a few hundred more in 4.4 :)
GL Compatibility renderer - 3D (Done)
We merged support for MSAA, LightmapGI (including baking), resolution scaling, glow, ReflectionProbes, post process adjustments and color correction in time for 4.3. At this point we consider the Compatibility renderer feature complete which means it now has all the features we planned for it when we first designed the renderer. We will continue adding some new features to achieve closer parity with the Mobile renderer, but new features will have less of a priority now.
This was merged early in the 4.3 release cycle, but was improved steadily throughout the release cycle. The D3D12 rendering driver is now available for widespread use. This is especially important for ARM64 Windows devices which don’t support OpenGL or Vulkan.
This was very important foundational work that has allowed us to simplify our rendering code and ease the future maintenance burden as we port to more rendering backends.
As expected we merged the new Acyclic Render graph in 4.3. It significantly improved stability of the engine and resolved many hard to fix errors as well as moderately improved performance. To read more see the blog post.
Compositor Effects (Rendering Hooks) (GH-80214) (Done)
The new CompositorEffects API allows you to register callbacks that will be called in the middle of the rendering process. This lets you insert custom RenderingDevice commands in the middle of the render frame to customize rendering.
Right now the API is functional and exposes almost all internal render state so you can access all the intermediate information.
There is already an official demo so you can see how it works!
This was a work in progress for much of the 4.3 release cycle and was finished slightly too late to include in 4.3. We merged it immediately for 4.4 so we can get widespread testing before release. It’s ready to try in 4.4-dev1 or later releases.
Metal enhances both performance and stability on Apple silicon devices. Please test it out and let us know if you run into any issues!
This is still a work in progress, but results are already quite good. Both performance and quality are better than SDFGI. Juan still has many ideas he wants to apply, so this work may continue for some time before it is ready.
New Priorities
We have completed almost all of our previous priorities, so now we get to set out new goals for the next few release cycles. Right now rendering contributors are most excited about two things:
Unblocking advanced users (especially for advanced VFX).
Improving performance.
These are rising to the top of the priority list as Godot becomes increasingly stable and the core user-experience feels quite good.
In particular the following are areas where you can expect to see changes in the next couple of releases. Bear in mind that we don’t have dedicated people working on any of these priorities. If you are interested in contributing, please consider contributing in one of these areas.
Performance
Performance is our number one priority. Now that Godot 4 has been out for over a year we are seeing more games releasing with Godot and users are starting to create bigger and higher-fidelity games. A natural consequence is that Godot’s renderer is starting to become a limiting factor for some users. Accordingly, it’s time for us to prioritize speed and to start implementing all the optimizations we have been putting off for later. You can find a list of a number of them listed in our 4.x Rendering Roadmap Github project.
Lightmapping improvements
We have had a lot of recurring requests to improve the quality and ease-of-use of LightmapGI. So far in 4.4 we have had a few major improvements (including bicubic sampling and a GPU-based texture compressor), but there is a lot of work still to do to ensure that baking and using LightmapGI is as seamless as possible.
Improving VFX workflow
Godot 4 has brought many quality of life features to particles like animated velocities and turbulence. However, particles still fall short in term of the broader workflow. VFX artists have to come up with their own structure for VFX (often script + animation player), figure out ways to check timings of their effects outside the engine (using screen capture software, for example), modify billboarding logic manually when moving to custom particle shaders, and so on. Despite improvements to the flexibility of the engine, artists still need advanced technical knowledge to do many things (like writing post-processing effects with the new CompositorEffect API).
We still have a lot of work to make Godot more accessible for people that are less interested in learning shaders or programming but still want juicy effects and immersive environments in their games.
If you want to help, there are plenty of things to do. From helping by gathering knowledge and evaluating solutions from multiple perspectives, to implementing agreed new features and bug fixes, finally, by joining us in the VFX Discord server.
Customized rendering
As Godot adoption increases, it is being used for more niche and specialized projects. However, we can’t provide everything that every user needs out of the box without becoming bloated, slow, and hard to use. So we need to provide more tools to customize rendering for projects that need more specialized effects. We started that process in 4.3 with the CompositorEffects API. We want to continue that effort by implementing more things in the Compositor API to allow users to control the order of rendering, override shader templates, etc.
All of the screen-space effects in Godot 4 were designed to run without using temporal reprojection for 2 reasons: 1) we didn’t want to force anyone to enable TAA in order to have a good looking game and 2) we didn’t properly calculate motion vectors for moving objects until Godot 4.2. Temporal reprojection allows us to make our effects much higher quality for a lower base performance cost.
Now that we have proper motion vectors, we want to provide versions of all the screen-space effects that take advantage of motion vectors to increase their quality and reduce performance cost.
We still won’t require TAA for any of the built-in effects as we want users to be able to choose whether to enable TAA or not, but we will likely use temporal reprojection by default for most of these effects.
This is an area that is really easy to contribute to if you are already familiar with rendering but want to get more familiar with Godot!
Support
Godot is a non-profit, open source game engine developed by hundreds of contributors in their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!
-
+
\ No newline at end of file
diff --git a/article/results-godot-jam-june-2018/index.html b/article/results-godot-jam-june-2018/index.html
index 91c7e3aa56..d0bcd1a26c 100644
--- a/article/results-godot-jam-june-2018/index.html
+++ b/article/results-godot-jam-june-2018/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde2 July 2018
This article is from July 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.
110 participants developed games with Godot Engine on the theme TEMPERATURE. There were ton of great ideas, and it has been a lot of fun to play them all and give the authors some feedback. All games can be downloaded from the itch.io jam page, and you can also see how they were implemented with the source archives or repositories provided by the developed. 38 of those games were their developers’ first Godot project (filter the entries with the “Yes” filter to see them).
For the first time, we also have some prizes for our jam winners, thanks to the generosity of Packt Publishing! See below for details, but first let’s check the top 3!
1. Fire and Fondness
Fire and Fondness is a delightful tale of love, tradition and carbonisation (UK spelling intended) by John Gabriel! This cute and well-designed pixel art puzzle game snatched the 1st position in the Gameplay and Graphics and Sound categories, and 2nd position in the Theme interpretation category (Overall rating: 4.088). And while there was no voting criterion for the writing, the introduction and ending texts of the game are definitely worth reading!
The Weather Guy by Emilio and Andre Mari Coppola is a clever quiz game where you have to guess real-time temperatures in big cities all around the world. The beautiful artwork and animation coupled with the witty writing and intelligent use of live real-world data made it a brilliant entry.
Emilio and Andre Mari’s 2nd place is all the more impressive given that this was their first Godot game!
3. On Blazing Rails to Kansas City
On Blazing Rails to Kansas City by Dalton5000 is a cute arcade game where you fire up your locomotive by throwing coal on it, while simultaneously splashing it with water to prevent overheating and throwing bombs at weight-dropping birds! While the game in the jam version is a bit on the easy side, the gameplay is very smooth and well executed, and the great art, animations, music and sound effects make it a gorgeous game.
We decided to celebrate this very successful game jam with some goodies for the winners, as well as for a couple randomly-selected participants (using GDScript’s randi() for the selection of course!).
We have nice Godot T-shirts from the previous GodotCon with the Godot 3.0 design that we will send to our 3 jam winners, but there’s more!
Chris Bradfield, one of the main contributors to Godot’s official documentation, as well as the guy behind the great KidsCanCode tutorials channel, has just published the Godot Engine Game Development Projects book with Packt Publishing. It was sent for printing today and should be available in paper format and ebook within a week. I had the opportunity to have a look at the book and it should be a pretty good learning resource, teaching how to use Godot hands-on with 5 different projects implemented from scratch, each introducing more advanced features of the engine to master.
Packt Publishing gave us several printed copies of the book as prizes for the jam, which we’ll have signed by Chris and shipped to our winners. We chose to give one copy to the overall jam winner, and one copy each to two first-time Godot users who participated in the jam (chosen randomly). Therefore we’re giving away three signed copies to:
And there’s more! Packt also gave us discount coupons for the book to share with all jam participants, you should receive them by email tomorrow (15% discount on the printed book and 50% discount on the ebook).
Thanks everyone for participating in this great jam, either as game developer or as player. Stay tuned for infos regarding our next jam!
-
+
\ No newline at end of file
diff --git a/article/retrospective-and-future/index.html b/article/retrospective-and-future/index.html
index 67a7895549..bc3e4177f3 100644
--- a/article/retrospective-and-future/index.html
+++ b/article/retrospective-and-future/index.html
@@ -11,7 +11,7 @@
Interest over time in “Godot Engine” on Google Trends
GodotCons
As the project started growing, Godot Conferences started being organized, this way most of the core contributors could meet face to face. This greatly improved discussions and decision-making in key areas.
Nowadays, we meet several times a year in Europe. In fact you are welcome to join us next month in Brussels!
New goals
Afterwards, the plan was to “split” teams, as I would work on the Vulkan branch (which will become the master branch soon, and is expected to release as Godot 4.0 by mid 2020) and Rémi would manage with the rest of the contributors the release of Godot 3.2 (for the first time, entirely on his own, and he is doing an amazing job so far).
And then a decade has gone by. The almost six years since Godot was open-sourced were a roller-coaster. It’s hard to believe so much happened in such a short amount of time.
Future
Today, Godot has over a thousand contributors and an amazing user community. The new 3.2 version will hopefully be released this month (January 2020), with even better and improved usability and stability, and putting an end to our best release cycle yet.
Afterwards, the Vulkan branch will become master (it will be pretty unstable for a while, so definitely not advised for production). The plan is to not add a lot of new general features in 4.0 and focus exclusively on bringing rendering quality and performance on par with mainstream game engines.
Of course, as always, keep in mind that all this is done with ease of use as our first priority, as Godot is designed so that small and medium sized teams, as well as individual developers, have the best possible tool for the games they want to make.
The new rendering architecture will also allow companies working on console ports to more efficiently port the engine and offer our users the possibility of running their games on the most popular game consoles (something we will, unfortunately, never be able to offer officially due to legal reasons, thus forcing us to cooperate with companies porting it on their own).
So, to everyone contributing, using, following or donating to Godot development, have a happy new decade! From the bottom of our hearts, lets hope our hard work will help you one day make your dream games come true!
-
+
\ No newline at end of file
diff --git a/article/review-gamescom-2024/index.html b/article/review-gamescom-2024/index.html
index 66eefdb666..d82d6fdfa5 100644
--- a/article/review-gamescom-2024/index.html
+++ b/article/review-gamescom-2024/index.html
@@ -15,7 +15,7 @@
On Thursday evening, we hosted our own off-site Godot mixer, and attendance was great! Sitting on the outside patio of the Haxenhaus, an old GDC Europe staple location as we were told, we got to enjoy plenty of food and drink - courtesy of our longtime sponsor W4 Games.
It is always a pleasure to meet our community face to face, and we are flattered that many of you seem to agree. Thank you to all attendees for sharing your personal Godot Engine stories with us, we learn a lot from these conversations every time. For the next events, we might need more sponsors to be able to accommodate more than “just” 50 of you.
To meet a few more community members, we also assembled Friday afternoon at the aforementioned Indie Arena Booth. Despite having to yell-talk and running out of goodies to distribute, we had a lot of fun helping fellow developers network and mingling ourselves. Considering the amount of people that showed up, we were almost concerned the Germans would come after us for “unlawful assembly” or “blocking the exit paths” - luckily for us, nothing of that sort happened and instead we got to take a big happy group picture:
What event would you like to see us attend next? Tell us on our official forum! Bonus points if you know a local user group or creators who would help us staff a booth, and a sponsor to help with the related expenses.
-
+
\ No newline at end of file
diff --git a/article/review-godotcon24/index.html b/article/review-godotcon24/index.html
index e4bfd487c6..cd07d87092 100644
--- a/article/review-godotcon24/index.html
+++ b/article/review-godotcon24/index.html
@@ -19,7 +19,7 @@
-
+
\ No newline at end of file
diff --git a/article/schedule-godotcon-2018-poznan/index.html b/article/schedule-godotcon-2018-poznan/index.html
index 41d370fb08..59dcf4c8bc 100644
--- a/article/schedule-godotcon-2018-poznan/index.html
+++ b/article/schedule-godotcon-2018-poznan/index.html
@@ -6,7 +6,7 @@
We’ll shape the day based on the interests of the audience to make the most out of it :)
Juan will show us how the exciting new TPS demo is set up, with insights in how to import assets, set up 3D scenes and configure the materials and environment for such a visual output.
Talk:My Godot toolbox: patterns, animation and encapsulation
Godot is a powerful multipurpose engine that can be used for pushing the boundaries of medical simulation. In this presentation we will explore non-conventional use of the engine, software practices that emerged during development and thoughts about Godot itself.
Talk:Procrastinators hate him - a simple trick to keep development momentum
Jagiellonian University is deploying Godot as main teaching software for Geometry and Simulation. Leszek will present their project and how the Godot community can benefit from it.
Basic way to get a normal mapped 2D sprites from Blender to Godot, and a few fun things you can do with them in Godot.
Prerequisites: Laptop with Godot 3.x and Blender 2.79c installed.
The speakers
Here’s some info about our GodotCon speakers. Note that we’re still accepting late proposals of activities, so you could be one of those too :)
Ilaria Cislaghi is a game designer working for simedis AG, a company specialised in virtual reality medical simulation. In her free time, she enjoys developing games about Antarctica with Godot.
Fabio Alessandrelli is a core Godot developer and maintainer of the networking stack of the engine, among other contributions. As an indie dev, he also published Aequitas Orbis in early access, a multiplayer 2D space game using Godot 2.1.
Gilles Roudière is one of Godot's core developers and focuses lately on the engine's usability, with many changes to the editor like an enhanced FileSystem dock, a better workflow in the 2D CanvasItem editor and a new axis handling system for gamepads.
Jakub Grzesik is the programmer half of Polish studio Kivano Software, who brought us the Godot game Marble Machine and is now getting close to releasing RivenTails: Defense. He's also a contributor to Godot's bug triage team.
Juan Linietsky is Godot's co-creator and lead developer, and oversees most of the features added to the engine to keep it efficient and well-designed. He splits his work time between writing code himself, and helping other contributors make good changes.
Krzysztof Jankowski is the prolific coder of FOSS-focused Polish studio P1X, and worked on projects such as Tanks of Freedom, Piradice and BitWars.
Leszek Nowak teaches Game Development at the Jagiellonian University in Krakow, where they are now using Godot as default teaching software for Simulation and Geometry courses. He also made over 10 games with Godot during game jams.
Mariusz Chwalba describes himself as a programmer by trade, gamer by hobby, game developer for fun. He loves sci-fi and fantasy - both movies, books and games - and works on ΔV - Rings of Saturn with Godot 3.1.
Rémi Verschelde is Godot's project manager, working relentlessly to facilitate contributors' work and make sure that it fits Godot's architecture and standards. That also implies organizing community events like this GodotCon :)
Wojciech Chojnacki is a professional backend programmer, also streaming and gamedev enthusiast, enjoying making games as much as playing them. Part of the P1X team, working on small, open-source projects.
-
+
\ No newline at end of file
diff --git a/article/schedule-godotcon-2019-brussels/index.html b/article/schedule-godotcon-2019-brussels/index.html
index 063f06535c..5b07b284ac 100644
--- a/article/schedule-godotcon-2019-brussels/index.html
+++ b/article/schedule-godotcon-2019-brussels/index.html
@@ -10,7 +10,7 @@
Today, while still not an avid coder, he uses Godot to make videogames to help us further understand the human mind and brain as a neuroscientist.
-
+
\ No newline at end of file
diff --git a/article/schedule-godotcon-2019-poznan/index.html b/article/schedule-godotcon-2019-poznan/index.html
index d5a0e313b5..1a07a2ef03 100644
--- a/article/schedule-godotcon-2019-poznan/index.html
+++ b/article/schedule-godotcon-2019-poznan/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde10 October 2019
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.
Update 2019-10-16: Here is the current schedule with time table: Link to PDF.
As announced a few months back, we are organizing a Godot Conference (GodotCon) in Poznań, Poland next week, on 16 & 17 Oct 2019. We expect close to 90 attendees, so this should be a great event!
Thanks again to the organizers of the Game Industry Conference for hosting us as a pre-GIC event, as well as hosting the Godot Sprint on 14 & 15 Oct at the same venue, where engine contributors will meet to work together, discuss the roadmap for 4.0 and future releases and many other technical topics :)
Below you will find the preliminary schedule for GodotCon Poznań, as well as a short description of the talks and the speakers. The order of the talks is still likely to change, and a few more talks may be added as we often get last minute proposals (especially from core contributors who tend to prefer making Pull Requests over preparing talks ;)).
Note for GodotCon attendees: Always refer to the Events page when in doubt about specifics regarding the event (time, location). We’ll update this page in priority whenever there is new details (especially more precise indications about how to find the conference room).
For people who cannot attend GodotCon, do not despair―we plan to have a livestream on Godot’s YouTube channel, which will also be available in replay.
GodotCon schedule
Update 2019-10-16: Here is the current schedule with time table: Link to PDF.
Juan will show us the current state of the (work-in-progress) Vulkan branch, and explain how it was designed and the main differences with the Godot 3.x backend. He will show new features such as the reworked Global Illumination probes, anisotropy, and how a project like the TPS demo fares on Vulkan.
At GDQuest, we’ve learned to make free software creating small demos, tools, and tutorials for the community. This year was essential for us as we focused on complex projects and learned to work as a team. The next step is to build free and open-source games that both go beyond entertainment and benefit the community. Everyone is welcome to join us on this journey to become better game developers and create meaningful projects together.
Talk:GPU procedural map generation in Godot
Paweł Mogila
Godot has support for simplex noise and you can generate procedural 2D or even 3D noise with with various parameters. If we use and mix one or more of such noises in proper way you can get nice looking maps. All that happens on the CPU. In my talk I would like to show another approach which uses the GPU for making 2D maps. It’s much faster and we can instantly see the effects as we modify the shader. That gives us much faster iterations and more possibilities.
Through the nature of Imperative Programming coupled with Object Oriented Programming countless solutions for solving a problem emerge. This flexibility comes with a cost: beginners struggle with knowing where to start while advanced users seek out coding patterns for simplifying their projects, picking the helpful path not necessarily being an easy task. The GDQuest Coding Guidelines have emerged as a “standardized coding layout system” to improve code readability and project workflow by providing a way to think about code structure and object coupling in Godot.
This talk will teach the foundations of music composition and will show a workflow by which anyone can create his own instrumental tracks combining that knowledge with the aid of certain software. That’s the exact same workflow the speaker used to create the music for his upcoming game.
Demo:My first PR - how to start contributing to Godot
Ever wanted to become a Godot contributor, but don’t know where to start? This little guide will show how to identify the cause for a simple issue and make a Pull Request (PR) fixing it, following Godot’s contribution workflow.
Talk:WebRTC: Low-latency, encrypted, peer-to-peer multiplayer for Godot Engine
Overview of the new WebRTC support in the upcoming Godot 3.2: why and how to use it, how it is implemented, etc.
Talk:Using Godot for economic simulation and agent-based modelling
Jeremiah Lasquety-Reyes
Economic models are difficult to understand for ordinary people. I talk about how Godot can be used for more intuitive and understandable economic models especially through combining a certain school of economics (Austrian economics) and a certain kind of simulation (agent-based modelling). I consider how Godot’s unique scene-node system, flexible graphics, scripting language, and open source code make it a promising alternative to standard agent-based modelling software.
Talk:Implementing game programming patterns in Godot
Giovanny Beltrán
A software design pattern is a repeatable solution that can be useful in many different scenarios. In this talk, I want to share with you how after developing several games in our studio using Godot, we have started improving our software design practices by implementing design patterns that make coding easier for us while making our games easier to maintain.
Demo:Enhance your Godot game with PBD based soft bodies
Leszek will show how to implement various soft bodies using Position Based Dynamics in Godot. Followed by discussion about advantages of using Position Based Dynamics instead of Mass Spring Systems.
Talk:Trip the Ark Fantastic
Aleksandar Gavrilović
A short presentation of an upcoming Godot based video game called Trip the Ark Fantastic. It is a fable-based RPG cofunded by the MEDIA fund of the European Union which will be released in 2021/2022.
Demo:Character rigging using Skeleton2D
Matejs Balodis
A quick demo on how to set up, rig and animate a 2D character in Godot Engine using 2D meshes and the Skeleton2D node. In the process you’ll learn some tips and tricks that Matejs has picked up from his experience while creating characters for a stream overlay game.
More demos of current and upcoming games by several attendees.
Possibly a talk on the FBX support in the upcoming Godot 3.2.
The speakers
Here’s some info about our GodotCon speakers. Note that we’re still accepting late proposals, so you could be one of those too :)
Fabio Alessandrelli (Italy) is a core Godot developer and maintainer of the networking stack of the engine, among other contributions. As an indie dev, he also published Aequitas Orbis in early access, a multiplayer 2D space game using Godot 2.1.
Matejs Balodis (Latvia) is a game developer, streamer and member of Rocknight Studios, where the development is done using FOSS tools. He actively promotes Godot Engine and other FOSS tools during livestreams on Twitch by showing viewers the creative process. As part of Rocknight, Matejs hosts a 3-hour game jam every weekend since January 2019 called Trijam, where over 325 games in 40 jams have been created thus far.
Giovanny Beltrán (Colombia) is a software engineer with experience working with JavaScript and Python. After working for startups in California, he is now the lead programmer and producer of Black Mamba, an independent game studio located in Bogotá, Colombia, which uses Godot for their projects. He is also co-organizer of BogotaJs, a huge JavaScript meetup in Bogota, co-host of JuegosIndies, a YouTube channel about game design, and just founded a Godot Bogotá meetup.
Tomasz Chabora (Poland) is a passionate game developer and gamer. He is a member of Gamedev Students Association at Jagiellonian University, where he actively promotes Godot engine. He also happens to be an active contributor to the engine, fixing and implementing random stuff.
Pedro J. Estébanez (Spain) has been involved in different kinds of software development across the years, his main interest and focus regarding computers being multimedia, computer graphics and video game development. He has been contributing to Godot for some years and providing consultancy about it. Currently he's working on his video game Hellrule.
Aleksandar Gavrilović (Croatia) is the CEO of Gamechuck, a Croatian video game company. Aleksandar previously worked on award winning and critically acclaimed point-and-click adventures, and is now a producer for Trip the Ark Fantastic.
Jeremiah A. Lasquety-Reyes (Germany) is a researcher at the Institute for Advanced Study on Media Cultures of Computer Simulation (MECS) at the Leuphana Universität Lüneburg, Germany. Much of his work deals with ethics and medieval philosophy. He plans to use Godot for his upcoming project, the Austrian Economics Model.
Juan Linietsky (Argentina) is Godot's co-creator and lead developer, and oversees most of the features added to the engine to keep it efficient and well-designed. He splits his work time between writing code himself, and helping other contributors make good changes.
Nathan Lovato (France) is a game creation tutor and free software advocate. With GDQuest, he makes tutorials for programs like Godot and Krita, and releases all his code as source.
Paweł Mogiła (Poland) teaches game programming and motion capture at Jagiellonian University in Krakow. He also creates his own stuff and recently released his last game Clinically Dead on Steam. His next game will be in Godot.
Leszek Nowak (Poland) teaches Game Development at the Jagiellonian University in Krakow, where they are now using Godot as default teaching software for Simulation and Geometry courses. He also made over 20 games with Godot during game jams.
Răzvan Cosmin Rădulescu (Romania) is a programming freelancer working at GDQuest on creating tools & plugins for FOSS. He's also the lead developer on GDQuest's latest 2D platformer game demo. Holds a masters in physics, but slowly drifted away from academia being drawn more by the idea of game development. He also has a keen interest in digital painting & drawing and generally tech-related craft. His latest big dream is to create a highly dynamic community in his (small) home town in Romania, centered around the FOSS philosophy stretching across domains, not just tech.
-
+
\ No newline at end of file
diff --git a/article/schedule-godotcon-2020-brussels/index.html b/article/schedule-godotcon-2020-brussels/index.html
index 1bb3dcec02..00e5ef833d 100644
--- a/article/schedule-godotcon-2020-brussels/index.html
+++ b/article/schedule-godotcon-2020-brussels/index.html
@@ -6,7 +6,7 @@
He loves being distracted by the inner workings of the Godot engine and fixing some of those long-standing issues.
Matejs Balodis (Latvia) is a game developer, streamer and member of Rocknight Studios, where the development is done using FOSS tools. He actively promotes Godot Engine and other FOSS tools during livestreams on Twitch by showing viewers the creative process. As part of Rocknight, Matejs hosts a 3-hour game jam every weekend since January 2019 called Trijam, where over 450 games in 52 jams have been created thus far.
Yann Burrett (United Kingdom) is a professional educator, teaching everything from Stage Management to Game Design to English to Making Games in Godot. He’s one of the company directors of Canopy Games Ltd and the author and instructor of the Discovering Godot and Godot Getaway courses.
Aurélien (France) is not a professional developer but he has designed several successful serious games in the legal sector. He is currently working on a 3D game project with Godot, displaying the adventures of a blue rabbit.
Pedro J. Estébanez (Spain) has been involved in different kinds of software development across the years, his main interest and focus regarding computers being multimedia, computer graphics and video game development. He has been contributing to Godot for some years and providing consultancy about it. Currently he's working on his video game Hellrule.
Paweł Fertyk (Poland) is a long-time coder with a passion for open source and game development. His company, Miskatonic Studio, published the Godot-made Intrepid on Steam in December 2018 and is currently working on 3D adventure games.
Juan Linietsky (Argentina) is Godot's co-creator and lead developer, and oversees most of the features added to the engine to keep it efficient and well-designed. He splits his work time between writing code himself, and helping other contributors make good changes.
Bojidar Marinov (Bulgaria) is a young software developer and open source contributor to the Godot engine. His main interests are in the design of programming languages, elegant algorithms, and generally in doing more with less. He regularly visits various Godot community channels, helping newcomers to learn the engine's specifics.
George Marques (Brazil) has worked at Javary Games and IMVU making games with Godot, being a contributor to the engine since 2015. Currently works directly for Godot, in special maintaining the GDScript codebase. He's also a co-author of the book Godot Engine in 24 Hours published by Pearson.
Julian Murgia (France) is a contributor and member of the Godot Engine Leadership Committee. He has contributed in both code and documentation, helping here and there when possible. He also maintains the Escoria framework for point and click adventure games on Godot Engine.
-
+
\ No newline at end of file
diff --git a/article/shedding-light-on-godot-development-process/index.html b/article/shedding-light-on-godot-development-process/index.html
index 6cfea89553..0a4f99388a 100644
--- a/article/shedding-light-on-godot-development-process/index.html
+++ b/article/shedding-light-on-godot-development-process/index.html
@@ -5,7 +5,7 @@
Juan Linietsky3 December 2017
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.
Godot keeps growing steadily in both users and contributors, and 3.0 will be our best release yet. As our community keeps expanding, the development process also reshapes to accommodate new contributions.
While our process is completely transparent, it is not obvious for a large part of the community how new features, fixes and improvements are added. This short article will attempt to shed some light on it.
Who is the boss?
We constantly get questions about who is the boss. Several community members also attempt contacting me, Rémi and others asking us for help or features, and giving suggestions. The problem is we are not anyone’s bosses.
As an entepreneur myself, and having owned many small companies in the past, I can assess that the relationship between open source developers is completely different to that in a corporate culture. An employee gets paid to do his or her job, but an open source contributor helps the project because of his or her own impulse to do it.
In open source projects, most developers work on their free time, on whathever they want, and when they want. No one has any authority over them, be it moral or monetary, and this is for the best. The code they give to the project is also still owned by them (under the same permissive license).
This may seem chaotic, but it works very well. Godot does not have to compete with companies for mindshare, we have some of the brightest minds working for the project.
Ok, but who decides?
When Godot was open sourced, I was the only lone contributor and of course, whathever was done was my decision. As more contributors joined the project, the priority was to incorporate them in the decision making.
The important word here is consensus. In everything we do, we try to look for agreement between all parties involved and, so far, we never had problems with this. Were there to be disagreements, we could look for voting but everything was discussed and agreed up to now.
How is consensus reached?
Here are some typical situations going on during development.
Feature request
Often, users request features on GitHub (by opening an issue). At first, other users will discuss whether they think it’s ok or not. Eventually, developers may chime in and give their view on how difficult it could be to implement and whether it’s worth or not.
If this feature is easy enough to do, usually one of the developers who commented may feel tempted to implement it and submit a Pull Request.
Sometimes, en existing or new developer comes up with a new feature and opens a Pull Request directly. This is fine, though we advise about first asking if the feature is wanted if the amount of work it takes is considerable, as it may be denied merge and result in wasted time.
Pull Request
Pull requests are commented and reviewed by developers. Only a few core developers can merge PRs, but they will only do if there is a consensus. To reach a consensus, we regularly host meetings to review PRs on IRC. If an agreement is reached, the PR is merged.
Whenever a PR is trivial to assess and (from the point of view of the reviewer) unquestionably good, it can be merged without extensive discussion to speed up the process. If it ends up being challenged later on by other devs, it can get reverted so that a new PR can be worked on addressing the shortcomings of the first one.
Direct commits
Some core developers are “owners” of areas. This means they have enough knowledge on this area of the engine (because they learnt it well or because they made it themselves), that allows them to commit directly to keep improving or working on it. Likewise, they can usually decide to merge a PR in an area of their responsibility if they approve it.
Community filter
There are hundreds of community users building Godot from source. In general, bad commits are easy to find and bisect and they can be quickly reverted. This is why Godot is always very, very stable.
No, Juan and Rémi don’t decide
Before approaching me, Rémi or someone else, please understand that our current role is more along the lines of communication. We try to convey information outwards to the community, and inwards to new and existing developers.
As mentioned before, most decisions on features, fixes, etc. are made in consensus and generally over GitHub or IRC.
What about Software Freedom Conservancy and the Godot PLC?
The original owners of the “Godot” trademark are me and Ariel Manzur, who worked on it since around 2007. Like many other high profile open source projects, we signed an agreement with Software Freedom Conservancy so they can use the trademark, collect money for the project and defend the project legally.
Conservancy requires that a PLC (Project Leadership Committee) is created. They also require that Ariel and I are in a minority in this committee, so there are three more members from the core team, selected by their longstanding contributions to the project over the years. The current PLC members are:
Juan Linietsky (me, who act as development lead)
Ariel Manzur (co-author of Godot, though not currently active in development)
Rémi Verschelde (who acts as project manager)
George Marques
Andreas Haas
Previous members:
Alket Rexhepi (stepped down due to lack of time).
In any case, Software Freedom Conservancy acts as our fiscal sponsor. They receive donations for the project and the PLC decides what to do with them. Of course, as a charity, Conservancy has very strict rules to ensure that money is only used for the benefit of the project. They control every penny that goes through and make sure it’s invested as intended, so this should act as a warranty to the whole community and sponsors.
But the responsibility of the PLC is only about managing money, it has zero inference on the development process itself. If developers are to be hired with this money, it will still be done in agreement and consensus with everyone else, and only for contributors with an extensive and proven track record. Hired developers have a strict contract to comply with, drafted by Conservancy’s laywers.
How about Patreon?
Our current Patreon is owned by the Software Freedom Conservancy. All donations go to our project finances within their organization.
Conservancy asks that Patreon rewards can at much affect the priority of tutorials, demos or features that the project is already intending to do. We can’t offer rewards unrelated to Godot’s goals. This is why we ask the whole community for proposals, then we later approve them, and only Patrons have voting power in the end.
As soon as 3.0 stable is out, we will work on the proposals first. In general, existing contributors want to work on them, though I make sure to work on them myself if no one is up for the task.
What if I want to pay for specific work to be done?
There are two choices for this. If the work to be done is something of interest of the project and we want to merge it, Conservancy can accept a directed donation. Meaning they will be in charge of hiring (with our recommendation) someone to work on that. This is how the Mozilla and Microsoft grants happened.
If the work is no interest for the project (like, supporting a proprietary API or technology), many of our core developers accept paid work. Just drop a line to contact at godotengine · org, which will reach the PLC. We will ask the developers to see if there is any interest.
Help us be transparent
Our goal with Godot is to be as transparent as possible. This article was created to shed light on how everything works, but if you still have any doubts or would like to have more information, please let us know!
-
+
\ No newline at end of file
diff --git a/article/showcase-your-godot-game-our-website/index.html b/article/showcase-your-godot-game-our-website/index.html
index 9355adbf43..5ce391270a 100644
--- a/article/showcase-your-godot-game-our-website/index.html
+++ b/article/showcase-your-godot-game-our-website/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde27 June 2016
This article is from June 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.
As a relatively young game engine on the market (at least with regards to our open sourcing two years ago), we are often asked to showcase what are the features of the engine. But an engine such as Godot has hundreds of features catering to different use cases, and it’s obviously difficult to do them all justice; especially when cool new features keep incoming in the development branch!
Showcasing Godot-made games
So the best solution for this is to let you, the game developers, showcase what you can do using Godot! Games of all genres, 2D and 3D, with simple or very complex gameplays, story-rich or casual… Godot can be used for all those games, and you can help show this to the world!
To this extent, we created a Showcase portal (check the navigation bar!) that displays a curated list of published and in-progress games developed by members of the Godot community. The page itself is a first draft and is bound to be improved little by little based on your feedback and ideas. In a first time, please add your comments to this broad GitHub issue, to gather everything in one place.
Currently the page can list every entry with a name, screenshot, short description, tags and category, as well as a link to the reference homepage for the said game.
Proposing content
We pre-filled the page with some known indie and libre games developed by active community members; we know however that there are many other Godot games out there that would be worth showing on this page.
There is currently no automatized system for you to propose new entries, so we will do it the good old way: by sending emails to the webmasters (webmaster @ godotengine · org).
Please include the following information:
Name of the game
Short description
**URL: ** Project website, Steam store page, git repo, etc. - the most relevant one.
Category: Finished, WIP or Demo.
Tags: Check other entries to see what tags could be relevant.
Screenshot(s): Currently we only display one but this might change soon. Make sure that they have an aspect ratio similar to existing entries (4:3).
Screenshot of the project opened in the Godot editor: This is just to check visually that it is indeed a Godot game, so that we don’t start showcasing projects from other engines ;) (not necessary if the source code is available, as we can easily check then).
We might then cherry-pick some of our favorite entries (with your permission) for our next video showcase. In the meantime, here’s the first one again:
That’s it! Looking forward to getting submissions and discovering some great new games developed with our beloved engine!
-
+
\ No newline at end of file
diff --git a/article/simplex-noise-lands-godot-31/index.html b/article/simplex-noise-lands-godot-31/index.html
index 645bc0a539..9ae50574a0 100644
--- a/article/simplex-noise-lands-godot-31/index.html
+++ b/article/simplex-noise-lands-godot-31/index.html
@@ -25,7 +25,7 @@
For more information about OpenSimplexNoise and what is the meaning of each parameter, don’t forget to check out the documentation.
Noise texture
If you only need access to a noise texture for visual effects, the new NoiseTexture resource type is your best bet. It allows you to specify a noise generator and a texture. The texture data will be automatically filled with noise, using the parameters of the generator. You can also enable the use of seamless noise (only works with square textures) and enable outputting the noise data as a normal map.
-
+
\ No newline at end of file
diff --git a/article/skeleton-inverse-kinematic/index.html b/article/skeleton-inverse-kinematic/index.html
index 387ac1f4e1..a568e9f32c 100644
--- a/article/skeleton-inverse-kinematic/index.html
+++ b/article/skeleton-inverse-kinematic/index.html
@@ -5,7 +5,7 @@
Andrea Catania5 August 2018
This article is from August 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.
This blog post is an announcement that 3D IK support was merged to the upcoming 3.1 branch.
Thanks to a new node, SkeletonIK, it is possible to procedurally change a skeleton pose! Check this explanatory video where you can learn how to use it:
The project shown in the video can be downloaded from the following link.
-
+
\ No newline at end of file
diff --git a/article/sketchfab-integrates-with-godot/index.html b/article/sketchfab-integrates-with-godot/index.html
index 309e34a0a5..6a1f1cfa84 100644
--- a/article/sketchfab-integrates-with-godot/index.html
+++ b/article/sketchfab-integrates-with-godot/index.html
@@ -11,7 +11,7 @@
Pedro J. Estébanez20 March 2018
This article is from March 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.
Sketchfab is a well-known site where you can browse a big library of 3D models and download them for use in your own projects. Many of them are free, covered by open licenses.
They have just announced their download API (announcement), which allows third-parties to integrate with it, giving any application access to hundreds of thousands of models in glTF, a standard format that many tools, Godot included, understand.
They have integrations for other famous game engines, like Unity and Unreal and have decided to provide an official plugin for Godot! It’s also available on the Godot Asset Library. You can watch the video to get a better idea:
So it seems that more and more companies are taking Godot very seriously and it’s becoming a big player in the game engine landscape.
In order to run the Sketchfab plugin, you’ll need to wait until the upcoming Godot 3.0.3 is released since it contains some needed bugfixes, that were done after the last official version. If you are a Windows (x64) user and can’t wait, you can get a build snapshot from the plugin repository, under which it will work.
-
+
\ No newline at end of file
diff --git a/article/small-defense-gltf/index.html b/article/small-defense-gltf/index.html
index ae011c84f2..facdb6024f 100644
--- a/article/small-defense-gltf/index.html
+++ b/article/small-defense-gltf/index.html
@@ -5,7 +5,7 @@
Juan Linietsky24 August 2017
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.
What is this and why?
A few weeks ago, I wrote an article about why I believe glTF 2.0 to be a great format and that we should encourage its widespread adoption. I also compared it to other formats, including Eric Lengyel’s OpenGEX.
As I mentioned on the original article, I think OpenGEX is a very good format. My main criticism to the format was that development is not lead in what today would be considered an open fashion. Eric alone maintains control of it. In contrast, glTF is a true standard developed by a non profit and an open development process.
Today, Eric has published what I assume is a defense of OpenGEX vs glTF (and the ancient Collada). Eric has claimed that glTF is a format with design flaws (and that it is not fit to be a pipeline format).
While I agree on many points, and I won’t argue that OpenGEX is a great format, I just wanted to clarify a few things from my point of view for those interested in the technical aspects, explaining why many of glTF “shortcomings” are, in my opinion, actually brilliant design decisions. All this, of course, always for the sake of helping glTF 2.0 gain more adoption.
Feature by feature
Hierarchial node relationships
This is IMO the worst part of glTF. A single parent node index would have sufficed on each node. Instead, each node has an array of children nodes. This makes validation considerably harder. I understand this is the price to pay for backwards compatibility with glTF 1.0. That said, it’s not too bad in any case and I agree with Eric that this is a minor problem.
Object / pivot transforms
Some 3D DCCs support an extra object Pivot (e.g. 3DS MAX). Collada exports this as an extra node and most likely if a glTF 2.0 exporter existed, the same would be done. In my opinion, this feature is rather useless and I don’t think any mainstream 3D engine supports extra object pivots either. Having this extra feature supported also makes an OpenGEX importer more complex, so this IMO is a bad design decision in OpenGEX, not an advantage.
Per-instance material binding
In a scene description format, materials can be contained in instances (as in, the instance is the mesh used, the transform in the world, and the material) or inside meshes (mesh comes with a material). OpenGEX and Collada apply materials to instances (the former), while glTF 2.0 does to meshes (the later).
In 3D DCCs, the most common case is that materials are applied to objects. It’s a very, very rare use case for artists to re-use the same model and apply different textures to it. As such, the method used by glTF 2.0 is in my opinion more suited to real-life even if less flexible.
Skinning
When skinning in 3D DCCs, bones have a list of vertices they affect and how much. In game engines, for performance, vertices have, instead, a list of bones they are affected by and how much. This is done usually by two attributes in the vertex array “bone indices” and “bone weights”. Attributes are limited to vectors of four (vec4) maximum and no game engine that I know crosses this limit.
While OpenGEX and Collada support more than 4, I side with glTF 2.0 on this one because there really is no reason to support more and it makes the parser simpler. Again though, I agree with Eric that this is a minor problem.
Morphing
In this area, glTF 2.0 is lacking, as absolute morph targets can be useful and are supported by 3D DCCs, although not as common. I think this is more a problem of a missing feature than a design flaw.
Level of Detail (LOD)
While most game engines support this, it really is not much of a problem to generate it on import on each of them. Having this supported in the format is nice, but not really important.
Multiple vertex attribute sets
This is a feature that, for some reason, is not supported in glTF 2.0 that it would have cost them nothing to add. In fact most of the attributes that can be added end in _0, which makes it seem like it will be added in the future.
That said, I think the fact glTF uses very concise format information for each attribute (ie, vertices are always VEC3, UVs are always VEC2) make it an easier format to support in my opinion.
Index array properties
Triangles in arrays can be specified in clockwise or counter clockwise order. Depending on this one can tell which is the front and which is the back face. This allows the renderer to not render triangles that are not facing the camera.
That said, the ability to specify this in a pipeline format, in my opinion is a bad decision. OpenGEX clearly commited a mistake here. There is zero benefit to this and it makes parsing the format more complex.
Likewise, the ability to add restart indices is nice, but nowadays GPUs have wide vertex caches, which make stripping not very useful. Again I think this was another bad decision from OpenGEX.
Lights
OpenGEX and Collada do support lights. glTF 2.0 does not. While this may seem counterproductive, the reality is that (unlike cameras and meshes) most game engines have different way of rendering light attenuation equations and parameters. In Godot, for example, lights exported from Collada are rarely useful anyway.
OpenGEX supports multiple attenuation models but then again, there is no practical benefit to this if your game engine does not support it.
For the sake of completeness, it could be better if they were supported in glTF 2.x, but they are not very useful.
Animation support
Here, Eric makes the point that glTF 2.0 has serious design flaws by poorly (or not) supporting:
Keyframe animation with cubic interpolation
Animation of rotation angles
Tension-continuity-bias (TCB) animation curves
When exporting animations from DCCs to glTF 2.0.
I think however, that here the point is missed and that OpenGEX has put a lot of effort into features that are impractical.
The reasoning behind this is that animation is imported in game engines mostly from characters. Nowadays, characters are rigged and animated using IK, not FK. Reproducing the full IK chain and settings in a game engine is not only inefficient but against the most common use case of using state and blend trees, and game-related IK.
Because of this, character animation is mostly sampled (when exported) to either transforms or TRS units at fixed intervals, then compressed.
In fact, my main criticism to glTF 2.0 is not supporting transforms tracks.
Support for world specification
OpenGEX and Collada (and FBX) support specifying how the world must be intepreted by defining:
Distance, angle, and time units
Configurable world-space up direction
Forward direction specification
I think this is a terrible design idea and the reason so much suffering happens when implementing these formats. There is ZERO benefit in having this feature. Importers have to implement all these conversions manually, which results in a lot of effort and code. This feature only makes it bit easier to write an exporter, while writing importers becomes a nightmare. This is bad, not something to be proud of.
glTF 2.0 only has a single coordinate system, scale and time unit and this is one of the things that makes the format stand out as very clever.
I understand that many of these problems can be solved by using an importer library, but that just adds more complexity to the whole system. My glTF 2.0 importer is only 2000 lines of code and does not need any extra library for parsing it, which shows how good of a format it actually is.
Exporter support for 3DSMax, Maya and Blender
OpenGEX and Collada have solid exporters for all DCCs. This is the area where currently glTF is lacking the most, but by pushing for its adoption, we’ll eventually see DCCs get support for exporting to glTF.
-
+
\ No newline at end of file
diff --git a/article/soft-body/index.html b/article/soft-body/index.html
index 843b9f00ef..38c3839b4d 100644
--- a/article/soft-body/index.html
+++ b/article/soft-body/index.html
@@ -5,7 +5,7 @@
Andrea Catania7 August 2018
This article is from August 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.
Soft body support has finally arrived!
It is now possible to create cloth simulation and soft bodies by just adding a node. In the following tutorial, you will learn how to create a Soft Ball and a Cloak.
At the end you will find a video with a more advanced cloak implementation and the relevant project.
Soft Ball
To create a Soft Ball is to add a SoftBody node and add a mesh to it, in this case I used a sphere maded in Blender (I used a custom mesh because the sphere created dynamically by Godot is not completely closed, but just for a test you can use it).
As you can see above, many parameters are supported in order to obtain the simulation results wanted.
Note 1
Be careful with some parameters, as this can lead to strange simulation results. As an example, if the shape is not completely closed and you set pressure to more than 0.
Note 2
The Simulation Precision will improve the final result, often with significant improvement (and performance cost).
First, open the “Player” scene, add a SoftBody node and assign to it a PlaneMesh.
Now open the PlaneMesh properties and set the size(x: 0.5 y: 1) then set Subdivide Width and Subdivide Dept to 5, get back to SoftBody and adjust its position. You should end with something like this:
Subdivide will generate a more tessellated mesh and it will make simulation better.
The next step to do is attach the cloak directly to the character skeleton, to do it first add a BoneAttachment under the skeleton node and select the Neck bone.
Select the SoftBody node in the tree and click the upper vertices:
This action will create 7 pinned points, now go in the SoftBody properties under Attachments you find pinned points and for each of them put the NeckBoneAttachment in the SpatialAttachment, as belowe.
Almost done, just add the Player Kinematic Body to parent collision ignore of SoftBody to avoid clipping:
Hit Play and (if it all went right) you will obtain the following result:
That’s it enjoy your first SoftBody Cloak :) and don’t forget to become a Patron if you like Godot and you want us to keep improving it! Godooooooooooooot!!
-
+
\ No newline at end of file
diff --git a/article/state-godot-gdc-2019-github-hq/index.html b/article/state-godot-gdc-2019-github-hq/index.html
index 4ade0278bf..86cc7f9091 100644
--- a/article/state-godot-gdc-2019-github-hq/index.html
+++ b/article/state-godot-gdc-2019-github-hq/index.html
@@ -5,7 +5,7 @@
Juan Linietsky15 April 2019
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.
This year, during GDC, GitHub again hosted a Godot Meetup at their offices and the amount of attendants was considerably bigger than last year. Thanks hugely to them for all their support!
We took the chance to do our GDC “keynote” presentation there, which we called “The State of Godot 2019”. It was recorded and is now made available for everyone to see on GodotEngine’s official youtube channel.
-
+
\ No newline at end of file
diff --git a/article/statement-on-godloader-malware-loader/index.html b/article/statement-on-godloader-malware-loader/index.html
index f1548d83de..ac15227801 100644
--- a/article/statement-on-godloader-malware-loader/index.html
+++ b/article/statement-on-godloader-malware-loader/index.html
@@ -6,7 +6,7 @@
We encourage people to only execute software from trusted sources – whether it’s written using Godot or any other programming system.
For some more technical details:
Godot does not register a file handler for .pck files. This means that a malicious actor always has to ship the Godot runtime (.exe file) together with a .pck file. The user will always have to unpack the runtime together with the .pck to the same location and then execute the runtime. There is no way for a malicious actor to create a “one click exploit”, barring other OS-level vulnerabilities. If such an OS-level vulnerability were used then Godot would not be a particularly attractive option due to the size of the runtime.
This is similar to writing malicious software in Python or Ruby, the malicious actor will have to ship a python.exe or ruby.exe together with their malicious program.
Good security practices
We would like to take this opportunity to remind users about some good security practices when it comes to downloading and executing software.
Only download and execute software (including game mods) from trusted sources:
Official project website. Confirm it by checking the URL, and verify with a search engine that this seems to be the most frequently referenced website for this software.
Trusted distribution platform: Steam, Epic Games Store, Windows Store, Google Play, Apple Store, etc.
People you know, after confirming that they are who they claim to be if the communication is text-based (see below).
On Windows and macOS, verify that the executable is signed (and notarized, on macOS) by a trusted party.
Be wary of executing cracked software, which is a prime attack vector for malicious actors.
Be wary of executing software even from people you know, if you can’t confirm that their account hasn’t been compromised. A very common attack vector targeting specifically game developers is for Discord accounts to get hacked, and then malicious actors use them to send malicious downloads to their friends in private messages (“hey will you try my game?”). Make sure to confirm the identity of your contacts before executing such software.
Reporting security issues
We thank Check Point Research for following the security guidelines of responsible disclosure, which let us confirm that this attack vector, while unfortunate, is not specific to Godot and does not expose a vulnerability in the engine or for its users.
If you would like to report a security vulnerability or concern, please send an email to security@godotengine.org.
-
+
\ No newline at end of file
diff --git a/article/status-godot-gdc-2019/index.html b/article/status-godot-gdc-2019/index.html
index 30c491da6e..41f56400f1 100644
--- a/article/status-godot-gdc-2019/index.html
+++ b/article/status-godot-gdc-2019/index.html
@@ -5,7 +5,7 @@
Juan Linietsky26 March 2019
This article is from March 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.
Rémi Verschelde, Hein Pieter van Braam and I went to GDC 2019 in representation of Godot. Until last year, I would go mostly alone. So, how did it go compared to last year?
Game Developers Conference
Before anything, I’m sure that many reading this article don’t really know what GDC is.
GDC stands for “Game Developers Conference”, and it’s the biggest industry wide event for game developers. Almost 100k developers (companies and indies) meet in San Francisco every year in March to showcase their work, make business meetings, socialize, have fun, etc. This event is not mainly about showcasing games, like E3 or Gamescom, but entirely for developers themselves.
There are also talks about technology, production or any other aspect one can think about related to game development.
It’s a very big event and you get overwhelmed easily by so much going on at the same time.
Godot at GDC 2019
This is the second year I go to GDC exclusively as Godot representative (before I went as business consultant and, before then, I went representing my own company which no longer exists). This time, Rémi Verschelde (Akien) and Hein Pieter van Braam (tmm) also came, with Ernest Lee (iFire) and Ariel Manzur (punto) occasionally tagging along.
Unlike last year, we decided to focus on meetings more relevant to the project goals and reduced the meetings with companies using or interested in Godot to a minimum. Most of our meetings were with hardware manufacturers, service providers, potential sponsors and education institutions. We also got the chance to meet with key industry people like Nicolas Cannasse, Terry Cavanagh, Ryan Gordon, Lars Doucet, Alon Zakai, and many others.
So far, we can feel there is a growing excitement about Godot in the industry as more and more developers and companies learn about it and try it, with many games in development and about to be published on desktop, mobile and consoles. Godot is growing at a lightening rate, more than duplicating it’s user base every year.
Many companies we met also expressed high interest in dumping their current engine and going for Godot, due to the freedom that open source conveys and the high quality and usability of the engine (their words, not mine :P).
Recognition
But what I’m sure most reading are willing to know is how much recognition did Godot get at the event.
Let me recapitulate my comments from previous years:
2016
The sad truth is that, even after two years of being open source… NO ONE KNOWS ABOUT GODOT!
2017
Compared to last year, some more people had heard of Godot, but it’s still very largely unknown. We seriously need to consider ways to improve on this.
2018
I would probably say most of the industry still has not heard about it, but there is a very significant chunk that did, though.
2019 (this GDC)
From everyone we talked to, it seems at this point a majority of the industry has heard of Godot. Most of those we casually talked to definitely had heard of it and many expressed interest in developing games with it in the future.
From the indie side, most Indies did hear about it, but for company executives Godot remains largely unknown. This, however, seems to be changing because the amount of Godot users within big companies is growing significantly and pushing for it from the inside.
Thanks to this, we surprisingly got a lot of endorsement from developers in large companies, which also is helping us become a more visible and believable option.
As an interesting anecdote, we printed around 800 beautiful metallic pins and distributed them at booths of companies or developers who use or sponsor Godot. At the second day, they had all ran out. They told us people passing by loved them and asked if they had anything to do with it.
Future
I’m excited about how next year will be for Godot. Growth seems fast and steady, so this makes up happy to know we can continue focusing on doing what we do best, improving Godot.
That said, please understand that Godot core development happens thanks to the generosity of our patrons. If you are not yet, please consider becoming one and supporting the project. It takes minutes to set up a recurring donation and any amount is vitally welcome, as it allows more of our most dedicated core contributors to focus solely on Godot. The more donations, the safer the project is and the faster it can mature and grow.
-
+
\ No newline at end of file
diff --git a/article/status-of-opengl-renderer/index.html b/article/status-of-opengl-renderer/index.html
index 0564f18915..d499517da7 100644
--- a/article/status-of-opengl-renderer/index.html
+++ b/article/status-of-opengl-renderer/index.html
@@ -5,7 +5,7 @@
Clay John20 December 2022
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.
Last year we announced that we were planning on creating an OpenGL-based renderer to complement the current Vulkan-based renderers. At that time, we thought that we wouldn’t have it ready until 4.1. However, we are now confident that we will be shipping 4.0 with an OpenGL-based renderer; it just won’t be feature complete.
As a reminder, an OpenGL-based renderer is still crucial so we can support older platforms, and Web export. There is a Vulkan-like web API called WebGPU in development, but it currently isn’t widely supported yet, so WebGL remains the best option for targetting web games.
At the time of writing this article, all planned 2D features and most basic 3D functionalities are now supported by the OpenGL 3 renderer. As it is much newer, the OpenGL 3 renderer hasn’t been tested as widely as the Vulkan-based renderer. We expect it will have more bugs for the time being.
Our goal is for the OpenGL 3 renderer to have broad compatibility and good performance on a wide range of hardware. Accordingly, it won’t receive all the fancy new features that the Vulkan-based renderers bring.
In many ways, the current OpenGL 3 renderer resembles the GLES2 renderer from Godot 3.x. It makes similar compromises to ensure compatibility with as many devices as possible. For example, like the GLES2 renderer, the OpenGL 3 renderer renders in sRGB-space (this is a simplification, but is roughly true). This means you will see a difference in lighting when using the OpenGL 3 backend, compared to the others which use proper linear-space lighting.
In 3D, only basic rendering is supported right now. Thus far, we’ve prioritized the 2D rendering engine to ensure that it is ready for the release of 4.0. We anticipate most users of the OpenGL backend will be using it for 2D development. For 3D, we have quickly added the basic features (drawing objects, lights, sky etc.) so that users can get something drawing on the screen, but we haven’t added any advanced features or optimization. Accordingly, the current OpenGL 3 3D renderer is still a shell of what it will be.
The big missing features that are planned are:
3D shadows
ReflectionProbes
LightmapGI
VoxelGI
Post-processing effects (likely only SSAO and glow)
Reading from SCREEN_TEXTURE and DEPTH_TEXTURE in spatial shaders
Vertex shading mode
Various optimizations
Individually, each of these features won’t take long to implement. However, if we tried to get them all finished before 4.0, we would have to delay the release of 4.0. Accordingly, these likely won’t make it in time for 4.0, but will be included in future releases.
For now, the focus remains on bug fixing and ensuring that we can release 4.0 soon.
If you want to follow the progress of the OpenGL 3 renderer, you can view the GLES3 GitHub Project.
Using the OpenGL renderer
From 4.0.beta 9 onward, the OpenGL renderer can be enabled either by selecting the Compatibility renderer when creating a new project or by changing the rendering-method project setting to gl_compatibility. Prior to 4.0.beta 9, the only way to enable it was through the project settings or the --rendering-driver opengl3 command line argument.
Additionally, the project manager now defaults to using the OpenGL renderer to ensure that users’ first experience with the engine isn’t a warning message saying “sorry, your computer doesn’t support Vulkan”.
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.
-
+
\ No newline at end of file
diff --git a/article/student-applications-gsoc-2020-open-today/index.html b/article/student-applications-gsoc-2020-open-today/index.html
index f8ac69d6fb..0ca9e684f4 100644
--- a/article/student-applications-gsoc-2020-open-today/index.html
+++ b/article/student-applications-gsoc-2020-open-today/index.html
@@ -5,7 +5,7 @@
George Marques16 March 2020
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.
Godot Engine is for the third time participating in the GSoC (Google Summer of Code) program. For the unaware, it is a worldwide internship program realized by Google every year, in which university students spend the summer contributing a project to an open source software.
If you are an eligible student, we’re glad to have you submitting your application to the Godot Engine organization. We know we can be daunting to deal with this so here are some tips to create a proposal.
Writing a great proposal for GSoC
Before diving into your application document, take a look a these steps:
Take a look in our ideas list. This is where most of our wanted projects are listed. If you are feeling adventurous, take a look at our community proposals to find a new idea.
Join our development IRC channel (#godotengine-devel on Freenode). This is where the Godot core developers hang out, so it’s a great place to ask questions about the engine internals.
Note that IRC is a slow platform. Usually no answer means “no one who’s online knows the answer”. You need to hang around to see an answer and sometimes ask again at a different time to catch the right person to answer.
Discuss your idea with the core developers. You need to make sure your project is wanted, otherwise you might waste an application.
Once that’s done, start a new document to write your proposal. Many times using Google Docs is the easiest way to share it.
We value some topics covered in the proposal. It makes our selection process easier and increases your chance of being aceppted. Here’s what we want to see:
Introduce yourself. Show your past experiences. Linking to your GitHub account is important too.
Note that we don’t mind that much your academic background. We’re more interested in practical past projects.
In particular, previous contributions to open source software are great to mention.
Tell us your experience with the Godot Engine. Are you familiar with it? If you have made some games, we definitely want to see it, so links are appreciated.
If you have contributed to Godot itself, we definitely want to know. Do mention pull requests that you’ve sent.
Present the problem you’re trying to solve. Even if you get something from the ideas list, we want to see your take on what’s missing in Godot that you want to solve.
Show a plan of action to solve this problem. How would your approach be, in broad strokes, to develop the solution.
If you have done research on the topic, now is the time to show it. Write a more detailed implementation proposal showing what you’ll change and add to Godot during the summer.
Code is not important in your proposal. We expect that you’ll write the code during the program. Here we want a textual description.
Write a timeline. We definitely value it because we can see how you plan to attack the issue in small chunks. It also helps the mentor plan the summer as well.
The timeline in general is a weekly-based progress. Write how much you want to have achieved by the end of each week.
We know that predicting time in the software world is super hard. Just do your best guess, it’s okay if this timeline is adjusted during the program.
Tell how much time you will work per week. If you have some planned away time, be sure to mention it in the proposal.
Remember that GSoC is a full-time internship. We can be a bit lenient and let you have some time away, but in general you are expected to work everyday during the program (except the usual non-working days, such as weekends).
Be part of the community
Remember that GSoC is not only about coding, but also being a part of the community. Be sure to interact with other Godot users and contributors. While the core devs are usually on IRC, you can also enter other community channels.
The community is also a great place to have your questions answered. If you have any doubt about something in the engine internals, there’s no need to ask directly to your mentor, you can ask it publicly and likely someone will be able to answer you more promptly.
Showing your progress constantly is also a great way to interact with the community. Users love to see work being done in the engine. This can also improve your motivation to keep pushing it.
Note that the people in an open source community can sometimes be or sound a bit too harsh in their critique. Fortunately those are a minority, most people will appreciate your work kindly. Don’t let critics demotivate you and talk to your mentor or to the Code of Conduct team if you have any problem.
We’re waiting for you
We are looking forward to see the proposals from the students this year. We hope to get some great projects from GSoC 2020. See you around!
-
+
\ No newline at end of file
diff --git a/article/submissions-open-godot-2019-showreel/index.html b/article/submissions-open-godot-2019-showreel/index.html
index 81af68f88d..8949770097 100644
--- a/article/submissions-open-godot-2019-showreel/index.html
+++ b/article/submissions-open-godot-2019-showreel/index.html
@@ -5,7 +5,7 @@
Juan Linietsky22 February 2019
Are you proud of your Godot-made game or tool (published or work in progress) and would you like us to showcase it in Godot’s 2019 showreel? Please send us a short video (10-15 secs) for us to include it!
Requirements:
If your game can scale resolutions, please submit a 1920x1080 video (or 1280x720 if not possible)
If your game is pixel perfect, then send the video at native resolution
Attach the video in a mail to contact at godotengine · org. Don’t forget to include the title of your game, and the name to credit for it.
-
+
\ No newline at end of file
diff --git a/article/submissions-open-godot-2020-showreel/index.html b/article/submissions-open-godot-2020-showreel/index.html
index 40352b6a6a..88a470e1d8 100644
--- a/article/submissions-open-godot-2020-showreel/index.html
+++ b/article/submissions-open-godot-2020-showreel/index.html
@@ -6,7 +6,7 @@
-
+
\ No newline at end of file
diff --git a/article/submissions-open-godot-2021-showreel/index.html b/article/submissions-open-godot-2021-showreel/index.html
index 41066266ca..f6f6a84aa7 100644
--- a/article/submissions-open-godot-2021-showreel/index.html
+++ b/article/submissions-open-godot-2021-showreel/index.html
@@ -7,7 +7,7 @@
-
+
\ No newline at end of file
diff --git a/article/submissions-open-godot-2022-showreel/index.html b/article/submissions-open-godot-2022-showreel/index.html
index 932e8c8272..972c639b70 100644
--- a/article/submissions-open-godot-2022-showreel/index.html
+++ b/article/submissions-open-godot-2022-showreel/index.html
@@ -8,7 +8,7 @@
-
+
\ No newline at end of file
diff --git a/article/submissions-open-godot-2023-showreel/index.html b/article/submissions-open-godot-2023-showreel/index.html
index 7784c8e3c1..663b3865df 100644
--- a/article/submissions-open-godot-2023-showreel/index.html
+++ b/article/submissions-open-godot-2023-showreel/index.html
@@ -5,7 +5,7 @@
Emi20 November 2023
Showcase your Godot Engine 2023 creations! We invite you to submit videos featuring your published or in-progress games or tools so we can make the Godot 2023 Showreel.
The showreels are an informative and celebratory showcase, to highlight the wide array of projects developed using the Godot Engine. If you want to participate and share your Godot-made game, app or tool submit your entry starting today.
How to submit
You can submit your entry in our Godot Showreel website. You can use your Godot account or any other account (GitHub, Discord, etc.) to log in. Before submitting, please read the submission guidelines.
-
+
\ No newline at end of file
diff --git a/article/submissions-open-godot-2024-showreel/index.html b/article/submissions-open-godot-2024-showreel/index.html
index 78280ab3e6..7a9d1d0d3a 100644
--- a/article/submissions-open-godot-2024-showreel/index.html
+++ b/article/submissions-open-godot-2024-showreel/index.html
@@ -6,7 +6,7 @@
Emi5 September 2024
Showcase your Godot Engine 2024 creations! We invite you to submit videos featuring your published or in-progress games or tools so we can make the Godot 2024 Showreel.
The showreels are an informative and celebratory showcase, to highlight the wide array of projects developed using the Godot Engine. If you want to participate and share your Godot-made game, app or tool submit your entry starting today.
How to submit
You can submit your entry in our Godot Showreel website. You can use your Godot account or any other account (GitHub, Discord, etc.) to log in. Before submitting, please read the submission guidelines.
📅 Submissions close on November 1st 2024 at 10:00 UTC
Changes from previous years
This year, the Godot Foundation will be selecting some games to be featured as well as the ones submitted by the community. This will be done due to the confusion caused by big titles not being present in past showreels because the developers forgot to submit or were not aware of our efforts. It shouldn’t change anything for the submission process, but we wanted to make sure we are transparent about the changes.
Need inspiration?
Check out our showreel playlist for some creative sparks and see what makes a great submission!
-
+
\ No newline at end of file
diff --git a/article/support-godot-patreon-lets-make-best-game-engine-ever-together/index.html b/article/support-godot-patreon-lets-make-best-game-engine-ever-together/index.html
index f5c2d83f7d..054c9a649a 100644
--- a/article/support-godot-patreon-lets-make-best-game-engine-ever-together/index.html
+++ b/article/support-godot-patreon-lets-make-best-game-engine-ever-together/index.html
@@ -5,7 +5,7 @@
Juan Linietsky9 August 2017
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.
Godot is now on Patreon!
We are launching a Patreon site to help fund Godot development. Help us develop Godot better and faster by becoming our Patron!
-
+
\ No newline at end of file
diff --git a/article/support-us-kickstarter/index.html b/article/support-us-kickstarter/index.html
index bd6ad00606..f294fa9c2e 100644
--- a/article/support-us-kickstarter/index.html
+++ b/article/support-us-kickstarter/index.html
@@ -5,7 +5,7 @@
Ariel Manzur20 October 2014
This article is from October 2014, 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 you know, Okam Studio, the company that develops Godot Engine, also makes games. One of our oldest projects is The Interactive Adventures of Dog Mendonça & Pizza Boy, a 2D point & click graphic adventure that we’ve been developing in-house as a side-project, and we’ve launched a Kickstarter to raise the funds to finish it.
You can find it here: http://kck.st/1CVtDF3
In addition to getting a cool game, you’d be helping us continue developing the engine, and if we reach the first stretch goal, we plan on releasing the templates plus documentation on how to make your own point & click graphic adventure (sidenote: Tim Schafer visited our studio last year, when we showed him the script tool we used to write the dialogues/cutscenes he said “It looks just like SCUMM!”, we were speechless :P).
-
+
\ No newline at end of file
diff --git a/article/tests-needed-godot-2-1-4-beta/index.html b/article/tests-needed-godot-2-1-4-beta/index.html
index c6ad538331..7e5814877d 100644
--- a/article/tests-needed-godot-2-1-4-beta/index.html
+++ b/article/tests-needed-godot-2-1-4-beta/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde25 June 2017
Edit 2017-08-25: Here’s finally the release candidate build. WinRT templates are still missing, but they’re not blocking for the release given that they are experimental.
Edit 2017-08-17: And another beta build, probably the last one before the release candidate. Note that WinRT templates are missing in this build, will be fixed for the RC.
Edit 2017-07-31: Time for another beta build, with one month’s worth of further improvements and especially fixes for various regressions found in the 2017-06-25 build:
Already more than 2 months since the last maintenance release in the 2.1 branch, and many bug fixes as well as new developments have made it to that branch.
Some of those new developments being slightly more experimental than we use to merge in the stable branch, the upcoming 2.1.4 release will need some heavy testing from the community to make sure it does not bring regressions.
So now’s your time to shine:
Download today’s beta build and test it extensively on your projects, both the editor and the exported games (make sure to install the corresponding templates).
What are regressions? They are bugs that did not occur in the previous stable release (2.1.3) but which can now be experienced in the beta build. You can also report bugs in the new features of 2.1.4, which, even if not strictly speaking regressions, should be worth looking into before the release.
Note: In this build the 32-bit Linux binaries are missing (both for the editor and the export templates) due to a buildsystem issue; this will be fixed before the stable release.
-
+
\ No newline at end of file
diff --git a/article/tiles-editor-progress-3/index.html b/article/tiles-editor-progress-3/index.html
index 01af785ca8..326acda82b 100644
--- a/article/tiles-editor-progress-3/index.html
+++ b/article/tiles-editor-progress-3/index.html
@@ -8,7 +8,7 @@
We will try to merge the pull request after that, so that other contributors and early adopters can have a look into it and test it in real world conditions.
-
+
\ No newline at end of file
diff --git a/article/tiles-editor-progress-4/index.html b/article/tiles-editor-progress-4/index.html
index e94543304a..7c3d111f74 100644
--- a/article/tiles-editor-progress-4/index.html
+++ b/article/tiles-editor-progress-4/index.html
@@ -5,7 +5,7 @@
Gilles Roudiere17 June 2021
This article is from June 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.
This is the part 4 of the progress reports about the TileMap and TileSet editors rework. You can find the previous report here.
We are close to the end of this huge work. Hopefully in the coming few weeks, the Tiles editors should be ready to be included in the first 4.0 alpha. Some improvements still have to be done, but we are getting close to feature completeness. Until then, here is the summary of the work done during the last two months.
See other articles in this Godot 4.0 tiles editor series:
Terrain painting has been implemented. When you are in the TileMap painting mode, you can access the Terrain tab which allows you to paint terrains. Similar to what autotile featured, painting a tile in the terrain mode will also update the surrounding tiles to make the terrains match:
Note that the terrain painting tool makes use of the probability property. It makes it so you can choose if a tile has more chances to be used instead of another when both use the same terrain pattern.
Scene tiles support
One of the very requested features was the possibility to paint scenes on TileMaps. This is now possible thanks to a new TileSetScenesCollectionSource allowing you to configure scene-based tiles. Those scenes are instanciated as internal child nodes of the TileMap node’s. They are not visible in the editor’s scene tree but can be accessed at runtime with $tile_map_node.get_child(...). In case your scene is not visible, you can configure the editor to display a placeholder.
Improved Tiles properties setup
Until recently, editing tile properties needed to be done by selecting each tile and setting their properties one by one. While editing one tile’s properties is useful, being able to set properties on several tiles at once makes setting up a TileSet a lot faster. To do so, I first implemented the possibility to select multiple tiles and edit their properties all at once (please don’t mind the bug switching to the TileMap mode, I’ll fix it):
While this helps, selecting tiles might still not be optimal enough when you have thousands of tiles to set up. That’s why I also implemented a “painting mode”. In this mode, you simply select a property to edit, a value for this property, then you can paint this value directly onto your atlas:
As you can see, the property values can be previewed directly onto the atlas. It also works when editing a property in the tile selection mode.
Out of the property painting tools, the terrain one is a little bit special as it allows you to paint terrain bits individually, instead of all terrains at once.
Aside from that, a few other improvements were implemented. For example the TileMap editor’s grid color is now configurable and the UI to create tiles on atlases was simplified.
What’s next
Once I am done with the tile property painting tools, I plan to work on two things. First, while I wanted to implement full support for single tiles, this is likely too much work for 4.0. So instead, we decided that each 3.x single tile will be imported as a single atlas, then you will be able to merge several atlases together into a bigger atlas.
Then, even if I was not sure about its usefulness, I decided to implement TileMap layers. While I think they do not bring a lot of value at runtime or make the API simpler, the fact is that implementing TileMap layers allows simplifying a lot the workflow when editing several layers. It will, for example, allow copy-pasting from one layer to another, or dim unselected layers in the editor. So we decided it was worth the work.
-
+
\ No newline at end of file
diff --git a/article/tiles-editor-progress-report-2/index.html b/article/tiles-editor-progress-report-2/index.html
index 5ecbe4cd30..c44e75db5b 100644
--- a/article/tiles-editor-progress-report-2/index.html
+++ b/article/tiles-editor-progress-report-2/index.html
@@ -5,7 +5,7 @@
Gilles Roudiere5 February 2021
This article is from February 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.
Two months have passed since my last progress report on the tiles editor rework. A lot of things have been implemented since then. Here are the news.
See other articles in this Godot 4.0 tiles editor series:
I am really close to be done regarding the implementation of the TileMap editor. I have reimplemented most of the tools needed to modify TileMaps, along with new features.
I will start with the selection tool. This tool allows selecting tiles, moving them, deleting them, or copy-pasting them around:
The paint, line and rect tools are making a comeback in 4.0, with a clean support for half-offset shapes:
I also implemented a bucket fill tool, which can either replace contiguous tiles or all tiles with the same IDs:
All those paint tools support erasing tiles instead of painting them, but they also allow painting with patterns. The pattern used can be set either by selecting multiple tiles in the TileSet, by selecting tiles in the TileMap using the selection tool, or by using the TileMap picker. Of course the picker allows picking a single tile too, so that you do not have to search for the tiles to re-use in the TileSet panel:
I also added an option making so that, instead of painting the pattern, the painting tools randomly pick a tile out of the ones in the pattern. With the scattering settings, which adds a probability for no tiles to be painted, it allows painting nice organic patterns:
Tiles with invalid IDs are drawn using a dedicated texture, modulated with a random color generated from the ID. This makes invalid tiles with the same ID being painted with the same color. Those tiles can then be easily replaced with the bucket tool by valid tiles.
Atlases setup
The TileSet editor, only supporting atlases right now, has received a few updates.
First of all, atlases now allow creating “alternative tiles”. Those alternative tiles share the same texture region as their base tile but can have different properties. This will mainly allow for rotated/flipped versions of the base tile, but any other property could be different too:
As you can see, the atlas editor now features a nice zoom widget, it displays inactive tiles as dimmed, and has a checkboard as a background.
The TileSet editor features several simple ways to create, delete or move tiles around, with a selection mode and two drawing modes. It also features a right-click context menu:
Finally, the TileSet editor features an automatic tiles creation system, which detect which tiles are occupied in a texture to create corresponding tiles automatically. Another tool also allows to automatically cleanup tiles outside of the atlas texture. Those are quite slow for now, but I hope I will be able to optimize that. (edit: this is now fixed)
Early builds
That’s it for now. However, if you want to try all of this by yourself, early builds are available, just right here. However, please read the following warning first.
IMPORTANT WARNING: Opening an existing project with these builds will make this project incompatible with any other Godot version. Try these build with a new project or create a backup of existing ones.
The master branch is really unstable right now, so some issues might not come from this tiles editors rework.
Also, for now, those builds can only import atlases from previous version, and only the graphical part is supported. You may give feedback on the already implemented features on this PR. As a reminder, you can see what is planned for the future in this proposal.
-
+
\ No newline at end of file
diff --git a/article/tiles-editor-progress-report-5/index.html b/article/tiles-editor-progress-report-5/index.html
index c076777dbe..c6f4512582 100644
--- a/article/tiles-editor-progress-report-5/index.html
+++ b/article/tiles-editor-progress-report-5/index.html
@@ -5,7 +5,7 @@
Gilles Roudiere23 September 2021
This article is from September 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.
Here comes a new progress report about the Tiles editor rework. This is most likely the last progress report before the 4.0 alpha. The previous blog post can be found here.
See other articles in this Godot 4.0 tiles editor series:
Some improvements were made to the tile atlas editor.
I first reorganized the tiles creation menus, which are now split into 3 modes. The first mode allows editing the atlas properties and creating/removing base tiles, the second one allows selecting and editing tiles properties, and the last one is to paint properties over the tiles.
In this third mode, I implemented a dedicated editor for tile shapes (collision shapes, occluders, naviagation shapes). Set by default to the tile’s base shapes, it then can be painted over tiles. This allows setting up tile collisions in a very fast way:
Since my previous implementation of panning was not working great in the atlas editor, I reworked it a little bit. The view is not constrained anymore and panning can be done with the right click.
Backward compatibility improvements
To improve backward compatibility, tiles from 3.x in the SINGLE_TILE mode will be imported as an atlas with a single tile each. As it might create a lot of atlases, an atlas merging tool is now available in the editor. Merging atlases will automatically gather tiles from all atlases and create a new one with its associated new texture. Here is an example workflow where I port the 3.x isometric tiles demo to 4.0:
As the atlas merging tool is only modifying the TileSet resource, using it might have made all TileMaps using the modified TileSet point to missing atlases. Hopefully, I implemented a way to solve this problem.
TileSet now features a system of tile proxies. Thoses proxies are basically a mapping table, that allows notifying the TileMap using a given TileSet that a given set of tile identifiers should be replaced by another one. Tile proxies are automatically set up when merging different atlases, but they can also be set manually thanks to a dedicated interface. This may become useful when you changed an atlas ID or want to replace all tiles from an atlas by the ones from another atlas. Note that, when editing a TileMap, you can replace all cells by their corresponding mapped value.
TileMap layers
As a widely requested feature, TileMap layers were implemented. TileMap layers allow stacking tiles on top of each other in the same layout. Layers have several features:
Layers can be enabled/disabled.
A layer might be set up to Y-sort its tiles. In such case, you may also provide a Y-sort offset that will be added to each tile’s Y-sort offset. This allows using layers as if they were on different height for top-down games.
Layers can have different Z-index values.
Implementing layers allowed to highlight the edited layer and dimming the unselected layers of the TileMap. This makes it more obvious which layer is currently edited:
Property arrays in the inspector
With both the TileMap layers and TileSet layers implemented, the limitations of the inspector regarding the editing of properties arrays became quite obvious. It was not possible to easily add, remove or reorder layers. This is now fixed thanks to a new improvement to the inspector:
This will allow exposing or moving out from dedicated editors a lot of properties. For example, items from an ItemList node could be moved back to the inspector.
Other
Aside from a lot of bug fixes and small UX improvements, all tiles-related classes are now documented.
What’s next
This work is not merged yet, but 4.0 should feature animated tiles, alongside a set of improvements to collisions. In the future, there will also be a possibility to make some tiles work as conveyor belts (moving the characters colliding with them) or to use TileMaps as moving platforms.
I might also have the time to implement a pattern palette, that would allow you to store chunks of tiles as reusable patterns. But that being said, most of my time will soon be used to fix all bugs the alpha release will allow us to spot.
-
+
\ No newline at end of file
diff --git a/article/tiles-editor-rework/index.html b/article/tiles-editor-rework/index.html
index 05cb9578ec..4876e3e2e9 100644
--- a/article/tiles-editor-rework/index.html
+++ b/article/tiles-editor-rework/index.html
@@ -7,7 +7,7 @@
Future
My next goals are to make the tile atlas management and most of the TileMap edition feature complete. I want to make the workflow for setting up tiles (only considering their rendering) as simple and intuitive as possible. This is the base work needed before implementing again all other features, like collisions, occlusion, etc…
-
+
\ No newline at end of file
diff --git a/article/turn-android-app-quest-vr-app-3-steps/index.html b/article/turn-android-app-quest-vr-app-3-steps/index.html
index da8755050e..a6e24dcc95 100644
--- a/article/turn-android-app-quest-vr-app-3-steps/index.html
+++ b/article/turn-android-app-quest-vr-app-3-steps/index.html
@@ -36,7 +36,7 @@
Build and run!
That’s all! Your app should now build and run on the Quest as a Godot VR app!
The framework has built-in support for hand tracking, enabling interaction with the VR app without the need for controllers.
Passthrough environment
The framework provides the ability to toggle passthrough on the Quest, enabling the user access to your app while interacting with their real-time surroundings.
See the documentation for instructions on how to enable it.
Oculus Keyboard support
The framework leverages the Oculus Keyboard for input.
And More!
We have more features in the pipeline for upcoming releases! Please take a look at the Godot XRApp framework roadmap to learn more.
-
+
\ No newline at end of file
diff --git a/article/upcoming-godot-jam-15-18-june-theme-proposals/index.html b/article/upcoming-godot-jam-15-18-june-theme-proposals/index.html
index 7ba6e0dd68..9e5d3ee7cf 100644
--- a/article/upcoming-godot-jam-15-18-june-theme-proposals/index.html
+++ b/article/upcoming-godot-jam-15-18-june-theme-proposals/index.html
@@ -6,7 +6,7 @@
Then 3.0 was released, a lot of backlog had to be worked on post-release, and the jam was delayed again…
But better late than never, now that Godot 3.0 is well established (with the maintenance version 3.0.3 likely coming in time for the jam) it’s time for a new Godot-focused game jam to see what the community is up to!
Shorter jams, more often
If you’re not familiar with our previousGodotjams, they used to run for a whole month (or even more for the last one).
This was nice to give everyone a chance to participate, be it with an entry worked on during the whole month or only during one free week-end. But at the same time many jammers prefer the shorter variant, focusing on a game for one week-end and moving on to something else, so we’ll give this formula a try this time. We’ll gather your feedback and see if you liked it this way or if we should adapt the format again for the next one.
As the community has grown a lot since 2016, we’d also like to propose jams more regularly - how often is yet to be determined based on your feedback, but every 3 months sounds like a good pace a priori.
Rules
The rules will be quite simple and similar to that of our previous jams, especially the requirement for all submissions to be free and open source. More details on this in the coming days as we flesh out the itch.io jam page and write the theme voting announcement.
We might even have some small prizes for the winners, stay tuned! :)
Livestreams with Juan Linietsky and more
It’s not related to the upcoming jam, but while you wait for the theme to be revealed, don’t miss the livestreams organized by Ben Tristem of GameDev.TV with our very own Juan Linietsky (today at 20:00 UTC on YouTube) and many others (see the full line up, dates and stream links).
-
+
\ No newline at end of file
diff --git a/article/update-godot-ar-and-vr/index.html b/article/update-godot-ar-and-vr/index.html
index a443706325..acff4213ba 100644
--- a/article/update-godot-ar-and-vr/index.html
+++ b/article/update-godot-ar-and-vr/index.html
@@ -8,7 +8,7 @@
There is a PR in the official godot_openvr repository that contains a fix, but for the official release of the plugin, HDR still needs to be turned off or the GLES2 renderer needs to be used.
You can download the official plugin from the asset library here: Godot OpenVR plugin
OpenXR
We’ve already talked about OpenXR, this is a specification that has been worked on for a couple of years now, but this year’s GDC finally reached a milestone where example source code has become available. The specification was also released in version 0.9.
The interface that was used during the Monado demonstration is based on the OpenHMD drivers. You can follow its development here: https://gitlab.freedesktop.org/monado/godot_openxr
GLES2
The addition of the OpenGL ES 2.0 render pipeline is one that is very interesting to VR. Stereoscopic rendering at high resolutions and frame rates puts a large tax on your GPU. For the new HP Reverb headset the output may be 2160x2160 pixels per eye, this means that we’re rendering at a resolution of 4320x4320 twice per frame at 90fps. That requires some serious grunt if you’ve turned up all the new features of the GLES3 renderer. The move to Vulkan will mitigate some of that but still, being able to fall back on a render pipeline that is simpler and therefore faster means that you can use a high resolution headset even if you’re running on the mid-end hardware that many gamers will actually own.
-
+
\ No newline at end of file
diff --git a/article/update-on-google-forge-2024/index.html b/article/update-on-google-forge-2024/index.html
index 187fe7fbb7..bc2cfb3e7d 100644
--- a/article/update-on-google-forge-2024/index.html
+++ b/article/update-on-google-forge-2024/index.html
@@ -5,7 +5,7 @@
Clay John19 April 2024
Our collaboration with Google and The Forge has achieved its original goal of improving performance in the Vulkan backend and enhancing our Vulkan API usage. The work started in mid-November and I have to say, the last few months went by very fast. Overall, I am happy to report that we finished everything that had been planned for this collaboration.
Most of the work is targeted at improving the Vulkan backend and will benefit all platforms that use Vulkan. The list of improvements is too long to list here, but some highlights are:
Usage of Unified Memory Architecture (UMA) buffers when available
During the project, we tested two different 3D scenes using a Google Pixel 7 and a Samsung S23. Depending on the project and device, we see a consistent 10% - 20% reduction in GPU frame times. Since mobile devices are currently heavily GPU bottlenecked in 3D scenes this translates directly into a 10%-20% frame time improvement!
This collaboration covered more than just performance, it also covered integrating tools like Android Thermal API which can be used to monitor and respond to changes in the thermal state of the device. Importantly, this allows you to automatically scale down quality to maintain a high framerate and cool temperature. Stay tuned for more documentation.
The work was developed in a private fork of Godot that was kept up to date with our main branch as the work progressed. The final work product can be accessed in this PR. We won’t merge this PR as-is, instead we will break it into smaller pieces that can more easily be tested and used to identify potential regressions. Expect this process to take a few months and be split between the 4.3 and 4.4 releases.
If you have a mobile game in development, we would like to hear your feedback and see what kind of impact this makes on your game.
We very much appreciate the support of Google and The Forge for this effort and we look forward to seeing our developers take advantage of Vulkan with Godot!
-
+
\ No newline at end of file
diff --git a/article/update-on-recent-vr-developments/index.html b/article/update-on-recent-vr-developments/index.html
index a6f6fef130..ee7d6c5d9e 100644
--- a/article/update-on-recent-vr-developments/index.html
+++ b/article/update-on-recent-vr-developments/index.html
@@ -5,7 +5,7 @@
Bastiaan Olij21 February 2018
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.
It has been a very busy month on the VR front in Godot.
OpenVR
The focus for development has remained on OpenVR support for the most part and it is slowly finding use within the community.
With the release of Godot 3.0 the OpenVR module can now be downloaded directly from the asset library.
It comes with support for OpenVR on 64-bit Windows and on Linux. We’ll add more platforms as testing is rounded off. On Linux it is important that Godot is started from the Steam runtime or it will not find Steam VR.
There are also several premade scenes in the module to help you get set up faster.
For more information on the asset or to let us know of any problems you encounter please visit our issue repository on GitHub.
Oculus
There is now also a native driver for the Oculus SDK. As the Oculus SDK is only available on Windows this driver is only available for that platform.
It comes with the same premade scenes as the OpenVR module. There are only small differences in the controller scenes but most of the others are interchangeable. If you use your own controller meshes (e.g. use hands) it is fully possible to create a Godot game where you can interchange the two drivers depending on which platform you want to deploy to.
For more information on the asset or to let us know of any problems you encounter please visit our issue repository on GitHub.
Future
Work will continue on improving these two drivers, especially the Oculus one which is still very new. A temporary fix is being tested to solve the HDR issue on the OpenVR driver so work continues on that as well.
Work on Gear VR is progressing slowly, we need more people who are more familiar with the Android system but we do hope to have something here in the not too distant future. Come find us on IRC on #godotengine-vr (#vr:godotengine.org on Matrix) if you’re able and willing to offer help.
Finally the last bit of news is that we’re going to support Leap Motion, initially on desktop but likely also on mobile some time in the future. More on this once we actually get started.
-
+
\ No newline at end of file
diff --git a/article/updates-on-the-release-cycle-and-godot-2-0-1/index.html b/article/updates-on-the-release-cycle-and-godot-2-0-1/index.html
index e5f4a4da4b..dbd0a15f4e 100644
--- a/article/updates-on-the-release-cycle-and-godot-2-0-1/index.html
+++ b/article/updates-on-the-release-cycle-and-godot-2-0-1/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde7 March 2016
The stable release of Godot 2.0 was nine months in the making and brought a great deal of new features and bug fixes alike. Some of our users had been testing the alpha and beta versions, but others had decided to stay on the stable 1.1 version and thus had to wait quite a long time for bug fixes.
We therefore decided two important things for our release cycle:
Shorter release cycle
Stable releases will happen more often. Release early, release often is a proven philosophy that we all affectionate and we think that it will be beneficial to Godot.
The long wait for Godot 2.0 was actually mostly due to breaking the compatibility with 1.1 (especially for the new TSCN/TRES format). We wanted to make it a big release so that the inconvenience of losing compatibility with 1.1 would be compensated by great new features.
On the other hand, we do not give an ETA for the future releases. In a community-driven project such as ours, it very much depends on the availability of the contributors, and we will then release when it’s ready. There has however been some good progress on the main features that we would like to release in 2.1 (not all those of the “2.1” roadmap though, we will split it in several sub-releases in the 2.x branch), mainly the new plugins API and addons sharing platform.
Maintenance releases for the current stable version
In the meantime, we plan to release bugfix versions of our latest stable release, to bring our users interesting bug fixes without having to “risk” using the master branch in production. It will also be particularly relevant for the version we distribute on Steam, where users would likely want to benefit from upstream bug fixes without being forced into beta-testing.
Godot 2.0.1
And to get started with these maintenance releases, we announce the availability of Godot 2.0.1! It contains some non-critical bug fixes and a few usability improvements, that should improve the overall experience of Godot 2.0 users.
The main fixes in this release are:
Enhancements:
Usability improvements in the help section (full object inheritance, searchable class list)
Better and configurable placement of the script editor call hint
Support configuration presets for self-contained builds (especially for Steam)
Added more gamepads bindings
Improved classes documentation
Reduced size of demos package
Bug fixes:
Fixed addition/delete of global variables in the project settings
Fixed blending functions in AnimationTreePlayer
Fixed transform localization event in mouse motion
Fixed closing a scene tab when it was not the current tab
For this release, we also used a new buildsystem to create and deploy the binaries, so please contact us if you experience any regression relatively to 2.0 stable.
-
+
\ No newline at end of file
diff --git a/article/versioning-change-godot-3x/index.html b/article/versioning-change-godot-3x/index.html
index 0a26c2e2ef..0118323dc1 100644
--- a/article/versioning-change-godot-3x/index.html
+++ b/article/versioning-change-godot-3x/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde17 March 2021
This article is from March 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.
As you may know, the current development focus for Godot contributors (in our master Git branch) is on Godot 4.0, our upcoming, major release which reworks a lot of the engine’s internals, modernizes the rendering backend, and more!
There’s still some way to go before Godot 4.0 is ready to release, and in the meantime we’re doing our best to support the Godot 3.x users who are developing and releasing games with the stable version.
When we released Godot 3.2 in January 2020 and shifted our focus to Godot 4.0, we expected that the 3.2 stable branch would be the last milestone before 4.0. The 3.2 branch would receive maintenance updates (bugfixes, usability enhancements) but major features would have to wait for the next major milestone.
Yet there’s a number of new features which could be safely backported, and we accepted to merge a significant number of those in the 3.2 branch. We’ve actually released a quite feature-packed Godot 3.2.2 update, blurring the line somewhat regarding what to expect of such 3.2.x releases. And now after 6 months of development, the upcoming Godot 3.2.4 is looking to be a huge feature release - still preserving backwards compatibility with 3.2.3, but the amount of new functionality is huge and not well-served by a “patch” version bump.
As such we decided to change our release policy for Godot 3.x, and to go back closer to a semantic versioning as we used to follow prior to 3.2.
Once it’s released, we’ll have two separate actively maintained branches for Godot 3.x users:
The 3.3 branch will release actual maintenance updates to fix bugs, enhance usability, update documentation and translations, etc., but no major new feature. This should enable us to release 3.3.x updates in a timely manner as soon as we have a significant amount of fixes that we want to push to production.
The 3.x branch will be developed further with new features towards Godot 3.4, and so on and so forth, for as long as we think that new minor releases are pertinent for Godot 3 users (i.e. at least until Godot 4.0 is released and most users have ported their projects). We’ll aim for shorter release cycles for new 3.x minor releases compared to what has been the experience so far with 3.0, 3.1 and 3.2. So do not despair if your favorite new feature or important bugfix didn’t make it into 3.3, it shouldn’t be long before Godot 3.4 is released with another batch of features.
All current users of Godot 3.2.x are strongly encouraged to upgrade to Godot 3.3 once it’s released, as it’s designed to be a fully compatible upgrade (since it was initially intended to be 3.2.4).
Also note that this doesn’t mean that we’re reopening the feature development for Godot 3.3 - we were already at our 5th Release Candidate for 3.2.4, and the next build will be 3.3 RC 6. So aside from a few needed documentation updates, there shouldn’t be significant delay to this upcoming release, nor changes compared to the latest RC.
-
+
\ No newline at end of file
diff --git a/article/visual-shader-editor-back/index.html b/article/visual-shader-editor-back/index.html
index 7eb84c5176..bcccba157a 100644
--- a/article/visual-shader-editor-back/index.html
+++ b/article/visual-shader-editor-back/index.html
@@ -5,7 +5,7 @@
Juan Linietsky14 July 2018
This article is from July 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.
After some weeks of work, the new visual shader editor is ready for testing!
What is a visual shader editor?
This editor allows creating shaders using nodes and connections, instead of typing code. It provides a simple and fool-proof way for those not confident in writing shader code to create complex shaders.
Why was it gone in the first place?
This editor compiles to shader code. As the shader code format changed significantly between Godot 2.1 and 3.0, this editor no longer worked. The way it was programmed was also too hardcoded and it missed several key functions.
What’s different in the new one?
The new editor is not too different from the original one, but it’s considerably more organized. The most significant changes are:
New full PBR output nodes
No more Vec3 <-> Scalar adapter nodes, conversion is automatic
Easier input nodes for more organized graph.
Extending it via scripting (creating custom nodes) is possible.
Port previews (see blow)
How do I create a visual shader material?
Here is a quick tutorial:
1. Create a ShaderMaterial
2. Create a Shader
3. Edit the Shader
4. Add new nodes to the canvas!
Try to create something from the Add Node Menu:
.. and connect it to any of the outputs:
Future
Eventually as we get feedback, the shader editor will keep improving.
Remember that all this is possible thanks to the infinite generosity of our patrons. If you haven’t already, please don’t hesitate to become one!
-
+
\ No newline at end of file
diff --git a/article/vote-godot-jams-theme/index.html b/article/vote-godot-jams-theme/index.html
index a110f1dd9e..a307e0a9b7 100644
--- a/article/vote-godot-jams-theme/index.html
+++ b/article/vote-godot-jams-theme/index.html
@@ -5,7 +5,7 @@
Rémi Verschelde13 June 2018
This article is from June 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.
As announced a few days ago, we will have a Godot Community Game Jam the coming week-end, from Friday 15 June at 18:00 UTC to Monday 18 June at 23:59 UTC. Check the itch.io page for the latest details and to register!
We had dozens of great proposals for the jam’s theme, and made a selection from those for you to vote on. The aim is now to select one theme, and everyone can vote for only one entry. Head over to the Framaforms poll and pick your favourite theme :)
We’re quite hyped to see what the community will cook up during this jam! And stay tuned, we should even have some neat prizes this time :)
-
+
\ No newline at end of file
diff --git a/article/vulkan-progress-report-1/index.html b/article/vulkan-progress-report-1/index.html
index 6272a7d8fb..04fc7d6ca8 100644
--- a/article/vulkan-progress-report-1/index.html
+++ b/article/vulkan-progress-report-1/index.html
@@ -5,7 +5,7 @@
Juan Linietsky1 July 2019
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.
While the rest of the Godot contributors are focused on finalizing 3.2 for release, I’m almost exclusively dedicating myself to porting the engine to Vulkan, as part of the 4.0 release effort. This is so far an exciting adventure and I’m learning a lot about it.
I plan on creating more in-depth technical devblogs on how this work is being done, but will do so at a later time when more of the work is done (and I feel more confident that the approach used in most areas is the right one).
See other articles in this Godot 4.0 Vulkan series:
Getting Vulkan initialized took a considerable effort. What used to be a few lines of OpenGL/GLX code is a large amount of Vulkan extension code to handle initialization and creation of rendering surfaces. This got even more complex because of the fact that one of the goals for Godot 4.0 is to support multiple windows and the way Vulkan is initialized to do this is not exactly straightforward.
It seems to be running nicely now, though (multiple window support has not been added at engine level yet, but the initialization is prepared for it).
RenderingDevice
One of the main features that will be present in Godot 4.0 is the new RenderingDevice abstraction. Up to now, it was impossible to do any internal modifications to how Godot does rendering. This means that if you wanted to run custom low-level rendering code to a texture or buffer, custom post-processing, custom drawing code (other than what Godot shaders allow), custom compute, etc., this was not possible without modifying Godot’s rendering backend.
The new RenderingDevice API allows to do all of this, or even completely override Godot’s rendering code in order to create your own.
The biggest challenge in the creation of this new API is that, nowadays, low-level rendering APIs such as Vulkan, DirectX 12 or Metal are quite complex and simple mistakes can have fatal consequences. Exposing them directly to the user would result in extremely difficult-to-use rendering APIs that very few would be able to take advantage of.
Instead, the chosen approach was to create a much simpler abstraction that handles all the complex tasks internally (such as swapchain management, frames, staging buffers, buffer updates, vertex formats, render commands, shader reflection, description sets, etc.) and only exposes a simplified API to the user.
Managing to make this API performant, yet hand-holding, was a challenge but the end result should be a very good tradeoff. RenderingDevice is very simple to use and takes care of validating everything you pass to it internally. If something invalid is detected, it will fail and print the appropriate error instead of just crashing. At the same time, it’s very efficient and thread-safe.
Additionally, having an abstract lower-level API will aid in other areas:
It will be easier for users and contributors to learn about rendering, as they won’t need to deal with the complexities of modern APIs, yet they will be able to do everything they need. We will try to make tutorials to learn rendering by using RenderingDevice.
Eventually, it will make porting Godot to other platforms if needed (such as Metal native, DirectX 12 or even PS4 –not officially though, sorry–) much easier, since what needs to be re-implemented is significantly reduced and well constrained.
Architecture changes
In modern rendering APIs, there are architecture changes that force us to break compatibility and do some things differently. The immediate one is that it is no longer possible to set repeat, filter, etc. flags on imported textures. In 2D, this will be set per canvas item (Control or Node2D) using a new set of options. It will be also be possible to specify this in the shader or the material options (or just globally, if you are making a pixel art game).
This allows more efficient rendering and the lifting of the limit on the amount of textures that can be used per material (you can use as many as you want now).
Status
Currently, RenderingDevice is more or less complete (compute support is missing) and the 2D engine is halfway being ported. Work on 3D rendering will begin near the end of the month.
The editor is also more or less working again (don’t believe the version number or renderer name :P):
Future
The goal is to have a more or less complete rewrite of the existing Godot 3.x feature set by October (cross your fingers), hard work and long hours are being put towards this.
As always, if you enjoy Godot and our work, it would be immensely useful for us if you become our patron (if you are not yet). This will help us split the work among more developers and speed up the development of the engine.
-
+
\ No newline at end of file
diff --git a/article/vulkan-progress-report-2/index.html b/article/vulkan-progress-report-2/index.html
index 69a5d6eafa..c885825e0e 100644
--- a/article/vulkan-progress-report-2/index.html
+++ b/article/vulkan-progress-report-2/index.html
@@ -5,7 +5,7 @@
Juan Linietsky3 August 2019
This article is from August 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.
See other articles in this Godot 4.0 Vulkan series:
In our latest episode, I was just barely getting Vulkan to work. A month later, many things happened.
Lighting and shadows
2D Lighting was introduced in Godot 2.0, with support for 2D shadow mapping and basic normalmapping. While it looks pretty nice, users quickly found its limitations.
The main problem with this system is that performance was never very good. The reason is that lighting was done in an additive way, requiring an extra pass (drawing all 2D content again) for every light in the scene. This ensured maximum compatibility with all hardware, but quickly restricted the amount of lights.
For Godot 4.0, the algorithm changed. All 2D lighting is now done in a single pass, ensuring much better performance. The only downside is that there is now a limit of 256 lights visible on-screen (your level can have as many as you want), and 16 lights per 2D node (as in, a single 2D node can be affected by a maximum of 16 lights). Considering today’s standards for 2D games, this is a very high limit anyway, and the performance improvement makes it worth it.
Added to this, many users requested specularity in 2D lights, so the effect of lights moving around stage is more visible and more types of materials can be created. Because of this, it will be possible in Godot 4.0 to use specular and shininess both as parameter and as textures supplied to Sprite, AnimatedSprite, Polygon2D and other nodes.
Finally, the way light shaders now works is more user friendly to creating custom lighting shaders.
2D materials
The 2D material system is back, so writing custom shaders works with the new Vulkan renderer. The shader language is mostly untouched since Godot 3.x, so existing shaders should just work.
Both regular shaders and screen space shaders work, including blur access to SCREEN_TEXTURE.
One interesting effect of the new material system is that there is now no restriction on the amount of textures your shaders can use. On desktop hardware, you can use thousands of them, while on mobile (except on very low end hardware) you can have hundreds of textures in a material.
Another fantastic effect of the new shader system is that, unlike Godot 3.x, shaders are compiled (and cached) on load. Situations where the game stalls because it needs to compile a shader (which are common in previous versions of the engine) will no longer happen in 4.0.
Multi-threading
Thanks to the fact that all new work on Godot 4.0 is done using C++11, many interesting advances were done with regard to multi-threading. Shader compilation is now done fully threaded (versions are compiled in threads), greatly improving performance.
Loading resources in threads is now much more efficient, because both textures and meshes can be created in sub-threads at no cost at all for the main thread. This paves the way to multithreaded resource loading, which will be implemented later. Access to RIDs (internal resource IDs) was made thread safe for some key types thanks to spinlocks. Spinlock usage will also be extended to other engine areas to vastly improve performance when using multiple threads.
For 3D rendering, a persistent thread worker pool was created for the rendering thread. Right now it’s only being used to compile shaders (in case they are not cached), but it paves the way for implementing multi-threaded spatial indexing and rendering optimizations (using secondary command buffers).
3D
With the 2D engine mostly completed, I am now starting work on the 3D side of things. The idea of the 3D engine in Godot 4.0, besides being faster and more capable, is that it will be smarter regarding resource allocation. As an example, if your game does not use 3D, then no memory for 3D rendering will be allocated. From there on, it will only allocate memory for the features and effects you use. In Godot 3.x, this could only be controlled manually and most users did not bother to, resulting in wasted memory.
Future
August will be fully dedicated to the 3D rendering side of things, so stay tuned!
As always, all my work in Godot is only possible thanks to the infinite generosity of our patrons. If you are not yet, please consider helping the project by becoming one.
-
+
\ No newline at end of file
diff --git a/article/vulkan-progress-report-3/index.html b/article/vulkan-progress-report-3/index.html
index 1f49beb347..9b11cd7a66 100644
--- a/article/vulkan-progress-report-3/index.html
+++ b/article/vulkan-progress-report-3/index.html
@@ -5,7 +5,7 @@
Juan Linietsky2 September 2019
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.
Work on porting the rendering engine to Vulkan continues at a steady pace.
See other articles in this Godot 4.0 Vulkan series:
Work on 3D rendering has begun. This month was mostly spent on refactoring and modifying the core rendering architecture.
One of the main goals for Godot 4.0 is to make it possible to replace the core rendering class with as less rewriting as possible. The default 3D renderer will be as good as possible, but if some game requires a completely different one (because of very specific requirements), the idea is that just re-implementing some functions should be enough to achieve this.
Added to this, a lot of hacks were removed from the 3D engine viewports (no more need to flip, set a viewport to keep linear color to embed on 3D, etc), and the strategy of allocating buffers on demand continues (so by default users don’t need to configure the game features to tweak memory usage manually, engine will automatically allocate whatever is needed on the fly).
Status
Environment
Basic PBR rendering using a panorama background that supplies ambient and reflected light now works (together with tonemapping). The “Environment” resource will see some changes, allowing to specify custom sources for both light types (ambient and reflection), giving more flexibility in an area where users wanted to have more control. This will be split in two classes, Environment and CameraSettings, with some settings (like DOF blur) being moved to the camera, where it makes more sense.
A significant change from Godot 3.0 to 4.0 is the internal use of actual cubemaps for reflection probes and environment (3.0 used 2D atlases based on dual parabolloid projection). This is possible because the hardware supported by Vulkan all supports cubemap arrays.
Lights & Shadows
Currently, work is in progress on porting shadow/lights code from Godot 3.0, which will work about the same way (I think the shadow atlasing system in 3.x has proven to be very good, so this is being kept).
The main change for 4.x will likely be significant improvements in handling multiple directional lights (currently, each directional light is handled in a separate render pass in 3.x), as many users requested the ability to use more than one directional light in their games without having to take such a big performance hit.
I am also interested in adding a new light type, ShaftLight, which would be like a mix between a spot light, but shoot parallel light rays, more akin to a directional light. This can be used for both small light shafts in interiors as well as combined with masking to create standalone shadows for characters (useful on 3D platformers, as an example).
Future
For now, the goal remains on having most of the 3D renderer ported by October, then the work of adding new features will begin afterwards. As always, remember that all this work is done thanks to the enormous generosity of our patrons. If you are not yet, please consider becoming one, as we are close to reaching our third hire!
-
+
\ No newline at end of file
diff --git a/article/vulkan-progress-report-4/index.html b/article/vulkan-progress-report-4/index.html
index 693d1001fb..efafc4e171 100644
--- a/article/vulkan-progress-report-4/index.html
+++ b/article/vulkan-progress-report-4/index.html
@@ -5,7 +5,7 @@
Juan Linietsky12 October 2019
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.
Over the course of September 2019, I continued working on Vulkan all day long, and several improvements have been made.
See other articles in this Godot 4.0 Vulkan series:
3D materials are now working again. Post processes are still mostly missing, but the material testers demo is fully functioning.
The SpatialMaterial class has been renamed to StandardMaterial, as this name will be more user friendly and less ambiguous. All the settings and categories in this material have been reorganized:
This should make editing 3D materials hopefully easier than it was before, as all the material options were crammed up in singled categories.
Added to this is a simple ORM material variant, which should make importing textures from GLTF2, or from applications such as Substance Painter, or similar much easier. It takes a single texture with Occlusion, Roughness and Metallic parameters and does not expose a lot more.
Finally, due to popular demand, the depth texture has been changed to height texture. It retains a flag to flip the color for compatibility.
Note that old SpatialMaterials will still work in Godot 4.0 and their data will be automatically remapped to StandardMaterials. Likewise, Meshes created in Godot 3.x will work using the mesh format in 4.x. The .import folder will need to be erased when switching between versions, though.
Visual Frame Profiler
Another very requested feature for 2D and 3D is performance analysis tools. Users often run on CPU or GPU side performance bottlenecks and it is not always obvious what the source of the problem is.
To better find what is going on, a new visual frame profiler was added. This profiler shows all the steps that take place during rendering a frame and their cost in both CPU and GPU. Inspecting the frame history is also possible, so going back in time to find what caused a peak is done the same way as with the script profiler.
Shadows, Reflections, Skeletons, Multimesh, etc.
Most real-time lighting code has already been implemented, so the 3D platformer demo (and even the TPS demo) seems to work
Basis Universal
While not strictly Vulkan based, Basis Universal was added to Godot as an optional import format.
Basis Universal is mostly useful for 3D games and results in 75% smaller textures, at the cost of much slower import time (so, won’t want to use it until deploy) and slightly worse visual quality and loading times.
Stay tuned for next month!
October will be a fun month, with all the focus on the new real time global-illumination features that will be coming for Godot 4.0!
-
+
\ No newline at end of file
diff --git a/article/vulkan-progress-report-5/index.html b/article/vulkan-progress-report-5/index.html
index caa1fc2d8d..c09b43cec7 100644
--- a/article/vulkan-progress-report-5/index.html
+++ b/article/vulkan-progress-report-5/index.html
@@ -5,7 +5,7 @@
Juan Linietsky2 November 2019
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.
Another month, another Vulkan progress report! October was a busy month, as most of it was split between working on the new Global Illumination system and Godotcon/GIC in Poland.
Despite this, strong progress was made and the new GI system seems pretty much complete.
See other articles in this Godot 4.0 Vulkan series:
Godot 3.0 introduced GIProbes. They provide Global Illumination to scenes. They were, however, pretty limited. Only static geometry could provide GI and dynamic objects were ignored. Added to this, changes in light settings had significant frames of delay. Added to a not so great performance and quality, the feature was barely usable as is.
For Godot 4.0, GIProbes will see several significant changes, which will be outlined as follows:
Improvements to Performance
Performance will see some improvements, thanks to work from Matias Goldberg from Ogre 3D, who implemented the same technique and figured out many optimizations. The default quality in 4.0 will also be the low quality mode in Godot 3.0, which was faster and the performance loss was only very small.
Real-Time lighting
Changes to lighting now happen 100% in real-time. Changing light directions, positions, settings, etc. have immediate effect. Light bounces are updated smoothly and with no delay, thanks to a very clever voxel lighting implementation using signed distance fields.
Multiple Bounces
GIProbe also now supports multiple bounce lighting (3 bounces). This considerably improves the image quality, but it also makes voxel reflections more useful (before, they would only reflect direct light, severely limiting them).
Ambient Occlusion
GIProbes by default generate voxel ambient occlusion, but options to tweak it manually now exist. This allows having more control on this feature.
Dynamic Objects
It is now possible to add dynamic objects to the scene. Just toggle the “Dynamic” flag in any object and it will both contribute to the scene and receive lighting from it.
This feature is extremely powerful, as objects can even emit light from their own material or shader. Complex shaders using the emission channel can actually light their environment accordingly, including the whole scene.
Likewise, dynamic objects will also make use of real-time voxel AO, so it is possible to have screen space independent and wide AO, with a much higher degree of realism than traditional SSAO.
The voxelization technique used for real-time objects is very fast (you can have dozens of dynamic objects at little to no cost in a medium or low end dedicated GPU) and also very innovative, as it voxelizes supersampled objects. This allows moving dynamic objects around the scene without creating sudden changes in lighting (which was always a problem with most other implementations of voxel cone tracing, and made dynamic objects barely usable).
Future
Godot 4.0 will come with a fast and complete solution for real-time global illumination, in an easy to use package.
There are still many pending features that will be worked on in the coming months, so stay tuned to all the new and shiny things! As always, remember that Godot is done entirely out of love for you and the game development community so, if you are not yet, please don’t hesitate to become our patron, and help bring the world top quality, free and open source tools for making games.
-
+
\ No newline at end of file
diff --git a/article/vulkan-progress-report-6/index.html b/article/vulkan-progress-report-6/index.html
index a2ae959a03..c603dfb104 100644
--- a/article/vulkan-progress-report-6/index.html
+++ b/article/vulkan-progress-report-6/index.html
@@ -6,7 +6,7 @@
Future
The plan is to finish, in February, the features that are missing to be ported from Godot 3.x. This includes subsurface scattering (will include a more correct human skin mode), and screen space reflections. Afterwards, all the new planned features and optimizations will finally be implemented!
As always, please keep in mind Godot is developed with love for all of you, so you have a completely free and open tool to make your games, and make them entirely yours. This could never happen without generous donations from our patrons, so if you are not yet, please consider becoming one.
-
+
\ No newline at end of file
diff --git a/article/vulkan-progress-report-7/index.html b/article/vulkan-progress-report-7/index.html
index 99f5a7e467..71aeeb6a6c 100644
--- a/article/vulkan-progress-report-7/index.html
+++ b/article/vulkan-progress-report-7/index.html
@@ -5,7 +5,7 @@
Juan Linietsky1 May 2020
This article is from May 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.
It’s been three months since a Vulkan progress report! I know you guys missed them, so I made sure to work extra hard to have something nice to make up. It feels great to be back to doing graphics programming after two months refactoring the core engine.
So, here are the things that were worked on during April 2020!
See other articles in this Godot 4.0 Vulkan series:
While not entirely rendering specific, a lot of nodes are being renamed. Users often complain that it’s confusing that 2D nodes have the “2D” suffix, while 3D ones do not. This will change in Godot 4.0. A lot of nodes will also be renamed to have clearer naming. A compatibility option will be added on load so older scenes still open properly.
New screen-space reflection
Screen space reflection in Godot 3.x was rather limited. It supported roughness, but it did so in a way where the texture reads appeared rough, but not the reflected image (the edges of the reflected objects remained intact). This is changing in 4.0, using a special screen-space filter to correctly simulate roughness.
New Subsurface Scattering
This effect worked to some extent in Godot 3.x, but the quality was limited by several factors. In Godot 4.0, Subsurface Scattering has been redone with a completely new state-of-the-art scattering model. In the example below, you can see that transitions from light to shadow now use the right skin sub-surface colors (red in this case), and that the ear is semi-translucent thanks to scattering.
Additionally to being able to simulate skin more correctly, it also supports transmittance, so light that comes from behind will spread towards the front by scattering below the surface.
Besides using the pre-existing tuned skin model, you can customize scattering so it works in a wider amount of material types.
Reworked shadow bias settings
A very common complaint when using shadowmaps in Godot is that tweaking shadow bias is extremely difficult compared to other game engines. Godot uses many different shadow techniques, which require different bias settings. Additionally, some situations like screen aspect ratio, draw distance or objects behind the camera frustum may also affect the biasing effect in ways it escapes user control.
In Godot 4.0, biasing has been entirely redone. Instead of reflecting the actual offset in shadow coordinates, bias is now a a reference value that adjusts itself to different shadow settings and types. It all happens automagically so, once set, the setting is adjusted to all possible internal conditions and light types.
This way, when you add a new light, a default value that works out of the box (or almost does) is always present and, even if you need to adjust the bias for some reason, the effort is minimal.
Additionally, slope-scale was replaced by normal-bias, allowing a very significant increase in shadowmap quality. Shadows look so good now that the old “contact” approximator no longer makes sense and it was removed. For directional shadows, pancaking was added (and is enabled by default). This makes shadows extremely stable, but has the downside that triangles too large may break the shadow a bit. If this happens, you need to adjust the pancake size, or subdivide the geometry.
As you can see in the image below, shadows “just work”, with no visible gaps or peter panning.
Soft Shadows
Godot 4.0 will support soft shadows in all its light types. For Omni and Spot shadows, a “size” parameter was added to the settings.
Soft shadows can become expensive quickly, so make sure to use them with relatively small softness values, or in controlled environments. For Directional lights, an “angular distance” parameter was added instead (0.5 is the Sun’s size). Setting this value results in more realistic shadows from the Sun.
Accurate frame render time
In Godot 3.2, you can only see the frames per second that takes rendering the whole editor. This is very misleading and not representative of rendering performance.
For 4.0, you can see the exact time it takes to render each 3D viewport, for both the CPU and GPU, and a correct estimation of what the “frames per second” will be when running your actual game.
MSAA and Screen-Space antialiasing
MSAA is back in master branch. Additionally, you can choose screen space antialiasing method such as FXAA.
Together with specular aliasing improvements for Godot 4.0, image quality is starting to be extremely high for this upcoming version, without having to resort to techniques such as TAA.
Decals
A very long-since requested feature has finally made it to Godot. Decals are now supported in the engine. They are very easy to use, just select the right texture channels and blending options and they work without much hassle.
Godot uses clustered decals, so the cost is very low (the pixel is shaded only once and there are no extra draw calls for each decal). Still, it is possible to set a maximum (including fadeout) distance for the decals. Make sure to abuse them as much as you want!
Light projectors
Both the Omni and Spot lights are now able to project textures. For Omni lights, in order to throw light in all directions, a panorama is required so make sure to look for a proper tool to generate them.
Low level access to RenderingDevice
Godot 4.0 will allow you to have low level access to the rendering APIs, allowing you to do all the same things Godot does during rendering, or calling your custom code in the middle of render passes.
Additionally, GLSL shaders (not Godot shaders, real GLSL 4.50+Vulkan extensions) can now be imported. It can’t be edited in-engine, but it supports shader variants using a custom syntax. They will be automatically imported and converted to SPIR-V when found, giving you proper reports on import errors.
It is also possible to create local rendering devices, which run in the game thread (or any other thread). This is very useful for games that may want their logic accelerated by the GPU (such as sandbox or simulation games).
Future
As you can see, a lot of cool new features were added this month! A 4.0 Alpha is still some months away, but it’s getting closer every day! So, stay tuned for next month’s progress report, which will include a lot of great new features including the new GPU accelerated lightmapper.
As always, please remember that Godot is made out of love for you and everybody else making games. We want to create the ultimate game engine and give it to you and the rest of the world for free, so you can own your games down to the last line of code. If you are not yet, please consider becoming our patron, and help us make this dream become reality.
-
+
\ No newline at end of file
diff --git a/article/warning-head-going-unstable/index.html b/article/warning-head-going-unstable/index.html
index 9f3422a56f..6d8738b24f 100644
--- a/article/warning-head-going-unstable/index.html
+++ b/article/warning-head-going-unstable/index.html
@@ -5,7 +5,7 @@
Juan Linietsky2 January 2017
This article is from January 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.
We know Godot has been known for many years to have a relatively stable master/HEAD at Github, so users can try the new features in their projects with very little risk of breaking them.
Starting now, and only for the upcoming 3.0 release, HEAD will break compatibility completely. Projects from Godot 1.x and 2.x will not work and this is expected.
Godot 3.0 is expected to be a compatibility breaking release. We will take the chance to do deep changes in Godot internals, which (while for the better) will render it incompatible with previous versions.
Moreover, starting new projects in the HEAD branch, using the new features and expecting them to work with the upcoming 3.0 release is discouraged - unless you want to help find and fix bugs in the development code of course.
Please wait at least until we can release an Alpha!
Some time before the 3.0 release, we will create a tool for project migration, which should make it easy to move to Godot 3.0 with as little work as possible. In the meantime, keep using Godot 2.1.x :)
-
+
\ No newline at end of file
diff --git a/article/we-hired-gdquest-work-manual/index.html b/article/we-hired-gdquest-work-manual/index.html
index fb42077dff..4ec9f0731e 100644
--- a/article/we-hired-gdquest-work-manual/index.html
+++ b/article/we-hired-gdquest-work-manual/index.html
@@ -5,7 +5,7 @@
Nathan GDQuest10 September 2020
This article is from September 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.
Hi! Nathan here.
I got hired by the Godot team to work part-time mission to help improve the official documentation. The job involves the following tasks:
Auditing the documentation to find missing, low-quality, and outdated content.
Improving the content’s organization.
Triaging issues.
Solidifying the workflow for core contributors and writing content guidelines.
Removing outdated content.
Improving the getting started guide.
Note that I will be working on the godot-docs repository and specifically on the reference manual; not on the class reference (although I took some extra time to review pending pull requests for the code reference).
All my work is public and open to feedback, entirely done on GitHub. This contract already stems from a public proposal to improve the manual by the time Godot 4.0 comes out. We had a long discussion with users and core contributors there, leading to this project.
Any changes to the content will only affect the latest version of the online manual, that is to say, the future Godot 4.0 docs. So you won’t see the changes in the stable version of the documentation until the Godot 4.0 release.
I’ve already gotten to work, starting with the audit and reviewing pull requests. To get progress report on this project periodically, you can follow me on Twitter. Alternatively, you can watch the godot-docs repository to get notified of all new issues and pull requests.
This project was funded by a generous donor who asked for work to be done specifically on the documentation.
-
+
\ No newline at end of file
diff --git a/article/we-need-your-help-improve-our-documentation-system/index.html b/article/we-need-your-help-improve-our-documentation-system/index.html
index 346ca32e1f..9ff4457e5a 100644
--- a/article/we-need-your-help-improve-our-documentation-system/index.html
+++ b/article/we-need-your-help-improve-our-documentation-system/index.html
@@ -8,7 +8,7 @@
How to contribute
The best way to contact us for this work is joining the #godotengine-atelier IRC channel on Freenode, which is dedicated mostly to website development.
-
+
\ No newline at end of file
diff --git a/article/we-should-all-use-gltf-20-export-3d-assets-game-engines/index.html b/article/we-should-all-use-gltf-20-export-3d-assets-game-engines/index.html
index 426794c87a..d7ca62e9b0 100644
--- a/article/we-should-all-use-gltf-20-export-3d-assets-game-engines/index.html
+++ b/article/we-should-all-use-gltf-20-export-3d-assets-game-engines/index.html
@@ -5,7 +5,7 @@
Juan Linietsky3 August 2017
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.
Introducing glTF 2.0
glTF 2.0 was introduced two months ago by Khronos, the body behind Vulkan and OpenGL.
Today, this format was added to Godot, which now supports the full specification. The reasoning behind this late feature addition is that, now that we released 3.0 alpha1, users need more content to test with the new 3D engine.
Sites like Sketchfab provide plenty of PBR-ready assets for downloading, and plugins that export scenes from other popular game engines to this format.
The surprise, though, is how good this format is for video game asset exchange. Nothing as good existed before, and it solves a problem that we, as an industry, have been struggling with for a long time.
Khronos, with glTF 2.0, has given us a fantastic chance to standardize a smooth workflow between 3D modelling software and game engines. To better understand why, a list of previous attempts will be explained and why they failed.
OBJ / 3DS
The first formats used for asset exchange were Wavefrom .OBJ and Autodesk .3DS. Both are formats from the early days of 3D computer graphics (late 80s, early 90s). Despite their popularity, they only support basic geometry, and .OBJ does not even support object transforms.
Collada
Collada (also from Khronos) was the first serious attempt to create an open exchange format, but it was not really intended to be used by the game industry (until later, at least). It was more of a tool to exchange assets between 3D modelling applications.
Despite supporting almost everything a modern game engine needs, the format fell into disuse. There are many reasons for this:
The specification was not that complex, but parsing an XML based format can be a hassle as all datatypes need to be converted from text. Implementers preferred libraries to do this work, but no good libraries existed. FCollada was discontinued, and OpenCollada turned out to be bigger than most game engines.
The specification was very ambiguous in many aspects, such as how data, skeletons, blend shapes, etc. had to be exported. It also gave exporters a lot of freedom in units used, as well as world transform specifications (e.g., which axis was up). All this resulted in a tremendous work for anyone wanting to parse the format.
Most exporters are, to this day, broken. IDs are not unique in some, the order of sections dictated by the spec is not respected, and information is often missing.
Collada is a text format, so loading large files is slow.
Autodesk (willingly or unwillingly) worked against the format adoption by including an incomplete and buggy exporter in their products. To this day, a large amount of developers believe Collada is not capable of a lot of functions that it actually is.
Blender (willingly or unwillingly) worked against the format by adopting an incomplete exporter.
While many factors worked against it, the truth is that Collada was never good enough.
FBX
One would assume (given its popularity) that FBX is pretty much the industry standard… except there isn’t any standard published by Autodesk about it.
FBX is used via the FBX SDK, which has a very restrictive license. This license makes it very hard to use in open source projects (an EULA must be accepted by the user unless a special license is purchased from Autodesk).
Besides the legal issues, implementing the library is rather difficult and suffers many of the same format ambiguity issues Collada does. One could argue, though, that the main technical advantage about it (besides working with the most popular 3D modelling applications) is that the file format is binary, so parsing it is fast.
That said, as an industry, we should look for true standards to work with. As useful as FBX may be, Autodesk alone controls its future.
OpenGEX
OpenGEX was born from one of the most brilliant minds the game industry has ever produced: Eric Lengyel, who single-handedly created the C4 engine. It has a well defined specification and comes with exporter plugins for the most common 3D modelling software, as well as documentation and support libraries. It also has the very innovative approach of encoding floating point data as hexadecimal for quick and efficient parsing (despite being text based).
Unfortunately, OpenGEX did not catch up. The main reasons I can think of are:
There are no open tools where you can test and visualize your exported files, save for Eric’s own commercial engine.
It’s not really standard, as it’s not registered in any relevant body.
Development is not peer-based, only Eric decides the future of the format.
In short, for a format not so open, it does not offer many advantages over FBX.
glTF 1.0
The first version of glTF had many good ideas, but it was clearly intended as a storage format for WebGL. In fact, materials could only be created by writing GLSL shader code. This made format unusable for anything else, as modern game engines only allow the user to create materials by customizing a small part of the rendering pipeline.
glTF 2.0: What makes it great?
By just reading the spec, the advantages should become clear. Still, I will detail the key points below:
JSON based
GLTF is a JSON based format. It’s very easy to parse and the data already comes typed. This significantly reduces the need to rely on complex third party libraries to read it. Many languages (e.g., Javascript, Python) even support this format natively.
Comparing the size (in lines of code) of both Godot’s glTF 2.0 and Collada importers, the result is as follows:
Collada: ~5000 loc
glTF 2.0: ~2000 loc
Godot does not even use third party libraries to parse these files. This makes it more evident how simple the format is in comparison.
Theoretically, glTF2 should be less efficient to parse than Collada, as it requires parsing the whole JSON into memory. Collada can be streamed in by using a SAX XML parser but, in practice, glTF beats Collada hands down. This is because (besides many Collada exporters not obeying the specification, so they can’t be parsed as SAX anyway) glTF has yet another killer feature:
Separate binary blob for arrays
glTF allows specifying an external file for the big data, in binary format. It even supports many common GPU data types, so in practice this file can be moved in chunks directly to the GPU memory. Yes, glTF is the first of these formats that can even be used efficiently as in-engine data.
Even if engines would prefer to import to their own format, like Godot does, glTF is extremely fast to export and import. This makes it ideal for making changes to a complex file in the 3D software and updating them to the 3D engine almost instantly.
No ambiguity
glTF’s file structure is crystal clear. No extra or redundant data exists. There is only one way the scene definition can be understood, which gives no room for exporters to take shortcuts. It also makes life for importers simpler, warranting that all existing scenes will work on the first implementation attempt.
Collections of objects of the same type are stored in JSON arrays and referenced by indices. No more confusing IDs.
There is also no support for different coordinate systems or units, and this is great. Quoting one of the first paragraphs of the specification:
glTF uses a right-handed coordinate system, that is, the cross product of X and Y yields Z. glTF defines the y axis as up.
The units for all linear distances are meters.
All angles are in radians.
Positive rotation is counterclockwise.
Just one simple use case to care about. No extra conversions. All work is left to the exporter. As there are usually way more importers than exporters, this is an excellent design decision.
Modern features
glTF 2.0 fully supports skeletons and morph targets, which can be parsed easily and unambiguously.
It also supports PBR based materials using the Disney/Unreal format, which is what most engines and 3D modelling applications use nowadays, with albedo, metallic, roughness, normal, emission and ambient occlusion. It also handles two-sidedness and transparent materials, including alpha to coverage.
Extensions for handling shader material graphs are in the work.
Great animation support
Animation support is also well done. glTF 2.0 supports multiple animations per file, which is ideal for exporting character actions (though be careful with some official examples, they are old and incomplete). It also supports many key interpolation types, such as Catmull Rom and Cubic Spline.
Animations are also stored in the binary file, so they can be loaded quickly.
Clean documentation
The specification is very complete, I personally found it well worded and not lacking in any area. There are many sample files to test all functions.
Flexible extension support
glTF uses the same extension system as other Khronos specifications, which is proven to be centralized and well organized.
Strong backing
glTF is developed by individuals from many companies, such as Microsoft, Unity, Google, Adobe, NVidia, Oculus, etc. in collaboration with Khronos.
Best of all, it’s completely open and everyone can contribute!
glTF is an open standard and the development process is also transparent.
Support glTF!
For glTF to succeed, it needs strong developer adoption. Ask your favorite 3D modelling software or engine developer to support it!
Currently, the Blender exporter is in the works and not complete, and there is no support at all for Autodesk products (export plug-ins need to be written).
This is the best chance we’ll ever have in a long time for a proper, open standard. Let’s work together to make it happen!
-
+
\ No newline at end of file
diff --git a/article/webassembly-godot-web/index.html b/article/webassembly-godot-web/index.html
index 5be50013c7..eb9bd77350 100644
--- a/article/webassembly-godot-web/index.html
+++ b/article/webassembly-godot-web/index.html
@@ -5,7 +5,7 @@
Juan Linietsky25 June 2015
This article is from June 2015, 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.
Running native on the web
Godot has a long story on attempts trying to make it run on the web. We always wanted this to happen, we tried many approaches, it may finally happen. This article will be a small recap of our experiences with this matter.
Atmosphir
A long time ago Ariel and I wrote a game named Atmosphir as contractors. It was one of the first voxel games and a Minecraft precursor. Although far from what Godot is now (almost the entire codebase is different at this point), the game+engine combo were written almost from scratch in seven months and Atmosphir got a warm welcome by the community.
As it did well, investors wanted to expand the game and one of their first ideas was to make it a web based game to run it in Kongregate (which was trendy). They were set on this idea and completely convinced that downloadable games were a thing of the past (a common idea at the time, Steam did not exist yet and Minecraft was a year or two away from proving them wrong).
First attempt, native plugin
We did research on how to make the game run on a browser and researched NPAPI and similar technologies and even made prototypes, but reality was that we believed it was a huge security risk to do this, as plugins don’t have any sort of protection against attacks (reason why now they are being removed from Chrome and Edge).
Finally It was decided that the game was to be ported to Unity so it could run on the web. Unity at the time was a very immature engine and Atmosphir was probably one of the biggest projects made with it, if not the largest. Still, it had a great web plugin with a decent userbase. At the time we had other priorities so we ceased involvement with the project.
Second attempt, native client
Shortly afterwards, Google announced Native Client. Native Client works by allowing developers to compile “safe” binaries that run on the Browser. You had to compile a binary for each processor by yourself, but that wasn’ t too bad. We believed it was a great idea, as it was a safe way to run native code on the web. Ariel did a very early port of Godot to it and it worked fantastic.
At the time, Google started experimenting with Pepper API (PPAPI), proposing it as an open safe (sandboxed) plugin interface. Mozilla was interested too so so we believed this was the future (Hey, if both Firefox and Chrome had it working, Microsoft would have been forced to implement it, right?). Unfortunately, Mozilla changed course and decided not to go that route (no PPAPI) and, as a Chrome-only plugin would not be very useful, we abandoned it to.
Failure. A shame because PNaCL was not going to get support either, as a great of an idea as it was. Thanks Mozilla.
Third attempt, Flash
Fast forward to Farmville. Making games in Flash became all the rage and the most popular way to make games on Facebook. On the peak of it’ s glory, Adobe announced a cool internal project called “FlasCC“, later renamed to “Project Alchemy” and finally settled as “Adobe CrossBridge”. This technology allowed to compile C++ to run on the FlashVM.
At the time, It was still immature and it needed some work, but it showed promise. “This is it!” we thought again, this is how to run Godot on the web. We met with Adobe privately at GDC and worked with them in the closed beta with the hopes to have a nice flash exporter.
Unfortunately, one day Steve Jobs decided that “Flash is dead” and killed it. It was a simple as that. Can’t complain about it as it was probably a good thing, but efforts to bring Godot to the web failed again as Adobe abandoned both Flash and Cross Bridge. Thanks Apple.
Fourth attempt, ASM.JS
When I first heard that someone made a compiler that converted C++ to JavaScript, I laughed a lot and ignored it for about a year. Finally, one day, decided to gave it a try and I was surprised that it worked. It had a lot of limitations but it could run Godot. Firefox ran it flawlessly and perfectly, but not Chrome and much less Internet Explorer. The situation improved the following years, with support somehow improving in all major browsers and Microsoft deciding to adopt it for Edge.
Unfortunately, the process of detecting asm.js and pre-parsing it efficiently seems it’s too much of a hack to implement by browser vendors other than Mozilla. Despite it being adopted by Unity and Unreal too, ASM.JS is still hit or miss. It requires a huge amount of resources to compile the Javascript blob, a large pre-allocated chunk of memory (to serve as process memory), and a relatively fast computer to run it. Forget about mobile web. This back-end is still in the works in Godot, but we were mainly waiting for browser vendors to make it not suck. This may never happen.
Fifth attempt, WebAssembly
Some days ago, WebAssembly was announced. It’s a bytecode specification to run code that converts to native on the browser. On paper it’s great and provides every single thing that Godot needs. It’s still in diapers and we might not see support for it until next year, but it’ cool because this time Unity and Unreal are in our same boat and they have more lobby power than us.
In fact, all this is probably because they freaked after Google decided to deprecate NPAPI from Chrome and Microsoft decided to stop supporting plugins on Edge. Will we succeed this time? I hope so, but i we do it will definitely be thanks to Google and Microsoft this time! Thanks for having the balls to deprecate native plugins!
As soon as there is an initial implementation of this technology in all major browsers, we will definitely be giving it a try! Stay tuned!
-
+
\ No newline at end of file
diff --git a/article/website-back/index.html b/article/website-back/index.html
index 5760b515bb..fded1eaea5 100644
--- a/article/website-back/index.html
+++ b/article/website-back/index.html
@@ -6,7 +6,7 @@
We are engine developers, not web developers, so securing hosted sites is definitely not our strong point.
After being open sourced back in February, Godot development went under. We got a lot of enthusiasm and positive feedback back them, but also a lot of bug and usability reports. The engine was stable for us and the handful other people that was using it at the time but, when exposed to so many new developers, all the flaws, bugs and general usability issues and lack of polish that remained shined in the sunlight. For months, we put priority to this and worked hard to solve most of them without trying to draw much attention. Finally, this work has paid off and we are close to finally announce our first stable release, Godot 1.0!
The source code has been stable for the few weeks, so at this point we are working on the tiny details and issues that remain. Welcome back to the website and let’s hope we can celebrate soon!
-
+
\ No newline at end of file
diff --git a/article/websocket-ssl-testing-html5-export/index.html b/article/websocket-ssl-testing-html5-export/index.html
index e02fb31a4f..964b5a1e5e 100644
--- a/article/websocket-ssl-testing-html5-export/index.html
+++ b/article/websocket-ssl-testing-html5-export/index.html
@@ -35,7 +35,7 @@
Godot has a cool feature that allows users to export for some plaftorms in debug mode and run the exported game directly on a connected device with the press of a button, as long as at least one runnable export preset for that plafrom has been created.
HTML5 exports, used to have this feature too, opening the exported HTML in the default browser directly from the file system. Since most browsers now no longer allow making async requests from a page loaded from file://, we added a minimal HTTP server to the editor to serve the exported HTML5 game.
This is also a very important step towards allowing users to profile HTML5 exported games via websocket connection. Stay tuned for more.
-
+
\ No newline at end of file
diff --git a/article/websocket-updates-udp-multicast/index.html b/article/websocket-updates-udp-multicast/index.html
index e51505efe5..1f1971286f 100644
--- a/article/websocket-updates-udp-multicast/index.html
+++ b/article/websocket-updates-udp-multicast/index.html
@@ -5,7 +5,7 @@
Fabio Alessandrelli22 August 2019
This article is from August 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 effort to better Godot’s networking, two main changes were worked on in June and are now merged in the current master branch:
The third party library used to implement WebSocket in non web export has been changed.
PacketPeerUDP multicast support has been added.
WebSocket update
Third-party library change
In an effort to make Godot’s WebSocket implementation more portable, maintainable and lightweight we recently swtiched from libwebsocket to wslay.
This new library allows us to use our own networking classes, making it more portable across different platforms, and solving some long lasting problems we had with the previous library, while also decreasing the overall code size.
If you are using WebSocket in your project please try out these changes and report any issue you might encounter.
WebSocket tutorial and demos
A new WebSocket tutorial and three new WebSocket demos (minimal, chat, multiplayer) have been added to Godot’s documentation and demo projects.
UDP multicast
Multicast support is finally coming for PacketPeerUDP, this is useful for network discovery (e.g. finding LAN peers, servers, etc.). See the documentation for join_multicast_group and leave_multicast_group.
Along with this change, it is now also possible to get more information about the network interfaces of the machine on which Godot is running via the new IP.get_local_interfaces() function.
-
+
\ No newline at end of file
diff --git a/article/welcoming-our-new-gold-sponsor-imagecampus/index.html b/article/welcoming-our-new-gold-sponsor-imagecampus/index.html
index a4e96686eb..d884111d1e 100644
--- a/article/welcoming-our-new-gold-sponsor-imagecampus/index.html
+++ b/article/welcoming-our-new-gold-sponsor-imagecampus/index.html
@@ -5,7 +5,7 @@
Juan Linietsky21 September 2018
This article is from September 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.
Godot gets a new Gold sponsor! In this case, we are welcoming Image Campus, an education institution located in Buenos Aires, Argentina, which specializes in animation, digital art and videogames.
They are one of the pioneers in the region regarding videogame related careers and constantly supply a large portion of the Argentine industry (one of the largest in South America) with professionals, allowing it to keep growing at a rapid pace.
It personaly makes me happy to announce them as sponsors, and they always supported the project, helping organize workshops and talks in the city, and having incorporated Godot to their regular classes.
Remember that, you too can also contribute to aid Godot development by becoming our patron!
-
+
\ No newline at end of file
diff --git a/article/whats-missing-in-godot-for-aaa/index.html b/article/whats-missing-in-godot-for-aaa/index.html
index 8a9c00ace6..17c50b5b46 100644
--- a/article/whats-missing-in-godot-for-aaa/index.html
+++ b/article/whats-missing-in-godot-for-aaa/index.html
@@ -5,7 +5,7 @@
Juan Linietsky16 January 2023
This article is from January 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.
Godot 4.0 is coming out soon. It includes major improvements all across the board in features, performance, and usability. Still, one of the biggest questions the community has is: How does it compare with mainstream commercial offerings?
Godot 4.0 improvements
Rendering
Godot 4.0 has an entirely new rendering architecture, which is divided into modern and compatibility backends.
The modern one does rendering via RenderingDevice (which is implemented in drivers such as Vulkan, Direct3D 12, and more in the future). Additionally, the modern backend can implement rendering methods, such as forward clustered, mobile, and more in the future (such as deferred clustered, cinematic, etc.).
The compatibility backend is based on OpenGL ES 3.0 / OpenGL 3.3 / WebGL 2.0 and is intended to run on very old PC hardware as well as most older (still working) mobile phones.
Rendering is significantly more efficient in Godot 4.0, using data oriented algorithms to process the culling of objects and both secondary command buffers and automatic batching to efficiently submit the draw primitives.
The features offered are also a lot more reminiscent of AAA games, such as far more material options and advanced visual effects (including circle DOF, volumetric fog, AMD FSR, etc.). Additionally, Godot 4.0 supports advanced global illumination techniques such as lightmapping (including SH lightmapping), Voxel GI (which is fully real-time) and SDFGI (which is a one-click, open world GI solution). SSIL can be used to enhance realism even more.
Physics
After an unsatisfactory attempt at using Bullet, Godot 4.0 returns to its own physics engine which, despite not being a high end physics engine like PhysX, aims to offer a lot more flexibility and “just works” capabilities to users.
Several features were added to Godot Physics since 3.x, such as soft bodies and cylinder shape support, as well as several optimizations to make use of multiple threads.
The custom physics engine still has a considerable amount of issues remaining but we are working hard to ensure it is in a decent state for shipping when 4.0 reaches stability. It will continue seeing improvements afterwards, during the following 4.x release cycles.
That said, Godot 4.0 introduces the ability to bind custom physics engines at runtime (without recompiling Godot) via GDExtension, so it’s perfectly possible for the community to integrate other engines such as PhysX, Jolt, or Box2D if needed.
Scripting
Godot 4.0 has a new version of GDScript, which is far more powerful and overcomes most shortcomings found in 3.x. Majorly, the addition of lambdas, first class functions/signals and a much reduced reliance on string identifiers (which are prone to errors). It also has more useful built-in data types such as integer vectors.
Core engine
The core engine has been significantly optimized, especially in the memory and data-oriented areas. Core and Variant have been massively cleaned up and made more extensible. Besides being faster and more modern, the core codebase is now significantly easier to maintain and extend.
GDExtension
It is now possible to extend Godot and add features to it practically in any language and without recompiling the engine, thanks to the new GDExtension system. Aside from Godot C++ (which makes it easy to extend Godot as easy as with modules but allowing pluggable, dynamic add-ons), there are other bindings in the work such as Python, Rust, Go, etc.
A lot more
Several other areas got improvements, like the editor (which has been vastly reworked), UI system, multiplayer, navigation, audio, animation, etc. This is a major release with major improvements all across the board.
So, what’s missing?
Do not be mistaken: A lot is still missing from Godot in order to be used comfortably for large projects and teams. That said, what remains is now much less work than it was for Godot 3.x.
First of all, most of the new features still have significant bugs and performance problems that will not be solved in time for the upcoming 4.0 release (there is just too much new code that needs to be tested thoroughly).
These problems will be fixed across the 4.x point releases (which we are now intending to do more often, allowing several releases per year). It may be an extra year or even two until everything feels as solid and fast as everyone expects. See this article about our plans for 4.0 and beyond.
But other than that, there are still some fundamental aspects missing in Godot. The following is an incomplete list of the most important ones:
Streaming
The traditional way to make games longer since the beginning of times is to divide them in stages. As soon as one stage is completed, it is unloaded while the new one is loaded.
Many games still use this approach nowadays (after all, if it’s not broken, don’t fix it) but, increasingly, game design has been moving from “individual stages” to “open” or “continuous” worlds where the boundaries between levels disappear. Creating games this way is, as a result, more challenging.
This is handled nowadays by a type of technology called “streaming”. It means that assets are pulled from disk on demand (loaded only at the time they are needed), rather than as a part of a larger stage. The most common types of streaming are:
Texture streaming: All textures are loaded in a tiny size by default. As textures get closer to the camera, higher resolution versions (or mip-maps) are streamed from disk. Textures which haven’t been used for some frames are freed instead. At any given time, the textures loaded (and their detail) closely reflect the place the player is in.
Mesh streaming: Models are loaded as low detail (few vertices). As they gradually approach the camera, higher resolution versions are streamed from disk. Models that were not used (displayed) for a while are often just freed and will be loaded again when needed.
Animation streaming: Modern games have long cinematics, which require a lot of animation data. Loading those animations requires a lot of memory and loading them takes a lot of time. To avoid this, animations are streamed by generally keeping the first second or two in memory and then new sections are loaded on demand as the animation plays. Godot 4.0 supports strong animation compression and animation pages, so most of the work is already done.
Audio streaming: Similar to animation streaming, it requires storing the first second or two of audio and then streaming the rest directly from disk.
Of the above, most are relatively straightforward to implement. The most complex is mesh streaming, which generally needs to be implemented together with a GPU culling strategy to ensure that very large amounts of models can be drawn at no CPU cost. This is more or less what techniques like Nanite do in Unreal, although Godot does not need to implement something that complex to be of use in most cases.
Streaming is the most important feature missing for managing large scenes or open worlds. Without it, Godot users are subject to long loading times (as every texture, model and animation has to load before anything is shown). There is also a risk of running out of memory if too many assets are loaded in parallel instead of streaming them.
Low level rendering access
Despite the new renderer in Godot 4.0, there is no architecture that can be considered a one size fits all solution. Often developers need to implement rendering techniques, post processing effects, etc. that don’t come bundled with the engine.
The Godot philosophy has always been to cater to solving the most common use cases, and leave the door open for users to solve the less common on their own.
As such, this means that low level access to all the rendering server structures needs to be exposed via GDExtension. This will allow creating custom renderers or plugging custom code during the rendering steps, which is very useful for custom rendering techniques or post processes.
Scene job system
Most of the work done for Godot 4.0 involved large feature and performance improvements to all the servers (rendering, physics, navigation, etc.). Servers are also now multithreaded and optimized. Even asset loading can now be done multithreaded (using multiple threads to load multiple assets).
Still, the scene system (which uses those servers), despite several usability improvements, has not seen significant optimization.
Scene nodes in Godot are mostly intended to carry complex high level behaviors (such as animation trees, kinematic characters, IK, skeletons, etc.) for limited amounts of objects (in the hundreds at most). Currently, no threading happens at all and only a single CPU core is used. This makes it very inefficient.
This makes it an ideal target for optimizing with multithreading. There is an initial proposal on threaded processing for scene nodes, which should give complex scenes a very significant performance boost.
Swarms
Scenes, as mentioned before, are designed for complex high level behaviors in the hundreds of instances. Still, sometimes, some games require larger amounts of instances but less complex behaviors instead.
This is needed for some types of game mechanics such as:
Projectiles (bullet hell for example).
Units in some types of strategy games with thousands of entitites roaming across a map.
Cars/people in city simulators, where thousands appear all across the city.
Sandbox style simulations.
Complex custom particles that run on CPU.
Flocks, swarms, mobs, debris, etc.
More experienced programmers can use the servers directly or even plug C++ code to do the heavy lifting. ECS is often also proposed as a solution for this. Even GPU Compute (which is fully supported in Godot) can be easily used to solve this pattern.
But for the sake of keeping Godot accessible and easy to use, the idea is to create a swarm system that takes care of the rendering and physics in large amounts of those objects and the user only has to fill in the code logic.
Large team VCS support
Godot’s text file formats are very friendly to version control. They only write what is needed (no redundant information), keep the ordering of sections and are simple enough to understand changes by just looking at the diff. Few other technologies work as well in this area.
Despite that, this is far from enough to enable large team collaboration. To enable this, Godot VCS support has to improve in several areas:
Better integration with the filesystem dock.
Better real-time refresh of assets if they were modified externally (and checked out).
Support for permissions and file locking: Git does not support this out of the box, but Git LFS and Perforce do. This feature is essential for large teams to avoid conflicts and keep files protected from unintended modifications (e.g. a team member modifying code or a scene they don’t own by mistake).
Unless the support for this is solid, using Godot in large teams will remain difficult.
Commercial asset store
While for very large studios this is not an area of interest, medium-sized studios still rely on significant amounts of assets and pre-made functionality. The Asset Library currently existing in Godot only links to open source resources (e.g. hosted on GitHub or GitLab) and is unable to be used for commercial assets.
For the Godot project, a commercial asset store would be a great way to add an extra source of income, but it was not possible given our legal status until recently. With the move to the Godot Foundation, this is a new possibility that opens up.
Is solving these problems enough for Godot to become a top AA / AAA game engine?
The answer is “it depends”. Godot, at its core, is and will always be (by design) a very general purpose game engine. This mean that the tools provided, while certainly capable, are still game neutral. The goal for Godot is to provide a great set of building blocks that can be used and combined to create more specialized game functions and tools.
In contrast, other types of game engines already come with a lot of high level and ready to use components and behaviors.
I don’t mean to say that Godot should not support any of that in the future. If it does, though, it will most certainly be as official extensions.
So, what kind of features are we talking about? Well..
Game specific templates and behaviors
As an example, Unreal comes with a player controller, environment controller, and a lot of tools to manage the game pacing and flow. These are most likely aimed at TPS/FPS games, which are the most popular game types made with the engine.
Some of these can be found as templates in Godot’s Asset Library but are nowhere close to that functionality. Eventually, official ones should be created that are more powerful and complete.
Visual scripting
While Godot had visual scripting in the past, we found that the form we had implemented didn’t really prove adequate for the needs of the community, so it was discontinued.
What we realized is that visual scripting really shines when combined together with the premade behaviors mentioned in the previous section. Without a significant amount of high level behaviors available, visual scripting is cumbersome to use as it requires a lot of work to achieve simple things by itself.
All this means that, if we produce a visual scripting solution again, it needs to go hand in hand with high level behaviors and, as such, it should be part of a set of extensions to the engine.
Specialized artist UIs
When doing tasks such as shader editing, VFX (particles) or animation, there is a large difference between Godot and engines such as Unreal.
The difference is not so much in features supported. In fact, the feature set is fairly similar! The main actual difference is in how they are presented to the user.
Godot is a very modular game engine: this means that you achieve results by combining what is there. As an example, editing a particle system in Godot means a lot of subsystems must be understood and used in combination:
GPUParticles node.
GPUParticlesMaterial resource (or even an optional dedicated shader).
Mesh resource for each pass of the particle.
Mesh material resource for each surface of the mesh (or even an optional dedicated shader).
As another example, the AnimationTree in Godot requires that AnimationNodes are laid out in a tree fashion. They can export parameters, sections can be reused (because they are resources), etc.
Or even more. Godot’s animation system is often praised because anything can be animated. Any property, other nodes, etc.
This makes Godot an extremely powerful engine that gives developers a lot of flexibility, but…
It also assumes that the user is knowledgable enough about Godot and all its inner workings in order to take advantage of it. To clarify, none of these systems are too technically complex and this is part of what makes Godot appealing and accessible, but it still requires a certain level of technical and engine knowledge.
In contrast, engines like Unreal have entirely dedicated and isolated interfaces for each of these tasks (materials, cinematic timeline, VFX, animation, etc.).
Sure, they are monolithic and hence less flexible, but for a large team with high amounts of specialization, an artist does not need to understand as much in-depth how the engine works in order to produce content with it.
This shows the fundamental difference of target user between engines. If Godot wants to appeal to larger studios, it needs to provide simpler and more monolithic interfaces for artists to be able to do their job without requiring significant time investment in learning the technology.
This could, again, be supplied via official add-ons and, like the sections above, would require a significant amount of research to understand how to build it, since without actual feedback from artists we would only be guessing what is needed. But the question here is, is it worth it?
So, are we not even close?
While the goal of this article is to make clear how significant the work remaining is to make Godot an offering closer to the ones in the commercial segment, it is important to not forget one key detail:
Godot is Free and Open Source Software. And as such, it can be modified by anyone to fit any purpose.
Currently, many large studios have the ability to create their own in-house technology. Still, as hardware becomes more and more complex to develop for, they are giving up in favor of spending money on pre-existing commercial technology offerings.
Godot, on the other hand, serves as an excellent platform to build upon, as it solves the vast majority of problems already. As a result, more and more studios are using Godot as a base to derive their own technology from.
This is a win/win situation, as it allows them to keep their freedom to innovate and, at the same time, avoid paying expensive technology licensing costs.
Time will tell how Godot transitions from its current state to something more widely used by larger studios, but it will definitely need significantly more work from our side.
Future
I hope that this write up made more evident why Godot is such a key technology for the future of the game industry. We will continue working hard to ensure that more and more individuals and companies find Godot useful! But we need your help to happen, so please consider donating to the project.
-
+
\ No newline at end of file
diff --git a/article/whats-new-in-csharp-for-godot-4-0/index.html b/article/whats-new-in-csharp-for-godot-4-0/index.html
index e86a0d0a9f..62d951be3e 100644
--- a/article/whats-new-in-csharp-for-godot-4-0/index.html
+++ b/article/whats-new-in-csharp-for-godot-4-0/index.html
@@ -14,7 +14,7 @@
Even though the parameter is optional, the method now has a different signature. Therefore libraries built against the previous version that invoke MyMethod won’t be able to find it.
Godot implements various systems to preserve compatibility and allow for smooth transition, even when we have to change some fundamental things. You should expect future releases of Godot 4 to work with your Godot 4.0 project, but we still leave the room for the inevitable. In case of completely incompatible changes introduced in minor releases, we promise to provide clear migration instructions and possibly tools for automated conversion. In order to further minimize issues make sure your game project as well as the libraries it uses are all referencing the same GodotSharp version.
IDE support
With the move to the .NET Core CLR runtime, Godot gained support to use the official C# debugger. This means IDEs that support C# and official C# extensions support debugging Godot projects out of the box. Although configuring your IDE may require a few more steps at the moment.
Other features of Godot’s IDE extensions for C#, such as our Roslyn completion providers, are planned to be moved out of the extensions and into NuGet packages so that all IDEs can benefit without requiring a dedicated extension.
The Configuring an external editor section of the C# basics documentation page has yet to be updated to explain how to set up your editor for Godot 4.0. Stay tuned for an updated version.
Relevant links
Make GodotCompletionProviders work via NuGet (GH-18).
Future
Some features didn’t make it in time for Godot 4.0, but are already on our roadmap for a future release (and some are already in the works).
Global classes
Global classes, also known as named scripts, are classes registered in the editor so they can be used more conveniently. These classes appear in the Add Node and Create Resource dialogs. GDScript supports this feature with the class_name syntax.
We tried, but ultimately failed, to bring this feature to C# in time for 4.0. Luckily, there’s already a PR open, so it’s very likely it is going to be ready for the next minor release, Godot 4.1.
We aim to support C# on all the platforms that Godot is available on. Unfortunately, we were unable to implement support for mobile and web platforms for 4.0. These platforms gained support upstream somewhat recently so we didn’t have much time to work on it. The new workloads in .NET 6 should allow us to support the mobile and web platforms really soon, so keep an eye out for that.
Support for these features can greatly reduce binary size and enable further performance optimizations. In order to support them, we need to ensure that our libraries are prepared. Dynamically accessed types can’t be trimmed, so we need to avoid reflection as much as possible.
Some target platforms don’t support JIT, so we are definitely looking into supporting AOT. We’ll be working on this as we add support for more platforms in future 4.x releases.
The ability to create GDExtensions using C# will enable new and powerful workflows. This would allow us to avoid the limitations of a scripting language implementation, such as relying on file paths to reference C# classes. Users are going to be able to implement C# types that can be registered in Godot’s internal type database, ClassDB, and that would behave as built-in Nodes and Resources.
GDExtension is still very new to the engine, and is subject to change. It also has some limitations that would result in UX regressions, if C# moved away from the scripting language implementation. But it also has the potential to reduce some pain points that users have had in the past. In Godot 4.0, C# is still implemented as a scripting language, but we are planning to add support for GDExtension creation using C#. We will be keeping the scripting language implementation for your regular game scripting needs.
Consuming APIs provided by a GDExtension is also currently unsupported. We’ll keep working on bridging the gap between GDExtension and C# in future 4.x releases.
As mentioned throughout this article, several areas can benefit from allowing users to create their own third-party source generators that can extend what’s currently available. For example, allowing our source generators to be affected by custom user-defined attributes.
This is tricky to get right, but we’ll be exploring some ideas in future 4.x releases to see how we can provide some extensibility without requiring users to disable and re-implement all of our source generators.
Editor unification
Just like Godot 3 before it, Godot 4.0 is going to come with two versions of the editor, one “standard” and one with extra support for C# and .NET. However, the plan for 4.x is to provide one unified editor, that support everything the .NET build currently supports. If you’re a GDScript user, this doesn’t come at any cost for you. But for maintainers and C# developers it greatly simplifies things and allows for more efficient editor development and testing. To keep things slim and flexible, components required to support .NET projects would be downloaded on-demand when the user needs them.
Relevant links
From embedding Mono to Godot as a library and the future (GH-2333).
Godot as a library
The concept of Godot as a library and C# being the entry point is something that a lot of users seem to be interested in. We think this could bring many benefits to C# users, it would make it easier to support all the platforms where .NET is available, and stay up-to-date with newer .NET versions.
We started exploring this area in 4.0, but it still requires more investigation and work. It’s unlikely to be finished any time soon but we’ll keep working on it in the future.
Relevant links
From embedding Mono to Godot as a library and the future (GH-2333).
As you can see, a lot of work has been done, and more work is in the pipeline. We are constantly looking into more ways to improve performance and usability of the API, and we keep fixing all the bugs that you can find. We are looking forward to see what you think of the .NET module in Godot 4.0. Don’t hesitate to reach out with your feedback! 🙂
-
+
\ No newline at end of file
diff --git a/article/why-does-godot-use-servers-and-rids/index.html b/article/why-does-godot-use-servers-and-rids/index.html
index 5a0b0ae251..e23f56a4da 100644
--- a/article/why-does-godot-use-servers-and-rids/index.html
+++ b/article/why-does-godot-use-servers-and-rids/index.html
@@ -6,7 +6,7 @@
How is this achieved? Rendering, while mostly a sequential process (GPUs are sequential), can be parallelized in a few places, like frustum culling and (in modern APIs such as Vulkan, Metal or DirectX12) creation of command lists.
For Physics, it’s a bit more difficult. Physics engines divide their work per frame in the following stages:
Force Integration: Compute gravity and external forces and apply them to velocity
Broad Phase: Finding pairs of close objects
Near Phase: Generating collision information of overlapping objects
Solver: Iterative or LCP approximation to collision resolution
Velocity Integration: Move the objects
Of those, mainly the near phase and the solver steps can be highly parallelized. Physics engines do this via the creation of islands, which are standalone group of objects that don’t interact with other groups. This allows to process them in parallel.
If we put all together, rendering a frame with multiple threads, splitting in jobs, becomes something like this:
A different parallelism
Implementing a job system in Godot was too challenging, unfortunately. While for high-end game engines this makes sense, usability would end up severely affected. As Godot aims to be an easy to use engine, users would have too many challenges with a system like this:
It would be too easy for users to step on a piece of code that is currently being modified in a separate thread, resulting in crashes or undefined behaviors.
To avoid this, locking would have to be put all over the place. This would make code more complex, and likely still impact performance due to waiting for mutexes or semaphores.
Sync points would help, but it offloads more complexity to the user. For custom engines in large games this can be a benefit, but for us it impacts usability.
All this led to a question: How can we make Godot multi-threaded but keep it easy to use?
The answer to this puzzle lies in understanding the following facts:
Logic sets information into Physics, but it does not need to retrieve data from it.
Both Logic and Physics set information into Rendering. Neither need to retrieve data.
Rendering alone has all the information it needs to display a frame and no one needs to wait for it.
Physics needs to set back information (bodies that moved and collisions) into the logic layer, but this can be done anytime before the next frame.
If we put everything together, it becomes obvious that all 3 tasks can run in parallel:
Physics syncs information from the previous fixed frame to Logic
Logic runs the fixed step, syncs back with Physics and then goes on to do the regular step while Physics starts working.
Physics pushes data to Rendering.
Rendering completes whathever it was doing from the previous frame, syncs (swaps buffers), then takes the info from Logic and starts working on the new frame.
This results in multi-threading, in a way that is transparent to the programmer:
Basically, the concept of “frame time” (doing everything in less that 1/60 seconds), no longer exists with this approach. Logic, Physics and Rendering have the whole frame time for themselves, and they don’t run in sync (i.e. Rendering will process the frame “later”, and both Logic and Physics will process their frame at the same time and only spend a bit syncing).
This sounds great in theory, but in implementation it’s chaos. It means both Physics and Rendering must receive commands, and that commands need to be buffered somehow. With traditional OOP and C++ this is a recipe for spaghetti code. Passing around objects that may not execute functions when you call them is weird.
Servers
To make this easier, we came up with the concept of Servers. They are called like this because of their requirements:
An entity that contains all the information and state, does the processing and returns the results.
It runs in parallel, it could be in the same device or even in a remote device.
The user has no direct access to it.
All communication is done via commands sent on a single channel.
It’s clearly a server pattern!
As this is a command-oriented API, it is exposed via a single class representing the Server. Remote objects are represented with RIDs.
Servers work very well in Godot, and even allow for some extra goodies:
Background loading and information processing on threads works great (e.g. generating terrain), because each thread can create content, then register it via a single channel.
It’s easy to tell when something has changed by just checking the command data. This allows Godot behaviours such as not redrawing the editor screen if nothing changed.
Switching between single and multi-threaded server is easy, as it just requires an adapter server that provides the command buffering.
Future
For Godot 3.0 we are working on improving some aspect of servers. The main one is optimizing RIDs, which will now also cache an opaque pointer to the objects used. Before this, objects had to be looked up internally in a hash table.
The advantage of this is higher performance, while the obvious drawback is that the game can crash on release and less information will be provided. To avoid this, always check the errors reported in debug builds!
-
+
\ No newline at end of file
diff --git a/article/why-isnt-godot-ecs-based-game-engine/index.html b/article/why-isnt-godot-ecs-based-game-engine/index.html
index 6ed2e83569..b5e6358336 100644
--- a/article/why-isnt-godot-ecs-based-game-engine/index.html
+++ b/article/why-isnt-godot-ecs-based-game-engine/index.html
@@ -5,7 +5,7 @@
Juan Linietsky26 February 2021
This article is from February 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.
About
The topic of why Godot does not utilize ECS comes up often, so this article will explain the design decisions behind that, as well as shed some light on how Godot works.
Note: In hopes to avoid misunderstandings, I did changes to the article to better stress that this is not an inheritance vs composition or anti-ECS article to spark a flame-war. It only explains the reasoning for which Godot went with its current architecture. I don’t believe there is an universally better way to do things, so if you prefer to use other approaches or architectures that work better for you, then that’s great. Read this if you are interested to understand the reasoning behind Godot’s architecture, not to understand if one approach is better over the other.
What is ECS?
ECS is a design pattern commonly used in video games (although not very often used in the rest of the software industry) which consists of having a base Entity (a container object) and Components that can be added upon it. Components provide data and the means to interact with the whole world. Finally, Systems work independently and do actions on every similar component.
This design became common in game engines and libraries in the early 2010s. The main appeal (besides architecture) is the fact that component data can be placed in contiguous memory, improving cache access. This is a common form of data-oriented optimization.
Architecturally wise, ECS aims to replace inheritance, by favouring composition, similar to how interfaces or multiple inheritance works in OOP. The key advantage in ECS is that components are dynamic (can be added or removed in run-time).
Why does Godot not use ECS?
Godot uses more traditional OOP by providing Nodes, that contain both data and logic. It also makes heavy use of inheritance. It still does composition, but at a higher level (the nodes you compose are generally higher level than components in traditional ECS).
As an example of the difference, in typical ECS, a Button entity can have components like:
Transform
Renderer
EventHandler
Button
Behavior
To make it simpler and avoid problems, some implementations force some components to exist when others are added.
In Godot, a Button has the full inheritance chain implicit:
Node -> CanvasItem -> Control -> Button -> Behavior Script
A more complex example can be a rigid body with a sprite attached, in typical ECS, this is found as an entity containing:
Transform
RigidBody
Collider
Sprite
In Godot, however, this is more complex. You need 3 nodes and hierarchy:
So, at first it seems that the approach in Godot is more wasteful, but is it really?
Node is lightweight, similar to a component.
Node2D contains the 2D transform, similar to Transform component in ECS. Three nodes are required whereas one component suffices in ECS. This seems wasteful, but is it really? In the entity, the collider and the sprite will most likely not be used centred and will still require offset and rotation properties, so in the end not much changes.
In Godot adding more of these (multiple sprites and colliders) is kind of free, the transform offset happens automatically. In ECS, special logic needs to exist to take care of this.
As can be seen, inheritance and composition can live together and make sense in the context of Godot.
The main difference can be summed up as:
Godot does composition at a higher level than in a traditional ECS.
This has two fundamental differences in both architecture and performance.
Architecture
Architecture wise, this leads to significant changes over how ECS works:
Inheritance is more explicit
As inheritance is preferred (for what would be implicit relationships between components in ECS), these relationships are now explicit in the inheritance chain.
This makes it very easy to understand (to Godot users) how the scene nodes are organized and what they can do, by just looking at the inheritance tree.
Scenes are more explicit
As composition happens at a higher level (nodes), it’s also very easy for Godot users to understand what a scene actually does by just looking at the scene tree:
Re-usability improves
Thanks to everything being nodes (and not entities with components) it becomes easier to reuse and combine everything as much as possible. This is why Godot does not have the concept or distinction between prefabs and scenes.
Additionally, by having higher level nodes, Godot does not have the concept of “scene settings”, as these is done with nodes too.
The result is a much greater ability to do composition than in a traditional ECS approach. What typically is:
Components -> Entity -> Prefab -> Scene -> World
Godot just has nodes, and a scene is simply a bunch of nodes forming a tree, which are saved in a file. Scenes can be instantiated and inherited with a higher flexibility than in most other tools.
Optimization
Leaving components aside, Godot has no differentiation between Data and System, choosing to bundle everything together in a more traditional OOP fashion. Nodes contain their own logic.
Architectural preference aside, this may seem like a problem on the optimization side. One of the biggest advantages of ECS is the Systems (data-oriented) part, which allows running through a lot of similar component’s data organized in linear memory. This brings huge performance improvements over the way Godot works with nodes.
The key point here is, again, to understand that scenes and nodes in Godot operate at a higher level than in a traditional ECS implementation.
This can be understood by examining the Engine and Game Logic parts separately:
Engine
Godot uses plenty of data-oriented optimizations for physics, rendering, audio, etc. They are, however, separate systems and completely isolated.
Most (if not all) technologies that utilize ECS do it at the core engine level, by serving as the base architecture and building everything else (physics, rendering, audio, etc.) over it.
Godot instead, those subsystems are all separate and isolated (and fit inside of Servers). I find this makes code simpler and easier to maintain and optimize (a testament to this is how tiny Godot’s codebase is compared to other game engines, while providing similar levels of functionality).
The scene system in Godot (nodes) is generally very high level when compared to a traditional ECS system. Most of what goes on happens via signal callbacks (as in, objects collided, something needs to be repainted, button was pressed, etc.). The situations where something needs to be processed every frame in Godot from the user side are very rare, as the engine will manage this internally, taking the complexity away from the user.
To put it simply, nodes are just interfaces to the actual data being processed inside servers, while in ECS the actual entities are what gets processed by the systems.
In other words, Godot as an engine tries to take the burden of processing away from the user, and instead places the focus on deciding what to do in case of an event. This ensures users have to optimize less in order to write a lot of the game code, and is part of the vision that Godot tries to convey on what should constitute an easy to use game engine.
Game logic
Still (while, by far, not the majority) some types of games will see a performance benefit when using ECS in the game logic side.
These are generally games that need to process game logic on dozens of thousands of objects, where data-oriented optimizations become a must, as the amount of pages moved into CPU cache increases by several orders of magnitude, severely affecting performance (and battery usage on mobile devices).
Again, I will stress the point that, while this use case is rare (in contrast, most games are generally just in the hundreds of objects at most, for which the memory access frequency is far more than good enough without cache optimizations), games that require cache optimizations are real and do exist.
Examples of these types of games are:
City builders (lots of things going on).
Sandboxes (lots of tiny things need processing every frame).
Some strategy games (while not the majority, some can use thousands or dozen of thousands of game units at the same time).
Other AAA games with lots of content going on.
So, does this mean these types of games can’t be made with Godot?
The answer is that, you can still do anything you want, but you need to do it in a different way.
Do clever optimizations
Before going head-on into brute performance, many times you can still rely on clever optimizations. Ever wondered how SimCity could run on a Commodore 64? It did so by alternating which tiles were processed every frame, so it never needed to process thousands of them at the same time (which would be impossible on a 6502 CPU).
Optimizations can vary from not processing everything in all frames, to giving more priority to processing whatever is visible (or close to the camera). Often, these optimizations will reduce the amount of objects that need to be processed by orders of magnitude, and still perform better than going full data-oriented.
Godot provides nodes such as VisibilityEnabler to aid you on this, and upcoming Godot 4.0 has more fine grained control on disabling sections of a scene tree.
Still, this may not be enough for your game, or too much of a hassle. In this case, you may need to simply skip the scene:
Using Servers directly
As mentioned before, Godot puts most of the high performance/low level parts of the engine in Servers. The APIs to servers are fully exposed in and allow you to control the whole engine at the very low level.
Most of the time, even using the servers from GDScript, C# or C++ via GDNative (or modules) is more than enough for the type of games mentioned above. While they might require high performance code for the core game loop, the logic is rarely so complex that a full-blown framework is required for it.
This is similar to just writing the game yourself in SDL/OpenGL, except the rest of the engine is still available for everything else that is not specialized game code (like UI, IO, saving, networking, etc. In other words, the remaining 90% of the game).
Using Compute
Compute (GPGPU) is nearly universal nowadays (supported on desktop and mobile) and allows for huge flexibility and performance optimizations. Godot 4.0 will include easy to use Compute support for highly parallel tasks.
Using ECS
Nothing prevents you to use an ECS solution in Godot. In fact, I strongly suggest to check Andrea Catania’s fantastic work on Godex, which aims to bring a high performance ECS pluggable implementation.
Future
For future versions of Godot we are evaluating (optionally for when you actually need it) cache friendly ways to process similar nodes, separating data and logic in a way similar to how ECS does Systems, but adapted to how Godot works. After all, these type of optimizations are not exclusive to ECS.
Summing up
While architectures and design patterns that aim to solve several problems at once are very tempting to programmers, Godot is developed with a very pragmatic approach.
While it is true that ECS brings advantages to the table, the cases where it can objectively prove to be a benefit towards Godot’s goals are very limited, so it is very hard (for us at least) to justify an architecture change, given they are the exception and not the common rule (and often optimization can be achieved by other, simpler means).
Godot has chosen the path of being user friendly and scalable above all, and we understand that for most cases, due to how the engine is designed, the cases where extreme game logic performance is needed are much lower (as the engine takes takes care of most of the heavy lifting). Still if this need arises, Godot is designed to give you answers on that front, and more options will keep coming over time.
-
+
\ No newline at end of file
diff --git a/article/why-we-broke-your-pr/index.html b/article/why-we-broke-your-pr/index.html
index b1ac9abbee..b7f90abbaf 100644
--- a/article/why-we-broke-your-pr/index.html
+++ b/article/why-we-broke-your-pr/index.html
@@ -17,7 +17,7 @@
The .write proxy will work for read-only access as well, however a copy may be made. From now on it would be better to have a quick think about whether or not the use of the variable you’re reading is constant or not. Particularly in loops. Look at line 220 of visual_server_canvas.cpp for instance. Using .write in this case would’ve worked but wouldn’t have actually saved a CoW operation.
I’d also like to ask all PR reviewers to please be mindful of the correct use of .write from now on.
-
+
\ No newline at end of file
diff --git a/article/will-your-contribution-be-merged-heres-how-tell/index.html b/article/will-your-contribution-be-merged-heres-how-tell/index.html
index 9eaff1d436..306de4fa3b 100644
--- a/article/will-your-contribution-be-merged-heres-how-tell/index.html
+++ b/article/will-your-contribution-be-merged-heres-how-tell/index.html
@@ -5,7 +5,7 @@
Juan Linietsky19 November 2018
This article is from November 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.
The pull request workflow is great, because it allows proposing changes to the codebase in a way where they can be evaluated, reviewed (with feedback) and eventually merged or rejected. Despite this, a large amount of pull requests (PRs) get rejected for reasons that are often unclear to new contributors.
To avoid unnecesary work, this short article has some suggestions on what is desired and what is not, and the general rules for accepting or rejecting pull requests.
Ask first
Ask about what you want to do, by either opening an issue, or asking in the Godot contributors chat platform. This will defintely save you time and effort, as other contributors will better guide you on whether your proposal is desired or not (or what needs to be changed so it would be).
We refuse by default
Contributions are considered rejected until proven useful. There are no hypotheticals here and we never accept something because it might be useful. Functionality is merged only when there is a valid and proven real-life use case for it. This means that someone (and especially more than one user) needs this new functionality for their actual projects, in order to save considerable amounts of time or just because it’s otherwise impossible to advance development without it.
Again, hypothetical use cases are ignored most of the time, whereas real projects being worked on (and their needs) take the priority.
This also means that it’s your resonsibility (or that of fellow interested users) to demonstrate the use cases and need for a specific feature. Discuss it beforehand as mentioned, and add some details in your pull request (or the affiliated issue) about what this proposal aims to solve. A never-discussed, no-comment PR with a terse “Add feature X” 500 LOC commit will likely produce a deep sigh among PR reviewers, more than anticipation for a potential great feature.
Bloat accumulates quickly
Please understand that we need to keep the engine size as small as possible. This ensures download on Steam, Mobile stores or HTML5 are as smooth as possible. Adding features that will not be used (or seldom used when then can be easily worked around) just adds more weight to the engine.
Even if a feature is small (say, a few kilobytes), we get several requests of them per week. If we were to accept/merge all of them as a general rule, Godot would grow several megabytes bigger over time.
And even if size was not a problem, more code means more difficulty for potential contributors and users to understand how the engine works, as well as more surface area for potential bugs.
We really do our best effort to keep it simple and small, help us with this!
General logic
The following diagram shows the logic steps used to evaluate pull requests. If you can ask yourself the same questions, everyone’s time will be saved.
This can seem a bit confusing at first, so let’s go over it question by question:
Do you need it?
Just adding a feature because it seems like it would be a cool addition does not cut it (feel free to ask first, of course). As mentioned before, we are only interested in real-life use cases. This needs to be for a project being worked on (or for types of projects that are not possible without this feature).
Does this feature cover a common use case?
Is this something you need to use often for your project? Will other users also find it often useful? If a feature covers a common use case and it’s needed very often, then it may be worth considering for addition.
Even if it’s not needed often but implementing it from the user’s side is difficult, then it may also be worth considering for addition.
This is why the following question is also important..
Can it be worked around with a few lines of code?
If you don’t need a feature that often (say, just a couple of times) and working it around can be easily done by writing a small amount of scripting code, then there is no merit in integrating this as a new feature. It’s better that this complexity goes on your side rather than ours.
Can you program C++?
It should be obvious from this article, but remember that, in a community-driven FOSS project like Godot, no one is obliged to do anything for anyone. If you can work on something yourself, feel free to do it and propose it. We will lend you a hand if you need!
-
+
\ No newline at end of file
diff --git a/article/winter-holiday-godot-game-jam/index.html b/article/winter-holiday-godot-game-jam/index.html
index 2aeb11c172..7b63966dc6 100644
--- a/article/winter-holiday-godot-game-jam/index.html
+++ b/article/winter-holiday-godot-game-jam/index.html
@@ -5,7 +5,7 @@
Juan Linietsky9 December 2014
This article is from December 2014, 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.
GamingPenguin from the forum is organizing a Winter Holidays Godot Game Jam! (Summer Holidays Game Jam for us in the southern hemisphere).
The rules seem to be (copied from the forum):
The game must be made with Godot
The game should have a Winter Holiday theme
You must enter using the entry thread here: (Coming Soon)
You must open source the full project, code and assets, Binaries for Windows, Mac and Linux are not required but would be very welcome
No Pornographic or offensive games
Games can be worked on by multiple people
One person can submit more than one game
This can be a nice chance to use or learn Godot for a little project and get to know the community better, as well as learning from the other projects.
The forum url is: http://www.godotengine.org/forum/viewtopic.php?f=7&t=1172
-
+
\ No newline at end of file
diff --git a/article/x11-display-server-progress-report/index.html b/article/x11-display-server-progress-report/index.html
index 2c0a2ee6fd..9c6ef0c99a 100644
--- a/article/x11-display-server-progress-report/index.html
+++ b/article/x11-display-server-progress-report/index.html
@@ -68,7 +68,7 @@
Because this protocol requires asynchronous communication to receive each chunk of data and send notifications for the next one, I’ve implemented it in a similar way as for SAVE_TARGETS, with a blocking call that handles all events or aborts in the case of timeout.
More details about INCR protocol in the X11 documentation here.
After completing this work package, most regressions related to X11 should be fixed now for Godot 4, even if there will still be some maintenance to do on all platforms before the release.
Xlib or XCB: While working on the X11 Display Server, I’ve chosen to focus on fixing specific issues in the current system with minimal refactoring, but using XCB to modernize the implementation is currently in discussion among contributors.
Wayland: Support for Wayland will be added to Godot in the future. It will be done as a separate Display Server implementation.
I hope this post put some light on the way Godot works under the hood in this specific area, for current and future contributors. See you around!
Credits illustration: Tux logo by rafael3334 (modified from source)
-
+
\ No newline at end of file
diff --git a/atom.xml b/atom.xml
index 78b4b365a2..d8e769390c 100644
--- a/atom.xml
+++ b/atom.xml
@@ -1 +1 @@
-Godot Engine Official2024-12-11T18:06:01+00:00https://godotengine.org/Meet the creator behind the Godot Game Awards2024-12-09T18:00:00+00:00https://godotengine.org/article/godot-game-awards-stayathomedev/StayAtHomeDev has been sharing his passion on YouTube for over two years and now he's running the awards.EmiDev snapshot: Godot 4.4 dev 62024-12-05T17:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-6/New snapshot on the road to beta, with a lot of 3D workflow goodies!Thaddeus CrewsBeyond #100000: You're breathtaking!2024-12-04T19:00:00+00:00https://godotengine.org/article/beyond-100000-you-re-breathtaking/As we reach issue #100,000 on GitHub, we celebrate with a little retrospective on our issue and pull request growth.Rémi VerscheldeGodot Foundation Update December 20242024-12-02T17:00:00+00:00https://godotengine.org/article/godot-foundation-update-dec-2024/We’ve made progress on several key initiatives for the organization and the Godot ecosystem. Here’s what we’ve been up to.Godot FoundationStatement on GodLoader malware loader2024-11-28T11:00:00+00:00https://godotengine.org/article/statement-on-godloader-malware-loader/Godot security team clarifies the risk exposed by Check Point Research's report.Godot Security TeamDev snapshot: Godot 4.4 dev 52024-11-21T18:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-5/With GodotCon behind us and our developers recuperated, we're thrilled to return to a more frequent release-cycle.Thaddeus CrewsGodotCon 24: Berlin Edition2024-11-13T18:30:00+00:00https://godotengine.org/article/review-godotcon24/Our biggest conference yet!NatDev snapshot: Godot 4.4 dev 42024-11-08T12:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-4/After a short delay due to GodotCon, we are back with another exciting update.Clay JohnDev snapshot: Godot 4.4 dev 32024-10-03T12:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-3/We haven't slowed down and are bringing you another feature-packed update!Clay JohnGodot XR update - October 20242024-10-02T12:00:00+00:00https://godotengine.org/article/godot-xr-update-oct-2024/Looking back at a year of XR development.Bastiaan OlijGodot SDK Integrations2024-09-24T14:30:00+00:00https://godotengine.org/article/godot-sdk-integrations/A new GitHub organization to centralize the community efforts to provide support for third-party SDKs for Godot.Godot FoundationGodot Rendering Priorities: September 20242024-09-23T15:45:00+00:00https://godotengine.org/article/rendering-priorities-september-2024/4.3 is out. It's time for an update!Clay JohnGodot Editor on the Meta Horizon Store2024-09-20T16:00:00+00:00https://godotengine.org/article/godot-editor-horizon-store-early-access-release/Introducing the Godot Editor for Meta Quest (Horizon OS) devicesFredia Huya-KouadioDev snapshot: Godot 4.4 dev 22024-09-10T16:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-2/The PR harvest keeps going strongly for Godot 4.4, with massive new features such as typed dictionaries and error-less project import!Rémi VerscheldeGodot 3.6 finally released!2024-09-09T11:00:00+00:00https://godotengine.org/article/godot-3-6-finally-released/After 2 years of development, Godot 3.6 is finally out and it comes fully packed with features and quality of life improvements! This includes 2D physics interpolation and hierarchical culling, and 3D mesh merging, level of detail, tighter shadow culling, ORM materials, and more.lawnjellySubmissions open for Godot 2024 showreel!2024-09-05T15:00:00+00:00https://godotengine.org/article/submissions-open-godot-2024-showreel/Showcase your Godot creations in 2024! We're inviting submissions of short videos featuring your published or in-progress Godot games or tools. Don't miss this chance to be a part of it!EmiAbout Official Console Ports2024-09-03T18:30:00+00:00https://godotengine.org/article/about-official-console-ports/With this post we aim to address the community’s questions about the lack of official console ports through the Godot Foundation.EmiMeeting the community at gamescom 20242024-09-02T18:30:00+00:00https://godotengine.org/article/review-gamescom-2024/Back from gamescom, ready to report.NatDev snapshot: Godot 4.4 dev 12024-08-26T13:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-1/The first snapshot after releasing 4.3, already packed with new features!Clay JohnGodot 4.3, a shared effort2024-08-15T11:00:00+00:00https://godotengine.org/article/godot-4-3-a-shared-effort/With over 3,500 commits authored by over 500 contributors, the latest Godot Engine release comes packed full of new features and improvements.Godot contributorsDesign of the Skeleton Modifier 3D2024-08-12T10:00:00+00:00https://godotengine.org/article/design-of-the-skeleton-modifier-3d/We have reworked the skeleton bone update process to add SkeletonModifier3D for modifying the Skeleton.Silc RenewRelease candidate: Godot 4.3 RC 32024-08-08T14:00:00+00:00https://godotengine.org/article/release-candidate-godot-4-3-rc-3/With all known major regressions fixed, we are now publishing a third release candidate to confirm that 4.3 is ready to go stable.Rémi VerscheldeGamescom here we come!2024-08-06T17:00:00+00:00https://godotengine.org/article/gamescom-2024/We are once again attending gamescom, and organizing two meet-up opportunities this time.NatIntroducing the improved ufbx importer in Godot 4.32024-08-02T20:36:00+00:00https://godotengine.org/article/introducing-the-improved-ufbx-importer-in-godot-4-3/Godot 4.3 now includes native .fbx supportLyuma
\ No newline at end of file
+Godot Engine Official2024-12-17T15:53:44+00:00https://godotengine.org/Meet the creator behind the Godot Game Awards2024-12-09T18:00:00+00:00https://godotengine.org/article/godot-game-awards-stayathomedev/StayAtHomeDev has been sharing his passion on YouTube for over two years and now he's running the awards.EmiDev snapshot: Godot 4.4 dev 62024-12-05T17:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-6/New snapshot on the road to beta, with a lot of 3D workflow goodies!Thaddeus CrewsBeyond #100000: You're breathtaking!2024-12-04T19:00:00+00:00https://godotengine.org/article/beyond-100000-you-re-breathtaking/As we reach issue #100,000 on GitHub, we celebrate with a little retrospective on our issue and pull request growth.Rémi VerscheldeGodot Foundation Update December 20242024-12-02T17:00:00+00:00https://godotengine.org/article/godot-foundation-update-dec-2024/We’ve made progress on several key initiatives for the organization and the Godot ecosystem. Here’s what we’ve been up to.Godot FoundationStatement on GodLoader malware loader2024-11-28T11:00:00+00:00https://godotengine.org/article/statement-on-godloader-malware-loader/Godot security team clarifies the risk exposed by Check Point Research's report.Godot Security TeamDev snapshot: Godot 4.4 dev 52024-11-21T18:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-5/With GodotCon behind us and our developers recuperated, we're thrilled to return to a more frequent release-cycle.Thaddeus CrewsGodotCon 24: Berlin Edition2024-11-13T18:30:00+00:00https://godotengine.org/article/review-godotcon24/Our biggest conference yet!NatDev snapshot: Godot 4.4 dev 42024-11-08T12:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-4/After a short delay due to GodotCon, we are back with another exciting update.Clay JohnDev snapshot: Godot 4.4 dev 32024-10-03T12:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-3/We haven't slowed down and are bringing you another feature-packed update!Clay JohnGodot XR update - October 20242024-10-02T12:00:00+00:00https://godotengine.org/article/godot-xr-update-oct-2024/Looking back at a year of XR development.Bastiaan OlijGodot SDK Integrations2024-09-24T14:30:00+00:00https://godotengine.org/article/godot-sdk-integrations/A new GitHub organization to centralize the community efforts to provide support for third-party SDKs for Godot.Godot FoundationGodot Rendering Priorities: September 20242024-09-23T15:45:00+00:00https://godotengine.org/article/rendering-priorities-september-2024/4.3 is out. It's time for an update!Clay JohnGodot Editor on the Meta Horizon Store2024-09-20T16:00:00+00:00https://godotengine.org/article/godot-editor-horizon-store-early-access-release/Introducing the Godot Editor for Meta Quest (Horizon OS) devicesFredia Huya-KouadioDev snapshot: Godot 4.4 dev 22024-09-10T16:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-2/The PR harvest keeps going strongly for Godot 4.4, with massive new features such as typed dictionaries and error-less project import!Rémi VerscheldeGodot 3.6 finally released!2024-09-09T11:00:00+00:00https://godotengine.org/article/godot-3-6-finally-released/After 2 years of development, Godot 3.6 is finally out and it comes fully packed with features and quality of life improvements! This includes 2D physics interpolation and hierarchical culling, and 3D mesh merging, level of detail, tighter shadow culling, ORM materials, and more.lawnjellySubmissions open for Godot 2024 showreel!2024-09-05T15:00:00+00:00https://godotengine.org/article/submissions-open-godot-2024-showreel/Showcase your Godot creations in 2024! We're inviting submissions of short videos featuring your published or in-progress Godot games or tools. Don't miss this chance to be a part of it!EmiAbout Official Console Ports2024-09-03T18:30:00+00:00https://godotengine.org/article/about-official-console-ports/With this post we aim to address the community’s questions about the lack of official console ports through the Godot Foundation.EmiMeeting the community at gamescom 20242024-09-02T18:30:00+00:00https://godotengine.org/article/review-gamescom-2024/Back from gamescom, ready to report.NatDev snapshot: Godot 4.4 dev 12024-08-26T13:00:00+00:00https://godotengine.org/article/dev-snapshot-godot-4-4-dev-1/The first snapshot after releasing 4.3, already packed with new features!Clay JohnGodot 4.3, a shared effort2024-08-15T11:00:00+00:00https://godotengine.org/article/godot-4-3-a-shared-effort/With over 3,500 commits authored by over 500 contributors, the latest Godot Engine release comes packed full of new features and improvements.Godot contributorsDesign of the Skeleton Modifier 3D2024-08-12T10:00:00+00:00https://godotengine.org/article/design-of-the-skeleton-modifier-3d/We have reworked the skeleton bone update process to add SkeletonModifier3D for modifying the Skeleton.Silc RenewRelease candidate: Godot 4.3 RC 32024-08-08T14:00:00+00:00https://godotengine.org/article/release-candidate-godot-4-3-rc-3/With all known major regressions fixed, we are now publishing a third release candidate to confirm that 4.3 is ready to go stable.Rémi VerscheldeGamescom here we come!2024-08-06T17:00:00+00:00https://godotengine.org/article/gamescom-2024/We are once again attending gamescom, and organizing two meet-up opportunities this time.NatIntroducing the improved ufbx importer in Godot 4.32024-08-02T20:36:00+00:00https://godotengine.org/article/introducing-the-improved-ufbx-importer-in-godot-4-3/Godot 4.3 now includes native .fbx supportLyuma
\ No newline at end of file
diff --git a/blog/10/index.html b/blog/10/index.html
index e2025c3833..67c331687f 100644
--- a/blog/10/index.html
+++ b/blog/10/index.html
@@ -63,7 +63,7 @@
101112
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/11/index.html b/blog/11/index.html
index 4ee103e817..4ad10ebc60 100644
--- a/blog/11/index.html
+++ b/blog/11/index.html
@@ -63,7 +63,7 @@
111213
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/12/index.html b/blog/12/index.html
index c34cd2705d..2b294ffcde 100644
--- a/blog/12/index.html
+++ b/blog/12/index.html
@@ -63,7 +63,7 @@
121314
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/13/index.html b/blog/13/index.html
index c89871c85a..b85250c880 100644
--- a/blog/13/index.html
+++ b/blog/13/index.html
@@ -63,7 +63,7 @@
131415
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/14/index.html b/blog/14/index.html
index b3bd3ba3fd..66bf860c99 100644
--- a/blog/14/index.html
+++ b/blog/14/index.html
@@ -63,7 +63,7 @@
141516
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/15/index.html b/blog/15/index.html
index df6576e55e..6b7a79fad0 100644
--- a/blog/15/index.html
+++ b/blog/15/index.html
@@ -63,7 +63,7 @@
151617
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/16/index.html b/blog/16/index.html
index ff95f1a40b..5d5ff22ff1 100644
--- a/blog/16/index.html
+++ b/blog/16/index.html
@@ -64,7 +64,7 @@
161718
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/17/index.html b/blog/17/index.html
index ad41b361ae..cb3662412a 100644
--- a/blog/17/index.html
+++ b/blog/17/index.html
@@ -63,7 +63,7 @@
171819
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/18/index.html b/blog/18/index.html
index 800c7e9658..91c49890f1 100644
--- a/blog/18/index.html
+++ b/blog/18/index.html
@@ -63,7 +63,7 @@
181920
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/19/index.html b/blog/19/index.html
index 2ddc6e5bde..f3261a7f26 100644
--- a/blog/19/index.html
+++ b/blog/19/index.html
@@ -63,7 +63,7 @@
192021
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/2/index.html b/blog/2/index.html
index 305643e03b..dd6f845785 100644
--- a/blog/2/index.html
+++ b/blog/2/index.html
@@ -63,7 +63,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/20/index.html b/blog/20/index.html
index 32c2b7ee08..ad2f8fc0ce 100644
--- a/blog/20/index.html
+++ b/blog/20/index.html
@@ -63,7 +63,7 @@
202122
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/21/index.html b/blog/21/index.html
index 6f659c7228..75859cc8a6 100644
--- a/blog/21/index.html
+++ b/blog/21/index.html
@@ -63,7 +63,7 @@
212223
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/22/index.html b/blog/22/index.html
index 6f5f2d85b2..573effc0f0 100644
--- a/blog/22/index.html
+++ b/blog/22/index.html
@@ -64,7 +64,7 @@
222324
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/23/index.html b/blog/23/index.html
index bb3ac21c2d..b5f437ddad 100644
--- a/blog/23/index.html
+++ b/blog/23/index.html
@@ -66,7 +66,7 @@
232425
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/24/index.html b/blog/24/index.html
index a6f002d94a..b655e74f62 100644
--- a/blog/24/index.html
+++ b/blog/24/index.html
@@ -68,7 +68,7 @@
242526
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/25/index.html b/blog/25/index.html
index e1c9731b2b..765406418b 100644
--- a/blog/25/index.html
+++ b/blog/25/index.html
@@ -63,7 +63,7 @@
252627
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/26/index.html b/blog/26/index.html
index 6b5f1d5ad6..e4cce6af31 100644
--- a/blog/26/index.html
+++ b/blog/26/index.html
@@ -64,7 +64,7 @@
262728
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/27/index.html b/blog/27/index.html
index dd57a24cc7..00f2afa164 100644
--- a/blog/27/index.html
+++ b/blog/27/index.html
@@ -63,7 +63,7 @@
272829
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/28/index.html b/blog/28/index.html
index a8cecf1da0..f765cdf1ee 100644
--- a/blog/28/index.html
+++ b/blog/28/index.html
@@ -63,7 +63,7 @@
272829
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/29/index.html b/blog/29/index.html
index 2a776f04e8..794e84ebbb 100644
--- a/blog/29/index.html
+++ b/blog/29/index.html
@@ -18,7 +18,7 @@
262728
-29
+29
\ No newline at end of file
diff --git a/blog/3/index.html b/blog/3/index.html
index 7ec63241da..2356db02b4 100644
--- a/blog/3/index.html
+++ b/blog/3/index.html
@@ -63,7 +63,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/4/index.html b/blog/4/index.html
index 633e013af5..ad5704e1e3 100644
--- a/blog/4/index.html
+++ b/blog/4/index.html
@@ -63,7 +63,7 @@
456
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/5/index.html b/blog/5/index.html
index cce1b5d71a..41b06e6e91 100644
--- a/blog/5/index.html
+++ b/blog/5/index.html
@@ -63,7 +63,7 @@
567
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/6/index.html b/blog/6/index.html
index 068f744b03..6f481c86bd 100644
--- a/blog/6/index.html
+++ b/blog/6/index.html
@@ -63,7 +63,7 @@
678
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/7/index.html b/blog/7/index.html
index fbd8cdf811..3aefc54a31 100644
--- a/blog/7/index.html
+++ b/blog/7/index.html
@@ -63,7 +63,7 @@
789
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/8/index.html b/blog/8/index.html
index 303d85a049..8fad0dbf8d 100644
--- a/blog/8/index.html
+++ b/blog/8/index.html
@@ -63,7 +63,7 @@
8910
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/9/index.html b/blog/9/index.html
index 2c769dd23f..ee19beebe2 100644
--- a/blog/9/index.html
+++ b/blog/9/index.html
@@ -63,7 +63,7 @@
91011
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/events/2/index.html b/blog/events/2/index.html
index 1ae613ad44..14b0b0858a 100644
--- a/blog/events/2/index.html
+++ b/blog/events/2/index.html
@@ -60,7 +60,7 @@
123
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/events/3/index.html b/blog/events/3/index.html
index a282e334cb..523c4033e2 100644
--- a/blog/events/3/index.html
+++ b/blog/events/3/index.html
@@ -52,7 +52,7 @@
- 9 December 2014
Winter holiday Godot game jam!
GamingPenguin from the forum is organizing a Winter Holidays Godot Game Jam! (Summer Holidays Game Jam for us in the southern hemisphere).
+3
\ No newline at end of file
diff --git a/blog/events/index.html b/blog/events/index.html
index bba6c112d7..70a24f3263 100644
--- a/blog/events/index.html
+++ b/blog/events/index.html
@@ -57,7 +57,7 @@
- 21 January 2021
Online GodotCon 2021: Schedule
Online GodotCon 2021 is right around the corner, streaming on Saturday, January 23rd from 8:45 am UTC! Join us on the YouTube Premiere to watch the conference at the same time as all other Godot users in the world, and use our new open source chat platform to discuss about talks or Godot in general with attendees and speakers.
+Next →
\ No newline at end of file
diff --git a/blog/index.html b/blog/index.html
index 5483cadcc4..bb68eab835 100644
--- a/blog/index.html
+++ b/blog/index.html
@@ -61,7 +61,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/news/2/index.html b/blog/news/2/index.html
index f908b47fb5..8b4fbe2bb3 100644
--- a/blog/news/2/index.html
+++ b/blog/news/2/index.html
@@ -63,7 +63,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/news/3/index.html b/blog/news/3/index.html
index 365734accd..b57b86b203 100644
--- a/blog/news/3/index.html
+++ b/blog/news/3/index.html
@@ -63,7 +63,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/news/4/index.html b/blog/news/4/index.html
index 4139b960ad..289c9e64df 100644
--- a/blog/news/4/index.html
+++ b/blog/news/4/index.html
@@ -67,7 +67,7 @@
456
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/news/5/index.html b/blog/news/5/index.html
index 8e041692e0..f02dcfb191 100644
--- a/blog/news/5/index.html
+++ b/blog/news/5/index.html
@@ -63,7 +63,7 @@
456
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/news/6/index.html b/blog/news/6/index.html
index 645ebcd6fb..82c79a6885 100644
--- a/blog/news/6/index.html
+++ b/blog/news/6/index.html
@@ -31,7 +31,7 @@
345
-6
+6
\ No newline at end of file
diff --git a/blog/news/index.html b/blog/news/index.html
index 4cdde2eb1f..84e4e55dd5 100644
--- a/blog/news/index.html
+++ b/blog/news/index.html
@@ -61,7 +61,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/10/index.html b/blog/pre-release/10/index.html
index 57e069df2b..24b524462a 100644
--- a/blog/pre-release/10/index.html
+++ b/blog/pre-release/10/index.html
@@ -51,7 +51,7 @@
789
-10
+10
\ No newline at end of file
diff --git a/blog/pre-release/2/index.html b/blog/pre-release/2/index.html
index 25cfa40c41..ea8a29a40a 100644
--- a/blog/pre-release/2/index.html
+++ b/blog/pre-release/2/index.html
@@ -63,7 +63,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/3/index.html b/blog/pre-release/3/index.html
index ba509c9aec..6d4e9d398f 100644
--- a/blog/pre-release/3/index.html
+++ b/blog/pre-release/3/index.html
@@ -63,7 +63,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/4/index.html b/blog/pre-release/4/index.html
index babb3ed51c..309874a4de 100644
--- a/blog/pre-release/4/index.html
+++ b/blog/pre-release/4/index.html
@@ -63,7 +63,7 @@
456
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/5/index.html b/blog/pre-release/5/index.html
index 53e4f42ca9..59c99b72b3 100644
--- a/blog/pre-release/5/index.html
+++ b/blog/pre-release/5/index.html
@@ -63,7 +63,7 @@
567
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/6/index.html b/blog/pre-release/6/index.html
index 573fe46fc8..94ad2432f4 100644
--- a/blog/pre-release/6/index.html
+++ b/blog/pre-release/6/index.html
@@ -63,7 +63,7 @@
678
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/7/index.html b/blog/pre-release/7/index.html
index eb6d99d6c2..4f1364ac50 100644
--- a/blog/pre-release/7/index.html
+++ b/blog/pre-release/7/index.html
@@ -64,7 +64,7 @@
789
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/8/index.html b/blog/pre-release/8/index.html
index 3a9ef18905..8d1de63ce5 100644
--- a/blog/pre-release/8/index.html
+++ b/blog/pre-release/8/index.html
@@ -63,7 +63,7 @@
8910
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/9/index.html b/blog/pre-release/9/index.html
index 258db7d57b..187831d145 100644
--- a/blog/pre-release/9/index.html
+++ b/blog/pre-release/9/index.html
@@ -63,7 +63,7 @@
8910
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/pre-release/index.html b/blog/pre-release/index.html
index ec7b690c50..e139a2641f 100644
--- a/blog/pre-release/index.html
+++ b/blog/pre-release/index.html
@@ -61,7 +61,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/progress-report/2/index.html b/blog/progress-report/2/index.html
index 0bb0c08d0e..9fe6c1d43b 100644
--- a/blog/progress-report/2/index.html
+++ b/blog/progress-report/2/index.html
@@ -63,7 +63,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/progress-report/3/index.html b/blog/progress-report/3/index.html
index 4af64fb127..f3b69e6a82 100644
--- a/blog/progress-report/3/index.html
+++ b/blog/progress-report/3/index.html
@@ -63,7 +63,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/progress-report/4/index.html b/blog/progress-report/4/index.html
index 4728779e61..f11c4571ff 100644
--- a/blog/progress-report/4/index.html
+++ b/blog/progress-report/4/index.html
@@ -63,7 +63,7 @@
456
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/progress-report/5/index.html b/blog/progress-report/5/index.html
index 873e4f6986..8fee663b66 100644
--- a/blog/progress-report/5/index.html
+++ b/blog/progress-report/5/index.html
@@ -63,7 +63,7 @@
567
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/progress-report/6/index.html b/blog/progress-report/6/index.html
index 36367a32e7..45856d77bb 100644
--- a/blog/progress-report/6/index.html
+++ b/blog/progress-report/6/index.html
@@ -65,7 +65,7 @@
567
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/progress-report/7/index.html b/blog/progress-report/7/index.html
index df39cd5b72..f42e54536e 100644
--- a/blog/progress-report/7/index.html
+++ b/blog/progress-report/7/index.html
@@ -58,7 +58,7 @@
456
-7
+7
\ No newline at end of file
diff --git a/blog/progress-report/index.html b/blog/progress-report/index.html
index 6734b31f46..f20980427d 100644
--- a/blog/progress-report/index.html
+++ b/blog/progress-report/index.html
@@ -61,7 +61,7 @@
345
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/release/2/index.html b/blog/release/2/index.html
index b6e838661e..7ec1f5524c 100644
--- a/blog/release/2/index.html
+++ b/blog/release/2/index.html
@@ -60,7 +60,7 @@
123
-Next →
+Next →
\ No newline at end of file
diff --git a/blog/release/3/index.html b/blog/release/3/index.html
index e9fa92d1c0..749d2446ba 100644
--- a/blog/release/3/index.html
+++ b/blog/release/3/index.html
@@ -32,7 +32,7 @@
Because of this we are opening the engine to the community so anyone can develop games using Godot and benefit from it’s amazing workflow design. We are also opening the source code with the most generous license, MIT with the hope that other developers will contribute to it and publish their games without any restriction.
+3
\ No newline at end of file
diff --git a/blog/release/index.html b/blog/release/index.html
index 4f97695194..2252244d19 100644
--- a/blog/release/index.html
+++ b/blog/release/index.html
@@ -57,7 +57,7 @@
- 17 December 2021
Maintenance release: Godot 3.4.1
Godot 3.4.1 is the first maintenance release in the 3.4 stable branch, fixing a number of issues (including some 3.4 regressions) while preserving compatibility with 3.4-stable. Alongside general bugfixing, it improves Godot's compatibility with Windows 11's new Windows Terminal, which prevented starting the Godot editor from the project manager.
+Next →
\ No newline at end of file
diff --git a/blog/showcase/index.html b/blog/showcase/index.html
index 7b820fa9d7..2395bde5d5 100644
--- a/blog/showcase/index.html
+++ b/blog/showcase/index.html
@@ -39,7 +39,7 @@
Juan Linietsky - 16 April 2019
Announcing the Godot 2019 showreel
Another year, another showreel. As every year, the amount of quality games being created by Godot has increased significantly (as did the amount of submissions).
Are you proud of your game and would you like us to showcase it in Godot's 2019 showreel? Please send us a short video (10-15 secs) for us to include it!
\ No newline at end of file
diff --git a/code-of-conduct/index.html b/code-of-conduct/index.html
index ca750d9fc3..99e36fb98e 100644
--- a/code-of-conduct/index.html
+++ b/code-of-conduct/index.html
@@ -35,7 +35,7 @@
acceptable.
Reporting a breach
If you witness or are involved in an interaction with another community member that you think may violate this Code
of Conduct, please contact Godot's Code of Conduct team.
The Godot team recognizes that it can be difficult to come forward in cases of a violation of the Code of Conduct.
To make it easier to report violations, we provide a single point of contact via email at: conduct@godotengine.org. If you are more comfortable reaching out to a
-single person, you are also welcome to contact one or more members of the team using their personal emails listed below, or via direct messaging on community platforms where they are present.
Code of Conduct team
HP van Braam, hp@godotengine.org (they/them)
GitHub: hpvb – Contributors Chat: hp
Languages: English, Dutch
Julian Murgia, julian@godotengine.org (he/him)
GitHub / Contributors Chat: StraToN
Languages: English, French
Nat, nat@godotengine.org (she/they)
GitHub / Contributors Chat: MurderVeggie
Languages: English, German
Rémi Verschelde, remi@godotengine.org (he/him)
GitHub: akien-mga – Contributors Chat: Akien
Languages: English, French, German
+single person, you are also welcome to contact one or more members of the team using their personal emails listed below, or via direct messaging on community platforms where they are present.
Code of Conduct team
HP van Braam, hp@godotengine.org (they/them)
GitHub: hpvb – Contributors Chat: hp
Languages: English, Dutch
Julian Murgia, julian@godotengine.org (he/him)
GitHub / Contributors Chat: StraToN
Languages: English, French
Nat, nat@godotengine.org (she/they)
GitHub / Contributors Chat: MurderVeggie
Languages: English, German
Rémi Verschelde, remi@godotengine.org (he/him)
GitHub: akien-mga – Contributors Chat: Akien
Languages: English, French, German
\ No newline at end of file
diff --git a/community/index.html b/community/index.html
index 0980b25211..73c86d878b 100644
--- a/community/index.html
+++ b/community/index.html
@@ -1,6 +1,6 @@
Community – Godot Engine
Send bug reports here. To request features, use the Godot proposals repository instead.
\ No newline at end of file
diff --git a/community/user-groups/index.html b/community/user-groups/index.html
index 53f407a692..3eb8a0e40c 100644
--- a/community/user-groups/index.html
+++ b/community/user-groups/index.html
@@ -72,7 +72,7 @@
(Discord)
If you run a local community and would like to have it listed here,
-please send an email to webmaster at godotengine · org.
+please send an email to webmaster at godotengine · org.
\ No newline at end of file
diff --git a/contact/index.html b/contact/index.html
index ca6a0a18ba..514e605f15 100644
--- a/contact/index.html
+++ b/contact/index.html
@@ -23,7 +23,7 @@
must be directed to its administrators, not to us:
Godot Community Forum Contact
General inquiries
For other inquiries such as business, education, non-profit, promotion, etc.
Contact contact@godotengine.org.
Godot Engine team
The Godot Engine team is made of hundreds of developers around the world,
-with both regular and occasional contributors.
Project Founders:
Juan Linietsky (reduz)
Ariel Manzur (punto-)
Lead Developer:
Juan Linietsky (reduz)
Project Manager:
Rémi Verschelde (akien-mga)
Developers:
Aaron Franke (aaronfranke)
Aaron Record (LightningAA)
Adam Scott (adamscott)
Alexander Holland (AlexHolly)
Alex Drozd (brno32)
Alexey Khoroshavin (allkhor)
Alfred Reinold Baudisch (alfredbaudisch)
Alistair Leslie-Hughes (alesliehughes)
Alket Rexhepi (alketii)
Andrea Catania (AndreaCatania)
Andreia Gaita (shana)
Andrii Doroshenko (Xrayez)
Andy Maloney (asmaloney)
Andy Moss (MillionOstrich)
Angad Kambli (angad-k)
Anilforextra (AnilBK)
Anish Bhobe (KidRigger)
Anton Yabchinskiy (a12n)
Anutrix
Aren Villanueva (kurikaesu)
Ariel Manzur (punto-)
Arman Elgudzhyan (puchik)
AThousandShips
aXu-AP
Bartłomiej T. Listwon (Listwon)
Bastiaan Olij (BastiaanOlij)
Ben Brookshire (sheepandshepherd)
Benjamin Larsson (Nallebeorn)
Bernhard Liebl (poke1024)
Bhuvan Vemula (Bhu1-V)
bitsawer
BlueCube3310
Błażej Szczygieł (zaps166)
Bojidar Marinov (bojidar-bg)
Brian Semrau (briansemrau)
Bruno Lourenço (MadEqua)
Cameron Reikes (creikey)
Camille Mohr-Daurat (pouleyKetchoupp)
Caner Demirer (cdemirer)
Carl Olsson (not-surt)
Carter Anderson (cart)
ChibiDenDen
Chris Bradfield (cbscribe)
Clay John (clayjohn)
ConteZero
Dana Olson (adolson)
Daniel J. Ramirez (djrm)
Daniel Rakos (aqnuep)
Daniel Zilberleyb (dzil123)
Danil Alexeev (dalexeev)
dankan1890
Darío Banini (DarioSamo)
David Cambré (Gallilus)
David Sichma (DavidSichma)
David Snopek (dsnopek)
Dharkael (lupoDharkael)
Dmitry Koteroff (Krakean)
Dmitry Maganov (vonagam)
Dominik Jasiński (dreamsComeTrue)
Douglas Leão (DeeJayLSP)
DualMatrix
Ellen Poe (ellenhp)
Emmanuel Barroga (codecustard)
Emmanuel Leblond (touilleMan)
Eoin O'Neill (Eoin-ONeill-Yokai)
Eric Lasota (elasota)
Eric M (EricEzaM)
Eric Rybicki (ericrybick)
Erik Selecký (rxlecky)
est31
Eveline Jarosz (Marqin)
Fabian Mathews (supagu)
Fabio Alessandrelli (Faless)
Fabrice Cipolla (fabriceci)
Ferenc Arn (tagcup)
FireForge (fire-forge)
Florian Kothmeier (Dragoncraft89)
follower
foxydevloper
François Belair (Razoric480)
Franklin Sobrinho (TheHX)
Fredia Huya-Kouadio (m4gr3d)
Geequlim
George Marques (vnen)
Gerrit Großkopf (Grosskopf)
Gilles Roudiere (groud)
Gordon MacPherson (RevoluPowered)
Guilherme Felipe de C. G. da Silva (guilhermefelipecgs)
Hakim Rouatbi (hakro)
Hanif Bin Ariffin (hbina)
Haoyu Qiu (timothyqiu)
HP van Braam (hpvb)
Hendrik Brucker (Geometror)
hilfazer
Hiroshi Ogawa (hi-ogawa)
HolonProduction
homer666
hoontee
Hugo Locurcio (Calinou)
Ian Bishop (ianb96)
Ibrahn Sahir (ibrahn)
Ignacio Etcheverry (neikeq)
Igor Kordiukiewicz (IgorKordiukiewicz)
Ilaria Cislaghi (QbieShay)
Indah Sylvia (ISylvox)
J08nY
Jake Young (Duroxxigar)
Jakub Grzesik (kubecz3k)
Jakub Marcowski (Chubercik)
James Buck (jbuck3)
Jan Haller (Bromeon)
Jason Knight (jasonwinterpixel)
Jean-Michel Bernard (jmb462)
Jérôme Gully (Nutriz)
Jia Jun Chai (SkyLucilfer)
jitspoe
Joan Fons Sanchez (JFonS)
Johan Manuel (29jm)
Johannes Witt (HaSa1002)
Jonathan Nicholl (jtnicholl)
Jordan Schidlowsky (winterpixelgames)
Josh Jones (DarkKilauea)
Joshua Grams (JoshuaGrams)
Juan Linietsky (reduz)
Julian Murgia (StraToN)
Julien Nguyen (Blackiris)
Jummit
Justo Delgado (mrcdk)
karroffel
Kelly Thomas (KellyThomas)
kleonc
Kongfa Waroros (gongpha)
Kostadin Damyanov (Max-Might)
K. S. Ernest (iFire) Lee (fire)
lawnjelly
Leon Krause (leonkrause)
Liz Haas (27thLiz)
Lucien Menassol (Kanabenki)
Lyuma
Maganty Rushyendra (mrushyendra)
Malcolm Nixon (Malcolmnixon)
Manuele Finocchiaro (m4nu3lf)
Marcel Admiraal (madmiraal)
Marcelo Fernandez (marcelofg55)
Marc Gilleron (Zylann)
Marcin Zawiejski (dragmz)
Marcus Brummer (mbrlabs)
Marcus Elg (MCrafterzz)
Mariano Javier Suligoy (MarianoGnu)
Mario Schlack (hurikhan)
Marios Staikopoulos (marstaik)
Marius Hanl (Maran23)
Mark Riedesel (klowner)
Markus Sauermann (Sauermann)
Martin Capitanio (capnm)
Martin Liška (marxin)
Martin Sjursen (binbitten)
marynate
Masoud BH (masoudbh3)
Mateo Kuruk Miccino (kuruk-mm)
Matias N. Goldberg (darksylinc)
Matthew (skyace65)
Matthias Hölzl (hoelzl)
Max Hilbrunner (mhilbrunner)
merumelu
Meru Patel (Janglee123)
MewPurPur
Michael Alexsander (YeldhamDev)
Michał Iwańczuk (iwek7)
MichiRecRoom (LikeLakers2)
Micky (Mickeon)
Mikael Hermansson (mihe)
MinusKube
MJacred
Morris "Tabor" Arroad (mortarroad)
mrezai
Muhammad Huri (CakHuri)
muiroc
myaaaaaaaaa
Nathan Franke (nathanfranke)
Nathan Lovato (NathanLovato)
Nathan Warden (NathanWarden)
Nicholas Huelin (SirQuartz)
Nikita Lita (nikitalita)
Nils André-Chang (NilsIrl)
Noah Beard (TwistedTwigleg)
Nông Văn Tình (nongvantinh)
Nuno Donato (nunodonato)
ocean (they/them) (anvilfolk)
Omar El Sheikh (The-O-King)
Ovnuniarchos
Pascal Richter (ShyRed)
passivestar
Patrick Dawson (pkdawson)
Patrick Exner (FlameLizard)
Patrick (firefly2442)
Paul Batty (Paulb23)
Paul Joannon (paulloz)
Paul Trojahn (ptrojahn)
Pāvels Nadtočajevs (bruvzg)
Paweł Fertyk (pfertyk)
Pawel Kowal (pkowal1982)
Pawel Lampe (Scony)
Pedro J. Estébanez (RandomShaper)
Pieter-Jan Briers (PJB3005)
Poommetee Ketson (Noshyaar)
Przemysław Gołąb (n-pigeon)
Rafael M. G. (rafallus)
Raffaele Picca (RPicster)
Rafał Mikrut (qarmin)
Ralf Hölzemer (rollenrolm)
Ramesh Ravone (RameshRavone)
Raphael2048
Raul Santos (raulsntos)
Ray Koopa (RayKoopa)
RedMser
RedworkDE
Rémi Verschelde (akien-mga)
Rhody Lugo (rraallvv)
Ricardo Buring (rburing)
Ricardo Subtil (Ev1lbl0w)
Riteo Siuga (Riteo)
Roberto F. Arroyo (robfram)
Robert Yevdokimov (ryevdokimov)
Robin Hübner (profan)
romulox-x
Rune Smith (rune-scape)
Ruslan Mustakov (endragor)
Ryan Roden-Corrent (rrcore)
Saniko (sanikoyes)
santouits
SaracenOne
Septian Ganendra S. K. (sepTN)
Sergey Minakov (naithar)
sersoong
Shiqing (kawa-yoiko)
Silc 'Tokage' Renew (TokageItLab)
Simon Wenner (swenner)
smix8
snailrhymer
Sofox (TheSofox)
Stanislav Labzyuk (DarkMessiah)
Stijn Hinlopen (hinlopen)
stmSi
Swarnim Arun (minraws)
TC (floppyhammer)
TechnoPorg
Thaddeus Crews (Repiteo)
Thakee Nathees (ThakeeNathees)
thebestnom
Theo Hallenius (TheoXD)
Timo Schwarzer (timoschwarzer)
Timothé Bonhoure (ajreckof)
Timo (toger5)
Tomasz Chabora (KoBeWi)
trollodel
Twarit Waikar (IronicallySerious)
Umang Kalra (theoway)
Vinzenz Feenstra (vinzenz)
Vitika Soni (Vitika9)
박한얼 (volzhs)
V. Vamsi Krishna (vkbsb)
Wilhem Barbier (nounoursheureux)
William Deurwaarder (williamd67)
Will Nations (willnationsdev)
Wilson E. Alvarez (Rubonnek)
Xavier Cho (mysticfall)
Yaohua Xiong (xiongyaohua)
yg2f (SuperUserNameMan)
Yordan Dolchinkov (Jordyfel)
Yuri Rubinsky (Chaosus)
Yuri Sizov (YuriSizov)
Zae Chao (zaevi)
Zak Stam (zaksnet)
Zher Huei Lee (leezh)
Zi Ye (MajorMcDoom)
ZuBsPaCe
谢天 (jsjtxietian)
风青山 (Rindbee)
+with both regular and occasional contributors.
Project Founders:
Juan Linietsky (reduz)
Ariel Manzur (punto-)
Lead Developer:
Juan Linietsky (reduz)
Project Manager:
Rémi Verschelde (akien-mga)
Developers:
Aaron Franke (aaronfranke)
Aaron Record (LightningAA)
Adam Scott (adamscott)
Alexander Holland (AlexHolly)
Alex Drozd (brno32)
Alexey Khoroshavin (allkhor)
Alfred Reinold Baudisch (alfredbaudisch)
Alistair Leslie-Hughes (alesliehughes)
Alket Rexhepi (alketii)
Andrea Catania (AndreaCatania)
Andreia Gaita (shana)
Andrii Doroshenko (Xrayez)
Andy Maloney (asmaloney)
Andy Moss (MillionOstrich)
Angad Kambli (angad-k)
Anilforextra (AnilBK)
Anish Bhobe (KidRigger)
Anton Yabchinskiy (a12n)
Anutrix
Aren Villanueva (kurikaesu)
Ariel Manzur (punto-)
Arman Elgudzhyan (puchik)
AThousandShips
aXu-AP
Bartłomiej T. Listwon (Listwon)
Bastiaan Olij (BastiaanOlij)
Ben Brookshire (sheepandshepherd)
Benjamin Larsson (Nallebeorn)
Bernhard Liebl (poke1024)
Bhuvan Vemula (Bhu1-V)
bitsawer
BlueCube3310
Błażej Szczygieł (zaps166)
Bojidar Marinov (bojidar-bg)
Brian Semrau (briansemrau)
Bruno Lourenço (MadEqua)
Cameron Reikes (creikey)
Camille Mohr-Daurat (pouleyKetchoupp)
Caner Demirer (cdemirer)
Carl Olsson (not-surt)
Carter Anderson (cart)
ChibiDenDen
Chris Bradfield (cbscribe)
Clay John (clayjohn)
ConteZero
Dana Olson (adolson)
Daniel J. Ramirez (djrm)
Daniel Rakos (aqnuep)
Daniel Zilberleyb (dzil123)
Danil Alexeev (dalexeev)
dankan1890
Darío Banini (DarioSamo)
David Cambré (Gallilus)
David Sichma (DavidSichma)
David Snopek (dsnopek)
Dharkael (lupoDharkael)
Dmitry Koteroff (Krakean)
Dmitry Maganov (vonagam)
Dominik Jasiński (dreamsComeTrue)
Douglas Leão (DeeJayLSP)
DualMatrix
Ellen Poe (ellenhp)
Emmanuel Barroga (codecustard)
Emmanuel Leblond (touilleMan)
Eoin O'Neill (Eoin-ONeill-Yokai)
Eric Lasota (elasota)
Eric M (EricEzaM)
Eric Rybicki (ericrybick)
Erik Selecký (rxlecky)
est31
Eveline Jarosz (Marqin)
Fabian Mathews (supagu)
Fabio Alessandrelli (Faless)
Fabrice Cipolla (fabriceci)
Ferenc Arn (tagcup)
FireForge (fire-forge)
Florian Kothmeier (Dragoncraft89)
follower
foxydevloper
François Belair (Razoric480)
Franklin Sobrinho (TheHX)
Fredia Huya-Kouadio (m4gr3d)
Geequlim
George Marques (vnen)
Gerrit Großkopf (Grosskopf)
Gilles Roudiere (groud)
Gordon MacPherson (RevoluPowered)
Guilherme Felipe de C. G. da Silva (guilhermefelipecgs)
Hakim Rouatbi (hakro)
Hanif Bin Ariffin (hbina)
Haoyu Qiu (timothyqiu)
HP van Braam (hpvb)
Hendrik Brucker (Geometror)
hilfazer
Hiroshi Ogawa (hi-ogawa)
HolonProduction
homer666
hoontee
Hugo Locurcio (Calinou)
Ian Bishop (ianb96)
Ibrahn Sahir (ibrahn)
Ignacio Etcheverry (neikeq)
Igor Kordiukiewicz (IgorKordiukiewicz)
Ilaria Cislaghi (QbieShay)
Indah Sylvia (ISylvox)
J08nY
Jake Young (Duroxxigar)
Jakub Grzesik (kubecz3k)
Jakub Marcowski (Chubercik)
James Buck (jbuck3)
Jan Haller (Bromeon)
Jason Knight (jasonwinterpixel)
Jean-Michel Bernard (jmb462)
Jérôme Gully (Nutriz)
Jia Jun Chai (SkyLucilfer)
jitspoe
Joan Fons Sanchez (JFonS)
Johan Manuel (29jm)
Johannes Witt (HaSa1002)
Jonathan Nicholl (jtnicholl)
Jordan Schidlowsky (winterpixelgames)
Josh Jones (DarkKilauea)
Joshua Grams (JoshuaGrams)
Juan Linietsky (reduz)
Julian Murgia (StraToN)
Julien Nguyen (Blackiris)
Jummit
Justo Delgado (mrcdk)
karroffel
Kelly Thomas (KellyThomas)
kleonc
Kongfa Waroros (gongpha)
Kostadin Damyanov (Max-Might)
K. S. Ernest (iFire) Lee (fire)
lawnjelly
Leon Krause (leonkrause)
Liz Haas (27thLiz)
Lucien Menassol (Kanabenki)
Lyuma
Maganty Rushyendra (mrushyendra)
Malcolm Nixon (Malcolmnixon)
Manuele Finocchiaro (m4nu3lf)
Marcel Admiraal (madmiraal)
Marcelo Fernandez (marcelofg55)
Marc Gilleron (Zylann)
Marcin Zawiejski (dragmz)
Marcus Brummer (mbrlabs)
Marcus Elg (MCrafterzz)
Mariano Javier Suligoy (MarianoGnu)
Mario Schlack (hurikhan)
Marios Staikopoulos (marstaik)
Marius Hanl (Maran23)
Mark Riedesel (klowner)
Markus Sauermann (Sauermann)
Martin Capitanio (capnm)
Martin Liška (marxin)
Martin Sjursen (binbitten)
marynate
Masoud BH (masoudbh3)
Mateo Kuruk Miccino (kuruk-mm)
Matias N. Goldberg (darksylinc)
Matthew (skyace65)
Matthias Hölzl (hoelzl)
Max Hilbrunner (mhilbrunner)
merumelu
Meru Patel (Janglee123)
MewPurPur
Michael Alexsander (YeldhamDev)
Michał Iwańczuk (iwek7)
MichiRecRoom (LikeLakers2)
Micky (Mickeon)
Mikael Hermansson (mihe)
MinusKube
MJacred
Morris "Tabor" Arroad (mortarroad)
mrezai
Muhammad Huri (CakHuri)
muiroc
myaaaaaaaaa
Nathan Franke (nathanfranke)
Nathan Lovato (NathanLovato)
Nathan Warden (NathanWarden)
Nicholas Huelin (SirQuartz)
Nikita Lita (nikitalita)
Nils André-Chang (NilsIrl)
Noah Beard (TwistedTwigleg)
Nông Văn Tình (nongvantinh)
Nuno Donato (nunodonato)
ocean (they/them) (anvilfolk)
Omar El Sheikh (The-O-King)
Ovnuniarchos
Pascal Richter (ShyRed)
passivestar
Patrick Dawson (pkdawson)
Patrick Exner (FlameLizard)
Patrick (firefly2442)
Paul Batty (Paulb23)
Paul Joannon (paulloz)
Paul Trojahn (ptrojahn)
Pāvels Nadtočajevs (bruvzg)
Paweł Fertyk (pfertyk)
Pawel Kowal (pkowal1982)
Pawel Lampe (Scony)
Pedro J. Estébanez (RandomShaper)
Pieter-Jan Briers (PJB3005)
Poommetee Ketson (Noshyaar)
Przemysław Gołąb (n-pigeon)
Rafael M. G. (rafallus)
Raffaele Picca (RPicster)
Rafał Mikrut (qarmin)
Ralf Hölzemer (rollenrolm)
Ramesh Ravone (RameshRavone)
Raphael2048
Raul Santos (raulsntos)
Ray Koopa (RayKoopa)
RedMser
RedworkDE
Rémi Verschelde (akien-mga)
Rhody Lugo (rraallvv)
Ricardo Buring (rburing)
Ricardo Subtil (Ev1lbl0w)
Riteo Siuga (Riteo)
Roberto F. Arroyo (robfram)
Robert Yevdokimov (ryevdokimov)
Robin Hübner (profan)
romulox-x
Rune Smith (rune-scape)
Ruslan Mustakov (endragor)
Ryan Roden-Corrent (rrcore)
Saniko (sanikoyes)
santouits
SaracenOne
Septian Ganendra S. K. (sepTN)
Sergey Minakov (naithar)
sersoong
Shiqing (kawa-yoiko)
Silc 'Tokage' Renew (TokageItLab)
Simon Wenner (swenner)
smix8
snailrhymer
Sofox (TheSofox)
Stanislav Labzyuk (DarkMessiah)
Stijn Hinlopen (hinlopen)
stmSi
Swarnim Arun (minraws)
TC (floppyhammer)
TechnoPorg
Thaddeus Crews (Repiteo)
Thakee Nathees (ThakeeNathees)
thebestnom
Theo Hallenius (TheoXD)
Timo Schwarzer (timoschwarzer)
Timothé Bonhoure (ajreckof)
Timo (toger5)
Tomasz Chabora (KoBeWi)
trollodel
Twarit Waikar (IronicallySerious)
Umang Kalra (theoway)
Vinzenz Feenstra (vinzenz)
Vitika Soni (Vitika9)
박한얼 (volzhs)
V. Vamsi Krishna (vkbsb)
Wilhem Barbier (nounoursheureux)
William Deurwaarder (williamd67)
Will Nations (willnationsdev)
Wilson E. Alvarez (Rubonnek)
Xavier Cho (mysticfall)
Yaohua Xiong (xiongyaohua)
yg2f (SuperUserNameMan)
Yordan Dolchinkov (Jordyfel)
Yuri Rubinsky (Chaosus)
Yuri Sizov (YuriSizov)
Zae Chao (zaevi)
Zak Stam (zaksnet)
Zher Huei Lee (leezh)
Zi Ye (MajorMcDoom)
ZuBsPaCe
谢天 (jsjtxietian)
风青山 (Rindbee)
\ No newline at end of file
diff --git a/donate/index.html b/donate/index.html
index d565fcc6cd..7cde75a201 100644
--- a/donate/index.html
+++ b/donate/index.html
@@ -15,7 +15,7 @@
-
Donate now!
\ No newline at end of file
diff --git a/download/3.x/android/index.html b/download/3.x/android/index.html
index db9b1fc994..710c10f106 100644
--- a/download/3.x/android/index.html
+++ b/download/3.x/android/index.html
@@ -30,7 +30,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/download/3.x/linux/index.html b/download/3.x/linux/index.html
index f3fdb07f13..5e12a4878d 100644
--- a/download/3.x/linux/index.html
+++ b/download/3.x/linux/index.html
@@ -39,7 +39,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/download/3.x/macos/index.html b/download/3.x/macos/index.html
index 4036a85773..27b514897e 100644
--- a/download/3.x/macos/index.html
+++ b/download/3.x/macos/index.html
@@ -34,7 +34,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/download/3.x/server/index.html b/download/3.x/server/index.html
index 176313c39a..0c3044d6dc 100644
--- a/download/3.x/server/index.html
+++ b/download/3.x/server/index.html
@@ -39,7 +39,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/download/3.x/windows/index.html b/download/3.x/windows/index.html
index 2e9dd9704a..f64c0061a4 100644
--- a/download/3.x/windows/index.html
+++ b/download/3.x/windows/index.html
@@ -40,7 +40,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/download/android/index.html b/download/android/index.html
index 568550860d..f12c9ffebd 100644
--- a/download/android/index.html
+++ b/download/android/index.html
@@ -28,7 +28,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/download/archive/1.0-stable/index.html b/download/archive/1.0-stable/index.html
index bb902f02ba..0167c14854 100644
--- a/download/archive/1.0-stable/index.html
+++ b/download/archive/1.0-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/1.1-stable/index.html b/download/archive/1.1-stable/index.html
index 9eabd3f2b1..6943dd36ed 100644
--- a/download/archive/1.1-stable/index.html
+++ b/download/archive/1.1-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.0-stable/index.html b/download/archive/2.0-stable/index.html
index d63d89ce84..e0726cc804 100644
--- a/download/archive/2.0-stable/index.html
+++ b/download/archive/2.0-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.0.1-stable/index.html b/download/archive/2.0.1-stable/index.html
index 34e19d75aa..72cc4e430e 100644
--- a/download/archive/2.0.1-stable/index.html
+++ b/download/archive/2.0.1-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.0.2-stable/index.html b/download/archive/2.0.2-stable/index.html
index 4447ca3f96..9e97da6873 100644
--- a/download/archive/2.0.2-stable/index.html
+++ b/download/archive/2.0.2-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.0.3-stable/index.html b/download/archive/2.0.3-stable/index.html
index 95eb9ede43..ad0fa72d55 100644
--- a/download/archive/2.0.3-stable/index.html
+++ b/download/archive/2.0.3-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.0.4-stable/index.html b/download/archive/2.0.4-stable/index.html
index b8034825cd..e13dd95ba0 100644
--- a/download/archive/2.0.4-stable/index.html
+++ b/download/archive/2.0.4-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.0.4.1-stable/index.html b/download/archive/2.0.4.1-stable/index.html
index 183bf9191a..20685b551b 100644
--- a/download/archive/2.0.4.1-stable/index.html
+++ b/download/archive/2.0.4.1-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.1-stable/index.html b/download/archive/2.1-stable/index.html
index d51ac4e837..554bc3a18d 100644
--- a/download/archive/2.1-stable/index.html
+++ b/download/archive/2.1-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.1.1-stable/index.html b/download/archive/2.1.1-stable/index.html
index 7990ec00e7..ea91d34095 100644
--- a/download/archive/2.1.1-stable/index.html
+++ b/download/archive/2.1.1-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.1.2-stable/index.html b/download/archive/2.1.2-stable/index.html
index a4e3cfc04e..c5f07ab872 100644
--- a/download/archive/2.1.2-stable/index.html
+++ b/download/archive/2.1.2-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.1.3-stable/index.html b/download/archive/2.1.3-stable/index.html
index 2fd5187805..329fd100f9 100644
--- a/download/archive/2.1.3-stable/index.html
+++ b/download/archive/2.1.3-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.1.4-stable/index.html b/download/archive/2.1.4-stable/index.html
index 6b47f99663..9b80e8a99c 100644
--- a/download/archive/2.1.4-stable/index.html
+++ b/download/archive/2.1.4-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.1.5-stable/index.html b/download/archive/2.1.5-stable/index.html
index c693b7c039..60d87816e5 100644
--- a/download/archive/2.1.5-stable/index.html
+++ b/download/archive/2.1.5-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.1.6-rc1/index.html b/download/archive/2.1.6-rc1/index.html
index eefefe00a5..9c1e784f99 100644
--- a/download/archive/2.1.6-rc1/index.html
+++ b/download/archive/2.1.6-rc1/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/2.1.6-stable/index.html b/download/archive/2.1.6-stable/index.html
index dcbca9e95a..7175394593 100644
--- a/download/archive/2.1.6-stable/index.html
+++ b/download/archive/2.1.6-stable/index.html
@@ -19,7 +19,7 @@
x86_32
Export templates
-Used to export your games to all supported platforms
+Used to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/archive/3.0-alpha1/index.html b/download/archive/3.0-alpha1/index.html
index b92890d1df..17a9964684 100644
--- a/download/archive/3.0-alpha1/index.html
+++ b/download/archive/3.0-alpha1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0-alpha2/index.html b/download/archive/3.0-alpha2/index.html
index a0f3acc530..e9002710b0 100644
--- a/download/archive/3.0-alpha2/index.html
+++ b/download/archive/3.0-alpha2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0-beta1/index.html b/download/archive/3.0-beta1/index.html
index 7f1ae8f7e7..79f3c4312d 100644
--- a/download/archive/3.0-beta1/index.html
+++ b/download/archive/3.0-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0-beta2/index.html b/download/archive/3.0-beta2/index.html
index e765807032..e947aa8b62 100644
--- a/download/archive/3.0-beta2/index.html
+++ b/download/archive/3.0-beta2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0-rc1/index.html b/download/archive/3.0-rc1/index.html
index 4de087b781..5b7a8b1ae6 100644
--- a/download/archive/3.0-rc1/index.html
+++ b/download/archive/3.0-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0-rc2/index.html b/download/archive/3.0-rc2/index.html
index 5755d87262..8700e671ed 100644
--- a/download/archive/3.0-rc2/index.html
+++ b/download/archive/3.0-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0-rc3/index.html b/download/archive/3.0-rc3/index.html
index d0008e5d31..d9a1d41631 100644
--- a/download/archive/3.0-rc3/index.html
+++ b/download/archive/3.0-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0-stable/index.html b/download/archive/3.0-stable/index.html
index aa11d8fadf..543a25ad96 100644
--- a/download/archive/3.0-stable/index.html
+++ b/download/archive/3.0-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.1-rc1/index.html b/download/archive/3.0.1-rc1/index.html
index 474cfd22e1..5ae2e1cb8d 100644
--- a/download/archive/3.0.1-rc1/index.html
+++ b/download/archive/3.0.1-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.1-stable/index.html b/download/archive/3.0.1-stable/index.html
index cf15cc4733..ff3de774fa 100644
--- a/download/archive/3.0.1-stable/index.html
+++ b/download/archive/3.0.1-stable/index.html
@@ -44,7 +44,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.2-stable/index.html b/download/archive/3.0.2-stable/index.html
index cabfb64244..bfebf09b0a 100644
--- a/download/archive/3.0.2-stable/index.html
+++ b/download/archive/3.0.2-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.3-rc1/index.html b/download/archive/3.0.3-rc1/index.html
index 25c70b1a52..a0efd9a86f 100644
--- a/download/archive/3.0.3-rc1/index.html
+++ b/download/archive/3.0.3-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.3-rc2/index.html b/download/archive/3.0.3-rc2/index.html
index 9de2955ef6..5904d4c6d0 100644
--- a/download/archive/3.0.3-rc2/index.html
+++ b/download/archive/3.0.3-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.3-rc3/index.html b/download/archive/3.0.3-rc3/index.html
index 23b136e56f..5846799718 100644
--- a/download/archive/3.0.3-rc3/index.html
+++ b/download/archive/3.0.3-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.3-stable/index.html b/download/archive/3.0.3-stable/index.html
index 4a25eb9422..bdc20cc34f 100644
--- a/download/archive/3.0.3-stable/index.html
+++ b/download/archive/3.0.3-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.4-stable/index.html b/download/archive/3.0.4-stable/index.html
index 97b42d5820..e6e6b02b4a 100644
--- a/download/archive/3.0.4-stable/index.html
+++ b/download/archive/3.0.4-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.5-stable/index.html b/download/archive/3.0.5-stable/index.html
index 754ec00f75..03732cd698 100644
--- a/download/archive/3.0.5-stable/index.html
+++ b/download/archive/3.0.5-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.0.6-stable/index.html b/download/archive/3.0.6-stable/index.html
index f5dea51120..bc94402404 100644
--- a/download/archive/3.0.6-stable/index.html
+++ b/download/archive/3.0.6-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-alpha1/index.html b/download/archive/3.1-alpha1/index.html
index e93581b0b1..27dcc985a5 100644
--- a/download/archive/3.1-alpha1/index.html
+++ b/download/archive/3.1-alpha1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-alpha2/index.html b/download/archive/3.1-alpha2/index.html
index b3523bda04..784d28b41d 100644
--- a/download/archive/3.1-alpha2/index.html
+++ b/download/archive/3.1-alpha2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-alpha3/index.html b/download/archive/3.1-alpha3/index.html
index d38397e267..f2dd127bea 100644
--- a/download/archive/3.1-alpha3/index.html
+++ b/download/archive/3.1-alpha3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-alpha4/index.html b/download/archive/3.1-alpha4/index.html
index 2529b36b24..e5a46d26e4 100644
--- a/download/archive/3.1-alpha4/index.html
+++ b/download/archive/3.1-alpha4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-alpha5/index.html b/download/archive/3.1-alpha5/index.html
index ec4f1c866b..92874c22f5 100644
--- a/download/archive/3.1-alpha5/index.html
+++ b/download/archive/3.1-alpha5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta1/index.html b/download/archive/3.1-beta1/index.html
index 71bbfb6172..2bc8818378 100644
--- a/download/archive/3.1-beta1/index.html
+++ b/download/archive/3.1-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta10/index.html b/download/archive/3.1-beta10/index.html
index bbed2b1227..356ade080b 100644
--- a/download/archive/3.1-beta10/index.html
+++ b/download/archive/3.1-beta10/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta11/index.html b/download/archive/3.1-beta11/index.html
index 82469d57c4..50c8ddc963 100644
--- a/download/archive/3.1-beta11/index.html
+++ b/download/archive/3.1-beta11/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta2/index.html b/download/archive/3.1-beta2/index.html
index b27944fdf8..17e84fe772 100644
--- a/download/archive/3.1-beta2/index.html
+++ b/download/archive/3.1-beta2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta3/index.html b/download/archive/3.1-beta3/index.html
index 452db97db1..f364d34b5e 100644
--- a/download/archive/3.1-beta3/index.html
+++ b/download/archive/3.1-beta3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta4/index.html b/download/archive/3.1-beta4/index.html
index 489c8fed77..d1483f3c63 100644
--- a/download/archive/3.1-beta4/index.html
+++ b/download/archive/3.1-beta4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta5/index.html b/download/archive/3.1-beta5/index.html
index 3b9cfa19d7..2718690ef8 100644
--- a/download/archive/3.1-beta5/index.html
+++ b/download/archive/3.1-beta5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta6/index.html b/download/archive/3.1-beta6/index.html
index 1811519db8..896131dc60 100644
--- a/download/archive/3.1-beta6/index.html
+++ b/download/archive/3.1-beta6/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta7/index.html b/download/archive/3.1-beta7/index.html
index 8e7c337487..fdee624685 100644
--- a/download/archive/3.1-beta7/index.html
+++ b/download/archive/3.1-beta7/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta8/index.html b/download/archive/3.1-beta8/index.html
index b72e095f0e..199605335f 100644
--- a/download/archive/3.1-beta8/index.html
+++ b/download/archive/3.1-beta8/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-beta9/index.html b/download/archive/3.1-beta9/index.html
index 4937e564c5..ca7823af6b 100644
--- a/download/archive/3.1-beta9/index.html
+++ b/download/archive/3.1-beta9/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-rc1/index.html b/download/archive/3.1-rc1/index.html
index 464f79a73a..a90990b42a 100644
--- a/download/archive/3.1-rc1/index.html
+++ b/download/archive/3.1-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-rc2/index.html b/download/archive/3.1-rc2/index.html
index d5d829cf11..32906a5ada 100644
--- a/download/archive/3.1-rc2/index.html
+++ b/download/archive/3.1-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-rc3/index.html b/download/archive/3.1-rc3/index.html
index 57d026b40d..30c2306dc4 100644
--- a/download/archive/3.1-rc3/index.html
+++ b/download/archive/3.1-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1-stable/index.html b/download/archive/3.1-stable/index.html
index e1a1092d40..891e73ec63 100644
--- a/download/archive/3.1-stable/index.html
+++ b/download/archive/3.1-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1.1-rc1/index.html b/download/archive/3.1.1-rc1/index.html
index d68f289616..248dd6f5cf 100644
--- a/download/archive/3.1.1-rc1/index.html
+++ b/download/archive/3.1.1-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1.1-stable/index.html b/download/archive/3.1.1-stable/index.html
index be6166bbd0..22123efc66 100644
--- a/download/archive/3.1.1-stable/index.html
+++ b/download/archive/3.1.1-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1.2-rc1/index.html b/download/archive/3.1.2-rc1/index.html
index 6be965ec4e..85a59fdba0 100644
--- a/download/archive/3.1.2-rc1/index.html
+++ b/download/archive/3.1.2-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.1.2-stable/index.html b/download/archive/3.1.2-stable/index.html
index e0769f6fba..b3148413fa 100644
--- a/download/archive/3.1.2-stable/index.html
+++ b/download/archive/3.1.2-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-alpha0-unofficial/index.html b/download/archive/3.2-alpha0-unofficial/index.html
index 034d64a58a..14968d177d 100644
--- a/download/archive/3.2-alpha0-unofficial/index.html
+++ b/download/archive/3.2-alpha0-unofficial/index.html
@@ -42,7 +42,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-alpha1/index.html b/download/archive/3.2-alpha1/index.html
index bae465237e..95a89be5b3 100644
--- a/download/archive/3.2-alpha1/index.html
+++ b/download/archive/3.2-alpha1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-alpha2/index.html b/download/archive/3.2-alpha2/index.html
index 1130fdb779..eee4e1db83 100644
--- a/download/archive/3.2-alpha2/index.html
+++ b/download/archive/3.2-alpha2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-alpha3/index.html b/download/archive/3.2-alpha3/index.html
index 70ad63ea12..b723865927 100644
--- a/download/archive/3.2-alpha3/index.html
+++ b/download/archive/3.2-alpha3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-beta1/index.html b/download/archive/3.2-beta1/index.html
index aeadfeee8a..132e19fe9f 100644
--- a/download/archive/3.2-beta1/index.html
+++ b/download/archive/3.2-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-beta2/index.html b/download/archive/3.2-beta2/index.html
index d812cebe03..4abafef0fe 100644
--- a/download/archive/3.2-beta2/index.html
+++ b/download/archive/3.2-beta2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-beta3/index.html b/download/archive/3.2-beta3/index.html
index 088da44d08..7398f180e5 100644
--- a/download/archive/3.2-beta3/index.html
+++ b/download/archive/3.2-beta3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-beta4/index.html b/download/archive/3.2-beta4/index.html
index 5e39279464..0eba8d64c0 100644
--- a/download/archive/3.2-beta4/index.html
+++ b/download/archive/3.2-beta4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-beta5/index.html b/download/archive/3.2-beta5/index.html
index e7712d14ed..019bcd0c55 100644
--- a/download/archive/3.2-beta5/index.html
+++ b/download/archive/3.2-beta5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-beta6/index.html b/download/archive/3.2-beta6/index.html
index 8438ce2177..c97655956f 100644
--- a/download/archive/3.2-beta6/index.html
+++ b/download/archive/3.2-beta6/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-rc1/index.html b/download/archive/3.2-rc1/index.html
index 522016598b..b5d92fa546 100644
--- a/download/archive/3.2-rc1/index.html
+++ b/download/archive/3.2-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-rc2/index.html b/download/archive/3.2-rc2/index.html
index 56f9203157..49db007c00 100644
--- a/download/archive/3.2-rc2/index.html
+++ b/download/archive/3.2-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-rc3/index.html b/download/archive/3.2-rc3/index.html
index 6ae4d30251..f657fd7e2c 100644
--- a/download/archive/3.2-rc3/index.html
+++ b/download/archive/3.2-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-rc4/index.html b/download/archive/3.2-rc4/index.html
index de9387dc31..e2699f37aa 100644
--- a/download/archive/3.2-rc4/index.html
+++ b/download/archive/3.2-rc4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2-stable/index.html b/download/archive/3.2-stable/index.html
index ad7014d477..3464cf29b0 100644
--- a/download/archive/3.2-stable/index.html
+++ b/download/archive/3.2-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.1-rc1/index.html b/download/archive/3.2.1-rc1/index.html
index 158d5d5f82..f88563e10d 100644
--- a/download/archive/3.2.1-rc1/index.html
+++ b/download/archive/3.2.1-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.1-rc2/index.html b/download/archive/3.2.1-rc2/index.html
index 4278c9ae77..ccb7c65164 100644
--- a/download/archive/3.2.1-rc2/index.html
+++ b/download/archive/3.2.1-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.1-stable/index.html b/download/archive/3.2.1-stable/index.html
index d8228928b0..435835be60 100644
--- a/download/archive/3.2.1-stable/index.html
+++ b/download/archive/3.2.1-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-beta1/index.html b/download/archive/3.2.2-beta1/index.html
index 94df407f00..2773f18e80 100644
--- a/download/archive/3.2.2-beta1/index.html
+++ b/download/archive/3.2.2-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-beta2/index.html b/download/archive/3.2.2-beta2/index.html
index 3dd0fb8e20..fc7388889a 100644
--- a/download/archive/3.2.2-beta2/index.html
+++ b/download/archive/3.2.2-beta2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-beta3/index.html b/download/archive/3.2.2-beta3/index.html
index d4b947435d..3dcc294200 100644
--- a/download/archive/3.2.2-beta3/index.html
+++ b/download/archive/3.2.2-beta3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-beta4/index.html b/download/archive/3.2.2-beta4/index.html
index 48a01635b3..1ae2a104dc 100644
--- a/download/archive/3.2.2-beta4/index.html
+++ b/download/archive/3.2.2-beta4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-rc1/index.html b/download/archive/3.2.2-rc1/index.html
index 50c922ba5f..3e37768dbd 100644
--- a/download/archive/3.2.2-rc1/index.html
+++ b/download/archive/3.2.2-rc1/index.html
@@ -44,7 +44,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-rc2/index.html b/download/archive/3.2.2-rc2/index.html
index 795fce0216..261bc37c2c 100644
--- a/download/archive/3.2.2-rc2/index.html
+++ b/download/archive/3.2.2-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-rc3/index.html b/download/archive/3.2.2-rc3/index.html
index 6a1b126c74..591dd5abdb 100644
--- a/download/archive/3.2.2-rc3/index.html
+++ b/download/archive/3.2.2-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-rc4/index.html b/download/archive/3.2.2-rc4/index.html
index cd139a672c..6d1bdd4252 100644
--- a/download/archive/3.2.2-rc4/index.html
+++ b/download/archive/3.2.2-rc4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.2-stable/index.html b/download/archive/3.2.2-stable/index.html
index c362b42988..976412f8b9 100644
--- a/download/archive/3.2.2-stable/index.html
+++ b/download/archive/3.2.2-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.3-beta1/index.html b/download/archive/3.2.3-beta1/index.html
index bc87fbd0b9..4d1f5c70c4 100644
--- a/download/archive/3.2.3-beta1/index.html
+++ b/download/archive/3.2.3-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.3-rc1/index.html b/download/archive/3.2.3-rc1/index.html
index 8f61c6fcfb..bd53e72026 100644
--- a/download/archive/3.2.3-rc1/index.html
+++ b/download/archive/3.2.3-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.3-rc2/index.html b/download/archive/3.2.3-rc2/index.html
index 222dca08f9..c2fe206170 100644
--- a/download/archive/3.2.3-rc2/index.html
+++ b/download/archive/3.2.3-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.3-rc3/index.html b/download/archive/3.2.3-rc3/index.html
index eb63c75f4c..997ba5f728 100644
--- a/download/archive/3.2.3-rc3/index.html
+++ b/download/archive/3.2.3-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.3-rc4/index.html b/download/archive/3.2.3-rc4/index.html
index 84dc349986..77575621de 100644
--- a/download/archive/3.2.3-rc4/index.html
+++ b/download/archive/3.2.3-rc4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.3-rc5/index.html b/download/archive/3.2.3-rc5/index.html
index 33aec73231..d12b10d3fb 100644
--- a/download/archive/3.2.3-rc5/index.html
+++ b/download/archive/3.2.3-rc5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.3-rc6/index.html b/download/archive/3.2.3-rc6/index.html
index 4fd90d3222..f1733a96af 100644
--- a/download/archive/3.2.3-rc6/index.html
+++ b/download/archive/3.2.3-rc6/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.2.3-stable/index.html b/download/archive/3.2.3-stable/index.html
index 2e0d5b8584..4143f862f7 100644
--- a/download/archive/3.2.3-stable/index.html
+++ b/download/archive/3.2.3-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-beta1/index.html b/download/archive/3.3-beta1/index.html
index 5e6cf78336..37d01c842f 100644
--- a/download/archive/3.3-beta1/index.html
+++ b/download/archive/3.3-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-beta2/index.html b/download/archive/3.3-beta2/index.html
index 2864ae32e2..f4ac147c0d 100644
--- a/download/archive/3.3-beta2/index.html
+++ b/download/archive/3.3-beta2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-beta3/index.html b/download/archive/3.3-beta3/index.html
index 17e430554a..000ede5fbb 100644
--- a/download/archive/3.3-beta3/index.html
+++ b/download/archive/3.3-beta3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-beta4/index.html b/download/archive/3.3-beta4/index.html
index e892f49e8f..1d9b343378 100644
--- a/download/archive/3.3-beta4/index.html
+++ b/download/archive/3.3-beta4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-beta5/index.html b/download/archive/3.3-beta5/index.html
index 723b791570..c5500a90a8 100644
--- a/download/archive/3.3-beta5/index.html
+++ b/download/archive/3.3-beta5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-beta6/index.html b/download/archive/3.3-beta6/index.html
index 348c45add1..c45dad73c7 100644
--- a/download/archive/3.3-beta6/index.html
+++ b/download/archive/3.3-beta6/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc1/index.html b/download/archive/3.3-rc1/index.html
index fc840a76d4..774e40a45e 100644
--- a/download/archive/3.3-rc1/index.html
+++ b/download/archive/3.3-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc2/index.html b/download/archive/3.3-rc2/index.html
index 0c0bab3bee..1d8a67240a 100644
--- a/download/archive/3.3-rc2/index.html
+++ b/download/archive/3.3-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc3/index.html b/download/archive/3.3-rc3/index.html
index 480c8e28b5..36b9f52b19 100644
--- a/download/archive/3.3-rc3/index.html
+++ b/download/archive/3.3-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc4/index.html b/download/archive/3.3-rc4/index.html
index c2dbb6a739..a2412bc233 100644
--- a/download/archive/3.3-rc4/index.html
+++ b/download/archive/3.3-rc4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc5/index.html b/download/archive/3.3-rc5/index.html
index 5dd14c8bd0..e9ebd1d318 100644
--- a/download/archive/3.3-rc5/index.html
+++ b/download/archive/3.3-rc5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc6/index.html b/download/archive/3.3-rc6/index.html
index 62dbca4404..57afb98186 100644
--- a/download/archive/3.3-rc6/index.html
+++ b/download/archive/3.3-rc6/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc7/index.html b/download/archive/3.3-rc7/index.html
index 1b8b09c672..7b4e9a19d2 100644
--- a/download/archive/3.3-rc7/index.html
+++ b/download/archive/3.3-rc7/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc8/index.html b/download/archive/3.3-rc8/index.html
index f4b1677f13..e3f09e1092 100644
--- a/download/archive/3.3-rc8/index.html
+++ b/download/archive/3.3-rc8/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-rc9/index.html b/download/archive/3.3-rc9/index.html
index a284d39c9e..ba9fe3820b 100644
--- a/download/archive/3.3-rc9/index.html
+++ b/download/archive/3.3-rc9/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3-stable/index.html b/download/archive/3.3-stable/index.html
index ee6495fc79..cfe6e06672 100644
--- a/download/archive/3.3-stable/index.html
+++ b/download/archive/3.3-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.1-rc1/index.html b/download/archive/3.3.1-rc1/index.html
index fd09ac93e8..7a03411866 100644
--- a/download/archive/3.3.1-rc1/index.html
+++ b/download/archive/3.3.1-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.1-rc2/index.html b/download/archive/3.3.1-rc2/index.html
index f829edfa32..72f00b4aff 100644
--- a/download/archive/3.3.1-rc2/index.html
+++ b/download/archive/3.3.1-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.1-stable/index.html b/download/archive/3.3.1-stable/index.html
index 00e7d7f645..3243010283 100644
--- a/download/archive/3.3.1-stable/index.html
+++ b/download/archive/3.3.1-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.2-stable/index.html b/download/archive/3.3.2-stable/index.html
index 5694c47b81..569ae022af 100644
--- a/download/archive/3.3.2-stable/index.html
+++ b/download/archive/3.3.2-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.3-rc1/index.html b/download/archive/3.3.3-rc1/index.html
index a9b06d127b..a88aec3616 100644
--- a/download/archive/3.3.3-rc1/index.html
+++ b/download/archive/3.3.3-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.3-rc2/index.html b/download/archive/3.3.3-rc2/index.html
index bcfc82a9d9..ee3a5bbe5e 100644
--- a/download/archive/3.3.3-rc2/index.html
+++ b/download/archive/3.3.3-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.3-stable/index.html b/download/archive/3.3.3-stable/index.html
index a42febb044..15eefcef14 100644
--- a/download/archive/3.3.3-stable/index.html
+++ b/download/archive/3.3.3-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.4-rc1/index.html b/download/archive/3.3.4-rc1/index.html
index c5a661aef9..22ad746c75 100644
--- a/download/archive/3.3.4-rc1/index.html
+++ b/download/archive/3.3.4-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.3.4-stable/index.html b/download/archive/3.3.4-stable/index.html
index b668f08a3b..92e2439532 100644
--- a/download/archive/3.3.4-stable/index.html
+++ b/download/archive/3.3.4-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-beta1/index.html b/download/archive/3.4-beta1/index.html
index ab4debf1f3..cebf17d4f7 100644
--- a/download/archive/3.4-beta1/index.html
+++ b/download/archive/3.4-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-beta2/index.html b/download/archive/3.4-beta2/index.html
index e1b3279ffc..c5f5813285 100644
--- a/download/archive/3.4-beta2/index.html
+++ b/download/archive/3.4-beta2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-beta3/index.html b/download/archive/3.4-beta3/index.html
index e132e4f8e6..220925ddec 100644
--- a/download/archive/3.4-beta3/index.html
+++ b/download/archive/3.4-beta3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-beta4/index.html b/download/archive/3.4-beta4/index.html
index 5378f5375d..9170696e81 100644
--- a/download/archive/3.4-beta4/index.html
+++ b/download/archive/3.4-beta4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-beta5/index.html b/download/archive/3.4-beta5/index.html
index 80acb76b71..5092f00504 100644
--- a/download/archive/3.4-beta5/index.html
+++ b/download/archive/3.4-beta5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-beta6/index.html b/download/archive/3.4-beta6/index.html
index 8dda72f62f..182e1c5d21 100644
--- a/download/archive/3.4-beta6/index.html
+++ b/download/archive/3.4-beta6/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-rc1/index.html b/download/archive/3.4-rc1/index.html
index 9141b4730b..05dab6d6ad 100644
--- a/download/archive/3.4-rc1/index.html
+++ b/download/archive/3.4-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-rc2/index.html b/download/archive/3.4-rc2/index.html
index 073a6db1aa..a7b982a23c 100644
--- a/download/archive/3.4-rc2/index.html
+++ b/download/archive/3.4-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-rc3/index.html b/download/archive/3.4-rc3/index.html
index 21dbb938c3..3536c62e10 100644
--- a/download/archive/3.4-rc3/index.html
+++ b/download/archive/3.4-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4-stable/index.html b/download/archive/3.4-stable/index.html
index 29e2bcda19..6a6975fe6e 100644
--- a/download/archive/3.4-stable/index.html
+++ b/download/archive/3.4-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.1-rc1/index.html b/download/archive/3.4.1-rc1/index.html
index 2753abf7fd..b2e8fc4446 100644
--- a/download/archive/3.4.1-rc1/index.html
+++ b/download/archive/3.4.1-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.1-rc2/index.html b/download/archive/3.4.1-rc2/index.html
index b82a78e98b..1113df4f7d 100644
--- a/download/archive/3.4.1-rc2/index.html
+++ b/download/archive/3.4.1-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.1-rc3/index.html b/download/archive/3.4.1-rc3/index.html
index d29c1616c4..87b1935ac7 100644
--- a/download/archive/3.4.1-rc3/index.html
+++ b/download/archive/3.4.1-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.1-stable/index.html b/download/archive/3.4.1-stable/index.html
index b5af826c30..0ec76c9637 100644
--- a/download/archive/3.4.1-stable/index.html
+++ b/download/archive/3.4.1-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.2-stable/index.html b/download/archive/3.4.2-stable/index.html
index 2b83be0d90..6b8fbe38ed 100644
--- a/download/archive/3.4.2-stable/index.html
+++ b/download/archive/3.4.2-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.3-rc1/index.html b/download/archive/3.4.3-rc1/index.html
index 8554a7277b..6b5cdf907c 100644
--- a/download/archive/3.4.3-rc1/index.html
+++ b/download/archive/3.4.3-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.3-rc2/index.html b/download/archive/3.4.3-rc2/index.html
index e0884e793b..a20fad433a 100644
--- a/download/archive/3.4.3-rc2/index.html
+++ b/download/archive/3.4.3-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.3-stable/index.html b/download/archive/3.4.3-stable/index.html
index 4711c94a8b..866cda94a2 100644
--- a/download/archive/3.4.3-stable/index.html
+++ b/download/archive/3.4.3-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.4-rc1/index.html b/download/archive/3.4.4-rc1/index.html
index 90c8a9bf29..3c407b7572 100644
--- a/download/archive/3.4.4-rc1/index.html
+++ b/download/archive/3.4.4-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.4-rc2/index.html b/download/archive/3.4.4-rc2/index.html
index 08ebf0f319..9561ad41ec 100644
--- a/download/archive/3.4.4-rc2/index.html
+++ b/download/archive/3.4.4-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.4-stable/index.html b/download/archive/3.4.4-stable/index.html
index c59ab219aa..02a69e55d0 100644
--- a/download/archive/3.4.4-stable/index.html
+++ b/download/archive/3.4.4-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.5-rc1/index.html b/download/archive/3.4.5-rc1/index.html
index 78794e5fd7..a2e5e4f664 100644
--- a/download/archive/3.4.5-rc1/index.html
+++ b/download/archive/3.4.5-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.4.5-stable/index.html b/download/archive/3.4.5-stable/index.html
index 750fb97124..86d592039e 100644
--- a/download/archive/3.4.5-stable/index.html
+++ b/download/archive/3.4.5-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-beta1/index.html b/download/archive/3.5-beta1/index.html
index d5f8ba946e..90e8450692 100644
--- a/download/archive/3.5-beta1/index.html
+++ b/download/archive/3.5-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-beta2/index.html b/download/archive/3.5-beta2/index.html
index 838aa9a17d..7cedb2875e 100644
--- a/download/archive/3.5-beta2/index.html
+++ b/download/archive/3.5-beta2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-beta3/index.html b/download/archive/3.5-beta3/index.html
index 7a82168fef..8f19b21515 100644
--- a/download/archive/3.5-beta3/index.html
+++ b/download/archive/3.5-beta3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-beta4/index.html b/download/archive/3.5-beta4/index.html
index 88c489ba81..5a58ec9df2 100644
--- a/download/archive/3.5-beta4/index.html
+++ b/download/archive/3.5-beta4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-beta5/index.html b/download/archive/3.5-beta5/index.html
index 6516868305..5f768e6f07 100644
--- a/download/archive/3.5-beta5/index.html
+++ b/download/archive/3.5-beta5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-rc1/index.html b/download/archive/3.5-rc1/index.html
index d6ed1623b5..d365463cbd 100644
--- a/download/archive/3.5-rc1/index.html
+++ b/download/archive/3.5-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-rc2/index.html b/download/archive/3.5-rc2/index.html
index ae41332a0e..978d6841f3 100644
--- a/download/archive/3.5-rc2/index.html
+++ b/download/archive/3.5-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-rc3/index.html b/download/archive/3.5-rc3/index.html
index 9516ce4d89..9e2557054e 100644
--- a/download/archive/3.5-rc3/index.html
+++ b/download/archive/3.5-rc3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-rc4/index.html b/download/archive/3.5-rc4/index.html
index 61538a70e0..13a9af1771 100644
--- a/download/archive/3.5-rc4/index.html
+++ b/download/archive/3.5-rc4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-rc5/index.html b/download/archive/3.5-rc5/index.html
index 479c163a60..74ea44df8b 100644
--- a/download/archive/3.5-rc5/index.html
+++ b/download/archive/3.5-rc5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-rc6/index.html b/download/archive/3.5-rc6/index.html
index 5bd9a8f1ba..8ae657055b 100644
--- a/download/archive/3.5-rc6/index.html
+++ b/download/archive/3.5-rc6/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-rc7/index.html b/download/archive/3.5-rc7/index.html
index 107d287c9e..b0fea00c4c 100644
--- a/download/archive/3.5-rc7/index.html
+++ b/download/archive/3.5-rc7/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-rc8/index.html b/download/archive/3.5-rc8/index.html
index adc4f77f1d..2a22b170fe 100644
--- a/download/archive/3.5-rc8/index.html
+++ b/download/archive/3.5-rc8/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5-stable/index.html b/download/archive/3.5-stable/index.html
index c206f58b0a..a0bcc75688 100644
--- a/download/archive/3.5-stable/index.html
+++ b/download/archive/3.5-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5.1-rc1/index.html b/download/archive/3.5.1-rc1/index.html
index b9fc04b15c..49489e38d6 100644
--- a/download/archive/3.5.1-rc1/index.html
+++ b/download/archive/3.5.1-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5.1-rc2/index.html b/download/archive/3.5.1-rc2/index.html
index 4244bb924e..64cafb2582 100644
--- a/download/archive/3.5.1-rc2/index.html
+++ b/download/archive/3.5.1-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5.1-stable/index.html b/download/archive/3.5.1-stable/index.html
index 8da9c4ef6a..7b8f42a6b6 100644
--- a/download/archive/3.5.1-stable/index.html
+++ b/download/archive/3.5.1-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5.2-rc1/index.html b/download/archive/3.5.2-rc1/index.html
index a5808eaab9..6390cc4d61 100644
--- a/download/archive/3.5.2-rc1/index.html
+++ b/download/archive/3.5.2-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5.2-rc2/index.html b/download/archive/3.5.2-rc2/index.html
index 7a07f8e0b1..93481f702b 100644
--- a/download/archive/3.5.2-rc2/index.html
+++ b/download/archive/3.5.2-rc2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5.2-stable/index.html b/download/archive/3.5.2-stable/index.html
index 3f4642c27c..36aff0102b 100644
--- a/download/archive/3.5.2-stable/index.html
+++ b/download/archive/3.5.2-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5.3-rc1/index.html b/download/archive/3.5.3-rc1/index.html
index 9024004579..0b7eb6f6d5 100644
--- a/download/archive/3.5.3-rc1/index.html
+++ b/download/archive/3.5.3-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.5.3-stable/index.html b/download/archive/3.5.3-stable/index.html
index 4cf556062e..b9fc01a617 100644
--- a/download/archive/3.5.3-stable/index.html
+++ b/download/archive/3.5.3-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.6-beta1/index.html b/download/archive/3.6-beta1/index.html
index 99c537df1b..01c7da3de0 100644
--- a/download/archive/3.6-beta1/index.html
+++ b/download/archive/3.6-beta1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.6-beta2/index.html b/download/archive/3.6-beta2/index.html
index 2831ceca14..86c1ec6f42 100644
--- a/download/archive/3.6-beta2/index.html
+++ b/download/archive/3.6-beta2/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.6-beta3/index.html b/download/archive/3.6-beta3/index.html
index c1d3d485b1..3d72d892a0 100644
--- a/download/archive/3.6-beta3/index.html
+++ b/download/archive/3.6-beta3/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.6-beta4/index.html b/download/archive/3.6-beta4/index.html
index a4453e5fef..7c3bd5425c 100644
--- a/download/archive/3.6-beta4/index.html
+++ b/download/archive/3.6-beta4/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.6-beta5/index.html b/download/archive/3.6-beta5/index.html
index 1c2b773a1d..ce81c8c633 100644
--- a/download/archive/3.6-beta5/index.html
+++ b/download/archive/3.6-beta5/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.6-rc1/index.html b/download/archive/3.6-rc1/index.html
index 442d0a3411..60696445ec 100644
--- a/download/archive/3.6-rc1/index.html
+++ b/download/archive/3.6-rc1/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Android plugins · Java · Kotlin · C# support
\ No newline at end of file
diff --git a/download/archive/3.6-stable/index.html b/download/archive/3.6-stable/index.html
index 6a20a4cd8e..3a57ce7567 100644
--- a/download/archive/3.6-stable/index.html
+++ b/download/archive/3.6-stable/index.html
@@ -43,7 +43,7 @@
Used to export your games to all supported platforms
+Changelog
\ No newline at end of file
diff --git a/download/linux/index.html b/download/linux/index.html
index a1c086d40e..6f0102ba36 100644
--- a/download/linux/index.html
+++ b/download/linux/index.html
@@ -46,7 +46,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/download/macos/index.html b/download/macos/index.html
index de33be444a..85bde38ae4 100644
--- a/download/macos/index.html
+++ b/download/macos/index.html
@@ -31,7 +31,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/download/preview/index.html b/download/preview/index.html
index 589483ac8e..7a0cd19f38 100644
--- a/download/preview/index.html
+++ b/download/preview/index.html
@@ -48,7 +48,7 @@
Self-hosted · Cross-platform
Export templatesUsed to export your games to all supported platforms
\ No newline at end of file
diff --git a/download/windows/index.html b/download/windows/index.html
index cbc6d94985..82766a79ca 100644
--- a/download/windows/index.html
+++ b/download/windows/index.html
@@ -41,7 +41,7 @@
Linux,
Windows,
and
-macOS.
\ No newline at end of file
diff --git a/education/index.html b/education/index.html
index 3cba01800a..ad0615496a 100644
--- a/education/index.html
+++ b/education/index.html
@@ -23,7 +23,7 @@
Tutorials and resources page.
We recommend GDQuest's Learn GDScript From Zero, which is a free and open source interactive tutorial for
absolute
beginners to learn to
-program with Godot's GDScript language. It is available as a desktop application or in the browser.
Want to know something else?
If there is something else you would like to know, you can get in touch by writing us at contact@godotengine.org.
If there is something else you would like to know, you can get in touch by writing us at contact@godotengine.org.
\ No newline at end of file
diff --git a/events/index.html b/events/index.html
index e671ab5041..14b872ab81 100644
--- a/events/index.html
+++ b/events/index.html
@@ -171,7 +171,7 @@
few weeks though).
Date: Sunday, Feb 5 @ 16:30
Location: Room AW1.126 (come early, places are limited)
The primary purpose for many of us will be to meet each other in person after having worked for months or
even years together online.
We will have plenty of time to grab some Belgian beers together, and maybe organize a community dinner
-together on Saturday evening.
Event details
Date: Feb 4 and 5 2017
Location:
Université Libre de Bruxelles (ULB), Brussels, Belgium
No registration needed, you can just show up at our stand and say hello, but we’d be glad if you would fill this form anyway so that we know who to expect.
+together on Saturday evening.
Event details
Date: Feb 4 and 5 2017
Location:
Université Libre de Bruxelles (ULB), Brussels, Belgium
No registration needed, you can just show up at our stand and say hello, but we’d be glad if you would fill this form anyway so that we know who to expect.
\ No newline at end of file
diff --git a/fbx-import/index.html b/fbx-import/index.html
index 3191d9be55..f8f1200a5d 100644
--- a/fbx-import/index.html
+++ b/fbx-import/index.html
@@ -26,7 +26,7 @@
case, macOS will automatically use Rosetta when running FBX2glTF. Creating an
universal macOS binary (x86_64 + ARM) for FBX2glTF is planned in the future.
There are no plans to support the Android and HTML5 editor with FBX import, as
those platforms don't allow executing arbitrary external programs. For Android and HTML5, you can use FBX2glTF on another device then save the
-converted glTF file.
+converted glTF file.
\ No newline at end of file
diff --git a/features/index.html b/features/index.html
index 89154dbb64..77bc3ce83e 100644
--- a/features/index.html
+++ b/features/index.html
@@ -64,7 +64,7 @@
or build your own engine on top of it — it's all in your hands.
Find the logic behind any system in an open source codebase
No need to wait for a support team to respond when you can read
the source code. Godot is an open book, and you can figure out everything
that is not yet documented after a single git checkout.
-If you find and fix an issue, we will appreciate a PR upstream too.
\ No newline at end of file
diff --git a/governance/index.html b/governance/index.html
index 78491a6776..d45ea2f581 100644
--- a/governance/index.html
+++ b/governance/index.html
@@ -11,7 +11,7 @@
for their work to be included. Pull Requests are approved and merged by the respective area maintainers while,
again, always striving to promote agreement before moving forward. All improvements to the engine are made through
the Pull Requests of community members.
Open discussion: Before doing any significant amount of work, we encourage maintainers,
-contributors, and community to open and discuss features and proposals in the Godot proposals repository. This allows all contributors to have a much better understanding of how users expect the new feature to be used. Because the primary aim of Godot is to produce a useful tool, we ask those who open proposals to discuss real-world use cases based on problems they are having with their current projects. This allows maintainers and contributors to have a much more "down to earth" understanding of user's requirements. This philosophy is best explained in the engine contributor guidelines.
Community-minded: The Godot project is developed by and for the community. No corporate entity exists behind Godot that prioritizes one feature over another. Priorities are set by project leadership and area maintainers based on the feedback of the community in bug reports, proposals, and discussions in the various community channels. Ultimately, it is the community that determines the direction of the project.
Every improvement to the engine, whether it is a feature or bug fix, is driven forward by Godot's community of contributors, users, maintainers, and leadership. Godot wouldn't exist in its current form without the countless contributions it receives from community members every day.
+contributors, and community to open and discuss features and proposals in the Godot proposals repository. This allows all contributors to have a much better understanding of how users expect the new feature to be used. Because the primary aim of Godot is to produce a useful tool, we ask those who open proposals to discuss real-world use cases based on problems they are having with their current projects. This allows maintainers and contributors to have a much more "down to earth" understanding of user's requirements. This philosophy is best explained in the engine contributor guidelines.
Community-minded: The Godot project is developed by and for the community. No corporate entity exists behind Godot that prioritizes one feature over another. Priorities are set by project leadership and area maintainers based on the feedback of the community in bug reports, proposals, and discussions in the various community channels. Ultimately, it is the community that determines the direction of the project.
Every improvement to the engine, whether it is a feature or bug fix, is driven forward by Godot's community of contributors, users, maintainers, and leadership. Godot wouldn't exist in its current form without the countless contributions it receives from community members every day.
\ No newline at end of file
diff --git a/index.html b/index.html
index 6aee2a1e33..8dace20b1f 100644
--- a/index.html
+++ b/index.html
@@ -23,7 +23,7 @@
-
Donate now!
\ No newline at end of file
diff --git a/license/index.html b/license/index.html
index dc86d2e90d..4ac6e212e3 100644
--- a/license/index.html
+++ b/license/index.html
@@ -51,7 +51,7 @@
legal advice.
They reflect the Godot Engine team's understanding of their own license terms and that of their third-party
components;
-in case of doubt, please refer to your lawyer.
+in case of doubt, please refer to your lawyer.
\ No newline at end of file
diff --git a/press/index.html b/press/index.html
index aa0704019d..3f78579f1d 100644
--- a/press/index.html
+++ b/press/index.html
@@ -45,7 +45,7 @@
credits or website, but it should not be done in a way that implies
endorsement of your project by the Godot developers.
Do not distort the logo or icon.
In other words, always preserve the aspect ratio when scaling images.
More design resources
You can find more design resources such as artwork and 4K editor screenshots in the
-godot-design repository on GitHub.
+godot-design repository on GitHub.
\ No newline at end of file
diff --git a/priorities/index.html b/priorities/index.html
index cd05a6a67e..e0c4efaedb 100644
--- a/priorities/index.html
+++ b/priorities/index.html
@@ -81,7 +81,7 @@
unfold_less
Allow compiling Godot as a library that can be loaded and used by other applications
unfold_moreunfold_less
Currently, the engine’s capabilities are only accessible if the application itself is a Godot application. However, there are many situations where an application might want to use Godot as an intermediary. One case would be an application that uses native OS API for it’s UI, but needs Godot to render a complex 3D scene. Our goal is to make Godot available as a library to expand the possible uses of the engine.
Allow GDExtensions to communicate with one another
unfold_moreunfold_less
GDExtension was created to allow developers to create extensions as if they were coding a module directly in Godot’s source code. Currently, modules can depend on one another, but this is not yet possible for extensions. We aim to expose the necessary API to be able to. So, for example, an extension built with godot-rust would be able to extend an extension built with godot-cpp.
Add the ability to enable/disable GDExtensions in project settings
unfold_more
-unfold_less
For the time being, there’s no way to disable a GDExtension from a project without deleting the related files themselves. We plan to create a dialog akin to the Plugin tab in the Project settings in order to easily enable and disable GDExtensions.
For the time being, there’s no way to disable a GDExtension from a project without deleting the related files themselves. We plan to create a dialog akin to the Plugin tab in the Project settings in order to easily enable and disable GDExtensions.
\ No newline at end of file
diff --git a/privacy-policy/index.html b/privacy-policy/index.html
index a29e334fb2..b27622ebee 100644
--- a/privacy-policy/index.html
+++ b/privacy-policy/index.html
@@ -95,7 +95,7 @@
Statement will be posted on this site. A notice will be posted on our homepage for 30 days whenever this privacy
statement is changed in a material way.
WordPress.org's Privacy Policy, used under Attribution-ShareAlike 2.5 Generic (CC BY-SA 2.5). https://wordpress.org/about/privacy
\ No newline at end of file
diff --git a/releases/4.3/index.html b/releases/4.3/index.html
index c4aae1d490..82fee9f82a 100644
--- a/releases/4.3/index.html
+++ b/releases/4.3/index.html
@@ -316,7 +316,7 @@
with special thanks to
GDQuest,
Kenney,
-and FR3NKD
Texts by Nathalie Galla & Adam Scott
\ No newline at end of file
diff --git a/showcase/Badaboom/index.html b/showcase/Badaboom/index.html
index 2805b5ff85..5536ce37c3 100644
--- a/showcase/Badaboom/index.html
+++ b/showcase/Badaboom/index.html
@@ -4,7 +4,7 @@
| October 2023
Badaboom is a match-3 puzzle game with gorgeous environments and great music.
Play in multiple environments, each with their own song. Each map has its own pace — whether you want to sit back and relax or you are in the mood to break your previous record, Badaboom has you covered!
Ideal for both casual and competitive players, Badaboom brings fun for the whole family. You can play seated or standing, with one or two controllers.
Main features:
🏞 10 different environments and songs, with an unlockable alternative version each + expansion packs!
📈 Global leaderboards.
⏰ Weekly challenges.
⚙️ Wide variety of accessibility options, including various colorblind settings.
🏆 Achievements & unlockable perks to enhance the gameplay experience.
+
\ No newline at end of file
diff --git a/showcase/a-most-extraordinary-gnome/index.html b/showcase/a-most-extraordinary-gnome/index.html
index 2b1d556917..3a15420125 100644
--- a/showcase/a-most-extraordinary-gnome/index.html
+++ b/showcase/a-most-extraordinary-gnome/index.html
@@ -3,7 +3,7 @@
Waking up every day as the forest’s only protector is not an easy job for anyone. There’s not only every animal’s personal problem a gnome has to deal with — as mysteriously dark, unprecedented things start happening in the forest; the source of which no one really understands. Fear, escaping and destruction taint the previously peaceful life of the animals. Seemingly only one can stop this — but what can a single gnome really do to save the world?
A Most Extraordinary Gnome is a short, narrative-driven game, which combines challenging and unique 2D action with complex storytelling. You control a small gnome, who uses his hat to defeat the dangers he encounters in increasingly intense stages.
The features of the game
Unlike anything you’ve seen in indie gaming! A colorful and vibrant 2D world, made entirely out of hand crafted paper cut-out elements
Gameplay tailored just to you. Whether you’re looking for a laid-back experience or a harder challenge, gameplay settings are there to accommodate your needs!
A deep story! There’s more than what just meets the eye. Embark on a short journey which will lead you to unexpected places.
Confront the dangers facing the forest! Fight multiple distinctive bosses, each with its own challenge!
Meet the dwellers of the forest! Your house is home to a diverse group of animals, each with its own look at the world and you.
A memorable score! The game features a unique, Eastern-European inspired soundtrack, which dynamically changes based on the level of threat your character is facing at the moment.
A world made out of paper
As a rare sight in gaming, the entire adventure comes alive with the help of paper. Anything you see in the game is made by hand, stacking layers of colorful paper on each other to create this flat, but heavily detailed aesthetic the game. Utilizing traditional stop-motion techniques wherever necessary, the movements also get a unique flair specific to this game.
+
\ No newline at end of file
diff --git a/showcase/action-game-maker/index.html b/showcase/action-game-maker/index.html
index 9a5211e45a..4b107fe9e6 100644
--- a/showcase/action-game-maker/index.html
+++ b/showcase/action-game-maker/index.html
@@ -5,7 +5,7 @@
Unchain Your Imagination!
Fully No Coding Visual Scripting
“ACTION GAME MAKER” builds on the node-based visual scripting system created for “Pixel Game Maker MV” with many improvements.
No knowledge of programming is needed. Simply connect up Actions (similar to RPG Maker’s Event Commands) and see the unique logic for your game come together!
Sample Assets Included!
Everything you need to build your first game is included, from character art to tiles, music, and sound effects!
Free yourself from worrying about assets and just get started!
The provided samples are intentionally simple and pixel-style so that it’s easy to open them up and make modifications or extensions to begin creating your own original look!
Of course, if you already have your own assets it’s easy to import them – and high resolutions are supported!
There's a lot to like about Godot. The very lightweight editor comes to mind first, but the straightforward UI and the breadth of 2D features combined with the modern selection of build targets are all great. But what really sets Godot apart is the energy and passion from the Godot community itself. Constantly active, you can really feel that everyone is working hard to make good games and Godot better at the same time. We're really going to need to give it our all to ensure that Action Game Maker can proudly be accepted by and call ourselves part of this community!
+
Why the developer chose Godot
There's a lot to like about Godot. The very lightweight editor comes to mind first, but the straightforward UI and the breadth of 2D features combined with the modern selection of build targets are all great. But what really sets Godot apart is the energy and passion from the Godot community itself. Constantly active, you can really feel that everyone is working hard to make good games and Godot better at the same time. We're really going to need to give it our all to ensure that Action Game Maker can proudly be accepted by and call ourselves part of this community!
\ No newline at end of file
diff --git a/showcase/beat-invaders/index.html b/showcase/beat-invaders/index.html
index 5952b29d9f..a6007543f3 100644
--- a/showcase/beat-invaders/index.html
+++ b/showcase/beat-invaders/index.html
@@ -3,7 +3,7 @@
Beat Invaders is a space-themed action roguelite shoot-em-up! Shoot your path through waves of enemies playing as one of three Pilots, each with their own Ship Class.
Combine upgrades, ship hacks, and specials to unleash an insane devastation on your enemies!
-Protect your freighters, beat the bosses and survive intense events to make your delivery.
Gameplay is speed is dependent on the speed of the current track, your opponents’ movements and firing rates are dictated by each song’s beat and tempo.
Level up during a run and choose from different upgrades to make your space ship more powerful. Combine different upgrades to create powerful builds.
Use your earned upgrade points after a run to further enhance your space ship and unlock different ship classes with unique main weapons and stats to take on enemies on harder difficulties. The upgrades can be reset and redestributed to try out different strategies with different ship classes.
Create devastating combos using events and boosts that wipe out screens full of enemies in seconds!
Event waves and mini events break up the pace and make for fun, rewarding challenges.
Features:
Action Roguelite Shoot-em-up, paying tribute to old school games like Space Invaders or Galaga.
Upgrade your ship’s and convoy's systems between enemy waves and purchase meta upgrades between runs.
Different game modes: Easy, Normal, Hyper Mode, Speedrun, Lone Wolf, Weeklies and Dailies!) - all with online leaderboards
Mini-events, Booster pickup items and different event waves make for challenging combos.
Permanentely improve your ship’s sub-system, unlock new weapons and convoy gadgets between runs.
Beat Bosses and tricky Events and show your worth!
High score challenge! Compare your scores to your friends playing Beat Invaders, and try to beat their records!
Runs great on the Steam Deck.
Full mouse, keyboard and controller support.
Atmospheric electronic and vocal soundtrack with 33 tracks that sets the pace of your adversaries, making each round unique to its song.
+Protect your freighters, beat the bosses and survive intense events to make your delivery.
Gameplay is speed is dependent on the speed of the current track, your opponents’ movements and firing rates are dictated by each song’s beat and tempo.
Level up during a run and choose from different upgrades to make your space ship more powerful. Combine different upgrades to create powerful builds.
Use your earned upgrade points after a run to further enhance your space ship and unlock different ship classes with unique main weapons and stats to take on enemies on harder difficulties. The upgrades can be reset and redestributed to try out different strategies with different ship classes.
Create devastating combos using events and boosts that wipe out screens full of enemies in seconds!
Event waves and mini events break up the pace and make for fun, rewarding challenges.
Features:
Action Roguelite Shoot-em-up, paying tribute to old school games like Space Invaders or Galaga.
Upgrade your ship’s and convoy's systems between enemy waves and purchase meta upgrades between runs.
Different game modes: Easy, Normal, Hyper Mode, Speedrun, Lone Wolf, Weeklies and Dailies!) - all with online leaderboards
Mini-events, Booster pickup items and different event waves make for challenging combos.
Permanentely improve your ship’s sub-system, unlock new weapons and convoy gadgets between runs.
Beat Bosses and tricky Events and show your worth!
High score challenge! Compare your scores to your friends playing Beat Invaders, and try to beat their records!
Runs great on the Steam Deck.
Full mouse, keyboard and controller support.
Atmospheric electronic and vocal soundtrack with 33 tracks that sets the pace of your adversaries, making each round unique to its song.
\ No newline at end of file
diff --git a/showcase/blastronaut/index.html b/showcase/blastronaut/index.html
index 59d5fd9437..0d27559324 100644
--- a/showcase/blastronaut/index.html
+++ b/showcase/blastronaut/index.html
@@ -3,7 +3,7 @@
It is a dangerous but lucrative job. Explore this vast procedurally generated world with your jetpack. Extract the minerals with an explosive gel. Expand your mining platform. But most importantly: stay alive.
The game offers you:
Mining and selling resources for profit
Exploring an infinite procedurally generated world
Upgrading your gear
A lot of explosions
The depths of the planet hide many unique biomes and treasures, but also dangers. Every biome has its own way to harm you and having the right set of gear will make your life much easier.
On the ground, you can build your base of operation. Different machines allow you to process and trade the resources that you have brought from your last mining operation.
+
\ No newline at end of file
diff --git a/showcase/brotato/index.html b/showcase/brotato/index.html
index 563cb20b02..a7a1070a30 100644
--- a/showcase/brotato/index.html
+++ b/showcase/brotato/index.html
@@ -3,7 +3,7 @@
A spaceship from Potato World crashes onto an alien planet. The sole survivor: Brotato, the only potato capable of handling 6 weapons at the same time. Waiting to be rescued by his mates, Brotato must survive in this hostile environment.
Features
Auto-firing weapons by default with a manual aiming option
Fast runs (under 30 minutes)
Dozens of characters available to customize your runs (one-handed, crazy, lucky, mage and many more)
Hundreds of items and weapons to choose from (flamethrowers, SMGs, rocket launchers or sticks and stones)
Survive waves lasting 20 to 90 seconds each and kill off as many aliens as you can during that time
Collect materials to gain experience and get items from the shop between waves of enemies
Accessibility options: tweak the health, damage and speed of enemies so the difficulty is right for you
+
\ No newline at end of file
diff --git a/showcase/case-of-the-golden-idol/index.html b/showcase/case-of-the-golden-idol/index.html
index 24d53d52e0..50000812ae 100644
--- a/showcase/case-of-the-golden-idol/index.html
+++ b/showcase/case-of-the-golden-idol/index.html
@@ -4,7 +4,7 @@
| Oct 2022
Investigate Gruesome Crimes
Step into the shoes of an 18th century detective and uncover the mystery behind twelve strange deaths spanning 50 years, all somehow connected.
Unmask the true killers in this sprawling narrative and discover their devious motives.
Piece Together the Plot
Observe closely and reconstruct each scene of death. Your skills of deduction can identify each suspect, motive and murder weapon.
Uncover the Conspiracy
Reveal the true nature of the mysterious Golden Idol and those who covet it. Follow the journey of a cursed aristocratic family as you untangle a web of deceit and villainy in your hunt for the truth behind this dark conspiracy.
+
\ No newline at end of file
diff --git a/showcase/cassette-beasts/index.html b/showcase/cassette-beasts/index.html
index 2c803dfead..3795250fcc 100644
--- a/showcase/cassette-beasts/index.html
+++ b/showcase/cassette-beasts/index.html
@@ -3,7 +3,7 @@
Welcome to New Wirral, a remote island inhabited by strange creatures you’ve only dreamed of, nightmares you hopefully haven’t, and a cast of brave folks who use cassette tapes to transform for battle. To find a way home you’ll need to explore every inch of the island, and record monsters to your trusty cassette tapes to gain their abilities!
Transform into monsters…using retro cassette tapes?!
Faced with the constant threat of monster attacks, you must protect the residents of Harbourtown. Record a monster to tape, then play it back to take on its form for battle!
Fuse monster forms!
Any two monster forms can be fused to produce unique, fully-animated new fusion forms.
Explore a rich open world
Certain monster abilities can be used in human form. You’ll need these to help you get around, solve puzzles, and locate dungeons. Glide, fly, swim, climb, dash, or turn magnetic!
Travel alongside a diverse cast of human companions
Never fight alone! Form bonds, spend time together, and help your selected partner complete personal goals to become a better team. The strength of your relationship determines how well you’re able to fuse!
Master a deep battle system
Take advantage of elemental chemistry to apply extra buffs or debuffs alongside your attack, or even alter your opponent’s elemental type!
+
\ No newline at end of file
diff --git a/showcase/city-game-studio/index.html b/showcase/city-game-studio/index.html
index f60c7d693e..dadecd8ffc 100644
--- a/showcase/city-game-studio/index.html
+++ b/showcase/city-game-studio/index.html
@@ -13,7 +13,7 @@
Furthermore you will be able to publish your own publishing contracts. Then
you will then be ready to dominate the market and buy back your competitors.
Feature list
Develop or rent game engines
Receive/publish game offers
Buying or renting several buildings
Develop and manage a digital store
Cracking competitors' games
Unlocking new game genres
Spy the competitors
Hire staff
Organize marketing campaigns
Organizing and attending conventions
Buy out companies
Executing contracts that trains your employees
Porting games to several consoles
Design your company logo
Manage your employees' schedules
Get awarded Game of the Year
Microtransactions
Console exclusive game
Lootboxes
Have a good time
This game doesn’t have:
eSport competitions
An R&D department
A multiplayer mode
City Game Studio is inspired by marvelous games like
+View on GOG.com
\ No newline at end of file
diff --git a/showcase/cruelty-squad/index.html b/showcase/cruelty-squad/index.html
index b45aa0f9e0..33e9596f09 100644
--- a/showcase/cruelty-squad/index.html
+++ b/showcase/cruelty-squad/index.html
@@ -1,7 +1,7 @@
Cruelty Squad – Godot Engine
Cruelty Squad is a tactical first person shooter set in the hardcore gig economy of corporate liquidations. You're an emotionally dead combat-substance fueled grunt of Cruelty Squad, a depraved subsidiary company tasked with performing wetworks for its host conglomerate. Will you make the Corporate Arch Demoness proud or succumb to bitter tears of failure?
Highly kinematic tactical gameplay using varied weapons such as the flechette shotgun, silenced 10mm pistol, radiation emitter, dart gun, corrosive gas launcher and more.
No handholding!
All of the missions have multiple viable approaches and routes. Plan out your equipment loadout to gain a tactical advantage. Choose between non-lethal and lethal options. Throw toilet bowls at enemies.
Fight and sneak through offices, suburbs, police stations and secret compounds. Find and unlock hidden equipment and levels.
Open objective based gameplay, in each mission your goal is to kill or destroy your targets before heading for the exit.
Revisit earlier missions and try to beat your best time. Can you S-rank all of the missions?
Enemies including private security, cops, psycho freaks, flower hybrids, swamp cultists and mutant dogs.
Talk to NPCs and figure out the mysteries of the world.
Cruelty Squad is a tactical first person shooter set in the hardcore gig economy of corporate liquidations. You're an emotionally dead combat-substance fueled grunt of Cruelty Squad, a depraved subsidiary company tasked with performing wetworks for its host conglomerate. Will you make the Corporate Arch Demoness proud or succumb to bitter tears of failure?
Highly kinematic tactical gameplay using varied weapons such as the flechette shotgun, silenced 10mm pistol, radiation emitter, dart gun, corrosive gas launcher and more.
No handholding!
All of the missions have multiple viable approaches and routes. Plan out your equipment loadout to gain a tactical advantage. Choose between non-lethal and lethal options. Throw toilet bowls at enemies.
Fight and sneak through offices, suburbs, police stations and secret compounds. Find and unlock hidden equipment and levels.
Open objective based gameplay, in each mission your goal is to kill or destroy your targets before heading for the exit.
Revisit earlier missions and try to beat your best time. Can you S-rank all of the missions?
Enemies including private security, cops, psycho freaks, flower hybrids, swamp cultists and mutant dogs.
Talk to NPCs and figure out the mysteries of the world.
\ No newline at end of file
diff --git a/showcase/delta-v-rings-of-saturn/index.html b/showcase/delta-v-rings-of-saturn/index.html
index b772475a86..b0f8eed37d 100644
--- a/showcase/delta-v-rings-of-saturn/index.html
+++ b/showcase/delta-v-rings-of-saturn/index.html
@@ -12,7 +12,7 @@
gameplay - adapt to survive in the hostile environment of space.
Discover the mystery of the Rings, or just try to get rich leading your
excavation company.
Plan your strategy back on Enceladus Prime station. Sell your output,
upgrade your ship, hire the crew and manage your company.
+View on itch.io
\ No newline at end of file
diff --git a/showcase/dome-keeper/index.html b/showcase/dome-keeper/index.html
index 73309ac08b..a00759abad 100644
--- a/showcase/dome-keeper/index.html
+++ b/showcase/dome-keeper/index.html
@@ -1,7 +1,7 @@
Dome Keeper – Godot Engine
Defend your dome from wave after wave of monsters in this innovative roguelike survival miner, Dome Keeper. Use the time between each attack to dig beneath the surface in search of valuable resources and artifacts – use them carefully to choose powerful upgrades and bonuses. Set on beautifully crafted pixel art alien planets, Dome Keeper offers a captivating atmosphere with music tracks fusing melodic and synthetic creations.
Dig
Drill tunnels beneath your dome in search of precious materials or to uncover powerful hidden artifacts. Watch the time, you need to get back to the dome and be ready when the next wave of attack comes. How deep will you get this time? How much can you carry back?
Defend
Take control of your defenses to fend off the alien attacks. Air and ground, slow and fast; the attackers must be prioritized and dealt with before they tear your dome apart.
Develop
Utilize your mineral harvest to unlock powerful upgrades: augment your weapons, enhance the impact of your drill, boost your jetpack’s max speed, and many other upgrade paths -- each of which gives you and your dome the best odds for survival!
Defend your dome from wave after wave of monsters in this innovative roguelike survival miner, Dome Keeper. Use the time between each attack to dig beneath the surface in search of valuable resources and artifacts – use them carefully to choose powerful upgrades and bonuses. Set on beautifully crafted pixel art alien planets, Dome Keeper offers a captivating atmosphere with music tracks fusing melodic and synthetic creations.
Dig
Drill tunnels beneath your dome in search of precious materials or to uncover powerful hidden artifacts. Watch the time, you need to get back to the dome and be ready when the next wave of attack comes. How deep will you get this time? How much can you carry back?
Defend
Take control of your defenses to fend off the alien attacks. Air and ground, slow and fast; the attackers must be prioritized and dealt with before they tear your dome apart.
Develop
Utilize your mineral harvest to unlock powerful upgrades: augment your weapons, enhance the impact of your drill, boost your jetpack’s max speed, and many other upgrade paths -- each of which gives you and your dome the best odds for survival!
\ No newline at end of file
diff --git a/showcase/dungeondraft/index.html b/showcase/dungeondraft/index.html
index 5085cdefa5..ac0419b036 100644
--- a/showcase/dungeondraft/index.html
+++ b/showcase/dungeondraft/index.html
@@ -2,7 +2,7 @@
\ No newline at end of file
diff --git a/showcase/endoparasitic/index.html b/showcase/endoparasitic/index.html
index 3ef7e9ae6f..9d7511dc31 100644
--- a/showcase/endoparasitic/index.html
+++ b/showcase/endoparasitic/index.html
@@ -2,7 +2,7 @@
Three limbs ripped off, infected with a deadly parasite, you must save your research. Drag yourself through the corridors of a secret research lab on a remote asteroid, fight off horribly mutated monsters, inject countless syringes of vaccines, and survive at all costs.
Endoparasitic is a tactical survival horror game where you must manually do every action from reloading to moving. Juggle movement and firing and plan room entrances to avoid getting swarmed.
Features:
One handed in game, one handed in real life: Everything is mouse-controlled
Guns are manually loaded one bullet at a time
Your healthbar is a parasite burrowing to your brain
+View on itch.io
\ No newline at end of file
diff --git a/showcase/ex-zodiac/index.html b/showcase/ex-zodiac/index.html
index 82fdee86e5..15a2a0aef5 100644
--- a/showcase/ex-zodiac/index.html
+++ b/showcase/ex-zodiac/index.html
@@ -5,7 +5,7 @@
early 90's 3D games. Join protagonist Kyuu as she fights to free the worlds of
the Sanzaru Star System, overrun by the intergalactic terrorist organization
known as Zodiac.
Featuring
A retro, colourful, low-poly visual style
12 main levels (plus secret areas and side-paths)
Multiple routes to complete the game
Major bosses at the end of each level, each piloted by a member of the Zodiac
A 16-bit style soundtrack by +TEK combining FM and wavetable synthesis
+View on itch.io
\ No newline at end of file
diff --git a/showcase/fist-of-the-forgotten/index.html b/showcase/fist-of-the-forgotten/index.html
index 7fdfb4d69e..c6fb4d3d56 100644
--- a/showcase/fist-of-the-forgotten/index.html
+++ b/showcase/fist-of-the-forgotten/index.html
@@ -1,7 +1,7 @@
Fist of the Forgotten – Godot Engine
Fist of the Forgotten is a platformer set in a harsh, dark world, but that doesn't mean you're helpless. Relics passed down from your family allow you to interact with forgotten technology and fight your way forward.
Make your way through a forgotten civilization, facing ancient automatons, and acquire some of their technology.
3D assets and high framerate physics allow for perfectly smooth, fluid animation, even on monitors that display at > 100hz. Mechanics in the game, such as sliding down slopes and grappling allow you to build up and maintain momentum.
Fist of the Forgotten's narrative contains no dialogue, so you are free to pay attention to the details to understand the depth of the story, try to uncover alternate endings, or simply focus on flowing through the levels as quickly as possible and enjoy the gameplay.
The fist provides combat capabilities as well as movement. Use it to reach further platforms and combine it with other momentum gaining abilities, such as sliding down hills, to cover extreme gaps.
Fist of the Forgotten is a platformer set in a harsh, dark world, but that doesn't mean you're helpless. Relics passed down from your family allow you to interact with forgotten technology and fight your way forward.
Make your way through a forgotten civilization, facing ancient automatons, and acquire some of their technology.
3D assets and high framerate physics allow for perfectly smooth, fluid animation, even on monitors that display at > 100hz. Mechanics in the game, such as sliding down slopes and grappling allow you to build up and maintain momentum.
Fist of the Forgotten's narrative contains no dialogue, so you are free to pay attention to the details to understand the depth of the story, try to uncover alternate endings, or simply focus on flowing through the levels as quickly as possible and enjoy the gameplay.
The fist provides combat capabilities as well as movement. Use it to reach further platforms and combine it with other momentum gaining abilities, such as sliding down hills, to cover extreme gaps.
\ No newline at end of file
diff --git a/showcase/gourdlets/index.html b/showcase/gourdlets/index.html
index f4d53315cb..1b5fa866fd 100644
--- a/showcase/gourdlets/index.html
+++ b/showcase/gourdlets/index.html
@@ -5,7 +5,7 @@
View on itch.io
-
+
\ No newline at end of file
diff --git a/showcase/gravity-ace/index.html b/showcase/gravity-ace/index.html
index 30bd51bfb2..738b885098 100644
--- a/showcase/gravity-ace/index.html
+++ b/showcase/gravity-ace/index.html
@@ -6,7 +6,7 @@
Descend into dark caverns, fly and blast your way past enemies, retrieve the
reactor core and make your escape, all while fighting the deadly embrace of
crushing gravity.
I think without Godot I'd be much farther behind where I am now. Godot just works in a way that meshes with how I like to think and work. I'd be much less productive for sure.
The 2D workflow is pretty great. Just drop some images in and drag them onto the canvas, attach a script, write a few lines of GDScript and you've got the beginning of a game. Modifying assets is seamless. And the node tree is super powerful. Reusing scenes in other scenes allows me to do a lot of stuff quickly and visually that would have been much more cumbersome in other frameworks.
I think without Godot I'd be much farther behind where I am now. Godot just works in a way that meshes with how I like to think and work. I'd be much less productive for sure.
The 2D workflow is pretty great. Just drop some images in and drag them onto the canvas, attach a script, write a few lines of GDScript and you've got the beginning of a game. Modifying assets is seamless. And the node tree is super powerful. Reusing scenes in other scenes allows me to do a lot of stuff quickly and visually that would have been much more cumbersome in other frameworks.
— Godot Showcase - Gravity Ace developer talks about his experience
\ No newline at end of file
diff --git a/showcase/haiki/index.html b/showcase/haiki/index.html
index 8c648a659f..de2f1d141a 100644
--- a/showcase/haiki/index.html
+++ b/showcase/haiki/index.html
@@ -8,7 +8,7 @@
oblivion. You’ll need precision jumps and keen reactions to survive the 80
hand-crafted levels standing between Haiki and victory.
Die, die and die again until your reflexes are sharp enough to face the
headless Baron and get your body back.
Or lose your head forever.
Want to get ahead? Get a hat! Collect dapper, dashing and dandy hats on your
-journey up from the gutter. How do the hats help Haiki on his quest?
\ No newline at end of file
diff --git a/showcase/halls-of-torment/index.html b/showcase/halls-of-torment/index.html
index 7f16adb83d..c4488715d8 100644
--- a/showcase/halls-of-torment/index.html
+++ b/showcase/halls-of-torment/index.html
@@ -4,7 +4,7 @@
| May 2023
Halls of Torment is a horde survival game in a pre rendered retro look reminiscent of RPGs from the late 90s. Choose one of many hero characters and descend into the deadly Halls of Torment. Fight unholy horrors from beyond and survive wave after wave until you face one of the tormented lords. Advance your hero with character traits, abilities, and items. Create a new powerful build during each run. Explore various underground expanses and find new powerful items that enable you to venture even deeper into the abyss.
Features
Quick and casual runs of maximum 30 minutes
Old school pre rendered artstyle
Quest based meta progression
Large selection of diverse abilities, traits, and items, all enabling you to create interesting synergies
Diverse bosses featuring unique mechanics and attack patterns
Items can be retrieved to the overworld and used to customize future runs
Dozens of interesting characters allowing many different playstyles
Unlock and explore multiple interesting and challenging underground worlds
Interactable environments: Use traps and hazards to your advantage!
Early Access Content
3+ stages unique environment
7+ playable characters
11+ different and upgradable abilities
12+ unique bosses
30+ unique monsters
14+ blessings making you stronger for each attempt
50+ different items to unlock and retrieve
500+ traits that upgrade characters and abilities
150+ quests to complete
This is the content the early access will start with and will be expanded on until the final release.
+
\ No newline at end of file
diff --git a/showcase/hive-time/index.html b/showcase/hive-time/index.html
index 6e1427838d..edc96c1cc2 100644
--- a/showcase/hive-time/index.html
+++ b/showcase/hive-time/index.html
@@ -8,7 +8,7 @@
find pollen and nectar, have Builders research new cell types, and ensure you
have enough Beesitters to raise the next generation of bees. Make interesting
choices that affect the hive - respond to wasp attacks, deal with outlaw
-slugs, or help a caterpillar realise a lifelong dream.
I felt like Godot enabled me to pull the core game together very quickly. The most attractive parts of the engine for me come from its nature as a Free/Open Source Software project and the ability that gives me to debug, fix, or modify the engine to suit my personal needs.
I also feel more comfortable using free and Free tools because I can be confident that if others want to follow in my footsteps, financial or philosophical hurdles won't prevent them from doing so.
I felt like Godot enabled me to pull the core game together very quickly. The most attractive parts of the engine for me come from its nature as a Free/Open Source Software project and the ability that gives me to debug, fix, or modify the engine to suit my personal needs.
I also feel more comfortable using free and Free tools because I can be confident that if others want to follow in my footsteps, financial or philosophical hurdles won't prevent them from doing so.
— Godot Showcase - Hive Time developer Cheeseness talks about his experience
\ No newline at end of file
diff --git a/showcase/human-diaspora/index.html b/showcase/human-diaspora/index.html
index ae51feb6fd..5c4f096480 100644
--- a/showcase/human-diaspora/index.html
+++ b/showcase/human-diaspora/index.html
@@ -9,7 +9,7 @@
the stars and landed on an alien planet. The only way to save humanity is to
fight the enemy invader and secure your place among the strongest. Be it on
land, sea or space territories, shoot your way into victory, never accept
-defeat. Humanity must endure!
Foremost, Godot is FOSS. It entails freedom to dispose of my game projects as I best see fit without worrying about the intricacies of software licenses. And while learning to use it, I realized it already had the necessary set of tools to pull out my game ideas. The node architecture with the concept of scene within scenes and the straightforward way of scripting with GDScript sealed the deal for me.
Foremost, Godot is FOSS. It entails freedom to dispose of my game projects as I best see fit without worrying about the intricacies of software licenses. And while learning to use it, I realized it already had the necessary set of tools to pull out my game ideas. The node architecture with the concept of scene within scenes and the straightforward way of scripting with GDScript sealed the deal for me.
— Godot Showcase - Human Diaspora developer interview
\ No newline at end of file
diff --git a/showcase/index.html b/showcase/index.html
index 5458ebaf77..0e604ded53 100644
--- a/showcase/index.html
+++ b/showcase/index.html
@@ -126,7 +126,7 @@
Gotcha Gotcha Games
Do you want us to showcase your game or project? Read our showcase guidelines and criteria.
\ No newline at end of file
diff --git a/showcase/kamaeru/index.html b/showcase/kamaeru/index.html
index 82275bfe32..3bf78bffc2 100644
--- a/showcase/kamaeru/index.html
+++ b/showcase/kamaeru/index.html
@@ -5,7 +5,7 @@
-
+
\ No newline at end of file
diff --git a/showcase/kingdoms-of-the-dump/index.html b/showcase/kingdoms-of-the-dump/index.html
index e86dc9630a..956ba70bd1 100644
--- a/showcase/kingdoms-of-the-dump/index.html
+++ b/showcase/kingdoms-of-the-dump/index.html
@@ -3,7 +3,7 @@
Kingdoms of the Dump is a SNES-styled RPG with heavy inspiration from
platformers and zelda-like games. Join Dustin Binsley, the Trash Can Knight,
-on his journey to save the Lands of Fill.
\ No newline at end of file
diff --git a/showcase/luck-be-a-landlord/index.html b/showcase/luck-be-a-landlord/index.html
index 87ee761532..c5669932a9 100644
--- a/showcase/luck-be-a-landlord/index.html
+++ b/showcase/luck-be-a-landlord/index.html
@@ -7,7 +7,7 @@
-
+
\ No newline at end of file
diff --git a/showcase/lumencraft/index.html b/showcase/lumencraft/index.html
index c223506e38..1167fd354e 100644
--- a/showcase/lumencraft/index.html
+++ b/showcase/lumencraft/index.html
@@ -4,7 +4,7 @@
| February 2023
Lumencraft is a unique combination of a top-down shooter and base building game with tower defense elements. Enter procedurally generated levels with a fully destructible environment to build your base, dig some tunnels and find the precious Lumen - humanity’s only chance for survival.
BECOME THE SAVIOR OF MANKIND
For two centuries the remnants of humanity struggle to survive without electricity and light. But there is a spark of hope. In 2221 the survivors find Lumen – a crystal of high energy potency that may be the last chance for mankind. Scouts, brave miners, established an underground settlement and voyage into the dark to reach the nearby Lumen deposits. But the darkness consumed them, as the subterranean caves and tunnels hold as much danger as salvation. Now it’s time for you to step into the endless shadows…
DRILL AND SHOOT YOUR WAY TO SALVATION
The lightless underground holds swarms of enemies that will raid your base. Illuminate the gloomy tunnels with your weapons and turrets in a struggle for survival. Drill new paths and shafts to reach valuable resources or blast walls and your foes.
EXPLORE A FULLY DESTRUCTIBLE ENVIRONMENT
With a lot of effort and a set of original algorithms, 2Dynamic Games have transformed the open-source Godot Engine into a completely new tool. This allows every bit of terrain (pixel, as we used to call them) to be destroyed, and maps to be painted as if in a drawing program.
YOUR WAY TO PLAY
Lumencraft offers several game modes to suit your gameplay style. With a 27-mission campaign experience the full narrative of humanity’s struggle for survival. Jump into procedurally generated maps and fight in a true roguelike fashion. Or maybe create your own level in the editor, or try out what the creators and Steam Workshop users have prepared for you. Custom game types (e.g. tower defence, action, survival or mix of them) with user-defined starting technologies/upgrades and goals allow you to test your skills as a scout in any conditions. Invite your friend to play locally or using Steam Remote play and dive into the darkness together.
MAP EDITOR
Easily create stunning maps with moldable terrain and a variety of objects to choose from. Invite friends to play in your custom map and define game types, starting technologies, upgrades, and goals.
We hope the community will create many amazing maps for the Steam Workshop.
KEY FEATURES
Multiple game modes - a story campaign, custom maps created by the developers and the community or procedurally generated levels. The choice is yours!
Defending the underground settlement by direct combat and the use of diversified turrets.
Highly efficient and satisfying digging mechanics (just listen to the sweet sound of crushed rocks and Lumen).
Explosive weapons. Yes, we have dynamite.
Dynamic lights and pixel-perfect interaction with a fully destructible terrain.
Dread atmosphere created through an impactful sound design and a unique 2Dynamic lighting system.
Realistic simulations. Just look at the lava!
Play with your friends in co-op mode either using Steam Remote Play or locally on a shared screen :)
+
\ No newline at end of file
diff --git a/showcase/madness-endless/index.html b/showcase/madness-endless/index.html
index d2daf1f580..4079a0413d 100644
--- a/showcase/madness-endless/index.html
+++ b/showcase/madness-endless/index.html
@@ -3,7 +3,7 @@
Darkness, despair, challenge… The world as we know it is run over by eldritch monstrosities. Survivors are few and far between, stuck between living in this new, grim world and scheming to overthrow others. You have been chosen to bear the greatest burden - the Herald’s Blade. Are you going to help your covenant or take over as the new overlord? Do you really have a choice?
Experience a unique ACTION STEALTH game created specifically for mobile. A hand crafted, pixel art world full of horrific creatures and hidden tragedies. Play with ONE hand and defeat enemies by using slick COMBOS and special ITEMS, while dashing through the environment with blinding speed! Discover a clandestine plot in this ruined world, where friends will betray you and foes will aid you…
Master the blade, master your surroundings and CONQUER!
But remember…
YOU ARE ALONE. YOU WILL DIE. YOU WILL DO IT AGAIN.
After two possible endings, see how far you can get in an ENDLESS MODE where you explore and conquer procedurally generated levels.
Fight against over 15 UNIQUE enemy types, Elite enemies and 4 carefully crafted BOSSES that will test your skills to their limit.
Speak to many colorful characters and try to piece together the bigger picture.
Uncover your own origin as your perspective on evil changes with every nightmare and flashback.
ORIGINAL CONTROLS - Built natively for touchscreen and one handed play, movement and combat interact smoothly and seamlessly.
TENSE, UNNERVING AND MYSTERIOUS - Reap through the ruined world with fast and furious dashes off walls, while staying out of sight of monstrosities, away from traps and countless hazards!
HARDCORE DIFFICULTY - Combine speed, skill, wits & reflexes, to solve increasingly complex rooms, use powerful items, and CONQUER gigantic bosses!
HANDCRAFTED & UNIQUE ARTSTYLE - A depressing, unique, visual horror where every nook and cranny was crafted to keep you on your toes and intensify the experience.
A GRIM quest awaits you! Will you answer the Heralds’ call?
+
\ No newline at end of file
diff --git a/showcase/material-maker/index.html b/showcase/material-maker/index.html
index a8770d4b11..fdcb69b73a 100644
--- a/showcase/material-maker/index.html
+++ b/showcase/material-maker/index.html
@@ -6,7 +6,7 @@
textures, and can be exported for the Godot, Unity and Unreal game engines.
A base library of ~150 nodes that define shapes, patterns, filters and
transforms on textures, as well as 2D and 3D shapes described as signed
distance functions.
New group nodes and shader nodes can easily be created using the user interface.
+View on GitHub
\ No newline at end of file
diff --git a/showcase/of-life-and-land/index.html b/showcase/of-life-and-land/index.html
index e99eef1692..8708e04044 100644
--- a/showcase/of-life-and-land/index.html
+++ b/showcase/of-life-and-land/index.html
@@ -4,7 +4,7 @@
| April 2024
Take the role of a leader delegated to build new settlements in remote, unknown corners of the empire. In those forgotten places, nature is wild and legends are more real and vivid than one may think. Experience the challenges of different seasons and climates in a world, where every animal and every plant tries to find their place in nature, while you lead your villagers. How much will you share with nature? Will you strive for balance or even enforce the extinction of certain animals? Follow the old paths… or find your own.
Build Your Economy
Manage the acquisition, refinement, and distribution of resources. Goods must be transported to desired locations by someone who has the time and space to do it.
Care For All Living Things
Manage the needs of the citizens. They are “alive” and have a specific home, workplace, and broad range of needs and goals. But animals also look for food, get thirsty, sleepy, form groups, look for social interactions, and try to find their place in nature. Even plants need water and the right temperature in order to survive.
Find Balance (Or Not)
Humans share the same space and resources with nature, and they influence each other. While in the beginning the influence of the humans is insignificant, it gets more and more important when the city - and its needs - grow. There is a risk that some animals or groups will become extinct or explosively multiply, depending on your actions.
Observe The Vibrant World
Seasons and weather affect the gameplay. Certain plants grow only in certain seasons, need more water on hot days or freeze during cold periods. Humans and animals need more energy to keep warm in winter or more water in summer to keep cool. In extreme cases, they suffer from exhaustion and may even be harmed.
Take Your Time
You set the pace. Pause the game, speed it up or slow it down whenever you want. Nature is robust, and your villagers develop more complex needs as you progress.
Build Your Own Scenarios
Create your own maps and scenarios in the editor. You can change the landscape, generate plants, and place animals. You can also connect watercourses and create new paths for travellers. Add new maps or link existing ones together to a new world.
Features
Unique deep simulation of the nature in a building strategy game with complex interdependence between humans and nature.
Manage simultaneously the acquisition, refining and distribution of resources on multiple maps in different climatic conditions.
Manage the needs of the citizens. They are “alive” and have a specific home, workplace, and unique needs.
Animals are looking for food, get thirsty, sleepy, and form social groups to find their place in nature.
Plants grow and are affected by the actions of the humans, animals, and their environment.
Seasons and climate affect the gameplay, as certain plants grow only under certain conditions. Temperature affects humans, animals, plants, and the environment.
Interact and trade with other factions that produce goods with the same rules as you do.
Create own maps and scenarios in the editor and extend them using mods.
+
\ No newline at end of file
diff --git a/showcase/pingo-adventure/index.html b/showcase/pingo-adventure/index.html
index 13e6c978d7..397ae9c19d 100644
--- a/showcase/pingo-adventure/index.html
+++ b/showcase/pingo-adventure/index.html
@@ -2,7 +2,7 @@
Pingo Adventure is a cute 3D platformer in a physics simulated world with jiggly plants, bouncy bridge, springy rope etc.
Explore the adorable & interactive 3D world from rainforest, ancient ruins to dungeon filled with hot lava and solving puzzles designed for the physics simulated environment.
But that’s not all, there are mini games in between the platforming level which can be unlocked and played in the “arcade mode”.
And don’t forget to customize your own Pingo with all the costumes that can be unlocked from the adventures.
Features:
Physics Simulation - Immerse in the physics simulated cute world with jiggly plants, bouncy bridge, springy rope and more...
Puzzles - Solving puzzles designed for the physics simulated environment
Mini Games - Collect replayable mini games from adventures
Camera Mode - Capture the cute moments of your adventures from different angles
Character Customization - Customize your own Pingo with various costumes that you can unlock from the adventures
+View on itch.io
\ No newline at end of file
diff --git a/showcase/pixelorama/index.html b/showcase/pixelorama/index.html
index a832e030e8..d415e29826 100644
--- a/showcase/pixelorama/index.html
+++ b/showcase/pixelorama/index.html
@@ -6,7 +6,7 @@
View on GitHub
-
+
\ No newline at end of file
diff --git a/showcase/planetenverteidigungskanonenkommandant/index.html b/showcase/planetenverteidigungskanonenkommandant/index.html
index 4b55547c5b..d2c3ebe64e 100644
--- a/showcase/planetenverteidigungskanonenkommandant/index.html
+++ b/showcase/planetenverteidigungskanonenkommandant/index.html
@@ -5,7 +5,7 @@
-
+
\ No newline at end of file
diff --git a/showcase/precipice/index.html b/showcase/precipice/index.html
index ddc70057bd..2b6efa0c0e 100644
--- a/showcase/precipice/index.html
+++ b/showcase/precipice/index.html
@@ -11,7 +11,7 @@
all pawns in the dangerous game of nuclear chicken.
Manage resources from territories under your control to resolve immediate
crises or win over future allies.
Recreate history, or forge your own path. Put a bear on the moon. The
possibilities are endless with simple, intuitive gameplay that is
-simultaneously difficult to master.
\ No newline at end of file
diff --git a/showcase/primal-light/index.html b/showcase/primal-light/index.html
index 580b04b187..2f9b02505c 100644
--- a/showcase/primal-light/index.html
+++ b/showcase/primal-light/index.html
@@ -8,7 +8,7 @@
victory, leaving a graveyard of grotesque bosses in your wake.
Features
Explore a bizarre and evocative world filled with ladders, levers, traps, and monsters, arranged linearly across 10 levels.
Face 10 challenging bosses in arcade-style combat reminiscent of the 16-bit era.
Master new acrobatic abilities as you progress, allowing you to overcome obstacles and enemies.
Dive into challenging side paths to uncover hidden collectibles, unlocking upgrades and passive abilities.
Experience jaw-dropping pixel art and a hypnotic soundtrack.
Godot has a ton of strengths. A few come to mind. First, Godot uses the pixel as the native unit of measurement, which makes it ideal for 2D games. Second, Godot has a much better implementation of coroutines than other engines (and coroutines are a game developer’s best friend). Third, Godot’s signal system provides an out-of-the-box implementation of the observer pattern that is more intuitive that what you have in other engines (for example, using C# events). Finally, Godot has better animation tools than other engines I have worked with.
Godot has a ton of strengths. A few come to mind. First, Godot uses the pixel as the native unit of measurement, which makes it ideal for 2D games. Second, Godot has a much better implementation of coroutines than other engines (and coroutines are a game developer’s best friend). Third, Godot’s signal system provides an out-of-the-box implementation of the observer pattern that is more intuitive that what you have in other engines (for example, using C# events). Finally, Godot has better animation tools than other engines I have worked with.
— Godot Showcase - Primal Light developer interview
\ No newline at end of file
diff --git a/showcase/resolutiion/index.html b/showcase/resolutiion/index.html
index 8efdc6501e..5a588d0683 100644
--- a/showcase/resolutiion/index.html
+++ b/showcase/resolutiion/index.html
@@ -12,7 +12,7 @@
that doesn’t care if it confuses or kills you — oh hey, a kitty!
Features
16 hour playtime
Explore a grim cyberpunk world where nothing is as it seems
Experience a dark story where you might be the hero - or the villain
Unlock new abilities to defeat your enemies
Survive in brutal fights and crush gruesome bosses
Developing with Godot is very easy. The core functionality can be picked up quickly and the engine is powerful enough to accomplish everything we were looking for in our game. Also the community is awesome and creates plenty of valuable tutorials and guides.
Developing with Godot is very easy. The core functionality can be picked up quickly and the engine is powerful enough to accomplish everything we were looking for in our game. Also the community is awesome and creates plenty of valuable tutorials and guides.
— Godot Showcase - Resolutiion developer Monolith of Minds talks about their experience
\ No newline at end of file
diff --git a/showcase/rogue-state-revolution/index.html b/showcase/rogue-state-revolution/index.html
index d20d5ddf94..d9966cfa32 100644
--- a/showcase/rogue-state-revolution/index.html
+++ b/showcase/rogue-state-revolution/index.html
@@ -9,7 +9,7 @@
global pandemic... no two playthroughs will ever be the same, and each run can
unlock new content as you stay in power longer. The coup is coming: can you
keep your wits about you and hold onto the presidency?
Steer the country in any manner you choose. Hundreds of events and an insane
-number of policies make every experience unique to the player.
We love how Godot's scene structure emphasizes getting things done quickly and flexibly. Writing editor plugins and custom nodes is very useful, and if there is ever something that we want to tackle that it's in the main branch, there is nothing stopping us from cracking the thing open and building our own solutions to whatever problems we might encounter.
We love how Godot's scene structure emphasizes getting things done quickly and flexibly. Writing editor plugins and custom nodes is very useful, and if there is ever something that we want to tackle that it's in the main branch, there is nothing stopping us from cracking the thing open and building our own solutions to whatever problems we might encounter.
— Godot Showcase - Little Red Dog Games talk about their experience
\ No newline at end of file
diff --git a/showcase/rpg-in-a-box/index.html b/showcase/rpg-in-a-box/index.html
index e7ba65e622..6fa35b13d8 100644
--- a/showcase/rpg-in-a-box/index.html
+++ b/showcase/rpg-in-a-box/index.html
@@ -17,7 +17,7 @@
engine's custom scripting language.
Basic dialogue and item systems, multiple camera options, UI customization,
sound effect generator, and much more!
One of the primary aspects that drew me to try Godot was its built-in UI components, since it would allow me to easily build the various editors and interfaces that I needed while also supporting graphical elements like 3D viewports. The fact that it's open source and supports multiple platforms, as well as how lightweight the engine is, are all attractive aspects that made the choice even more straightforward.
One of the primary aspects that drew me to try Godot was its built-in UI components, since it would allow me to easily build the various editors and interfaces that I needed while also supporting graphical elements like 3D viewports. The fact that it's open source and supports multiple platforms, as well as how lightweight the engine is, are all attractive aspects that made the choice even more straightforward.
— Godot Showcase - RPG in a Box developer talks about his experience
\ No newline at end of file
diff --git a/showcase/submissions/index.html b/showcase/submissions/index.html
index c2965066d4..922415de36 100644
--- a/showcase/submissions/index.html
+++ b/showcase/submissions/index.html
@@ -1,6 +1,6 @@
Showcase Submissions – Godot Engine
To ensure that our showcase page reflects the best of what the Godot Engine and its community has to offer, we have established the following criteria for featuring games. These guidelines help maintain the quality and relevance of the games presented.
Eligibility Criteria
👾 Completed Games or Demos: Only fully released games or those with a publicly available demo will be considered for the showcase.
⏳ No Pending Long-Term Releases: Games expected to be released more than 12 months from the submission date will not be considered.
4️⃣ Godot 4 Preferred: While we welcome all games made with any version of Godot, those developed using the latest ones will be given preference.
✨ Polished Experience: The game must exhibit a high level of polish, including well-designed gameplay, user interface, and/or visuals.
📈 Reviews: The game must have at least 100 positive reviews on platforms such as Steam, itch.io, or equivalent. If this criterion is not applicable, supplementary material such as videos, articles, a high number of wishlists, or strong media presence is welcome.
🏬 Active Store Page: The game must have an active and live store page, such as on Steam, itch.io, or another major platform. If the game is self-hosted, it should have its own website with detailed media describing the game.
🚫 Content Guidelines: Your game should be ideally intended for all audiences. Avoid breaching our Code of Conduct, referencing real life events and personalities, international politics, NSFW content, or excessive gore.
🤝 Exemptions for Collaborations: Games that may not fully meet the criteria but are part of collaborative efforts with the Godot Foundation (e.g., featured in events, blog posts, or other activities) may be included at our discretion.
Submission and Review Process
Developers wishing to have their game featured must submit it via this form. Please refrain from reaching out to project members directly. Kindly ensure that all eligibility criteria are met before submission.
Submissions will be reviewed on a best-effort basis, and selected games will be added to the showcase as per the eligibility criteria.
If a game is not selected, we may provide feedback. However, due to the volume of requests, not all submissions will receive a detailed response.
Games that have been pending or have not made significant progress towards release within 12 months may be removed from the showcase.
These guidelines are subject to change. We will update this page should there be any revisions to the criteria or process.
To ensure that our showcase page reflects the best of what the Godot Engine and its community has to offer, we have established the following criteria for featuring games. These guidelines help maintain the quality and relevance of the games presented.
Eligibility Criteria
👾 Completed Games or Demos: Only fully released games or those with a publicly available demo will be considered for the showcase.
⏳ No Pending Long-Term Releases: Games expected to be released more than 12 months from the submission date will not be considered.
4️⃣ Godot 4 Preferred: While we welcome all games made with any version of Godot, those developed using the latest ones will be given preference.
✨ Polished Experience: The game must exhibit a high level of polish, including well-designed gameplay, user interface, and/or visuals.
📈 Reviews: The game must have at least 100 positive reviews on platforms such as Steam, itch.io, or equivalent. If this criterion is not applicable, supplementary material such as videos, articles, a high number of wishlists, or strong media presence is welcome.
🏬 Active Store Page: The game must have an active and live store page, such as on Steam, itch.io, or another major platform. If the game is self-hosted, it should have its own website with detailed media describing the game.
🚫 Content Guidelines: Your game should be ideally intended for all audiences. Avoid breaching our Code of Conduct, referencing real life events and personalities, international politics, NSFW content, or excessive gore.
🤝 Exemptions for Collaborations: Games that may not fully meet the criteria but are part of collaborative efforts with the Godot Foundation (e.g., featured in events, blog posts, or other activities) may be included at our discretion.
Submission and Review Process
Developers wishing to have their game featured must submit it via this form. Please refrain from reaching out to project members directly. Kindly ensure that all eligibility criteria are met before submission.
Submissions will be reviewed on a best-effort basis, and selected games will be added to the showcase as per the eligibility criteria.
If a game is not selected, we may provide feedback. However, due to the volume of requests, not all submissions will receive a detailed response.
Games that have been pending or have not made significant progress towards release within 12 months may be removed from the showcase.
These guidelines are subject to change. We will update this page should there be any revisions to the criteria or process.
\ No newline at end of file
diff --git a/showcase/swords-and-sandals-immortals/index.html b/showcase/swords-and-sandals-immortals/index.html
index 50e0e67c23..137876af72 100644
--- a/showcase/swords-and-sandals-immortals/index.html
+++ b/showcase/swords-and-sandals-immortals/index.html
@@ -2,7 +2,7 @@
Gladiator! Grab your sword, equip your sandals and take on the world in multiplayer Swords and Sandals! Brutal turn-based combat where gladiators can lose limbs, wield guitars and yell so loudly enemy heads will fall off.
Fast, brutal turn based gladiator combat!
It’s Swords and Sandals as you’ve never seen it. Brutal turn-based combat where gladiators can lose limbs, wield guitars and yell so loudly their foe’s heads will fall off. This is the most fun you’ll ever have in the arena, and it all starts here.
Epic online battles against real players.
COMING SOON - Finally, for the first time in over a decade, multiplayer combat will return to the world of Swords and Sandals. Be matched with and test your skills against real humans as you strive to be the greatest gladiator in the whole world. Rise in the leaderboards and prove once and for all who the best player of all time is.
Sever limbs, wield guitars, the choice is yours.
Create a gladiator from one of dozens of races, make them a 7 foot undead giant with a battle axe or a tiny jelly blob with a laser cannon. Your gladiator will be unlike any other, with deep skill trees and hundreds of weapons to craft and equip you will not face the horrors of the arena unprepared!
Continue the story of the Starbound Gladiator.
For a decade we wondered what happened to the Starbound Gladiator at the end of Swords and Sandals III … now all answers are revealed as the robotic Automatons return to Brandor with new space-age technology! Embark upon a massive new single player campaign in the form of Swords and Sandals VI, where you shall journey across the vast continent in search of fabled Arena Champions to defeat. Do battle in the scorching heat of the T’Kash desert, in the lonely abyssal caverns of the Forbidden Depths and in the great palaces of Phaetor itself.
Swords and Sandals Immortals Core Gameplay Features
COMING SOON - Multiplayer mode! At last, battle player controlled gladiators from all over the world in online turn based combat!
Swords and Sandals VI : Continue the story from where S&S III left off as the Automatons return to Brandor with new challenges for our gladiators!
A single player adventure across Brandor featuring over 40 all new Arena Champions ( and some returning fan favourites )
Limb severing and decapitations! Sever arms and legs and keep on fighting as your gladiator finds the strength to endure
Create a gladiator your way. Customize everything from height and weight to facial features and hometown, the choice is yours. Will you be a powerful undead mandolin-wielding barbarian? A Sagan Blob archmage with the power to regenerate lost limbs?
Many new classes to choose, skills and talents to learn. Rain molten death from the skies, play guitar solos that shake the ground!
Dungeon Crawl through fast paced 3D mini-dungeons on your journey, fighting powerful Champions for great rewards
Defeat your enemy using all new combat skills. Throw your weapons, even throw discarded healing potions. Whatever it takes to win!
An all new game engine for the first time in years! New special FX, particles, animations and music, created from the ground up with the Godot Engine.
This is indeed the greatest Swords and Sandals adventure ever. Grab your sword, equip your sandals. It’s time to take on the world and become an immortal.
+
\ No newline at end of file
diff --git a/showcase/tail-quest/index.html b/showcase/tail-quest/index.html
index 993192175c..f703e63c59 100644
--- a/showcase/tail-quest/index.html
+++ b/showcase/tail-quest/index.html
@@ -5,7 +5,7 @@
Stop invaders by placing towers at strategic points around colorful landscapes. Collect hidden treasures, use the environment to your advantage and most importantly, save Nell’s fluffy friends!
Best game for couch co-op play!
Defeat hundreds of enemies and protect your friends!
Game for everyone! Casual, core and hardcore gamers
Game without violence
Colorful and vivid graphics
Tower defense mixed with puzzle platformer game
Explore a tiny world full of surprises
Solve environmental puzzles
Use the lever and watch the entire level change!
Use special items such as tomato-mines, the bubble gun, and more to stop evil robots!
-
+
\ No newline at end of file
diff --git a/showcase/the-garden-path/index.html b/showcase/the-garden-path/index.html
index 52c3074320..d1f981cbc2 100644
--- a/showcase/the-garden-path/index.html
+++ b/showcase/the-garden-path/index.html
@@ -5,7 +5,7 @@
View on itch.io
-
Why the developer chose Godot
I've been an advocate for open source software since I can remember, so Godot just seemed like the right fit. It's a good feeling knowing that my work isn't under the thumb of any kind of restrictive licensing.
I also liked the idea of being an early adopter at the time. There was buzz around the engine, but it still needs those flagship titles that people can point to. And that's really very important, because if people are asking 'how was this made' and the answer is something open source, that's a big accomplishment.
I've been an advocate for open source software since I can remember, so Godot just seemed like the right fit. It's a good feeling knowing that my work isn't under the thumb of any kind of restrictive licensing.
I also liked the idea of being an early adopter at the time. There was buzz around the engine, but it still needs those flagship titles that people can point to. And that's really very important, because if people are asking 'how was this made' and the answer is something open source, that's a big accomplishment.
Something for me to aspire toward, anyway.
— Godot Showcase - The Garden Path developer talks about his experience
\ No newline at end of file
diff --git a/showcase/until-then/index.html b/showcase/until-then/index.html
index 675ef867f2..b94c8e0052 100644
--- a/showcase/until-then/index.html
+++ b/showcase/until-then/index.html
@@ -4,7 +4,7 @@
| June 2024
“The world hasn’t ended yet.”
In a world still recovering from catastrophe, Mark Borja and his friends navigate the joys and woes of another year of high school. Wake up in a typical teenage bedroom, practice piano, race to meet homework deadlines, and build (and burn) relationships, as you reminisce about the daily insecurities of high school life.
That is, until a fateful meeting sets off a chain reaction, upending Mark’s life. People disappear and memories prove unreliable. Uncover a hidden truth with Mark and his friends in this narrative adventure and race to unravel the mystery before it’s too late.
Play Out Your Own Adventure
Meet a diverse and achingly familiar cast of characters to converse with in person, over text, and through email. Get to know them, build relationships, flunk group projects, and watch how their individual personal stories unfold alongside yours.
Investigate the Setting through Everyday Technology
Explore the depths of social media where your likes and comments may pose consequences. Scroll through social posts, emails, webpages, and more on your in-game smartphone, where you might discover hints and clues about the people and world around you. Chat with your friends, classmates, and even strangers.
Explore Themes of Love, Loss, and Friendship
Tackle philosophical issues as the main character. Make mistakes and difficult choices. Will Mark stand up for his friends and be there when they need him or will he let them down? Can he heal his wounds by letting go of the past? Decide for yourself how Mark grows and strives to do better throughout the story.
Play Addictively Mundane Minigames
Insert a flash drive—oh wait, wrong way—nope, it was right the first time. Fight your friend for more fishballs at the food stand outside. Get in the groove to pay for the jeepney. Lose yourself in little games you find yourself playing in everyday life.
Immerse Yourself in a Cinematic Visual Experience
Witness an intriguing narrative uniquely presented in eye-catching hand-drawn pixel art and immerse yourself in the warm colors and music of a world trying to move on from tragedy. Characters, landscapes, and props blend in 3D. Shadows, reflections, and lighting set the tone in a lovingly crafted experience.
Experience a World Inspired by Philippine Locations and Culture
Traverse Philippine-inspired landscapes in search for the truth. From the heart of the bustling capital to long bus rides past grass fields and coast towns, explore the world of Until Then set in a fictional version of the Philippines. Interior spaces are shaped by the mannerisms of the locals, setting the scene for a recent past.
+
\ No newline at end of file
diff --git a/showcase/usagi-shima/index.html b/showcase/usagi-shima/index.html
index 6ebafeaa0b..6311d26b37 100644
--- a/showcase/usagi-shima/index.html
+++ b/showcase/usagi-shima/index.html
@@ -5,7 +5,7 @@
View on Google PlayLearn More
-
+
\ No newline at end of file
diff --git a/showcase/windowkill/index.html b/showcase/windowkill/index.html
index f1b1d62e82..c0f3f65025 100644
--- a/showcase/windowkill/index.html
+++ b/showcase/windowkill/index.html
@@ -7,7 +7,7 @@
-
+
\ No newline at end of file
diff --git a/showcase/wrought-flesh/index.html b/showcase/wrought-flesh/index.html
index 2d1ec80864..be03170e1f 100644
--- a/showcase/wrought-flesh/index.html
+++ b/showcase/wrought-flesh/index.html
@@ -2,7 +2,7 @@
Rip out enemies organs and equip them in your own body. Fight biopunk monsters and drugged-up space bandits. You are a Gajeshian Cultist: A near-mythological being built from the bodies of long-dead saints. You have arrived on the partially terraformed planet of Chrisembourgh on a temple-ordained mission to find and kill someone. Explore the planet and trace your victims steps to the end.
+View on itch.io
\ No newline at end of file
diff --git a/teams/index.html b/teams/index.html
index 363a9fbf22..8eb2980b64 100644
--- a/teams/index.html
+++ b/teams/index.html
@@ -125,7 +125,7 @@
coordination, let us know so we can link it here.
-
/2.341210,48.871951,16/460x250.png?access_token=pk.eyJ1IjoibW96aWxsYS13ZWJwcm9kIiwiYSI6Ii0xYVEtTW8ifQ.3ikA2IgKATeXStfC5wKDaQ)
