Compatibility
RTX Remix is primarily targeting DirectX 8 and 9 games with a fixed function pipeline for compatibility. Injecting the Remix runtime into other content is unlikely to work. It is important to state that even amongst DX8/9 games with fixed function pipelines, there is diversity in how they utilize certain shader techniques or handle rendering. As a result, there are crashes and unexpected rendering scenarios that require improvements to the RTX Remix runtime for content to work perfectly.
With the release of our alpha version of the runtime in open source, it is our goal to work in parallel with the community to identify these errors and improve the runtime to widen compatibility with as many DX8 and 9 fixed function games as possible.
Over the next months, you will see revisions to the RTX Remix runtime that expands compatibility for more and more titles. Many of those solutions are in progress and are detailed in our product roadmap
Some of those solutions will be code contributions submitted by you, the talented mod developer community, which we will receive on our GitHub as pull requests and integrate into the main RTX Remix runtime.
RTX Remix is a first of its kind modding platform for reimagining a diverse set of classic games with the same workflow, but it's going to take some investigation and work to achieve that broad compatibility. We look forward to getting there in collaboration with you. For more details on compatibility, please read below.
Remix functions by intercepting the data the game sends to the GPU, recreating the game's scene based on that data, and then path tracing that recreated scene. With a fixed function graphics pipeline, the game is just sending textures and meshes to the GPU, using standardized data formats. It's reasonable (though not easy) to recreate a scene from this standardized data.
With a shader graphics pipeline, the game can send the data in any format, and the color of a given surface isn't determined until it is actually drawn on the screen. This makes it very difficult to recreate the scene - and there are a lot of other problems that occur as well.
The transition from 100% fixed function to 100% shader was gradual - most early DirectX 9.0 games only used shaders for particularly tricky cases, while later DirectX 9.0 games (like most made with 9.0c) may not use the fixed function pipeline at all. Applying Remix to a game using a mix of techniques will likely result in the fixed function objects showing up, and the shader dependent objects either looking wrong, or not showing up at all.
We have some experimental code to handle very simple vertex shaders, which will enable some objects which would otherwise fail. Currently, though, this is very limited. See the ‘Vertex Shader Capture’ option in ‘Game Setup -> Parameters’.
Remix functions as a DirectX 9 replacer, and by itself cannot interact with OpenGL or DirectX 7, 8, etc.
However, there exists various wrapper libraries which can translate from early OpenGL or DirectX 8 to fixed function DirectX 9. While multiple translation layers introduce even more opportunities for bugs, these have been effectively used to get Remix working with several games that are not DirectX 9.
We are not currently aware of any wrapper libraries for DirectX 7 to fixed function DirectX 9, but in theory such a wrapper is reasonable to create.
Games are 'compatible' if the majority of their draw calls can be intercepted by Remix. That doesn't mean there won't currently be crashes or other bugs that prevent a specific game from launching. If the game crashes, but the content is compatible, then fixing the crash means the game can be remastered. If the game's content isn't compatible, then fixing the crash won't really achieve anything.
This also doesn't mean that everything in the game will be Remix compatible - often specific effects will either need to be replaced using the existing replacements flow, or will need some kind of custom support added to the runtime (like terrain).
The best “at a glance” way to guess if a game is compatible is to look at the publish date. Games released between 2000 and 2005 are most likely to work. Games after 2010 are almost certainly not going to work (unless they are modified to support fixed function pipelines).
DirectX 8 and DirectX 9.0 will probably be fixed function, and thus feasible. DirectX 9.0c games are usually mostly shader based, so probably won't work.
The Nvidia Geforce 2 graphics card was the last card to be fixed function only, so if the game could run on that card, it's probably fixed function. Note that many games supported fixed function when they released, but removed that support in later updates. Testing the content It's actually possible to tell dxvk to dump out any shaders used by the game, adding these settings to your environment variables:
DXVK_SHADER_DUMP_PATH=/some/path
DXVK_LOG_LEVEL=debug
If that dumps out a few shaders, then the content may mostly be Remix compatible. If it dumps out a lot of shaders, then the game probably won't be workable.
You can just install the runtime (follow the instructions here) and see what happens. If you don't get the Remix popup on the top left corner when you launch, then the game probably didn't load Remix's d3d9.dll. It may need to go to a different location, or the game may not be using DirectX 9.
If you do get the popup, then you know the game is loading Remix - but not if the content is compatible. The most certain way to check how much content is actually being processed by Remix is to load into a scene and take a USD capture, then open that USD in a program of your choice (i.e. Create). Everything in the capture USD is content that Remix could be raytracing - though it may take configuration and workarounds to get it displaying correctly.
Note that games can display the Remix UI while rendering entirely using the raster pipeline, when all of their rendering is shader based. If the game looks very similar to the original game, there's high chances that it's actually just not working at all.
If you get a crash while trying to do that, well, see the crashes section below.
(Note: this is simplified and meant for someone with no knowledge of computer graphics)
What is a fixed function pipeline? Imagine you're making a little shoebox diorama, and you want the background to look like a brick wall. So you print out a picture of a brick wall and glue it on the back of the shoebox. Simple, easy, works great. This is basically what fixed function does - surface + texture, slap it on screen, done.
What is a shader? What if you want to make it fancier? What if you wanted more artistic freedom to change the back of your box? Well, you could slap a tablet back there, and just display whatever you want on the screen. You could even write a little program that detects where someone is looking at the box from, and changes what is on the tablet's screen based on the viewing angle. This is basically what shaders do - they get passed a bunch of arbitrary data from the app, are told the camera position, and are asked what color a tiny piece of an object is supposed to be.
Until the pixel shader runs for that tiny piece of that object, for that specific camera position, that object doesn't actually have a color assigned to it. The shader has to compute what color it should be. It also doesn't actually output the raw color - it includes lighting and whatever else the game is doing.
That just describes pixel shaders though. Vertex shaders let that tablet change shape however it wants... and I think the metaphor starts to fall apart at this point.
So why are shaders a problem? First off, shaders don't require a standardized description of the scene (positions of surfaces, cameras, lights, etc). Remix needs that information to reconstruct the scene for path tracing, and there's no standard way to extract that information that works across every game.
It can be done on a per game basis, but it's a decent chunk of work for each game.
Secondly, we need to know the color (and other material properties) of every surface - without any lighting or shading interfering. With pixel shaders, there's no straightforward way to get that - even if we could run the shader for every surface, it wouldn't be outputting the raw color data we need. This may be solvable with automatic shader processing, or letting modders write new ray-hit shaders to replace the functionality of the game's pixel shaders, but we'll need to do more experimentation to know what approach will actually work.
Thirdly, there are the vertex shaders - but fortunately, we've already got an experimental solution that handles most vertex shaders.
Once Remix is more stable and fleshed out, it may be possible to remaster shader based games. I've seen the modding community succeed at equally complicated projects, so I'm not going to rule that out. But I don't think it's worth even starting those projects yet - we should focus on the games that are actually a good fit first, build out and stabilize the tech for those, and get some remasters out the door.
Here are some steps to check:
- Open the developer menu
- Click Enable Debug View
- Change the dropdown below it to Geometry Hash
If it looks anything like the image below, then the content is probably remixable. If objects have a stable color, those objects are probably replaceable (once the tool comes out). If a mesh's color changes when you're in that view, that means the mesh won't be reliably replaceable using the current settings - though there may be workarounds with different configurations.
If nothing changes, the game's content isn't going through remix at all. Try lowering the graphics settings as far as they will go, playing with the shader model, or whatever other tricks you can to try to force the game into a fixed function fallback mode.
Regarding the geometry hash mode above: Dynamic meshes are expected to change color every frame - things like particle effects and maybe animated meshes. Animated meshes may flicker, depending on how the game does skinning:
Games in this era could do skinning two different ways:
- Software animation (apply skinning on the CPU) - this will flicker
- Hardware animation (apply skinning on the GPU) - this should be stable
Some games will support both based on some config value, so you may be able to force it into hardware animation.
Remix still can't actually replace an animated mesh, but that's relatively straightforward to do if the mesh is GPU skinned- it is on our roadmap to address in the future.
We have ideas to also enable CPU skinned meshes... but that's going to be a big experiment. It is a more speculative feature, and we will be investigating it sometime in the future.
Disclaimer: this is all theoretical and doesn't guarantee we'll actually be able to get any of this working. Check the roadmap for some more details.
Games do lots of very strange things. Remix does not behave exactly like DirectX 9, and often those differences lead to crashes. These can be fixed - if we can get reliably reproducible examples of them, and spend time debugging and fixing them. It often takes a week or more of work for an engineer to track down and fix one of these, but fixing one crash is likely to fix bugs in many other games. If you have a reliable crash in a game that you think should be compatible, post it up on github as an issue (or add your information to an already posted issue, if it already exists).
Lots of games re-use the same simple shader techniques, for things like terrain blending, camera-facing sprites, etc. It's possible to support these specific features in Remix, by tagging textures and telling the runtime to process them in a different way. As time goes on Remix will have more and more of these specific features supported - and this is a great area for users to submit pull requests.
This is a very hard problem. We've discussed a few approaches internally, but there are lots of unsolved problems here. Right now our priority is more on getting fixed function games working well, and there's plenty to keep us busy there.