Hyperresolution Neptunia 0.2 alpha release

I did some small code cleanups, and more crucially, compiled both .dlls in release mode instead of debug mode. I forgot about that for the initial release, so it had a higher CPU performance impact then expected. Do note that there will still be some CPU overhead from the interception compared to running the vanilla game — this is unavoidable.

Here’s the download, enjoy! And here’s the entirely optional donation link.

Is anyone interested in the source for this one? I don’t mind releasing it, but I made it by hacking an existing glintercept plugin so there’s tons of superfluous stuff in there.

 

Hyperresolution Neptunia 0.1 alpha release

Today I looked into the rendering resolution issue for Hyperdimension Neptunia Re;Birth 1, which was recently released on Steam.

What’s interesting about this release is that it uses OpenGL, which is really rare in Windows games these days. It’s the first Japanese port I’ve seen which uses it. Therefore I was interested in having a look, as I’d never done any interception work on an OpenGL game before.

The good news is that the free software situation is much better for OpenGL than it is for DirectX (and particularly, than it was for DIrectX before I started DSFix and later GeDoSaTo :P), with multiple options available for handling the mechanics of interception/logging etc. After some googling I chose glintercept to base this work on, and I haven’t regretted this choice at all. The codebase seems a bit heavy at a first glance, but you only really need to deal with the plugin interface, which seems solid from what I’ve tried.

As for the game itself, after acclimating myself to OpenGL it was basically the same process as always: find buffer creation calls, intercept, try, find stuff that breaks, and iterate until done. In this particular case HUD and minmap rendering were the easiest to fix of any game I’ve worked on so far, and it took less than an hour for those after I got basic rendering at higher resolutions working.

Anyway, here is the download.

And if you want to contribute to my continuing struggle for more pixels, you can do so here (this link includes a reference that lets me know you are donating because of Neptunia in particular).

 

 

DSFix 2.4

This might in fact be the final version of DSfix. Why? Because Nwks (the original author of the 60 FPS unlocker!) came back and did something which I had considered ideal for a long time now: make it scan for the addresses it needs to patch instead of hard-coding them.

What does this mean for you as a DSfix user? Hopefully, that when/if the game is updated in the future, DSfix, including the FPS unlocking, will still simply work. The only reason this would fail is if the binary code right around the places which need to be patched were to change, which seems unlikely for the smaller patches which can be expected at this point.

Also, since it seems like some hosts are still taking down DSfix for no discernible reason, here are 3 separate links to it:

Have fun!

Edit:
Just to reiterate: this version will not work with the GFWL version of the game, only with the beta Steamworks version (which will replace it at some point).

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 – 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!

Upsampling with GeDoSaTo, other small updates

The past day or two I have been looking into making GeDoSaTo a better tool for upsampling (as opposed to its usual downsampling use case). This might seem meaningless at first, but it’s useful in a few cases.

The most important such case are retro games (or modern retro-inspired indie games) which are stuck at a specific low resolution. In such cases, GeDoSaTo can be used to provide a nearest neighbour (or high-quality bicubic) upsampling, which often looks better than a straight bilinear filter. Now recently, someone integrated Timothy Lottes’ great CRT shader with GeDoSaTo. However, this only works if the shader has a sufficient number of pixels to work with. In order to support this use case, GeDoSaTo can now optionally perform postprocessing after upsampling.

Final Fantasy 6 in BSNES

Final Fantasy 6 in BSNES

The resulting pattern for fixed-resolution games is this: add the fixed resolution as a rendering res in the config file, use nearest neighbour upsampling to your display resolution, and then run the CRT shader. This works well for both emulators and low-native-res 2D titles. Obviously, a lot of tweaking can be done to get the CRT to look just like you want it (sharpness of pixels/scanlines, gamma, bloom etc.). Here’s a gallery with some of my results.

In other news, I also implemented a few small requested features:

  • You can now set the timeout for on-screen messages from GeDoSaTo, or disable them completely.
  • Settings can be reloaded on the fly just like shaders with a keybinding, but note that not all of them take effect immediately. This is mostly useful for trying out pshashes and such.
  • More than one action can now be bound to a key/button at a time.

As always, you can get the full version here or update. By the way, if the update ever fails (i.e. immediately prompts you to update again) delete the .dll and run the installer again. And also as always, if you’d like to you can donate here.

Edit:
Also, buy Valkyria Chronicles.

How recent Unity games do stuff, and a new GeDoSaTo version

Dreamfall Chapters: Book 1 was just released (go buy it), and it’s another game using the Unity engine. Like with another recent Unity title, Wasteland 2, it refused to work with GeDoSaTo. Now, since I like both of these games a lot I invested some time to find out what’s happening, and hopefully fix it.

Without further ado, here are my findings. This is what recent Unity engine games do on Windows if you select “fullscreen” mode. Note that all of this is based on deduction from the behaviour of Dreamfall and Wasteland 2, someone with access to the Unity source probably has a more exact understanding:

  1. Check the desktop resolution and create a fullscreen window as well as a DirectX device with that size.
  2. Check the native monitor resolution (using GetMonitorInfo), and reset the device/window to that size.
  3. Render at whatever resolution you specify in the game settings, to an off-screen surface.
  4. Stretch that surface to the window.

So, no real fullscreen mode in sight. Why would you do this? Well, it has multiple advantages: you don’t lose your resources switching to another rendering resolution, alt-tab behaviour is much faster and more stable, and you get free, correctly implemented triple buffering if the user is using Aero.

Obviously, this majorly messed up the way GeDoSaTo works — and the same goes for traditional downsampling methods. In the latest version, it’s now possible to downsample Unity games following this scheme, provided you add this magic formula to their configuration file:

It works by “pretending” that both the desktop and monitor are the given renderResolution in size, forcing that to always be reported, and modifying the mouse cursor position used by the game (so that clicks register correctly). GeDoSaTo takes care of actually constraining the fullscreen window to the correct size, and of course performs a high-quality downsampling of the rendering result as always.

Since the resolution you want to downsample from needs to be known before the game requests any, only a single rendering resolution can be provided.

Cursor Sidenote

Already in earlier versions, a problem in games using windowed modes was that custom cursors would be lost outside of the rectangular region corresponding to portion of the screen that would be taken up by a window downscaled by the downsampling factor. I figured out why this happens: To make games work, the cursor positions reported to them need to be adjusted (modifyGetCursorPos). This works for any processing within the game, as it thinks it is operating within a larger rendering area.

However, an issue occurs for cursors: I found out that many/most games use the Windows API WindowFromPoint function to check if the mouse is within their window before setting the cursor, passing the modified coordinates. Now obviously, Windows knows what the real window sizes are, and the modified virtual coordinates fall out of them. So I had to apply the reverse transformation in that function.

Release

Anyway, the new version is called “Tokikagura”. Other than the stuff discussed above it also includes some GeDoSaToTool fixes.

As always, grab the installer here or simply update, and if you want to you can donate here.

By the way, Nvidia’s DSR can’t downsample in these games (for now). Take that big boy corporate version!

GeDoSaTo Beta 0.14 “Barrage am Ring”

I’ll shortly release a new version of GeDoSaTo, which includes a pre-alpha version of a custom plugin for Final Fantasy XIII. Its current features are:

  • Arbitrary rendering and presentation resolutions (only 16:9 though)
  • HUD hiding (using the normal GeDoSaTo keybindings)

It’s bugs and known issues are:

  • Some off-by-a-bit scaling issues, making the output less sharp than it should be in some circumstances
  • DoF effects are unchanged (still at original, low resolution – this is more apparent in contrast to higher resolutions)
  • Probably some stuff somewhere is cut off. I saw some scissor calls and am not dealing with them yet
  • Crashes when taking screenshots using GeDoSaTo
  • Rendering resolutions larger than 3840×2160 don’t work
  • Probably lots more

Some observations:

  • The game performs really well from what I’ve seen, both GPU and CPU-wise. But their frame limiting/pacing stuff sometimes seems to bug out.

Tons of stuff can still be improved — obvious ones like fixing bugs and the DoF, but also e.g. probably shadow resolution — so if you like this work and want it to continue consider donating.

Of course, I’d also really appreciate any development or debugging contributions. As always, the source is on Github.

You can download the installer from here, it will automatically grab the latest version.

Don’t report bugs in the comments, report them on GitHub (and check for duplicates or if they are known issues).

GeDoSaTo Distribution Changes Mark II

Sadly the new method didn’t really work out all that well for many people, so I made everything automatic and as foolproof/convenient as I can:

updaterPlease go to the new GeDoSaTo page to learn more.

GeDoSaTo should now be supremely easy to install and keep up to date for everyone!

In the future, I’ll do blog updates about GeDoSaTo whenever there is a new interesting feature, but without an accompanying release, as it should now be very easy for everyone to always get the latest version.

GeDoSaTo release/distribution changes

As you might have noticed, there was no GeDoSaTo release this last weekend, even though I kept up a biweekly release cycle previously.

The reason for this is that I switched to uploading binaries on GitHub.

What this means for you:

  • You can always get the very latest gedosato.dll and executable right here, as well as new config profiles etc.
  • If there is a regression (that is, something which was previously working stops to work), you can help with fixing it even if you cant compile GeDoSaTo, by determining exactly which commit broke it.
  • You need to take slightly more care to also e.g. get the updated configuration file when getting a new version which makes configuration changes.

What this means for me:

  • I have more time to work on GeDoSaTo, since packaging, uploading and documenting/posting about a release does take some time.
  • I get more immediate feedback on new features from people who follow development closely.
  • I get fewer donations, since I usually get one or two with every new release. Well, you can’t win them all.

The current version on Github as of this posting is 0.11.1162, and it has a plethora of new features and fixes over the last “regular” release:

General:

  • Allow multiple downsampling resolutions to be available at the same time
  • Added support for multisampling while downsampling
  • Made the presentInterval setting work even when not downsampling
  • Can now bind Xinput buttons to actions
  • Added option to force presentation resolution regardless of request
  • Fixed Steam overlay rendering with alternative injection method
  • Fixed handling of GetDepthStencilSurface
  • Fixed crash bug with Steam Big Picture Mode
  • Hook d3d9 debug dll separately (restoring third party injector compatibility)

GeDoSaToTool:

  • Unified injection methods (!)
  • Stop accumulating empty lines when sorting
  • Added event handling for unloading dll (related to Steam Big Picture Mode crash fix)

Mitsurugi Kamui Hikae Plugin:

  • Added plugin, has all functionality of the generic plugin
  • Plus can render game at arbitrary resolution (vanilla game is limited to 1080p)

I hope this works out, it seems like a much better solution.

By the way, as I said in the last post, if you do a bug report in the blog comments it will most likely be lost. Please report bugs/issues at GitHub where they can be centrally tracked and more conveniently discussed.

Edit: I realized that this won’t work out for everyone. Stay tuned for new information, hopefully tomorrow.