Monthly Archives: October 2015

GeDoSaTo 0.19 “Chaos Flare” – Completely revamped injection

Posted on by
12

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.

Update:
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

Posted on by
19

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

Posted on by
8

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.