Tales of Symphonia GeDoSaTo plugin

Edit: My article about this sordid affair is now up on PC Gamer.

I never expected that, but Tales of Symphonia was released resolution-locked. I’ve released a preliminary GeDoSaTo plugin for the game to fix that.

Note that when I say “preliminary” I mean with a total development and testing time of less than 3 hours. So if you run into issues, keep that in mind. (Of course, if you get crashes, or the game failing to launch, or anything like that, it might just as well be the game or its DRM system rather than GeDoSaTo)

Things to keep in mind:

  • The game name, for purposes of config files, screenshot paths, etc, is “Symphonia”. This is a bit of a hack due to the silly DRM they use.
  • As always with games with locked rendering resolution, you need to set your desired one from the .ini file ( config\Symphonia\GeDoSaTo.ini ). It looks like this by default:
  • There is a bit of an ugly interaction with some low-res processing going on. I might fix that if I can find the motivation.
  • Keep the in-game resolution setting at 720p, that’s the only thing I tested.

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

 

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.