Nier:Automata AO resolution & tutorial for manipulating game graphics

Posted on 2017-04-01 by petert

Nier: Automata is a great game, but sadly some of its effect buffers are stuck at 800×450 out of the box. I’ve put some work into that, and the resulting improvements can be quite significant:

But more importantly, I’ve finally done something I’ve wanted to do for quite a while: write up a tutorial for how to do the things I do, based on an example which isn’t too challenging but also not trivial:

https://github.com/PeterTh/GameManipTutorial

Please give it a read, writing everything down and doing the images was at least as much

SSDs die

Posted on 2017-02-26 by petert

One of my SSDs died yesterday. Working perfectly with no S.M.A.R.T. abnormalities in one second, completely gone in the next.

I didn’t lose anything crucial in that (because if it was crucial it wouldn’t be just on one drive), but it still stings. What’s gone (that I know about so far):

Unpublished local changes to both GeDoSaTo and PtBI. They weren’t great or done, otherwise I’d have merged them into master and pushed them to Github, but still quite a bit of work there.
A ton of game screenshots and some older save games without Steam cloud support.
A lot of smaller development projects I worked on in the timeframe from 2011 to around 2015.

The last point is the one that truly matters. It included the final project that I wanted to post about in my “Graveyard of Forgotten Projects” series. It was a tile-based dungeon crawler I developed for my Galaxy S2 phone a few months after I got that, so in mid- to late 2011. If I hadn’t procrastinated so much with writing that, at least something of that game would still exist now. Well, something more than these two very short youtube videos of amusing bugs I uploaded (because of the amusing bugs):

The working title was “Sorceressry” (as in Wizardry), and the most interesting things I lost were:

An engine written from scratch in OpenGL ES. Which is of course stupid to do, but was fun. Featured a custom occlusion and visibility culling system for tile-based dungeon crawlers that worked really well and which I was proud of.
An “optimized” Java codebase which really showed that, at least at that point, trying to reach solid 60 FPS meant that garbage collection was more of a curse than a help. Basically, I remember going from 50 FPS with sporadic drops to 20 to 60 FPS by never doing any dynamic heap allocations and putting everything in manually managed static re-use arrays.
A full level editor written in C#, which allowed putting together maps with tilesets including corridors, rooms, torches, clutter and decoration parts. You could then designate zones with encounter percentages, BGM choices and so on.
A ruby script which automatically generated LOD meshes for the corridors using a basic (and really slow, but easily sufficient) recursive polygon reduction algorithm.
All the assets I made for it, including a complete cave tileset and various icons and UI elements.
A stupidly complex stat system, with 3 physical damage types, 6 magical damage types, and complex interactions between those and various stats. That’s probably the reason why I dropped the project when it came to implementing the battle system.
It featured the “look around in-game by moving your phone and using it as a window” feature in 2011 before it got cool.

Well, this sucks even more after I wrote it down like that. At least I showed it to some co-workers who can confirm that it existed and had these things :/

Moral of the story: keep backups even of non-essential stuff, and don’t trust SSDs. Personally, what I’ll do in the future is push stuff to GitHub even more often and early, and when I have something local that isn’t ready but significant enough that I really wouldn’t want to redo it I’ll put it in a branch.

Also, procrastination can bite you.

Little King’s Porting Story

Posted on 2017-02-03 by petert

I was contacted by Ken at XSEED back in 2016 concerning their troubled port of Little King’s Story to PC. You can now read up on the results in this blog entry.

I got to leverage my skills, learned a lot of things, and gained quite some insight into “real world” game code working on this. Never mind getting paid too! Thanks to Ken and XSEED as a whole for the opportunity.

After this experience, I’m now curious about what the market is like for port consulting, improvements, and/or from-the-ground-up ports of niche- to mid-end games. If you work for a company interested in these things, please do contact me and let me know about your case – I’m trying to decide whether to pursue this full-time in the future.

Anti-Aliasing comparison tool, MK2

Posted on 2016-10-08 by petert

3 years or so back, I wrote a tool to compare anti-aliasing methods. It was designed to accompany my Beyond3D article on the topic.

The tool is still useful, but it has a few issues:

It’s based on raw OpenGL code, which means that it’s hard to extend, and somewhat likely to break on driver updates.
For the same reason, it’s slightly more difficult to ship without dependencies.
It doesn’t offer any temporal anti-aliasing technology, which is currently where much of the most interesting research is happening.
Its user interface is terrible, and it doesn’t guide people in any way in terms of interpreting what they see.

To solve these issues, I implemented a very similar tool in Unity.

You can get it here.

It features a whole lot of information about the various AA types it supports in tool-tips, and also includes the currently-in-development Unity temporal anti aliasing.

If anyone is interested in the sources I can release them, it’s pretty basic and mostly boring UI stuff.

Article on “Optimization” for PC Gamer — Bonus Content

Posted on 2016-09-26 by petert

I wrote an article about “optimization” for PC Gamer. It doesn’t actually talk about the process of optimization all that much (it’s supposed to be understandable for a general audience), but it does touch on topics that I consider really important, like the fact that a game should never be considered “less optimized” for including higher-end settings.

It also gave me an opportunity to get some feedback on various topics from Croteam and Q-LOC, which was great. I couldn’t put all of it into the article, so here are a few more tidbits that stuck with me — not nearly in as organized a presentation as they should be:

Croteam’s Dean Sekulic talking about driver optimization as “pure magic”, and cautioning people to think twice before complaining about driver quality. I’ve said before that I imagine GPU drivers to easily be amongst the most complex software projects out there these days, between the strict performance requirements, massive feature sets, and compatibility/regression nightmare in both hardware and software.
He also told me that he’s prefer a single-core 10 GHz processor to anything else out there these days, and that multi-core parallelization is a “necessary evil”. It’s also a major part of my day job, and I agree with him.
One topic I originally wanted to include in the article but omitted was dynamic image quality scaling. QLOC had considered it before, but both them and Croteam seemed concerned about player feedback and potential controversy. It also seems like both only really conceptualized it so far for scaling down to prevent framedrops on lower-end hardware, but not really for scaling up. IMHO it’s a bit of a shame that something as potentially useful as this is being held back at least partially due to fear of controversy — an optional feature should never be controversial.
That said, both seemed open to experimenting more with it.
I also talked shortly to Dean about forward vs. deferred rendering, and the fact that the former seems to be making a bit of a comeback especially in the VR space due to MSAA. He is a huge fan of MSAA and considers it great bang for the buck as far as AA techniques go – their engine is based on forward rendering.
A topic QLOC mentioned was the difficulty of porting games designed for 6-7 cores (even if they are slower) to a dual core CPU (as those are still frequently targeted as minimum specs. We didn’t go into further detail on this but I wonder if they think SMT helps in that case.
Another interesting point they raised about ports is console games assuming the same deterministic math behavior across systems. This can obviously lead to desynchronization issues in online games when identical behavior is not a given. I’d have thought that modern physics engines — probably being multithreaded — couldn’t assume 100% deterministic results anyway, but then again, another issue they brought up is outdated middleware.
Talking about long-term software maintenance, Dean mentioned that their last full recode was in 2004 — and that he’d never want to do that again. I can empathize with that, having been more or less in charge of a decent scale software project (a few 100k LOC) for some years now, and pushing through a complete rewrite of just one major component in that timeframe.
A great point which I found amusing that he brought up was categorizing graphics effects into “game effects” and “screenshot effects“. This is based on their cost/benefit ratio, and he tells me that at Croteam they try to focus on actually usable game effects while circumventing anything too expensive a priori.
I think that’s a good approach, though I’d add that yesterday’s screenshot effects can be today’s game effects.
In addition to dynamic quality scaling, another topic originally planned for the article was GPU vendor specific features, APIs and effects. While quick to point out that a good relationship with the GPU vendors is extremely helpful for their technical expertise, everyone also seems apprehensive about using such technology directly, especially so as not to annoy gamers with different hardware.
Dean told me however that he will use this type of technology if it has a significant advantage and ideally exists on both sides of the fence, and specifically mentioned VRWorks and LiquidVR as a good example of that.

Finally, a concept that QLOC referred to indirectly and Dean brought up on his own is fluidity, and that it is still harder to attain than it should be. Croteam have been working on that topic for a long time, and still wish there was more support from the APIs on that. I’ve written a bit about frametime consistency before, but maybe it would be a nice topic for an entire article.

Small Stranger of Sword City plugin update

Posted on 2016-06-12 by petert

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

Posted on 2016-06-07 by petert

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

Posted on 2016-04-10 by petert

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.

Ergonomics

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.

Tracking

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.

Optics

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

Posted on 2016-04-09 by petert

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

Posted on 2016-03-08 by petert

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.