I’ve fixed the only remaining graphical issue I was aware of in the Stranger of Sword City plugin. It was related to horizontally flipped 2D textures, which as far as I can tell were only used for the “new item” window:
So now that should be pretty much perfect. I’m really liking the game itself so if you are into old-school, combat heavy dungeon crawlers do give it a try.
As always, you can get the update from within GeDoSaTo, or from here if you don’t have it yet.
Stranger of Sword City is what seems like a pretty good dungeon crawler which just released on Steam. The port is decent (should run on a toaster, good input support), and the 2D art is gorgeous, but the 3D dungeons are rendered at 720p internally.
No one seems to have noticed, which is probably due to the general low detail and contrast of these backdrops and the fact that you concentrate on 2D stuff during the actual gameplay. Nonetheless, it bothered me, so I fixed it.
The fix was actually a bit more complicated than I had anticipated, since the game really sends of all 2D rendering with hard-coded coordinates in a 1280×720 system. Adjusting that resulted in 2D artifacting on continuous surfaces rendered at tiles which people might recognize from playing games at larger than native resolution in emulators.
I worked around this issue by some rather ad-hoc texture coordinate hacking, but the current result looks pretty good to me. Since I don’t want to spend much time on this the plugin is limited to a hardcoded internal rendering resolution of 3840×2160 (replacing the native 1280×720) – even at that resolution the game uses less than 15% of my 970, so most people on gaming PCs should be fine. Otherwise, you can simply not use GeDoSaTo for the game.
Native 720p
With GeDoSaTo, native 3840×2160
Getting this plugin to people easily and timely also forced me to push a lot of commits which were more experimental in nature (rather than sort through them all manually), meaning in practice that some stuff might be broken in this version. It might be a better idea not to update for now if you don’t want to play Stranger of Sword City.
If you are interested, 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.
Someone asked for this, and I figured it would probably be easy enough to do. And it was, so here it is.
You can toggle the solid outlines in the game config file, like this:
|
1 |
symphoniaBlackOutlines true |
People are also asking about framerate unlocks, and that would be – if at all possible – a lot more work even in the best circumstances. With the game’s silly DRM, it’s even more annoying, and not a task I want to undertake.
You can get the latest version including this option by updating from within GeDoSaTo or with the installer provided here. As always, you can donate to support continuing GeDoSaTo development here.
The initial release from yesterday only fixed the main rendering resolution, the really low-res postprocessing (512×256!) still produced some ugly artifacts. I changed that now, in that the postprocessing scales with the rendering resolution selected. This was a bit harder than the other stuff, since I also needed to identify & fix a few vertex shader constants. Still, it took less time than creating this comparison image:
As a neat side effect, this also fixes the slight shift to the top/left that could be observed with the previous version at high resolutions, e.g. on the starting screen.
You can get the latest version including this change by updating from within GeDoSaTo or with the installer provided here. As always, you can donate to support continuing GeDoSaTo development here.
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:
|
1 2 3 4 5 6 7 |
# Lines starting with "#" are ignored by GeDoSaTo and used to provide documentation # This is a profile file for Symphonia # Put your desired rendering resolution below clearRenderResolutions renderResolution 3840x2160@60 forceRenderRes true |
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.
Since the last time I wrote about GeDoSaTo, there have been quite a few changes/improvements. The full changelist is on Github (basically everything under the beta 20 and beta 21 headings), but I feel like some things need further explanation.
This means that it’s easier to get perfect coverage of post-processing injection and hudless screenshots in more games, more situations , and with a larger variety of settings, with a single uniform profile.
It works like the PSHash system, but when the hash is encountered AO is applied (with the GenericDepth plugin). This means you can inject AO before the game renders things like volumetric fog, particles or light overlays:
The way both of these features work is illustrated by the new default profile for Dragon’s Dogma:
I also implemented a depth-based fadeout for AO, this helps work around issues with fog which are not resolved by the new hash targeting ability. You can currently configure it directly in the SAO shader. (Which you can of course customize for each game profile like any shader)
Combining AO hash targeting and the fade-out, it’s possible to get artifact-free AO in e.g. Dragon’s Dogma, which was my main test case.
Rather than pushing every effect into a single shader (which simply doesn’t even work for some combinations) you can now specify an additional postprocessing pass with e.g. addProcessingPass deband.fx in any settings file. Currently, only the deband shader has been separated out, and you can look at its source here. The system is still not as flexible as I’d like it to be (in order to be able to implement more complex effects without changing GeDoSaTo), but it’s a pretty significant step forward.
You can get the latest version by updating from within GeDoSaTo or with the installer provided here. As always, you can donate to support continuing GeDoSaTo development here.
And yes, I know that this is not the DX11 support that everyone is asking for all the time. Sadly, that’s on a different level of engineering time requirements.
While playing Lightning Returns, I noticed extremely ugly artifacts/flickering/aliasing whenever DoF was used (particularly in cutscenes) – even at 4k. Turns out the game rendered DoF effects at 720p regardless of the selected rendering resolution.
I fixed that (after spending far too much time on half-baked ideas which turned out more complicated than the real solution) in the latest version of GeDoSaTo. Here’s a comparison (crop from two 3840×2160 screenshots):
Left: default; Right: fixed
I spent some time making sure the DoF effect itself is as close as possible to the intended. I think it worked out pretty well.
While I was at it I also implemented AO support, you can look at a comparison here. It’s disabled by default, so you should enable it in your user .ini if you want to. The performance impact is rather significant.
You can get the latest version including the LR plugin by updating from within GeDoSaTo or with the installer provided here. And, as always, you can donate to support continuing GeDoSaTo development here.
It’s somewhat traditional (well, since last year) to have a Final Fantasy-related Christmas update.
This time around, I fixed a variety of bugs/missing features which made GeDoSaTo incompatible with Lightning Returns. After doing that, I also quickly discovered a PSHash for hudless screenshots which seems to work pretty well so far. Due to the way the game handles downsampling resolutions, you need to take some care when trying to get hudless downsampled screenshots, look in the .ini for details.
Other than the strange insistence on having a fixed set of supported resolutions rather than querying the OS Lightning Returns seems to be a pretty good port so far. At the very least, it doesn’t suffer from the random performance issues of the other two games in the trilogy. The gameplay seems fun as well so far.
People still frequently ask about these, so I thought I’d give a status update. For DX11, the vast majority of the relevant APIs are intercepted at this point, what’s missing is porting/reimplementing the support infrastructure required for downsampling and general operation (e.g. the text console, effect loading and application, rendertarget handling etc.) to the API. This is still a non-trivial amount of work.
64 bit support, on the other hand, would mostly just amount to compiling multiple versions of the .dlls, and setting the correct paths in the tool/loader. The only reason I haven’t done it yet is that it seems quite useless without DX11 support, given that 64 bit games are generally also DX11.
The latest version should also fix some other compatibility issues reported over the past few weeks (some, by far not all of them!), and even a few older ones, including installer issues – see the github tracker for details. I just hope it doesn’t introduce new ones, but if it does then do report them 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.
Happy Holidays everyone!
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:
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.
Quite 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 ;)):
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.
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.
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 NoteTo 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.
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.