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
nullvertex 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 withlevels = 0to 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
SharedHeapworks to reduce crashes at launch and require less finetuning of its settings. Since theSharedHeapcan still lead to issues in certain games we switched it to be turned off by default, but it can be enabled inbridge.confwith theuseSharedHeapsetting.- Added forced window client option
client.forceWindowedtobridge.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.zippackage to make debugging the source code from the compiled binaries easier.
See more on the NVIDIA website and GitHub.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
8 comments
It 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.
3 Likes, Who?
Huh. So like, in a weird way Windows games on Windows will all be using Proton . . .It 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.
0 Likes
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?It 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.
0 Likes
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?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.
2 Likes, Who?
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.
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.
2 Likes, Who?
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?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.
0 Likes
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.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.
0 Likes
Patreon
PayPal
See more from me