Small Stranger of Sword City plugin update

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 plugin for GeDoSaTo

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.

Comparing the seated Vive and Rift CV1 experience in Radial-G

Because my body was complaining a bit after 2 days of room-scale madness, I decided to test the “seated” experience in the Vive today. We all know that room-scale with tracked controllers is a transformative experience by now, but there are still plenty of games best played seated. To be honest, I expected it to be quite comparable to the seated experience in CV1, though a bit worse overall. The reality is not that straightforward.

I performed this comparison based on the game Radial-G. Why? For one, it’s a cockpit game, so quite the typical seated experience. Secondly, it natively supports both the SteamVR and Oculus APIs. And thirdly, I already own it and enjoyed it a lot on DK2.


No two ways about it, the Rift CV1 is both easier to put on and take off as well as lighter on your head. I slightly prefer the actual face interface (heh) of the Vive – the material is a bit softer and more rounded, but it doesn’t make up for the other ergonomic advantages of the Rift.

There is one use case however in which the ergonomic advantage of the Rift doesn’t hold: glasses. At least with my head shape and glasses size, the Vive (with its cut-outs) is basically just as comfortable to use with glasses as without them, while the Rift is far more of a struggle.

Field of View

Field of view was a hot discussion topic just days ago, but seems to have settled down a bit now that we know all the measurements. In the actual game, the difference is not massive. I’ve looked closely at what I can see in each headset just moving my eyes from the default position (right after reset) and here’s what it looks like with lines indicating the borders of my vision in each HMD (excuse the crude drawing):

As you can see, the difference is there in almost every direction, but only really noticeable at the bottom of the FoV. I found this additional viewing area towards to bottom worked to stave off motion sickness in this fast moving game, since you see more of your craft, but you can probably simply move back a bit to get a similar effect. All in all, I don’t believe the difference is as striking as a purely numerical comparison would indicate.


Both of the HMDs tracked perfectly throughout all my testing in this game. Obviously a cockpit game is hardly a challenging tracking test, but I do have my lighthouses set up for room-scale and not seated stuff so I thought I’d remark on it anyway.

Image Quality

In terms of image quality, the only noticeable difference for me was that the contrast ratio on the Vive seemed higher. At first I thought that its black level was better, but someone pointed out to me that it could just as well be due to higher maximum brightness with the same black level. Since our eyes are relative measurement devices, the only way to be sure is to use some more specialized equipment.

Logically I know that the same amount of pixels must be spread over a slightly larger relative area on the Vive, but I’d be lying if I said I noticed that in this game, even in a direct (well, a few minutes delayed) comparison.


Here we get to the single most surprising and noteworthy part, at least to me. Radial-G is a game with a lot of bright spots on dark backgrounds, so the optical artifacts introduced by the 2 HMD’s fresnel lenses gain prominence. Here’s an impression of what these look like:

As you can see, the Rift generates a straight, smooth blur from the center to the edge, while the Vive spreads the same amount of “light leakage” (or even slightly more) across concentric rings.

Now, just looking at the image comparison above in isolation, there’s a discussion to be had about which one is preferable. Clearly, on the Vive, a larger amount of space is affected, but on the other hand this space is less severely affected. Personally, I’m not entirely sure which one I prefer.

Be that as it may, what I found is that this isolated comparison is both irrelevant and misleading. In a real game scenario, you very rarely have a flat black background and a single bright spot source. There will usually be at least something going on in the background, and more than one bright spot around. And this changes the visual impression drastically.

Here’s the exact same image, but with some level of background noise added to simulate that we rarely have nothing going on in VR except for one dot on a flat background. I repeat, that’s the same strength of the respective artifacts as above. With some background in place, the more dispersed artifact on the Vive becomes almost completely unnoticeable, while the more focused glow on CV1 is still readily apparent.

This image comparison might look extreme or artificial, but it really does reflect exactly what I observed in the game. Given that, I find the type of artifacts produced by the Vive highly preferable in the general case.

HTC Vive mounting bracket measurements & early game impressions

My HTC Vive arrived today, and after roughly 10 hours in VR I’m really impressed and quite tired. But I promised that I’d provide some mounting bracket measurements since I was annoyed a few days back that I couldn’t find anything reliable about that online.

Brackets measure as length 8.4 cm / width: 4.45 cm / depth: 3 mm (Where the screws pass through, slightly curved)

Mounting holes are symmetric and centered exactly 1 cm from the ends (6.4 cm center <-> center distance). Their diameter is 5 mm. The length of the included screws is exactly 4 cm (after the cap).

Bonus room setup process image:

Here are some very early and short (because I’m tired) impressions:

Overall, and this might be hard to believe, room scale VR with tracked controllers is just about as magical as you heard. I really did grin like mad simply by creating and popping a few balloons in the tutorial. And it obviously gets better from there.

The Lab:surprisingly polished and diverse, both graphically and in the types of gameplay demonstrated. My favourites were the archery game and Xortex (the bullet hell shooter). The interactivity in the lab itself was also amazing. Oh, and the trademark Valve  humor is there in robot repair and the calibration testing. I love the robot dog.

Space Pirate Trainer: it’s a very simple foundation, but despite the straightforward mechanics it actually seems to have a very significant stratification in terms of skill. I think it’s a game where, even at this early state, you can spend a lot of time playing and notice a continuing increase in your skill and accomplishments, which is always rewarding. Better anti-aliasing would be nice, it seemed a lot worse than all the other games I played today in that regard.

Water Bears VR: I got this for free in some promotion, and after the real physical exhaustion and sensory overload of Space Pirate Trainer (and Xortex in The Lab before it) we wanted to try something a bit more laid back. It’s a fun puzzle game with surprisingly good production values and very intuitive controls. It’s also really “complete”, unlike some of the other games which do feel like the early access titles that they are.
And the “Water Bears” (which you can interact with after completing each level) are extremely cute, so this is a game to show off to anyone enthralled by that.

Cloudlands VR Minigolf: it’s minigolf, in VR. Except the courses are often a lot more inventive than what you’d find in reality. The controls work very well after a small adjusting period, but the game is surprisingly challenging in how it sets the par for each hole. Room scale helps a lot here in being able to actually walk around the ball or get down on the ground and check the intended trajectory of a shot.

Audioshield: perhaps the game I was most hyped for, having played Audiosurf for over 400 hours. It does not disappoint. The best part was starting off with a random semi-obscure song (Dogfight by M.O.V.E.) and someone had already played it!

Anyway, I’ll probably be capable of more coherent thoughts later.

Also, by the way, I wrote a in-depth DS3 pc version technical analysis (good thing I completed that article before the Vive arrived!)

PC gamer article about UWP/UWAs

Yesterday an article I wrote about UWP/UWAs got published at PC Gamer.

I actually asked about writing this 3 weeks or so ago, but with my real job interfering it took a while to get done. In the meantime, the topic blew up with Tim Sweeney weighing in, which isn’t something I expected.

I go into details on the current state of things, my concerns about future developments, and 2 questions I’d like Microsoft to answer in that article. One thing I don’t discuss, mostly because it requires technical background to understand which would take a long time to explain from the bottom up is the technical details of application signing. I also won’t do that here – on my blog I can afford not to ;) – but I will provide my more philosophical thoughts on the matter.

Signing, in general, is a good thing. At the very least, it makes man-in-the-middle attacks far more dangerous to execute. On truly open platforms like Linux it is even a great thing, with all the control still resting with the user and no one interested in making some particular commercial signatures “more trusted” or “better” than the rest.

On a commercial proprietary platform, it is a double-edged sword. Yes, ideally, it provides all the same advantages it does on the open platform with no additional drawbacks. However, when ultimately controlled by a commercial interest its potential for either subtle or obvious abuse is extremely high. From simply showing a small warning pop-up if some software is not corporate-approved all the way to restricting some functionality only to a subset of signatures. Compared to that, the somewhat more dangerous wild-west environment of Win32 does not offer the same capabilities – even to its creator.

Anyway, many people have told me that they appreciate the article, either for the information contained in it about current UWA limitations, or for the message it sends, or both. There are also those who think I am  overreacting or painting too grim a picture. And in this particular case, I’d be ecstatic if they were right and I am wrong: if in 10 years I can still as easily mod a game as I can do with a Win32 executable today then I’ll join them in laughing about just how silly I was. Happily.

Tales of Symphonia black character outlines

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:

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.

Tales of Symphonia postprocessing fix

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.


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.


GeDoSaTo 0.21 – multiple PSHashes, better AO targeting, multi-pass postprocessing etc.

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.

Multiple PSHashes can now be specified

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.

Introducing AOHash for the generic depth plugin

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:

hashesI 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.

Multi-pass Postprocessing

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.

Other Stuff

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.

Graveyard of Forgotten Projects (Part 3)

This is a direct continuation of the first and second parts. Let this partial quote from there serve as an introduction:

This series (hopefully) of blog posts will gather and shortly describe some previously unreleased and/or forgotten projects I’ve worked on over the past decade and a half, starting from 2000. This is by no means a complete listing, I’m still skipping over the vast majority of unfinished ideas and half-baked projects, but I’m trying to include everything which worked to an extent or has some interesting features.

The primary purpose of this is to serve as an archive for myself, because, as you will notice when I go through the list, I’ve already lost a lot of somewhat interesting stuff and would rather not have that happen again. Perhaps one thing or another might also be useful to someone else, but I obviously won’t troubleshoot code I wrote more than a decade ago and haven’t touched since then! And, just to make that clear, it’s also obviously not indicative of my current skills.

I started this series of posts at the beginning of the year, and resolved to do at least 3 before the end, so that’s why this is happening now. The previous two iterations together went up to the end of 2006, covering a lot of abortive game attempts, a released PSP game and some useful tools.

GPU-based Image Processing and Multigrid Solvers

Around that time I had already implemented my bachelor degree project, and relatively shortly later (well, 2 years, but who’s counting) – and it’s highly related, so I’ll include it here – my master degree project.

These projects together ran roughly from 2004 to 2007, and there was no specific GPU computing API at all until their very end. People were just starting to experiment with doing compute on graphics cards using standard graphics APIs, and so everything I worked on during these projects I did in OpenGL. So, my first step was to create a library which makes it easier to do compute on what is essentially a graphics platform:

Object Model OverviewBased on that, during my bachelor work I implemented a lot of image filters, from simple stuff, over arbitrary convolutions, up to non-linear/anisotropic image filtering like Perona-Malik diffusion.

Perona-MalikTo gather and evaluate a good amount of data on all the GPUs popular at the time, I  created a benchmark which reported various performance metrics and released that on Beyond3D. Other programs created were a testing environment for filter development called “ftest” (my naming sense strikes again) and even a C# GUI for comparing various data and generating charts. I lost the source for the latter, but I still have the former. In fact, ftest has no issue running on my current Windows 10 system – not bad for a binary compiled over 10 years ago (no guarantees on this one of course!):

ftestFor my master thesis in 2007 I implemented a multigrid solver for elliptic PDEs using the same framework. I won’t go into too much detail since this is getting kind of long already and we need to get back to the games! In case you are interested, here’s my master thesis.

Muh aka Project Y aka YouMUH!

This is a long story, spanning all the way from 2008 to 2012. This doesn’t mean that I worked on it for 4 years of course, just that I spent a few days on it from time to time, often with months between them. The basic idea for this game was to be a 2.5D side-scrolling platformer/action game starring Youmu Konpaku (who is in the logo of this blog by the way, and has been since its inception. I guess I always thought I’d talk about this project some day).

In any case, looking back on it now, the “game” seems to have been mostly an excuse for me to play around with whatever rendering, modeling or physics technology I was interested in at the time. That doesn’t mean that I didn’t have some idea for how the whole thing would play when it was completed (something like a mixture of Koumajou Densetsu, Bunny must die, and Noitu Love 2), just that completing it never seemed to be the point.

I started working on modeling for the game in 2008, with just a sword in Wings3D. During 2009 I spent a significant amount of time learning Blender and modeling/animating the main character. In 2009 I started with the actual coding, putting a lot of work into implementing deferred shading with a non-photorealistic art style. I created a cross-hatch shading algorithm which was based on a set of consecutively darker hatched base textures. The result looked like this:

muh_2010Subsequently, I spent far too much time with cloth simulation. At that point, this was still uncommon (nonexistent?) in games, and I basically created everything from scratch, starting with the physics simulation, over collision, to the file format used to specify cloth type/behaviour. It was an addition to the .obj file format and looked like this:

It was quite insane, but it worked out not too terribly in the end. I extended the same physics system to handle bone animations (this part worked well) and tried to also go for hair (this didn’t work well). You can see a video of the state ~2011 here. At that point, I had also switched to a more traditional cel shaded look (a decision which I would revert today).

muh_2011During all this time I continually refined the running animation, and looking back at the initial one and the final version I have to say that at least this was a clear track of improvement. The last things I worked on, some time in 2012, was level loading, where again I used a custom format, but at least it was XML-based. This is the final state of the project at this point:

muh_2012Basically, once I got a level loaded (with no materials mind you) I realized that, as a single developer, doing the entire game at a level of graphical sophistication which does the effort I put into just the main character’s skirt and running animation justice would be utterly infeasible. At the same time, doing it any lower level wasn’t going to make me happy, and just doing things again for which I already had a “proof of concept” so to speak would be boring. So, at that point I shelved the project — and a bit later started to work on DSFix, which turned out to be a lot more helpful to far more people.

Nonetheless, I learned a lot doing YouMUH! over the years, including:

  • Modeling and animation in Blender (and that I’m not great at it)
  • Deferred shading
  • Some approaches to non-photorealistic rendering
  • Physics simulation (particularly cloth/hair)
  • Some of the problems that come with trying to integrate neat state-of-the-art code with, well, art

And also, that it’s not a good idea to attempt a medium-fidelity 3D PC game (with bleeding edge features like cloth simulation and NPR) while doing almost everything from scratch and also handling all the code and art on your own. Well, it’s not a good idea if you want to finish something, it’s pretty nice as a hobby and for learning things!

That’s it for this iteration. There’s still one more project I’ve never posted about that I consider significant, and a few smaller ones. But I really wanted to at least reach the 2010s before 2015 is over!