Game developers might want to begin to look closer at this one! The free and open source Godot Engine is about to have the biggest update ever with 4.0 that now has a first Release Candidate. Since it's such a massive overhaul it would be close to impossible to list everything that has changed since Godot 3.x!
Just a small slice of what's actually new includes: Vulkan support, sky shaders, a big upgrade to their GDScript language, upgraded .NET for C# scripting, big improvements to importing and exporting assets, lots of improvements to accessibility within the game engine editor, AMD Fidelity FX Super Resolution (FSR) support, a volumetric fog effect was added, a new global illumination system, an improved and refreshed physics system and the list just keeps on going for quite some time.
Right now their focus is set firmly on fixing up issues and making sure it's truly release ready, so no more new features will be pulled in until Godot 4.1.
Pictured - Godot 4.0 RC1 on Fedora Linux.
Hopefully the 4.0 release, and then 4.1 after will keep pulling more people over to this FOSS game engine, rather than getting stuck with proprietary lock-in from Unreal, Unity, Game Maker and other popular game engines.
See their blog post for more.
Quoting: TheRiddickHope they can include FSR2 and DLSS3 down the line in the support list.
DLSS requires linking against a proprietary SDK (this can be done with `dlopen()`-style opt-in), which is technically feasible but unlikely to happen in core. This kind of optional linking is what PrBoom+-rt and vkQuake-rt use, for instance. Unfortunately, the end result isn't very convenient: even if the engine is built with DLSS integration enabled, this means the user must manually install the DLSS library for DLSS to be enabled (as the DLSS library wouldn't be distributed alongside the editor/export templates).
NVIDIA also requires you to inform them about any commercial release you make using DLSS. This is an additional burden that we'd prefer not to impose Godot users with (Unity and Unreal also require you to send them a form for any commercial release). Lastly, as of writing, the DLSS 3 SDK isn't publicly available yet (only DLSS 2 is).
GDExtension or even C++ modules don't expose what's required to add low-level rendering stuff, so I assume DLSS support will require a third-party engine fork in the foreseeable future. (This is the same approach used as Unreal Engine, where DLSS is distributed as an engine fork.)
On the bright side, FSR 2.x support has no such licensing restrictions and is planned for a future Godot 4.x release. It doesn't look exactly simple to implement though, given the official FSR 2.x buildsystem is heavily tailored towards Windows, Direct3D 12 and CMake.
I know you didn't mention XeSS, but I'll document its state here for completeness. XeSS is in a similar situation as DLSS. Only its compiled binaries are published on GitHub, not its source code. It's also under a restrictive EULA.
Last edited by Calinou on 12 February 2023 at 1:01 am UTC
Quoting: Calinou[It doesn't look exactly simple to implement though, given the official FSR 2.x buildsystem is heavily tailored towards Windows, Direct3D 12 and CMake.
What's the trouble with CMake?
Quoting: EikeWhat's the trouble with CMake?
Godot uses SCons, so any libraries using CMake must be converted to use SCons first. The more complex the library, the more difficult this is. This is especially the case for FSR2 as its build process relies on Windows-only executables we don't have the source code of.
Godot embeds the source code of all libraries in its GitHub Repository, so you can (cross-)compile the editor and export templates from source easily on any platform without having to compile and install libraries separately.
Last edited by Calinou on 12 February 2023 at 1:00 am UTC
See more from me