Nvidia “Dynamic Super Resolution”

It looks like Nvidia has been implementing real driver support for higher-quality downsampling:

They have a much nicer name for it – Dynamic Super Resolution – even though I still don’t see what exactly is dynamic about it. If you read their description, it does sound like it sets out to fix many of the issues I also tried to circumvent when I first started working on GeDoSaTo:

Enthusiasts with compatible monitors and technical knowledge refer to this process as Downsampling, and for some time they’ve been applying a basic version to improve fidelity in games. DSR improves upon this process by applying a high-quality Downsampling filter that significantly improves image quality, by making Downsampling compatible with all monitors, by removing the need for technical know-how, and by integrating DSR into GeForce Experience, enabling gamers to apply DSR Optimal Playable Settings with a single click.

Improving downsampling quality and making it independent from monitor hardware compatibility have always been two of the most essential goals of GeDoSaTo. Obviously, with driver integration you are also in a position to make things much easier for non-technical users, something which was never a real target for GeDoSaTo.

However, the largest advantages of a driver-based method are the following:

  • Compatibility - since you can act after the 3D API, and not on its level, you get compatibility with any API, including all versions of DirectX and OpenGL.
  • Input Independence – a lot of the hard parts both in writing GeDoSaTo and in configuring it come with making mouse input work, since the OS knows it’s actually running at resolution X while the game thinks it’s running at Y. When operating on the driver level, OS and applications will be on the same page again, removing a major source of issues and need for implementation work.

These are things which are far harder to achieve in GeDoSaTo, and will likely never be possible on the same level.

Nonetheless, GeDoSaTo has evolved a lot from its initial role as just a downsampling tool, with HuD-less screenshot taking, postprocessing, texture replacement and other features taking a major role. Also, it seems like, at least for now, it will remain the only option for larger than 2×2 downsampling. And of course, it will always be more highly configurable – and obviously less vendor dependent – than a driver tool.

In any case, I’m really happy that high-quality downsampling is finally acknowledged by a hardware vendor (and, if history is any indication, it won’t be too long before AMD catches up). And I’m even happier to think that perhaps the reason it happened now is at least partly because of GeDoSaTo.

Introducing GeDoSaTo

This is kind of awkward, but I have to do this quick because of external circumstances.

In 2013, after working on DPfix, I had a vision.

I saw a world in which everyone was free to downsample any game, unbound by the restrictions of their monitor or display driver. One where people could downsample at high refresh rates, and where the quality of the scaling in real-time was finally equal to that achieved in image manipulation programs.

But I dared dream further than that. What about providing a set of tools, which would allow anyone, without low-level knowledge of Windows programming or even access to a compiler, to perform game-specific modifications and improvements such as DSfix, AGmod or DPfix? Why not also enable talented artists to use their craft on any game, not just ones designed to be modifiable by their creators?

Initial Development

Around Christmas, I started work on GeDoSaTo, the Generic DownSampling Tool. It is a testament to both that dream, and to my complete inability to come up with good names. Development proceeded at a furious pace throughout January, using the very latest in development tools:

GeDoSaTo Advanced Bug/Feature Tracking System

At this point, I’d like to thank the beta testers who supported GeDoSaTo development during that time, and also Sara (of Ys PC fame among other things) who provided invaluable help regarding mouse position mapping when downsampling.

The Slowdown

In short, GeDoSaTo worked, but never sufficiently well for me to be happy releasing it to a broader public. It still only supports DirectX 9 and 9ex, and many games have issues even with those. Not all the features I originally envisioned are integrated yet. Moreover, in the second half of February and all of March I was swamped with “real work”, and so the project mostly rested.

However, with the release of Dark Souls 2 coming up, I’ve realized that if I wait until I am fully happy with it I might never release GeDoSaTo. Thus, this post.

Current State

Neat, huh?

Neat, huh?

As you can see above, GeDoSaTo works. It currently sports the following features:

  • Downsampling, better than any other solution:
    • Essentially no resolution limits (beyond those of the GPU)
    • Downsampling from more than 4x the resolution is useful (multi-stage downsampling)
    • Selection of downsampling methods (not just bilinear sampling)
    • Downsampling in linear color space
    • Support downsampling to high-frequency (e.g. 120 Hz or 144 Hz) target modes
    • Not limited by display hardware
  • Take screenshots of either the pre-downsampled full buffer or the actual image displayed on screen (automatically sorted in per-game folders!)
  • Generic texture overriding for all textures loaded using D3DX
  • It uses a far more solid injection and interception method than my earlier efforts

However, there are plenty of bugs, limitations, and many things I would like in order to call it “complete” are still missing:

  • Only DX9 and 9ex supported, and only in 32 bit. No DX10, 11 or OpenGL, and no 64 bit games
  • No per-game configuration yet
  • No plugin or scripting system yet, to allow everyone to implement game-specific graphical features

How? & the Problems

GeDoSaTo works by telling everyone who asks (generally, games and their configuration programs) that a given, configurable, arbitrary resolution is supported, and once that resolution is selected, it will actually use a different resolution in hardware, while pretending to use the other resolution to the software client. The final image is then downsampled (in a very high quality fashion) before being displayed on the screen.

The biggest challenges in development occurred (and continue to occur) due to the million ways an application can list resolutions, chose one, check it and so on. And it gets far harder if a game uses the mouse, with the billion and one ways you can get the mouse position in Windows. Furthermore, the whole interceptor environment is not really conducive to easy debugging, which is currently holding up scripting integration.