GeDoSaTo Injection, Once Again

Based on various bug reports and testing, I’ve identified 3 major causes which have contributed to the issues with the new injection system that some users of GeDoSaTo have experienced. Two of these are fixed now, and the other one is a system setting which is reported by GeDoSaToTool for you to fix.

The problems were:

  • Whitelist-based injection was case aware, while previously it was case-insensitive. Since case is based on the launch name of the .exe, this is not always easy to identify, and therefore I made it case-insensitive again.
  • Installing GeDoSaTo to paths with spaces in them would prevent it from working. This was fixed by generating the short path name rather than using the full path for injection.
  • On Windows 8 and 10, if the UEFI secure boot feature is enabled, it prevents the injection mechanism used by GeDoSaTo from working. I’ve added a step to the installation guide about this and also check for and report it as an error in the tool.

Luckily, all of these so far could be fixed without jeopardizing the stability and compatibility improvements of the new injection system.

I’ve also fixed some small issues in the updater/installer, and it now keeps a backup of the replaced executables/dlls until the next update (even though all of them are always available on github).

You can get the latest version by updating from within GeDoSaTo or with the installer provided here. And, as always, you can donate to support continuing GeDoSaTo development here.

Improving Mushihimesama with GeDoSaTo

BannerQuite recently Mushihimesama was released on Steam. It’s one of the best games in its genre of all time, and I urge anyone with even a passing interest in STGs to pick it up.

Sadly, the port has a few annoying issues right now, and while I’m sure that they will be fixed eventually, if you are like me and just can’t wait the latest GeDoSaTo version fixes pretty much all of them.

The issues are (or rather, were ;)):

No support for native resolution

It’s a 2D game, so no big deal, but scaling once is still nicer than scaling twice. This is easily fixed by the forcePresentRes option in GeDoSaTo. It induces some minor artifacts in the menus, but is perfect in-game.

Bad framelimiting logic on some systems

This results in ~57 rather than 60 FPS gameplay. Fixed with the new  timeGetTimeFactor  option which fools the in-game limiter, in conjunction with limiting the framerate with GeDoSaTo instead.

Crashes on pressing “start” at the startup screen

This is by far the most pressing issue, and also affected me. Looking at all the API calls the game makes before crashing, one can determine that it is probably related to how it queries Steam friends. Therefore, I added the capability to intercept the Steam friend API to GeDoSaTo. This was a bit of effort, but sure enough, “pretending” low or zero friends with the resulting new  steamFriendsLimit  option fixes the crashes for good.

Important Note

To use GeDoSaTo with Mushihimesama, set DispFull=1 in Mushihimesama.ini, otherwise it might crash on startup.

You can get the latest version by updating from within GeDoSaTo or with the installer provided here. And, as always, you can donate to support continuing GeDoSaTo development here.

Not that if you use a non-16:9 display, or still experience framepacing issues with the game, check this post.

Injection issues

I haven’t forgotten about the injection issues. From the feedback on Github, it seems like the primary culprit for the vast majority of issues is the “secure boot” option. I’ll add a check for that and make a seperate announcement when it’s done.

Zestiria character shadow improvements, GeDoSaTo injection compatibility

I just pushed a new game-specific plugin for Tales of Zestiria which increases character shadow resolution/detail. It’s just a minor change, but it was annoying me that the in-game shadow setting increased environmental shadow resolution, but only blurred character shadows more. It just doesn’t make sense that shadows (ostensibly from the same light source) would look completely different if they were cast from characters rather than the environment.

It turned out that the character shadows were being rendered at only 64×64 (!), with 128×128 for Sorey, so it’s hardly surprising that they lacked detail. The new game-specific plugin rectifies that, and it’s designed to show similar detail to the game’s “high” environment shadows. Compare:

Original character shadowsModded character shadowsNote how the character shadows are just amorphous blobs in the original image. This would be fine I guess as a design choice if it was uniform, but the environment shadows right next to them are much more sharp and detailed! In the modded version, I tried to unify their appearance so that they look like they belong in the same scene.

GeDoSaTo New Injection Compatibility

By now, I’ve got a lot of feedback on the new injection method. What I expected was for quite a few games to stop working for everyone, while others would still work perfectly. That didn’t really happen to any extent.

The good news is that the new (much safer) injection method seems to have fixed injection issues with the previous version for a large number of people. Perhaps even more importantly, it appears to have completely eliminated both updating issues and crashes in unrelated applications for everyone, which was very important to me. I really don’t want people to download GeDoSaTo and experience random crashes, which was the case for some previous versions.

The bad news is that there are people for whom previous versions worked which report that the new version doesn’t work at all. Worse yet, there’s no pattern which I could discern so far as to who it works for and who it doesn’t work for.

Therefore, I ask both people for whom the new version works and those for whom it doesn’t to report here. I hope we can track down some common reason for the behavior.

GeDoSaTo 0.19 “Chaos Flare” – Completely revamped injection

I just released a new version of GeDoSaTo, 0.19 “Chaos Flare”. This release completely changes the injection method. The goal is to be:

  • More consistent. There is now only one method of injection for everything.
  • More compatible. The first injected dll is extremely small, adheres to the Windows standards for DllMain and has no dependencies on any libraries.
  • Safer. The inital dll is written in a very defensive fashion, always loads correctly, and always unloads itself from processes.

This required switching to a 2-stage injection process. Instead of directly injecting the full GeDoSaTo dll, dragging in all its dependencies, and then checking whether it should unload itself, there is now a separate, minimal “shim” dll which has the sole task of injecting the full GeDoSaTo only into whitelisted processes. The entire injection workflow now looks like this:

injectionIn some more detail, the advantages of this are primarily that the “shim” dll, gedoshim.dll, has no dependencies at all except for kernel32.dll, which can be assumed to be present. Furthermore, it doesn’t perform any extensive processing in its DllMain entry point, but rather defers it to a thread it launches. Finally, it always unloads itself, regardless of what happens. All of these properties together should make it almost impossible for it to crash arbitrary processes, even if something does go wrong.

All of this required somewhat major changes, over the course of which I also got rid of some features which shouldn’t really have been used anyways. There are also some drawbacks to this, the extent of which will only be apparent after more people test this latest release:

  • The blacklist feature is gone completely. Every executable you want to run with GeDoSaTo now needs to be whitelisted. It’s safer, reduces complexity, and is really not much work at all.
  • Due to purging the old dual-injection method, the “delayDetouring” option no longer exists. The hope is that games which required it will now simply work anyway, due to the more solid implementation.
  • As you can already see to some extent in the illustration, it’s possible that the new injection mechanism leads to hooks being initialized only after a game has already performed some processing. This has not occurred in my limited testing so far, but it could nevertheless be an issue.

I’ve also used this opportunity to clean up the interface a bit, particularly in Windows 10, and update the readme for the first time in a while.

I’m looking forward to some user feedback on this release. I knew that these changes have been necessary for a while, but I dragged it out due to the high degree of annoyance caused by the shim dll implementation. String processing in C++ isn’t that great in the first place, but without any libraries (including the standard library!) it’s just terrible.

You can get the latest version and test this injection method with the installer provided here. And, as always, you can donate to support GeDoSaTo development (including annoying injection shims!) here.

Note that the main GeDoSaTo dll still requires the latest VC libraries.

From feedback on Github, it sounds like this update accomplished what it was supposed to. Whew, I’d have hated for all this work to be in vain.

Tales of Zestiria article, and the state of GeDoSaTo stability/compatibility

Starting with the good news, I’ve completed another port analysis for PC Gamer, this time around for the recent Steam release of Tales of Zestiria. In short, it’s about as good as a 30-fps-locked port can be, and I was particularly impressed by its keyboard and mouse input support.

To mark the occasion I’ve also pushed a profile for the game to the GeDoSaTo repository, which allows correct mouse mapping while downsampling and includes a PSHash for HuD toggling and HuD-less post-processing/screenshots.

Talking about GeDoSaTo, I’m well aware that the most recent version introduced serious compatibility/injection issues for some, and I’ve already invested some time in trying to pin those down. At this point, I’m still not sure what’s going on, but my best guess is that it’s related not to any code change but to switching to the latest version of Visual Studio and its runtime library. In general, getting the redistributable for Visual Studio 15 might help.

Overall, I fear like the only solid solution to this issue is creating a separate “shim” .dll for GeDoSaTo which doesn’t link any CRT library, injecting only that in all processes, and making the decision whether to actually load GeDoSaTo in that separate dll. This is a heavier undertaking, and I plan to give it a go this weekend.

If anyone has any ideas (well, viable ideas, not pure speculation) about other potential causes for these recent issues I’d be happy to hear it.

Sayonara 544p

Sayonara Umihara Kawase recently got a PC port. I was pretty enthused about this since I like quirky physics platformers. Sadly, the port turned out to be resolution locked in perhaps one of the worst ways seen to date. People believed it to render at 960×544 (Vita resolution), but the truth is even stranger.

Anyway, this sunday at around noon I thought I could give fixing it a try, given that the game should be DX9 according to the Steam requirements. Well, after buying it, the first thing I learned was that it is actually DX11. This turned what I was hoping for would be a quick fix into a longer struggle, but nonetheless I managed to unlock the resolution (it’s what I do after all).

In the process of that I also learned that internally, the game actually renders to a 896×512 portion of a 1024×512 rendertarget !! That’s, IMHO, even more insane than the 960×544 1:1 Vita port people expected.

Anyway, the result looked like this:

Which is a pretty decent upgrade from this:

However, the background texture, specifically the bricks on the right, are really really awful. Too awful to be truly improved by anything other than someone going in and replacing them with a redrawn version, but nonetheless I was apparently hyper-motivated today so I tried.

I integrated the texture scaling code I wrote for PPSSPP a while back into GeDoSaTo, and (somewhat surprisingly to me) even managed to apply it to Umihara without making everything explode. It’s very limited in when it works right now, but there’s nothing in principle preventing it from being potentially applied to all kinds of DX9 and DX11 games if there is a desire for that.

Anyway, the final result, with hybrid xbrz+bicubic texture scaling, looks like this:

Which clears up the pixelly mess of bricks slightly, though obviously you can’t expect miracles from an automatic process.

I started at around noon, and what I intended to be a fun few hours coding romp leaves me here at 22:40, but I think it was worth it. I hope the other 2 people who are both into ultra-niche Japanese physics platformers and rendering quality enjoy it!

All of this is integrated in the latest version of GeDoSaTo, 0.18 “Disharmonized Genesis”. You can get the latest version with the installer provided here. And, as always, you can donate to support GeDoSaTo development here.

Hexer – A hex editor

Way back in July I was doing some simple binary data file reverse engineering, and got annoyed at the fact that I couldn’t find a free hex editor for Windows which offered all of the following:

  • Seeing all interpretations of data (e.g. various integer types, floats and text) while hovering over some binary data.
  • Searching data of a given type (e.g. uint32) quickly and conveniently in different numerical formats (e.g. decimal or hex).
  • Marking identified pieces of data with their type and some notes.

I thought “it can’t be that hard now, can it?” and set out to create my own. After some deliberation I choose C#/Winforms to implement it, simply because the tool support is second to none and I didn’t want to waste more time on UI stuff than strictly necessary.

After spending a few hours on it way back then, and finally a few more today, it has turned into quite a usable (but far from complete or user-friendly) program. I called it Hexer, which is both appropriate in English and also means “Warlock” (or even “Witcher”, literally) in German.

It has all the features which I was missing:

  • The pane on the left shows various interpretations of selected and hovered-over data.
  • You can easily enter different types of numerical addresses written in any C-style string format (e.g. “161″ searches for the decimal number 161, “0xFF” searches for decimal 255 and 010 searches for decimal 8).
  • As seen in the screenshot, you can mark ranges of data with some data type, and see the in-line interpretation of that data in the file. These markers can be stored and loaded independently of the files they apply to.

I put the source up on GitHub here, and here’s an executable if you want to give it a try. (You’ll need the right version of the .net Runtime of course)

Of the entire implementation I like this part best, which is a simple descriptive listing of all the data types, including their properties (such as name and size) as well as the ability to convert values of that type to and from raw binary and strings. It’s succinct, easy to extend (both with new data types and new meta-information about them), and many of the UI elements are generated directly from that list.

Hexer is far from fully-featured – I put up a short list of TODOs in the Github readme, but there’s a lot more which could (and should) be done.

FF Type-0 Article – Snatching Defeat from the Jaws of Victory

I wrote a pretty in-depth port analysis of FF Type-0, for PC Gamer as usual. The game is intriguing: it’s clearly a far more technically competent port (it even uses some compute shaders!), with none of the random performance drops, but held back by a baffling regression in output resolution choice.

It also got a very bad rep initially on Steam because the options perhaps aren’t labeled expressively enough – the “high” and “highest” AA options perform 2.25x and 4x downsampling, basically, so they have a very significant performance impact. Many expected to just “max everything” in this port, so that came as a surprise.

What I didn’t expect is that the game actually has some decent improvements over the console version beyond just rendering resolution, including a high-end shadow option, a very fully-featured screenshot mode, and a speedup toggle.

1.5 Weeks of Windows 10, and Photoviewer executable release

I’ve been using Windows 10 for about 1.5 Weeks now, and I thought it would be time to write about the experience, explain a few workarounds, and post one tiny tool I made to make it more palatable.

So, what has gone wrong in Windows 10?

Booting & drivers

First of all, initially it wouldn’t even boot on my X99 system. It got stuck in an infinite loop on the initial boot screen. By looking through the boot log from my old WIndows 7 installation, I eventually figured out that the fault lies with the “Intel Management Engine” driver – a component I don’t need at all. Disabling it fixed that issue.

However, I still got a black screen on boot. Turns out that Windows 10 thought it was a good idea to show the initial login screen on my projector (turned off projector, I might add) rather than the  monitor.

Talking about boot issues, the idea of removing the option to get to the advanced boot loader with a key press is really fucking annoying. Being really annoying to power users for no good reason seems to be a theme in Windows 10, as I’ve found.

The new start menu

In short: it sucks. I tried living with it for a few hours, but its refusal to reliably index manually created desktop application shortcuts in its search makes it completely unusable to me. Good thing I bought two StartIsBack licenses back then, and great on the author for having a perfectly up-to-date and fully compatible version out with the Windows 10 release.

Look, it’s a beautiful start menu with actually working indexing for desktop applications and lots of neat functionality!

Program incompatibilities

Let’s start with an amusing one: Skype would crash every time I logged out of Windows 10. The amusing part here is that Skype is now owned by MS, so’ you’d assume that they’d get compatibility right. After a lot of googling, it’s apparently an issue where the sound driver gets unloaded before skype does, and it crashes when trying to play the logout sound. Go figure. The fix is to disable that sound.

There are also various incompatibilities with DirectX pre-9 games and fullscreen mode, resulting in flickering. In most cases I’ve encountered, forcing borderless windowed mode seems to work around those.

What’s nice is that it seems GeDoSaTo is compatible with Windows 10 out of the box, and so is PtBi.

Strange stuff happening to CPU usage

This has been a sporadic issue that seems to have stopped completely now, but for a while I was getting completely nonsensical CPU usage reports in task manager.

Apparently, my CPU was giving its all at 124%.

In complete idle state, my CPU was apparently running at ~30%. At least according to the new “Processes” view in task manager. “Details” was showing 97%-99% idle, and Process Explorer, which I trust more than both of them, agreed.

The “Appification” of general tools & Photoviewer

In the process of converting general windows default utilities to “apps”, it seems that almost invariably functionality is lost — often important functionality. The new “Photos” app apparently can’t even show images at 100% zoom with a simple click, and mouse wheel zoom is completely broken. I find that unacceptable.

Luckily, Windows 10 still ships with the old Photo Viewer. Because it’s MS though, that Photo Viewer is not an executable but rather a dll which needs to be hosted and invoked somewhere, so it’s hard to associate with images in Windows 10. To work around this I’ve created PhotoviewerWow.exe. It merely invokes the existing .dll, and should work on Windows 10 64 bit installations. Just put it somewhere permanent and you can easily associate it directly with image files. (The name is a homage to the insane hoops MS jumps through to run Windows32 on Windows64, since I also had to jump through hoops to run a standard Windows feature on the new Windows)

Another thing about appification that might be even more worrying is that apparently you aren’t even trusted – as an administrator no less – to look at your own apps’ files (hidden away in “Program Files/WindowsApps”). That’s just ridiculous. And worrying.


Well, I guess the new built-in virtual desktop support is neat, and they chose exactly the keyboard shortcuts for it that I would have chosen intuitively (Win+Ctrl+D, Win+Ctrl+Left/Right). So good job on that. And I also like the improvements to the “move window left and right” workflow, where it now shows you a selection of the remaining windows to move to the other half of the screen after you used Win+Left/Right to move one window. It’s also not quite as fugly as Windows 8, and it makes it rather easy to mostly ignore the entire app crap after installing StartIsBack.

DirectX 12 article on PC Gamer

I wrote an article about DX12 for PC Gamer. It discusses the differences between high-level and low-level graphics APIs and what that means for gaming. It also features some insight gained from talking to Dan Baker at Oxide games about a few related topics, which was a big help.

I went a bit wild in terms of technical detail in the middle section of it, but it could be up your alley if you read my blog (and hopefully also interest some PC Gamer visitors).