Two weeks have passed, time for another release. Lots of fixes and additions in this one, and also many new profiles. My article seems to have worked to at least some extent, it’s great to see pull requests popping up on GitHub (even if most are not code).
- Added feature to disable HUD (in games with a targeted injection profile)
- Added keybinding to toggle through scaling methods
- Added option to prevent Steam Overlay loading (thanks GoaLitiuM)
- Added “loadD3DEarly” compatibility option
- Now possible to list and query readable app name from whitelist
- Fixed downsampling with more than 3 levels
- Fixed stupid typo preventing games with backbuffer formats other than the default from working correctly (thanks Boulotaur2024)
- Fixed crash when framedumping, store framedumps as TGA, create folders for each
- Fixed crash with special characters in blacklist/whitelist entries
- Fixed “interceptOnlySystemDlls” with nonstandard system paths
- Can now sort black/whitelists
- Fixed working directory when launched at windows startup
- Generic Plugin:
- Show exe name and (if available) readable name in status display
- Added option to target screenshots/postprocessing to specific renderstate changes (“injectRenderstate [state],[value]” — example of use in Ys Origin profile)
- Added lots of profiles, thanks to all the contributors
Download GeDoSaTo 0.10 “Poltergeist” here. And if you just found out about GeDoSaTo or have been using it for a while and want to encourage further work on it donations are always welcome.
One more thing: if you want to report bugs or request features, please do so at github. It’s much easier to follow, manage and discuss such things there than in the blog comments!
I wrote a new article for PC gamer about the GeDoSaTo processing/screenshot taking function. It gives detailed instructions on how to create game profiles. Have a look, create a profile for your favourite game and contribute it!
This is mostly a bug-fixing and compatibility release, while under the hood changes continue to get ready for broader API support (which, before you ask, is a lot of work and will still take a while).
- Added nearest neighbour scaling option (this is intended to be used for upscampling in retro games, not downsampling)
- Added “interceptOnlySystemDlls” option to potentially increase compatibility with 3rd party injectors
- Fixed enum ordering in the scaler (should *really* fix Mafia 2)
- Fixed overlays/console not rendering in some games
- Fixed normal resolution screenshot regression introduced in beta 8
- Fixed initialization for games which use automatic depth/stencil generation (e.g. Witcher 1)
- Fixed initial render state settings
- Added option to launch at windows startup
- Added command line option for launching minimized
- Check for and resolve leftover registry entries on startup
- Generic Plugin:
- Extended postprocessing/screenshot targeting functionality (can now delay to first draw after marked pixel shader is set)
Basically, this release further improves compatibility, fixes some bugs and increases the functionality of the generic plugin. It also adds some requested useability features to GeDoSaToTool.
Download GeDoSaTo 0.9 “Underground Network” here, and if you want to encourage further work on GeDoSaTo donations are welcome.
There are even more options which can be configured per-game now, so if you find some compatibility settings (or good postprocessing options) for a given game please contribute on github.
Edit: Oh, and yes, Chrome is probably still falsely flagging GeDoSaTo. Take it up with Google, their processes for trying to get this fixed are stupid.
The first release after open-sourcing the project! There haven’t been any source contributions yet, but at least one person gave me some pointers to issues which need investigation.
I’m very happy with this release, particularly since I managed to fix the alt-tabbing crash bug which has been in GeDoSaTo since day 1 (read more here). But there are lots of other improvements as well, see below.
- Fixed Alt-tab crash when downsampling in fullscreen mode (!)
- Added IDirect3DSwapChain9 interception (fixes compatibility with some games, e.g. Dragon Age Origins)
- Screenshot fallback to full-size if hudless not available
- Fixed Z/stencil buffer format detection (fixes e.g. GTA4)
- Improved handling of automatically generated z/stencil buffers (don’t duplicate, we don’t need an original-res depth buffer when downsampling)
- Generic Plugin:
- Store screenshots after AA/postprocessing, not before
- Only use float BB if required (should improve AA/post performance on most games)
- Added ability to specify a “marker” pixel shader in the configuration, in order to apply AA/postprocessing before HUD rendering and capture hudless screenshots
- Added ability to edit game profiles using the built-in editor (still need to be created externally)
I guess I will need to create a guide for the new pixel shader marker functionality in the generic plugin. Its goal is to allow everyone to enable postprocessing without affecting the UI and hudless screenshots for every game, simply by editing the config file, without coding a plugin or compiling GeDoSaTo. Currently, I’ve added a config file for Blackguards which uses this feature.
Download GeDoSaTo 0.7 “Seishoujo Sacrifice” here, and I always appreciate any donations made here.
If you find a shader hash and create a config file for a given game, please post it on github, I will then include it in future releases.
I just fixed the alt-tabbing crash when downsampling.
This was the result of a bit more than 3 hours of heavy debugging today, after doing the same already (unsuccessfully) a few times previously over the week.
Basically, the issue has always been that my calls to
device->Reset() returned a
D3DERR_NOTAVAILABLE error code. According to the documentation that’s not even possible, but here we are.
My error when debugging this was assuming that similar issues as for “normal” programs could apply. So I spent most of my time trying to hunt down a resource/memory leak – the usual cause for failing calls to
Reset(). I should have known that I am not someone who just leaks memory willy-nilly ;). By the way, Microsoft’s PIX works really well for memory leak debugging DirectX9 applications.
The actual cause was much more obscure, and directly related to what a rather insane piece of software GeDoSaTo is in the first place. Basically, while downsampling, GeDoSaTo manipulates the results of umpteen Windows API calls to give an application the illusion – as perfectly as possible – that it is running on a display featuring the downsampling resolution. As it turns out, when DirectX performs a
Reset operation, it checks whether its resolution switching succeeded using one of these APIs. So, after many hours over weeks of debugging, the solution to the crash is simply to turn off all the relevant interception mechanisms while the
Reset() call is happening.
The source code for GeDoSaTo is now online at:
It includes a (rather short) developer Readme. The code base is, in my opinion, in a much better state than DSfix and DPfix, though I wouldn’t call it “clean” still. But it shouldn’t be too hard to get into.
I hope everyone who has sent me technically detailed mails about potential improvements (and everyone else interested of course!) will contribute!
The best way of contributing is using the GitHub facilities. That is, fork the project, add your improvements, and gather and document them into a pull request. As I wrote in the readme, if you plan to add a major new feature, it would be very helpful if you could contact me before (e.g. by email with a suitable subject line) so that we can discuss the design and not duplicate any work.
Please use the comments for this blog post only to discuss development or issues with this source release!
I’m rather proud of this release. There have been major changes under the hood, and I’m getting ready to release the source (and hopefully get bugfixes, improvements and plugins from lots of contributors).
First things first, I’ve decided to call this release the first beta. Also, since version numbers are dreadfully boring I’m adopting a new scheme whereby each release version will also have a name, and that name will be the name of an album I was listening to while working on it. This time around it’s “Stranger Than Fiction” by Bad Religion.
- Large-scale internal rewrite introducing game-specific plugin system
- Moved all Dark Souls 2 specific code to a Dark Souls 2 plugin
- Added generic plugin which supports AA and postprocessing in games without a game-specific plugin
- Added performance monitoring system (per-frame CPU and GPU timing)
- Added per-game settings support
- Various bugfixes
- Dark Souls 2:
- Added option for different types of SSAO blur (the softer and better performing one used pre-0.5, and a fixed version of the sharper one introduced in 0.5)
- Now start up activated by default
- Added Text viewer/editor component for readme viewing and editing setting files (has various text highlighting and autocompletion features)
- Fixed black/whitelist handling in some circumstances
- Fixed tray icon persistence in case of errors
Here is a screenshot of the new GeDoSaToTool UI:
And here’s what the performance monitor looks like:
In the source screenshot
for the image above you can see GeDoSaTo running with SMAA and postprocessing in Ys Origin.
Download GeDoSaTo 0.6 “Stranger Than Fiction” here, and as always you can donate here if you enjoy using it.
The next steps are writing some developer documentation and a ToDo list, and then getting the source up on GitHub.
This one focuses on adding and improving graphical features.
- Added new HDR bloom & eye adaption effect. Some example screenshots: 1 2 3 4 5. It’s highly configurable in the effect file. Also, it’s not particularly performance intensive, since it does large-scale gaussian blooming on a rendertarget pyramid.
- Improved the SSAO smoothing. It now takes relative depth into account, resulting in more detailed SSAO particularly on small features.
- Added Asmodean’s postprocessing suite as an option. It’s softer and features cinematic tone-mapping, and gives quite a different result from the profile included previously (which is still the default). Performance is comparable over both options. Default Postprocessing / Asmodean Postprocessing. Of course, both options can be customized in detail.
- I’m now distributing the release mode .dll of GeDoSaTo, which could result in a minor performance increase.
For the next version, I’ll focus on polish, adding some small requested features, and getting ready for a source release. In particular, I want to
- Create a plug-in system for game-specific code.
- Move all DS2 stuff to a DS2 plugin.
- Add a “generic” plugin which allows postprocessing and SMAA/FXAA on all games supported by GeDoSaTo.
Download GeDoSaTo 0.5 here, and as always you can donate here if you like it.
Oh, and once again, please do read the README file before reporting issues.
PC Games Hardware published an article (in German) about GeDoSaTo.
What surprised me most about it (in addition to the article’s existence) is the difference they measured between performance with GeDoSaTo downsampling and “native” downsampling. I always expected that to be negligible, at least if you use bilinear downsampling, but I never really benchmarked it. I’ll try to see if I can reproduce their results, and what can be done about it.
In other news, I’m getting closer to the next release, which will primarily be about adding a new HDR bloom & eye adaption effect for Dark Souls 2. This image shows it in-game.
This is a rather big one, even if you are not using GeDoSaTo with Dark Souls 2.
- Add option to completely hide the mouse cursor
- Add option to force borderless fullscreen windowed mode
That’s right, you can now downsample in Borderless Windowed Fullscreen mode! This was a tricky one to implement, I need to make the game think that it runs both in a different mode (fullscreen) and a different resolution than it actually does, both when it uses Windows APIs and when it uses DX to query any information. This feature might therefore still be a bit buggy. Incidentally, this is also a workaround for the crash-on-alt-tab issue when downsampling. However, it breaks the Steam overlay — but you can just alt-tab to Steam instead.
- Fix AO issue on systems with non-4:3 resolution, also improve other effect quality for such resolutions
- Improve AO shader depth calculation
- Upgrade SMAA to the latest version (quality improvement)
- Implement stencil masking for SMAA (performance improvement)
- Include FXAA option (a few people were asking for this since they prefer it in combination with downsampling)
The SMAA performance improvement is rather significant. In one test scene, previously Ultra SMAA would move GPU usage from 70% to 86% on my system, now it’s only from 70% to 80%. In comparison, the same scene with Ultra FXAA takes 77%.
Finally, I updated the readme file to hopefully make the instructions more clear. I’ll repeat them here:
- Extract the contents of the zip to some permanent directory
- Adjust the settings in GeDoSaTo.ini and GeDoSaToKeys.ini as desired
- [optional] Add your game executable names to “whitelist.txt” in the “assets” folder (dark souls 2 is already included!)
- Run GeDoSaToTool.exe *as Administrator*
- Click “Activate” (You can also make a shortcut for “GeDoSaToTool.exe -a”)
- Select the downsampling resolution in-game if you want to use downsampling
- ENABLE IN-GAME ANTI-ALIASING in Dark Souls 2 if you want to use any effects (also, disable in-game AO if you use GeDoSaTo AO, and in-game DoF if you use GeDoSaTo DoF)
Here is the download. And as always, you can donate here to support GeDoSaTo development, both for DS2 and in general.
To reply to the VAC questions: Yes, GeDoSaTo could potentially get you banned in any online game which uses an anti-cheat system. Just like anything else which modifies the game output, such as SweetFX or SMAA injection. Or, if you take user agreements literally, even FRAPS or a Mumble overlay. If you are concerned about this, then do not use anything which at all modifies what a game is doing in multiplayer/online games.
Personally, I hope modern anti-cheat tools are smart enough to figure out whether something just improves rendering or actually modifies the game’s data (that is, real cheating), but I can make no guarantees of any kind.