QuoteIf we only had a few more programmers. It’s the Linux problem

Lol, a few more programmers? What is Epic, some amateur ad-hoc company?

It's complete BS. It's Tim Sweeney problem - he doesn't like Linux gaming.

View this comment - View article - View full comments

Wine Wayland bits are in usable shape there. Can anyone with Sway/wlroots please test if you have the periodic halved refresh rate bug in it?

View this comment - View article - View full comments

Quoting: GuestYou can generate motion vector data just like how video codecs do. Nvidia also has a sdk specifically for this (nvidia optical flow). I know that it has been used to add motion blur. I dont know how good it would look in practice for FSR3, it would depend on the type of game. It would be interesting to see somebody try it, especially as this can be done with the video encoding unit which is separate from the gpu so it shouldn't really affect performance of the game.

Edit: it seems like FSR 3 already has an option for this and is likely how they add FSR 3 to all games on windows with AMD hypr-rx. So technically it should also be possible to do this on linux too, in proton maybe.

I mean, to do it you need a sample over time. How are you going to do it from a single frame? So the game has to feed it to the library. Post processing filters that can be used without game's involvement work with a single frame.

View this comment - View article - View full comments

Quoting: NociferI'm crossing my fingers that it will be possible to compile it as a DLL and so add unofficial FSR3 support to already existing games, like we can do with DLSS.

I don't think it's possible without games actually using it directly. How would temporal anti-aliasing work otherwise? It's not a post processing filter like let's say vkbasalt.

View this comment - View article - View full comments

Quoting: redmcgI recently learnt that you can also configure WineD3D to translate DX10 and DX11 calls to Vulkan. You can do this in the registry (see 'renderer' @ https://wiki.winehq.org/Useful_Registry_Keys) or with an environment variable; for example: WINE_D3D_CONFIG=renderer=vulkan.

That's possible, but as above, not worth doing it on Linux due to limited vkd3d features.

View this comment - View article - View full comments

Quoting: HohlraumI'm curious what impact Wayland Wine will have on gamescope?

I guess they might drop using X11 and use Wayland proper with it.

View this comment - View article - View full comments

Quoting: doragasuSomeone should make (maybe somebody has) a vd3d vs VKD3D-Proton vs DXVK for dummies, I am always lost about which one is for which use case.

In very short, vkd3d focuses on Vulkan compatibility that would work on macOS with MoltenVK which limits it a lot. Vkd3d-proton focuses on using all modern Vulkan features so it performs much better. So on Linux it's not even a question what to pick.

A bigger question is why Wine couldn't upstream both and use the limited one only on macOS.

View this comment - View article - View full comments

KDE is more attentive to gaming use cases than Gnome.

View this comment - View article - View full comments

Secrecy of console companies is such a total dinosaur of an idea.

It would be nice for Godot to compete with the likes of Unreal Engine.

View this comment - View article - View full comments

KDE supports it better, yeah. Except some scenarios where cursor breaks it, which I think is being addressed at Wayland protocol level before compositors will fix it. But Gnome just doesn't seem to focus on gaming use cases in general, so it takes them forever to add any adaptive sync support.

View this comment - View article - View full comments