GeDoSaTo 0.16 Christmas Release

As a holiday special so to speak, today I’m releasing GeDoSaTo 0.16.

The TL;DR version of the updates is this:

  • Fixed a number of memory leaks which caused instability in pretty much all games. In some (most?) it was unnoticeable, but in Final Fantasy 13 and 13-2 crashes could occur as early as after 15 minutes of playtime.
    All of that should be fixed now.
  • As a result of that fix, if you are looking to find a PSHash or VSHash for a game (and only then!) you should enable the new trackShaders option.
  • I’ve also improved keybinding modifier support and borderless fullscreen support.

You can get the latest version with the installer provided here. And, as always, you can donate to support GeDoSaTo development here.

Happy holidays everyone!


The long version for those who are interested:

I’ve been chasing the sporadic crashing issues on and off since the release of FF13. For the longest while, I assumed that they had to be related to screenshot taking, as that was when they first and most often occured. I tried many things related to that (pre-allocating buffers, using the library in a way that causes no additional memory allocations, …) but it turns out that this was, more or less, useless, as I was looking in the entirely wrong place.

When I finally realized that, despite the issue only appearing in the FFs, it had to be a general memory leak in all of GeDoSaTo, I manually checked every single instance of new in the code for the corresponding delete . This was less work than it sounds since I try to write modern C++ where you very rarely call those directly. Over the course of this, I found a few issues, specifically  operator delete  being called instead of operator delete [] . However, since those were arrays of POD types, while bad practice and undefined behavior it wasn’t the issue I was looking for either.

Afterwards, I made a few abortive attempts to use existing leak checking tools, but like many tools designed to make programmer’s lives easier they are really hard or impossible to apply in the — very unusual, admittedly — interception use case of GeDoSaTo. It would certainly be a good idea to implement a stand-alone executable testbench at some point, but these things, they take time.

Yesterday, I finally made the breakthrough. My new approach was to fill the memory almost completely at start-up so as to more quickly reproduce the issue. Then, I got a repeated crash during loading in FF13-2. This reminded me of earlier studies of FF log files, and that it loads far more separate shaders than any other engine I’ve looked at, and some of them 3 times each. And it continues to do so heavily throughout the game, which is somewhat unusual. This lead me to looking at the shader management code, and there I finally found the culprit.

And, as is almost always the case, looking back after finding the bug it seems painfully obvious: to enable things like PSHash HuD rendering identification or injection of postprocessing or AO in the case of specific plugins, I keep a map of all shader pointers and their names (which are derived from their code so as to be reproducible across runs). However, I never remove entries from that map. As it is impossible to know when an entry is save to remove without fully instrumenting shaders (which seems like overkill for this purpose) I’ve solved the issue by adding the new  trackShaders  option. If it is not set (the default), shaders will still be identified if they were set as PSHashes or VSHashes, but only those will be tracked. The only reason to enable the flag is to look for a new hash in a new game.

DSFix 2.3 DMCA takedown

So, Bandai Namco filed a DMCA complaint against DSfix 2.3 and got my Dropbox account blocked from public sharing.

You can all let them know what you think about that.

In the meantime, here is a link to “DSfix 2.3.1″.

If you want to donate to my apparent future need for legal counsel, you can do so here. (That’s a joke by the way, at least I hope it is)



Apparently, this was done in error, in a wide-reaching attempt to purge the leaked debug executable from the internet. While it’s still a problem that the DMCA simply allows companies to take down arbitrary non-infringing files, at least there shouldn’t be any further issues with DSFix.

DSfix 2.3 – Steamworks works

So, much earlier than I expected to, I’m able to present what everyone was waiting for: DSfix 2.3 supporting the Steamworks version of the game!

There is only one change, and that is updating the address offsets for the FPS fix to work with the new version. All other features still work as expected, at least according to my testing.

That this is possible so quickly is thanks to the contributions of boowoo90 on this very blog. Is he an undercover From Software operative? Just a talented reverse engineering guru? Who knows, but he supplied the required addresses in no time at all.

Get the latest version of DSfix here.

As all but the packaging of this update is the work of someone else, don’t donate just for that! However, if you are just now getting into Dark Souls after it is freed from the scourge of GFWL and find DSfix helpful you can donate here.

And remember, if you use the FPS unlock, you need to use some other method to achieve Vsync. Options include your graphics card’s control panel, D3DOverrider, or simply running Dark Souls in borderless windowed fullscreen mode using DSfix.

FF13 article

In unrelated news, my latest article on PC Gamer just got published. It discusses the Final Fantasy 13 and 13-2 ports. Busy day today!

GeDoSaTo updates / DSfix in the Dark Souls Steamworks version


I just pushed a new GeDoSaTo update. Among some smaller stuff, it also includes two significant changes:

  1. Fixes to the Borderless Windowed mode forcing behaviour, which should greatly increase compatibility of that setting (and hopefully not break it in anything it already worked with!).
  2. A new “performance tracing” feature which I used in an upcoming article for PC Gamer, and which I’ll describe a bit more below.

Performance tracing allows you to record the performance of a segment of gameplay to a file. There is a keybinding for it ( togglePerfTrace) which you can configure like any other keybinding (now including modifier keys!), and after recording a sequence it will output a file such as this:

The first 3 lines give general information, including the total frames measured, total duration in milliseconds and average FPS over that duration. The following 3 lines give 99, 95 and 75 percentile effective frame times. These give you a quick idea of the overall smoothness of a game.

Finally, the rest of the file is a CSV (comma-separated value) recording of each frame’s times. The individual measurements are (i) CPU time from the start of the frame to the present call, (ii) GPU time according to D3D API measurements, and (iii) effective frame time from one present call to the next. You can use this detailed data to do analysis or generate graphs in your favourite statistics tool, like e.g. this one representing frame time distribution:

I realize that tools doing something very similar already exist, but they may not report all the information, or not be open source, or not be compatible with GeDoSaTo, so I integrated the functionality.

Dark Souls update / DSfix compatibility

The Dark Souls Steamworks migration update is now live. As I expected, most DSfix functionality I implemented (which is based on API call interception) remains operational, but the framerate unlocking (based on binary hooks) does not work with the new version. This part was implemented by Nwks, so we should hope that he is still around and interested in updating it for the latest version. If not, I can try, but it lies outside my expertise and could potentially take a lot of time (which I’d rather spend on other projects). Of course, there’s also the chance for anyone else to step in, as all the code is available on github.

For now, you can use DSfix with the new version as long as you disable the framerate unlocking feature in the .ini file.