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 [External Link].

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.

View this comment - View article - View full comments

Quoting: TheRiddickHope they can include FSR2 and DLSS3 down the line in the support list.

Regarding DLSS

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 [External Link] 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.)

Regarding FSR2

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.

Regarding XeSS

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 [External Link], not its source code. It's also under a restrictive EULA.

View this comment - View article - View full comments

I've noticed the Steam Deck has increased interest in Flatpaks/Flathub a lot. There are a lot more Flatpaks to choose from nowadays compared to last year, even for more obscure things like OpenArena running on a more modern Quake 3 source port [External Link].

View this comment - View article - View full comments

Quoting: pete910To be honest having used HDR on windows in the Past and films ect on my LG oled I cant say it's that impressive. For the most part it resembles some turning the Saturation and colours up to full.

Dare say it's a personnel preference thing at the end of the day.

HDR implementation quality wildly varies across games, with some games having known busted implementations like RDR2 or Horizon Zero Dawn. Some games with known good HDR support are Cyberpunk 2077 (to an extent), Ori and the Will of the Wisps, maybe Spider-Man Remastered or Death Stranding too. You may also have to fiddle with tonemapping settings (HGiG vs DTM, there is no true winner but some people will prefer one or the other).

One common issue with HDR in games is that it's not well-tested by developers or not used as a daily driver, so there is little incentive to make it truly worthwhile. Most engine developers (or even environment artists) aren't using OLED/miniLED displays for development just yet.

View this comment - View article - View full comments

Quoting: mr-victory

These replace the Intel Pentium and Intel Celeron branding.

So Pentium and Celeron are gone? Do iGPUs of these ıse ANV driver instead of cirrus?

All recent Intel IGPs use ANV to my knowledge. The IGP architecture is the same, it's just weaker due to having less execution units and/or lower clock speeds.

View this comment - View article - View full comments

Quoting: Comandante ÑoñardoWhat is the practical function of PROTON_ENABLE_NGX_UPDATER ?

NGX is the library that contains DLSS support (it's compiled for Windows and Linux natively, although there are no Linux native games with DLSS support as of writing). The updater allows updating it independently of the version that ships with the game, as every game may ship with a different version of it (often outdated).

View this comment - View article - View full comments

Quoting: fagnerlnI use the experimental -vulkan option on CSGO, I hope that they updates it to enable the resolution change.

Note that even with Vulkan, windowed mode already allows you to use any resolution with the -w and -h command line arguments. I use this to play in 3840×1620 ultrawide with the window borders hidden by KDE's per-window overrides (Alt+F3).

View this comment - View article - View full comments

Quoting: Purple Library Guy

Nice that Epic gave it their approval too.

Get outta town! Really?

Indeed, they gave around the Unreal Engine 1 source code (under NDA) to several modders. This is how OldUnreal patches came to fruition after all.

There are some interesting licensing constraints though. For instance, OldUnreal's UT99 patch has native Apple Silicon support but OldUnreal's Unreal 1 won't get it.

Tim Sweeney said he'd look into open sourcing UE1 one day, but that was years ago and has yet to happen. I assume a legal review of third-party components (and making the original source build on modern compilers) would take a lot of time for no profit, so don't hold your breath for it.

View this comment - View article - View full comments

Quoting: elmapulOpenGL compatibility for older / low-end devices.

not yet

The OpenGL renderer is already implemented (in WIP state); it's just not exposed in the project manager yet. You can create a project from the command line [External Link] then start the editor using the `--rendering-driver opengl3` command line argument.

View this comment - View article - View full comments

Quoting: damarrinA 16” 16:10 screen, huh. That’s pretty cool. Shame about the res, I wonder what type of fractional scaling it needs to be useable.

2560×1600 on 16" should be usable with 150% scaling (not too bad on KDE X11 or Wayland), which gives you a screen real estate of 1706×1066 (but with improved text clarity over 100% scaling).

You could also try 130% or 140% scaling in KDE (as KDE doesn't seem to offer 125% scaling, unlike Windows).

View this comment - View article - View full comments