The Ys X: Nordics PC Optimization Journey

Even more so than for the turn-based JRPGs we frequently work on, solid performance is essential for a fast paced action RPG like Ys X. In this post, I'll briefly outline the various optimizations we made to the PC version of the game over the development period of our port.

The Overall Timeline

Let's not bury the lede and instead jump right to the results:

The image above shows performance at a fixed, very challenging benchmarking spot (see below for details). To give you an idea of the time scales here, 0.1 was released into beta at the end of July, 0.2 was just a few days later, and we reached version 0.8 in the middle of September.

[expand type="details" expanded="false"]This is a spot in Balta Island which we found to be the absolute worst-case in terms of CPU-bound performance. All settings are at their maximum, except for resolution and anti-aliasing, to make sure that the game is CPU-bound. We load into a fixed save and then report the FPS after waiting for 30 seconds in order for everything to settle. The system is my development workstation, which is a Core i9 12900k with an RTX 4090 -- but since we are interested in the relative comparison between versions here, that's not very relevant.[/expand]

I'll now go into some detail on the more interesting optimizations we carried out.

Before 0.1: Fun with Drivers

The version 0.1 you see in the chart above is the first version we released into beta, but of course not the first one we built for PC in general.

As performance (and, sadly, sometimes even correctness) can vary wildly across different hardware vendors, we have Nvidia, AMD and Intel hardware internally for testing. Luckily, our main developer on Ys X PC during its early phase was working on AMD hardware, so he immediately noticed that something was off.

During the intro scene pictured above (which looked a lot worse at that time, especially in terms of aliasing, but that's a different story), his framerate dropped below 5 FPS, on a rather high-end system. He immediately asked others to test on different hardware, and we found that there was no issue on Nvidia GPUs.

Something like this could well turn into a multi-week deep dive into API intricacies and driver behaviour, but fortunately we already saw something similar in Trails through Daybreak -- though not nearly to the same extent. To make a long story short, back then we found that particular uses of memory in DX11 led to catastrophic performance loss on AMD, and we solved this issue by changing the buffering implementation of GPU uploads. Applying the same procedure to Ys X also solved this performance drop.

As a side note: as AMD might in the future change the driver implementation, we made this into a setting. It's not in the menu, but if you are an AMD user and curious about this, you can set the

extra_host_write_buffering

setting in the "General" category to "Always" or "Never" rather than the default "Auto", and watch your performance plummet.

From 0.1 to 0.8: Low-hanging Fruit and Gradual Refinement

There's not too much to say about this part: despite the overall impact being very high, it's the result of many small tweaks and improvements that aren't particularly interesting on their own. Things like dealing with static geometry more effectively, skipping unnecessary recomputation and so on.

The general idea for CPU performance optimization is that you look at profiler output and try to optimize anything which seems to