A tale of two games

Hey folks! Almost time for a new release :-D

And as you might have guessed, this time I'll be extending VR support to not one, but two new games. Or to be accurate, one new game and one old game.

No actually, to be even more accurate, both are old games. Or maybe I should say they both were once old, but at some point became new again?

Mmm, where was I... Ah yes, the new release.

I'll write two separate posts, one for each game, since there is a lot of information to go over. But first let me give you a changelog of what you will find in the new version, apart from the additional games:

• Star Wars Outlaws has been thoroughly checked after the latest official update and fixed where needed;

• Atomic Heart has been restored to full functionality after the latest VR-breaking update;

• it will now be possible to force DLSS 4 in games directly with the NVIDIA app (or the Profile Inspector for games that the app doesn't recognize), without needing the DLSS swapper anymore;

• my DL(S)SS implementation has been revised to compensate for forward/backward camera movement, and the stereo image will now remain correct both with the original game DLLs and when forcing the new DLSS 4, no matter whether the CNN or Transformers model is used;

• the mod overlay will now undock automatically when you try to move it around with the gamepad or keyboard, which should make it easier to navigate even in games that cannot rescale the desktop window. [Sidenote: my framework uses Dear ImGui for the user interface, which despite being the undisputed #1 library for this kind of application can be really obscure and counterintuitive at times. As an example of this, by now most of you know that the gamepad gesture for moving an ImGui window around is using the left stick while keeping the 'X' button pressed ('square' button for PS-style controllers), but there's also a little-known keyboard gesture where you press Ctrl+Tab, as though you wanted to cycle tabs, and then you release Tab and while keeping Ctrl pressed you use the cursor keys to move the window around!];

• spurious cameras appearing in the Quick Menu presets in some games have been corrected.

Besides the above list (and the two new games of course), in the upcoming release you will find a new mechanism that I call the VRAM Guard, which I hope will be a nice quality-of-life improvement.

AAA games are becoming huge, and lately even the 24 GB onboard the RTX 4090 are no longer enough to guarantee that there will be some free VRAM at all moments while a game is active. The VR runtime on its own can consume several gigabytes (for instance, while writing this I'm seeing OVRServer_x64.exe, the service that powers the Oculus/Meta runtime, gobble up around 4 GB of VRAM just to run Link, without any games open). My mod also needs VRAM to move video data around from the game to the VR headset, and to implement temporal processing like AER v2 or DL(S)SS. Third-party overlays allocate their own chunks of VRAM... the list goes on and on.

Last-gen games usually try to expand their memory pools until all VRAM is utilized, especially when running with high graphics options and best-quality textures. But the games don't know about the VR runtime (because they were not designed to work in VR), and often developers make the wrong assumptions about users not wanting to use anything else on their PCs while a game is open. All of that can result in overallocation, and if at any given moment the total VRAM capacity of the GPU is exceeded the OS will start swapping out the misbehaving application. The end result is that suddenly the game goes from fluid to choppy, and if this VRAM thrashing cannot be corrected immediately, frame rate will plummet to 1-5 fps and the game could even crash to desktop.

One or two years ago we could simply be careful not to have other VRAM-hungry applications running at the same time as the game, and invest some money into buying a card with a larger VRAM size. But games' texture and geometry pools have grown much faster than video cards, so explicit management of the problem in real time is now needed.

The VRAM Guard will try to do just that. It will attempt to prevent the game from greedily expanding its requests until all video memory is used up, so that the OS will never need to come down hard. Operation should be mostly automatic, but you will have some control on it. Navigating to the VRAM Guard section of the R.E.A.L. VR main overlay tab (for games where I implement it), you will of course be able to disable or enable the guard. If enabled, you will see a slider that controls the portion of total VRAM which is made available to the game, and you will get real-time information on video memory pressure and statistics on overallocation.

You can just forget that it's there and let it do its thing, or if you like to squeeze out every drop of performance, you can use the VRAM Guard to monitor more strictly the moments when the game is most likely to overallocate. For example, you might want to give a tight budget to the game when you're changing resolutions, choosing DLSS quality presets, experimenting with graphics options... all operations that can potentially trigger VRAM thrashing. Then when you're happy with your settings and the initial allocations are done, you can drag the slider to the right to give back all the available budget to the game so that you get more fluidity and keep texture pop-in to a minimum. Or you could decide the budget based on the complexity of the level and the choppiness you're experiencing, or you might want to restrict the game usage to give some breathing room to your capture/streaming application.

As always your feedback will be super important in deciding whether this works or not, and if it does, in which direction it should go for future improvements!

See you soon ;-)