Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

Godot Engine 3.2.2 is out with 2D batching for the GLES2 renderer

By - | Views: 17,283

Godot Engine 3.2.2 is an update to the current latest stable branch of the open source game engine, which does pull in some big new features.

While it's only technically a maintenance release, they said they're still expecting Godot Engine 4.0 with Vulkan support to be some time away so it made sense to bring in more to the current release.

One of the biggest additions is 2D batching for the GLES2 renderer. This can greatly speed up 2D rendering performance, reduce drawcall-related bottlenecks and more. It depends on how each game is being rendered and only applies to the GLES2 renderer. There's also a lot of bug fixes for both the GLES2 and GLES3 renderers.

More highlights include:

  • C# support for the iOS platform
  • Re-architecture of the Android plugin system
  • DTLS support and ENet integration - better security for multiplayer games
  • Better handling of Variants pointing to released Objects
  • Updated and localized documentation

See the release post here.

Godot Engine just keeps going from strength to strength, hopefully it means more developers will look to use it as it matures both 2D and 3D rendering. Being proper open source and royalty free makes it ideal.

If you're interested to see more on what's going on with Godot Engine 4.0, which brings in Vulkan API as well as tons of new and more advanced rendering options, the main developer Juan Linietsky recently put out a video to show off SDFGI, Godot 4.0's new open world global illumination system:

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link
Article taken from GamingOnLinux.com.
15 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
5 comments

Samsai Jun 26, 2020
I think this release also brings LSP improvements to the crazy people that want to write GDScript in editors like Emacs instead of the integrated editor.
Dunc Jun 26, 2020
Quoting: SamsaiI think this release also brings LSP improvements to the crazy people that want to write GDScript in editors like Emacs instead of the integrated editor.
I totally understand why they're doing stuff like this (and GD-Native, to allow other languages), but I wish more people would give GDScript in the integrated editor a chance. For me, it's what makes Godot special.
Samsai Jun 26, 2020
Quoting: Dunc
Quoting: SamsaiI think this release also brings LSP improvements to the crazy people that want to write GDScript in editors like Emacs instead of the integrated editor.
I totally understand why they're doing stuff like this (and GD-Native, to allow other languages), but I wish more people would give GDScript in the integrated editor a chance. For me, it's what makes Godot special.
I've personally written GDScript inside the integrated editor. It's aggressively okay, as in, it works but that's about it. It doesn't match the editing comfort of my Doom Emacs configuration though and LSP should provide all the completion information that I lacked previously to write the code in an external editor. If I was using a "regular" editor like VSCode/Atom/Geany as my main editor I would probably stick to the integrated editor, but it just cannot hope to match the perfect immortal machine that is a precision-tuned, custom configured editor with modal keybindings.
setzer22 Jun 28, 2020
I've been on the alpha/rc versions of 3.2.2 for a while and I can confirm emacs for GDscript works quite well! Also Godot is a great engine overall and it's nice to see it progress!

@Samsai A note on emacs and GDscript: This relies on lsp-mode, which is painfully slow on emacs 26 due to a custom JSON parser written in elisp. If that happens to you, don't blame Godot. For this to be usable, you'll need to make sure you have emacs >27 compiled with native JSON parsing support (not all distros enable it). On arch, emacs27-git from the AUR worked for me.
Samsai Jun 28, 2020
Quoting: setzer22I've been on the alpha/rc versions of 3.2.2 for a while and I can confirm emacs for GDscript works quite well! Also Godot is a great engine overall and it's nice to see it progress!

@Samsai A note on emacs and GDscript: This relies on lsp-mode, which is painfully slow on emacs 26 due to a custom JSON parser written in elisp. If that happens to you, don't blame Godot. For this to be usable, you'll need to make sure you have emacs >27 compiled with native JSON parsing support (not all distros enable it). On arch, emacs27-git from the AUR worked for me.
I use lsp-mode for Rust and JS already on 26 and the performance is fine. My setup has pretty much got everything compiled down to bytecode anyway, so even Elisp stuff runs pretty smoothly. Might test 27 though, since that's what is recommended for Doom anyway.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.