Nier:Automata AO resolution & tutorial for manipulating game graphics

Nier: Automata is a great game, but sadly some of its effect buffers are stuck at 800×450 out of the box. I’ve put some work into that, and the resulting improvements can be quite significant:

But more importantly, I’ve finally done something I’ve wanted to do for quite a while: write up a tutorial for how to do the things I do, based on an example which isn’t too challenging but also not trivial:

https://github.com/PeterTh/GameManipTutorial

Please give it a read, writing everything down and doing the images was at least as much

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.

When?

Soon.