Don't want to see articles from a certain category? When logged in, go to your User Settings and adjust your feed in the Content Preferences section where you can block tags!
We do often include affiliate links to earn us some pennies. See more here.

NVIDIA open sources more of RTX Remix with v0.2

By - | Views: 20,027

NVIDIA has released version 0.2 of RTX Remix today, which on top of lots of improvements also opens up their NVIDIA RTX Remix Bridge.

What is it? A modding platform that allows people to make "RTX remasters" of various older games enhancing them with Ray Tracing and DLSS. It does this with thanks to the DXVK translation layer, which NVIDIA now have their own fork of just for this. This is the same tech NVIDIA used for Portal with RTX.

As of the 0.2 release they've now also open source the Remix Runtime Bridge, from the GitHub:

The NVIDIA RTX Remix project allows bringing high quality pathtraced rendering, lighting, shadows etc. into classic games. This repo contains the NVIDIA RTX Remix Bridge client and server components required for enabling a 32-bit game to interact with the 64-bit Remix Runtime dll.

So eventually we might see a whole bunch of mods for older DirectX 8 and 9 games, to give them fancy new rendering features. Although, NVIDIA do say on their roadmap they eventually plan to support OpenGL games as well. They should all be easy enough to get running on Linux, since Remix ends up with Vulkan thanks to their use of DXVK.

All the changes from the 0.2 release:

  • The Remix Runtime Bridge is now open source on GitHub! You can find the repo here!
  • Many Bridge improvements have gone into this release to address various game compatibility issues:
    • Fixed issues with shader parser logic that helps with Shader Model 2+ games.
    • Fixed surface data pitch issue that was leading to crashes in some games.
    • Added support for games that change the main window handle on Reset().
    • Allow null vertex declaration on server to fix unnecessary failures in some situations.
    • Properly initialize render state according to the official DirectX9 documentation to fix geometry corruption in some games.
    • Handle CreateTextureXXX() calls with levels = 0 to fix geometry corruption in some games.
    • Fixed mouse input processing for games where the mouse pointer would not move in the game or with the Remix menu opened, and added other DirectInput fixes for games using different exclusive modes. Also added optional input message pump hook that is needed for some games.
    • Better matching of the native D3D9 behavior when dealing with shaders and swapchain initialization.
    • Added more input validation on client and server side – the server is now properly returning failure codes to the client where failure is allowable.
    • Added DPI awareness to the bridge client so that the game window gets scaled and mouse input is handled properly on displays with higher than 100% DPI.
    • Optimized how the SharedHeap works to reduce crashes at launch and require less finetuning of its settings. Since the SharedHeap can still lead to issues in certain games we switched it to be turned off by default, but it can be enabled in bridge.conf with the useSharedHeap setting.
    • Added forced window client option client.forceWindowed to bridge.conf.
  • DXVK-Remix improvements and game compatibility fixes:
    • Improvements to culling issues–Remix now includes an initial set of heuristics to work around engine-side culling.
    • Improved handling of alpha-tested geometry that uses fractional ("feathered") alpha.
    • Improved detection of shadow volumes.
    • Support for capturing normals in vertex capture path.
  • Improvements to RTX Remix menus and documentation: expanded and clarified the existing documentation, and added tooltips in the UI to make it more accessible.
  • Debug symbols for the release are now available in a separate remix-0.2.0-symbols.zip package to make debugging the source code from the compiled binaries easier.

See more on the NVIDIA website and GitHub.

Article taken from GamingOnLinux.com.
14 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.
See more from me
8 comments

CatKiller May 12, 2023
View PC info
  • Supporter Plus
QuoteIt does this with thanks to the DXVK translation layer, which NVIDIA now have their own fork of just for this.
This suggests to me that Nvidia internally prioritise Vulkan over Direct3D. They could have just done it in DXR, and stayed in the DirectX realm, but they've chosen to translate all those DirectX games into Vulkan instead.
Purple Library Guy May 12, 2023
Quoting: CatKiller
QuoteIt does this with thanks to the DXVK translation layer, which NVIDIA now have their own fork of just for this.
This suggests to me that Nvidia internally prioritise Vulkan over Direct3D. They could have just done it in DXR, and stayed in the DirectX realm, but they've chosen to translate all those DirectX games into Vulkan instead.
Huh. So like, in a weird way Windows games on Windows will all be using Proton . . .
Liam Dawe May 13, 2023
Quoting: CatKiller
QuoteIt does this with thanks to the DXVK translation layer, which NVIDIA now have their own fork of just for this.
This suggests to me that Nvidia internally prioritise Vulkan over Direct3D. They could have just done it in DXR, and stayed in the DirectX realm, but they've chosen to translate all those DirectX games into Vulkan instead.
I think perhaps it's more a case that DXVK was just there and ready for them, so it was far easier to do this way?
CatKiller May 13, 2023
View PC info
  • Supporter Plus
Quoting: Liam DaweI think perhaps it's more a case that DXVK was just there and ready for them, so it was far easier to do this way?
Forking an existing tool is much easier than creating your own from scratch, for sure; if they'd done the latter then it would be a much stronger signal that they don't like using DirectX. But they didn't need to use Vulkan at all: Direct3D can do ray tracing. So they've made a decision to use Vulkan.

It might be that they prefer the ins-and-outs of using Vulkan; it might be that they wanted it to be multiplatform (which a DirectX solution wouldn't be); it might be that they wanted it to be open source (which a DirectX solution wouldn't be). Any combination of those would be good things, I think.

But, yeah, maybe there were enough OpenGL games that they didn't want to leave behind, and maybe Collabora's OpenGL-to-DirectX translator just isn't as good as DXVK; but that's not as interesting.
elmapul May 13, 2023
i dont think this is a good idea for 2 reasons:
1)it will differ from the artistic vision (not that any modder care)
2)some old games have baked lights on their textures, RTX wont remove the shadows properly, so the end result will look like crap.

but hey!
" It does this with thanks to the DXVK translation layer, which NVIDIA now have their own fork of just for this. This is the same tech NVIDIA used for Portal with RTX."
that line surprised me! i wish windows users realized how many of the improvments they see in their ecosystem were possible thanks to the linux or opensource comunities.
elmapul May 13, 2023
Quoting: CatKiller
Quoting: Liam DaweI think perhaps it's more a case that DXVK was just there and ready for them, so it was far easier to do this way?
Forking an existing tool is much easier than creating your own from scratch, for sure; if they'd done the latter then it would be a much stronger signal that they don't like using DirectX. But they didn't need to use Vulkan at all: Direct3D can do ray tracing. So they've made a decision to use Vulkan.

It might be that they prefer the ins-and-outs of using Vulkan; it might be that they wanted it to be multiplatform (which a DirectX solution wouldn't be); it might be that they wanted it to be open source (which a DirectX solution wouldn't be). Any combination of those would be good things, I think.

But, yeah, maybe there were enough OpenGL games that they didn't want to leave behind, and maybe Collabora's OpenGL-to-DirectX translator just isn't as good as DXVK; but that's not as interesting.

i dont think they want to support OpenGL and Dx prior to 12 for a long time, so translating then to a modern api is the next best logical choice.
DXVK already exist, and supporting RayTracing on vulkan + using DXVK seems to be an better option for then than writing their own translation layer to translate to dx12.

i wonder if those decisions where based on xcloud vs geforce now competition, or an quick prototype of both options have show then better results in this aproach than one based on DX.
CatKiller May 13, 2023
View PC info
  • Supporter Plus
Quoting: elmapulDXVK already exist, and supporting RayTracing on vulkan + using DXVK seems to be an better option for then than writing their own translation layer to translate to dx12.
They wouldn't need to write their own: Microsoft already translate lower versions into DX12, and Microsoft and Collabora made one to translate OpenGL into DX12.
Marlock May 13, 2023
eventually supporting OpenGL... using Zink atop the current vulkan stack maybe?
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!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.