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.



PtBi 5.1851 Released

Some recent emails reminded me that there are still people out there who use PtBi. It seems like AMD got more strict in their interpretation of the GLSL standard somewhat recently. This new version should hopefully fix that issue, and it also includes a few other things:

  • Various sound bug fixes. This time around, audio is really fixed.
  • A new, more readable console font.
  • Statistical tracking of frame processing time and audio buffering.
  • A snazzy overlay display for that information (the default toggle key for it is bound to “T”).

Here’s a screenshot:



Public VR Demonstration using Rift DK1

I rarely post about anything work-related on this blog (the last time was over a year ago), but I really wanted to write about this one. I’ve been a huge supporter of VR and the Rift since before the kickstarter, but the overwhelmingly positive reception when I had the chance to use it in a public demonstration still surprised me.


There is an annual event at Austrian universities called the “Lange Nacht der Forschung” (Long Night of Research). Basically, for one evening/night – starting at 17:00 and going on until 24:00 – the Universities prepare demonstrations, talks and interactive sessions about research for a general public. It’s (surprisingly?) popular, with 136500 visitors this year. There’s a great variety of visitors, students, families with their children, and even seniors.

Our Demonstration

This year, our group was asked to do a demonstration again. Since I wanted to do something which is both related to our current research and engages people I had a pretty hard time coming up with ideas. In the end, I settled on taking the result of one of our compiler analysis methods (designed and implemented by Herbert Jordan) which generates a Petri net representing the parallel execution of a program, and visualizing it in VR using the Rift.

I had a prototype up and running using OpenSceneGraph, but with the recent release of UE4 with licensing for mortals, I decided to try it using that. With just a bit over a week to go (and, it turned out, a few graph layout papers to read and 3D models to create in addition to getting used to coding for and working with a huge engine from scratch) it was a tight squeeze, and quite exhausting, but I completed it in time.

If you can read German you can find more detail here. Basically, it’s a set of nodes (2 types) floating in space, connected by “bridges” representing graph edges, and with pillars showing the ID of the related program node/construct, as well as (optional) “monitors” showing the associated code for e.g. region constructs. Here’s a screenshot:

Screenshot of the Visualization (Non-VR mode)

Screenshot of the Visualization (Non-VR mode)

For the actual demonstration at the event we also had a 30″ screen mirroring the Rift output set up, so that people could see what’s going on, as well as a copy of the poster I linked above to explain the context of what was being presented.

The Reactions

Now we get to the part which is actually interesting. I was really curious how these “normal” people would react to the Rift. I am happy to say that the overall reaction was much more positive than I expected, despite all the technical shortcomings of DK1. We had a group of people watching and waiting for their turn for the entire duration of the event (so 7 hours, actually closer to 7 and a half if you take all the time before and after the official start into account), and probably around 250 people using the Rift.

We had a wide range of visitors over all age and gender boundaries – with families, normally it would be the kids trying the Rift first and then convincing their parents or grandparents. Here are a few photos:

Some remarkable incidents and things of note I observed:

  • We actually had to reassure people multiple times that “we’ll still be here for 5/4/3 hours” during the most crowded periods.
  • Upon it being explained that importing DK2 to Austria will cost about 400€, most people were surprised at how inexpensive that is. One particular remark I remember is a boy (probably elementary school age) exclaimed “Wow, that’s 100€ less than the new Xbox!”.
  • A young woman in her early 20s telling her boyfriend “we need one of these at home” after walking around in the demo for 2 minutes.
  • More people recognized the Rift than I expected. I’m sure some of that had to do with the Facebook deal and the reporting around it.
  • You could easily tell if someone who tried it was familiar with twin stick FPS gameplay. Gamers would zip around using both sticks, but often fail to move their head and just look at stuff until prompted to do so. On the other hand, non-gamers would turn exclusively using their head/body, and be in danger of getting wrapped up in cables.
  • “Mom, can I get this for Easter?”

That’s it, pretty much. After this exhausting but fun experience I’m more certain than ever that VR will not just become big, it will do so very quickly. Oh, and I’d like to thank Philipp Gschwandtner for helping me with the demo, and for taking all the good pictures you see in the gallery above. The bad ones were taken by me.

Aliasing and Anti-aliasing Comparison Tool

ss_2013-12-24_20-32-42This is a tool for illustrating the various types of aliasing which can occur in computer graphics, and how many common methods of anti-aliasing interact with them. I wrote it to accompany an article which will be published some time in the future, and which contains a rather detailed treatment of the topics of aliasing and anti-aliasing.

A main point is to also show aliasing (that is, flickering and image instability) in motion, which is insufficiently captured by the common screenshot or (compressed) video comparisons.

There are 6 types of aliasing shown (transparency aliasing, geometry aliasing (2D and 3D), sub-pixel aliasing, texture aliasing and shader aliasing), and many methods of anti-aliasing are available.

ss_2013-12-24_20-44-07The 1-8 keys are mapped to presets which show some common anti-aliasing methods:

  1.  none
  2. 4x MSAA
    multisampling, generally sparse grid
  3. 2×2 OGSSAA
    ordered grid supersampling with 4 samples
  4. 4x SSAA
    turns the 4 multisamples into supersamples, thus 4x SGSSAA on most HW
  5. FXAA
    just post-processing, see sub-pixel effects
  6. SMAA
    as above (note better motion stability)
  7. 1.5×1.5 OGSSAA + SMAA
    similar to what can be achieved via injection in most games, often decently playable
  8. best
    maximum number of SGSSAA samples plus 2×2 OGSSAA. Close to the “ground truth”, that is the perfect representation of the scene on the pixel grid

Let me know if anything breaks. I do know that the PXAA and TPXAA PPAA methods don’t work on AMD, if anyone wants to help fix it (and has the time) contact me and provide some means of synchronous communication (e.g. Steam ID).

Source code release soon.

Download here!

(If you encounter an error about missing some .dll when running the program, get the Microsoft C++ redistributable here)

(Edit 2014-1-14: updated to fix an issue which could occur with some AMD drivers)

DPfix 0.9.5


  • Various adjustments to improve compatibility with version 1.01b of Deadly Premonition
  • Removed the “disableJoystick” option, as it is now superfluous (the bug it was designed to work around was fixed by the developers!)
  • Made AA apply in some circumstances where it did not before, like the in-game menu
  • The distribution version now includes (optional) logging, to make debugging problems easier

Sorry for the delay, as I wrote in the last update I didn’t really have much time to work on this over the past 2 weeks. One important thing: if you are experiencing any issues, please reboot your system and see if they are still reproducible afterwards. Even in its current version the game is still quite susceptible to strange random issues which go away after a reboot.

Download DPfix 0.9.5 here (donate)

DPfix 0.9.1 (Updated)

Here we go, I hope this one works well for everyone (unlike 0.8).

VSSAO2 screenshot


  • Fixed the issues introduced on some systems by 0.8
    (which were caused by the haphazard way I tried to fix the offset issue)
  • Fixed Video size during profiling
    (this was a bug related to improving the reflections introduced in 0.7)
  • Really fixed the pixel offset error, at all resolutions
  • Added high quality “VSSAO2″ option (see above, compare: off / on)
  • Adjusted windowed mode so that it’s possible to move the window

Tracking down the profiling issue and the correct fix for the offset error was rather cumbersome. Here you see the culprit for the “halos”:

Downlaod DPfix 0.9.1 here (donate)


DPfix source release

The source code for DPfix is now up on github.

I always planned to do this, but I decided to do so earlier rather than later for a few reasons:

  • 0.8 works perfectly for me, but causes problems on many other systems, and it’s very hard to “remotely” debug issues.
  • I’ll be really busy with work the rest of this week and throughout next week, so I can’t spend as much time on Deadly Premonition (or anything really) as I would like.
  • Someone asked for it.

Now, when I released DSfix I was a bit disappointed by the lack of external contributions. There were a few brave souls, and I’m very grateful, but overall 95% of the code in DSfix is still written by me and untouched.

I think the problem was at least partly a lack of documentation and guidelines on my part, so I just spent over 2 hours writing up a developer README for DPfix. Have a look if you are thinking about contributing, or if you simply want to get a better idea about how Deadly Premonition works or how I create these interceptors.

DPfix 0.8

Edit: Apparently there are some issues with this version on some configurations. If you experience any problems, revert back to 0.7.1 until I can figure this out.

Closing in on the final version.


  • Fixed pixel offset error in light buffer with higher rendering resolution (caused small halos around some objects)
  • Fixed AA not being correctly applied when the game uses the alternative rendering path (e.g. in the gallery)
  • Added option to improve the Depth of Field effect (reduces flicker/pixelation)
  • Added intial version of SSAO (screen space ambient occlusion) option

Some of these were much harder than they should have been. Maybe I’ll write up a longer post at some point with some more in-depth explanation of some of the things which go on in Deadly Premonition’s rendering pipeline, and how they affected DPfix development.

Download DPfix 0.8 here

Also check out this high-res font/UI pack by InfiniteNine.

This is the “halo” effect I’m talking about in point 1:

It was caused by some pixel size (or rather, 0.5/pixelsize) shader parameters not being correctly updated with the increased resolution, both for vertex and for pixel shaders, and it got worse with higher resolutions. It should be completely fixed now.

The DoF improvements can be seen in the shot up top already, with a less muddy/pixelated but still unfocused image in the distance. Finally, here are two screenshots showing off the current SSAO effect:

SSAO off | SSAO on

As always, if you like DPfix you can consider donating here, and if you enjoy the work InfiniteNine did on high-res UI textures you can donate here.

DPfix 0.7.1 (Updated)

I’m quite proud of this release, since it accomplishes something which is amongst the hardest things I did in any of my interceptor .dlls so far, and which I failed to do back in DSfix: improving the quality of the shadow mapping.

mirror finish


  • Fixed an issue that could happen when reloading and encountering a dual-perspective scene twice (0.7.1)
  • Fixed crash when accessing the Add-ons menu (might also fix other crashes)
  • Added the ability to improve shadow rendering: shadow map resolution and precision settings
  • Added reflection resolution setting (affects e.g. mirrors, see screenshot above)

The most complex of these is the shadow change, and it also make a rather large difference, as you can see for part of the shadow map of the opening scene below (Left shows the default, and right with settings shadowMapScale 4 and improveShadowPrecision 1):

shadow buffers

There are some minor bad news which come with the crash fix, since it involves changing how textures are hashed:

  • All A few existing texture mods may no longer work, until they are updated to the new hash code.
  • The fix for dual-scene rendering is also affected, and will not work until I can get to such a scene in the game again and find the right hash. (Or until someone provides me with a savegame in the room in chapter 5)

I will release a 0.7.1 to fix the latter issue once I am able to do so, I did not want to delay this release further since I might not get a chance to work on anything concerning Deadly Premonition until Saturday.

Download DPfix 0.7.1 Here

As always, if you enjoy this release, you can donate here.

DPfix 0.6.1 (Updated)


Just a small update:

  • Fixed crash caused by using the texture override functionality (sorry about that one)
  • Added screenshot functions for both normal and hudless screenshots
    You can configure the keys for screenshots in DPFixKeys.ini and the path they are stored at in DPFix.ini (default is [game path]/dpfix/screens)

Download DPfix 0.6.1 here

You can get the override textures used in the screenshot above here. The key texture can be used together with a controller profile to get correct key prompts when playing with a controller (particularly handy during QTEs).

(Ye olde donation link is here, since every post tagged dpfix could be the first/only one someone new sees)

Edit: 0.6 broke texture dumping, 0.6.1 fixes it again. Download from the link above.