#durante

The launch of Trails of Cold Steel on PC is here, which means it’s high time for the third and final iteration of this 3-part series of articles. The first part dealt with lifting the performance of the game to a level that I consider acceptable – great, even. The second one explained all the graphical options beyond the console version which were implemented in this port.

In this post I’ll introduce two final, previously unrevealed features which will be included in the release. The first should make everyone who has a lot of games to play and only little time – or wants to re-play Trails of Cold Steel on PC without any tedium – happy, while the second one is only really relevant for a much smaller audience – but I’m sure they will be enthusiastic about it.

Turbo Mode

The first feature is “Turbo Mode”. If this functionality is enabled in the launcher, holding down the R2 button (or other controller equivalent, or whatever you mapped it to in keyboard/mouse controls) will speed up battles, cutscenes and even field progress by a factor of four. This allows you to very quickly complete “unimportant” battles or traverse some of the larger late-game maps. When Turbo mode is active, it’s indicated by an animated on-screen icon:

While this is not entirely new - a few PC ports over the years have included a similar feature - it is fully integrated and has one particularity which I call “Smart Turbo”. In Trails of Cold Steel, when you “unbalance” an enemy, you are given a short timed prompt to select a special “link” move. During this prompt, even if you keep Turbo Mode active, it will automatically stop speeding up the progress of time so that you have the same chance to select an action that you have while playing normally.

During battle, turbo mode also skips most animations in addition to the general speed-up function. You can see the impact of this mode on a battle in this Youtube video.

Ultrawide Aspect Ratio Support

I was talking about a surprise feature that I didn’t believe XSEED would go for in my previous post, and this is it. Supporting additional aspect ratios in a game as UI-heavy as a JRPG, and one that was only ever targeted at 16:9, is never trivial, so my time estimate for this included several full work days. Since time is, in a very real sense, money in this case, I didn’t expect that XSEED would go for implementing a feature which – as of the latest Steam survey – is only really useful for less than 2% of the potential players.

Well, they did go for it, and after working through 32 distinct issues the game now supports any aspect ration larger than 16:9 out of the box! Of course, there are some limitations: primarily, that the main menu remains at 16:9, and also some battle UI overlays don’t transition perfectly at the edges of the 16:9 frame. But for most situations, I implemented unique solutions that I think look pretty nice.

Of course, if I was going to do wide aspect ratio support, I wasn’t going to do it just for 21:9 – every aspect ratio larger than 16:9 should work, at least in theory. So if, say, you have a 3-monitor 48:9 setup, then that will look a bit like this:

I have to admit that, just because of the constraints of reality, the ultrawide option is not tested as rigorously as playing at 16:9, so it’s not unlikely that you might find a small graphical hiccup in one particular scenario in the game or another. If you do, please report it.

Conclusion

Whew. A long road is about to come to its end, and I fervently hope that the game will work as well for you as it does on our testing machines. It’s the first time a game is released where I have been largely responsible for most of its PC-specific code, so I’m a bit nervous, but I do believe that it’s in a much better state than many of the releases I had a look at over the past few years.

And what I know is that if something major does go wrong, I won’t wait months, weeks, or even days to communicate with whoever is affected and try to get it resolved.

Welcome to the second part of this 3-part series on the PC port of Trails of Cold Steel. The first part dealt with lifting the performance of the game to a level that I consider acceptable – great even. Of course, you might now be wondering what to do with all that performance headroom if you’re planning to play on something faster than a GPD Win. After all, there isn’t really any need to run a turn-based JRPG at 300 FPS or more.

In this article I’ll introduce the various graphical settings I’ve added to the game, going into a bit more detail on some of them. I’ve been looking forward to this one in particular, so I hope you enjoy reading it as much as I did writing it.

The Launcher

Let’s start with a look at the game’s launcher:

There are a few things I’d like to remark on:

• Every single option has a description text, and often it also shows visual comparisons of the settings (on the right)
• The entire launcher you see here can be navigated just using a gamepad (actually, I made a tool for this that allows natural 2D-navigation and changing options in arbitrary C# WinForms dialogs using Xinput, and XSEED has graciously agreed to allow me to open source it, so look for that on my blog when things are less hectic)
• Can you spot the typo on this screenshot? It’s fixed by now.

The rest of this article will look at the options contained in the “Display”, “Image Quality”, “Shading” and “Graphics” sections of the launcher in order.

Display

Here, you have the basic choice between windowed or fullscreen rendering with or without v-sync. In terms of framerate, there are 3 settings: a 30 FPS limit, a 60 FPS limit, and unlimited FPS. While the game was 30 FPS on consoles, in the PC version both 30 and 60 are fully supported. Unlimited variable FPS also work very well in all my testing, but are not fully QA’d throughout the game and offered on a “your own risk” basis.

Finally, I’ve also added an option for adjusting the Field of View (FoV). While not as important as in first-person games, playing close to a large monitor often makes a larger Field of View desirable. Here you see a comparison between the default FoV (left) and a very high setting (I wouldn’t personally choose one this high, it’s just for illustration):

Image Quality

This section deals with resolution, anti-aliasing (AA) and texture filtering. Resolution works as you would expect. In terms of anti-aliasing, MSAA 2x, 4x and 8x are supported, and transparency supersampling (TrSSAA) is there as a high-end option to improve the quality of alpha-tested surfaces. It was strange to discover that TrSSAA is actually significantly more difficult to implement in DX11 than it is in Direct3D 9 or OpenGL, but at least that explains why so few games offer it. Here is a comparison to show what each option does – of course, the difference is much more pronounced in motion:

Before we move on to shading, there’s one thing I need to get off my chest. You know what really annoys me? When games offer some AA option, but do not apply that AA solution consistently to everything in the game (like e.g. character models in menus.) I had to extend the underlying engine to do it, but rest assured that when you select an AA option in Trails of Cold Steel on PC, everything will get that level of AA:

• The main game rendering will be AA’d of course.
• The rendered character dialogue portraits will also get the AA.
• The character models shown on the equip screen? AA’d.
• Character busts during special events? AA’d.
• Yes, even the minimap rendering gets MSAA. And TrSSA. Because why not! 

Oh, and there’s an anisotropic filtering option. It’s just a checkbox, because honestly, there’s no reason to bother with less than 16xAF for this game. Even the GPD Win can do it!

Shading

Now this is where things get even more interesting. There are four options related to the quality of dynamic shadows:

• Shadow Resolution, which, as you’d expect, adjusts the resolution of the shadow maps all the way from “low” to “absurd”.
  

• Shadow Casters, changing which objects cast shadows. Shadows are often enabled only selectively for performance reasons, with artists manually selecting which objects and characters are sufficiently “important” to cast shadows. This setting overrides that selection and makes every object in the scene cast a shadow.
• Shadow Distance, which can increase the distance shadows are cast at. Ever annoyed by shadows appearing and disappearing a few meters in front of you? I know I am. Well, not on my watch.
  

• Finally,Shadow Filtering enables softer and more aesthetically pleasing shadow transitions.
  

Even with these improved real-time shadows, the game’s environments still looked a bit flat. Since the environments, unlike the characters’ cel shading, are rendered and shaded in a more realistic style, I thought that a more realistic modern technique, namely ambient occlusion, might look good. With some engine improvements I was able to integrateHBAO+, one of the highest-quality and best-performing AO solutions available:

As you can see, it lends everything a lot more depth and plasticity, and also makes objects in the shadows appear more grounded. 

Graphics

Last, but certainly not least, the “Graphics” options seem comparatively unexciting with just two checkboxes: and really, the High Quality Depth of Field setting just does what it says on the tin and while it’s a nice improvement, it’s nothing to write home about.

On the other hand, the Unlimited Draw Distance option is, and excuse me if I say so myself, a really big deal. In fact, doing something about the draw distance was one of the very first requests that came up when the first article was posted. What I’ve done about it is completely eliminate any form of pop-in, by making all objects and characters draw at any range. On some maps this is quite a significant extra CPU load, especially combined with full shadow casters, but nothing a modern Desktop PC can’t easily deal with. 

Since pop-in is hard to demonstrate in images, I’ve made a video that really shows off the considerable effect of this option. 

Other Improvements and Conclusion

In addition to these options, there are a few graphical improvements over the console version that are “always on” and don’t have a launcher option. For example, the glow effects are rendered at 4 times the fidelity, and uncompressed textures are used instead of the compressed assets designed for consoles wherever they were available.

I hope you’ll enjoy these graphical improvements as much as I enjoyed creating them and writing about them. In the final article, we’ll have a look at some non-graphical features, and one particular, somewhat programming-intensive graphical option that will make a few people really happy and which I never expected XSEED to go for. Till then!

When XSEED approached me about contributing to their in-progress The Legend of Heroes: Trails of Cold Steel port, I was immediately excited about the prospect. The Trails in the Sky series features some of my favourite JRPGs on PC, so I looked forward to making this later game in the franchise the best it can be on PC.

Of course, back at that point I didn’t quite anticipate just how involved I would get - I was expecting to do some optimization here and there, maybe amounting to a week or two of full-time work. Reality would turn out different, and in this series of articles I’ll give you some idea of why.

The series is currently planned in 3 parts, leading up to the release of the game on August 2nd:

• Thefirst part, which you are reading right now, deals with performance aspects, primarily framerates and loading times.
• Thesecond part will describe the graphical enhancements and options available in the PC version, and how they came about.
  
• Finally, the third part will go into some specific features of the PC port that aren’t direct graphical enhancements, and explain some of the challenges in implementing them. 

The Beginning of the Performance Story

It seems appropriate for a story about a program to begin with loading, and the initial issue that I was consulted on were in fact loading times. In the PC version of the game at that point, even on a fast machine, loading would routinely take upwards of 20 seconds. And these were not some infrequent large loads, but rather loading which occurred e.g. every single time a battle started and ended. Additionally, significant loading stutters were present frequently throughout the game.

This was of course not an acceptable state of affairs. After a lengthy analysis, I figured out that the primary reason for both the stutters and the loading was that the game’s engine used Nvidia Cg (a - by now - very outdated and unsupported high-level shading language toolkit) to compile and load shaders at runtime. By caching and reusing shader compilation results, I was able to reduce loading times (after the initial load) to ~2-3 seconds, and also eliminate most stutter after a startup phase. Satisfied with the progress on the particular issue I was contacted about, I reported my findings and code.

Standards

Some time later, I was tasked with polishing up the game for its eventual release. While I spent some time improving graphical aspects in the game’s Cg-based version which existed at that point, with more playtesting I grew increasingly dissatisfied with its performance.

As the game was originally released on PS3 and even Vita (though the PC version only uses PS3-level assets and effects or better), you would expect a fast desktop system to churn through it with incredible ease. However, at that point I had already discovered a specific scene and camera perspective in which my PC dropped down to 45 frames per second, completely CPU limited. Using a variety of profiling tools I discovered that the issue was primarily related to how the OpenGL/Cg rendering backend of the engine managed shader state, ending up with dozens of state setting calls for each individual draw call. By doing some of the more obvious optimizations and tweaks, I brought performance in my testing scene up to 55 FPS. At that point, I estimated that by fully optimizing the Cg-based renderer I might get the game up to around 80 FPS on my PC in that scene at best.

That wasn’t going to be good enough.

I could never accept a port with my name on it for a game that ran on PS3 at 30 FPS which only gets up to 80 FPS on my fast 2015 desktop system. In fact, I’d personally like to run a game like this on a low-power portable like the GPD Win, and with that level of performance this wouldn’t be possible.

Changing Horses Midstream

The only true solution to the performance issue would be to completely replace the rendering backend. The underlying engine already had a DX11 backend, but unlike OpenGL/Cg it was clearly not used by Falcom during the development of Trails of Cold Steel, and the game and its assets used a very large array of features not available or not functioning in the same way in in the DX11 backend. As such, switching to the different renderer was actually a larger change in some ways than all of the PC porting work that had been done up to this point.

To give you a better understanding of what this means, here is the first screenshot I took during development of the DX11 version – and note that this was already after fixing a number of issues that would prevent the game from even starting:

In this screenshot you can see over a dozen separate rendering issues, some of which required fundamental engine extensions and reworking to fix. However, they were still just a subset of a final tally of 57 separate classes of rendering problems (not individual instances) related to changing the rendering backend. There’s no way I can go into all of them, but here is a particularly amusing one I was tracking at a much later point during development - as you can tell by everything no longer being a horrible mess:

The Result

Regardless of all these issues and the effort required for porting to an entirely different rendering backend, it was all worth it in the end. The following chart gives you an idea of the (CPU) performance of the game on my PC at various stages in development:

The current state of the game, designated as “Optimized DX11 version”, is more in line with what you would expect from a good PS3 to PC port.

I’d like to note one important fact about this chart: please don’t quote it as some kind of argument for how much faster DX11 is compared to OpenGL - this result is a direct consequence of how these APIs are used in their respective rendering backends in the underlying engine. I assume that the GL/Cg version is designed more as a development aid to very closely resemble the console targets than for performance on PC.

Reaching almost 300 FPS on a high-end PC is nice, but ultimately rather pointless in a turn-based JRPG. What is more interesting and the real fruit of all this effort is performance on a really low-end system, such as the GPD Win portable. This video shows the game running on that device, and as you can see the mission of smooth gameplay on a portable at native 1280x720 resolution was accomplished. In terms of settings, this video uses the game’s “portable” settings, and what exactly that means - and also some ways in which the PC version will allow you to spend the massive performance overhead on a fast desktop PC - will be the topic of my next post about Trails of Cold Steel on PC.

Hi everyone,

So we’re very happy to have a guest blog entry today from Peter Thoman, better known as “Durante” in gaming circles. Rather than a lengthy intro explaining why, I’ll let his own words below do the talking, so we hope you enjoy it.

Ken
Team Leader @ XSEED Games

A few months back Ken Berry of XSEED contacted me to ask whether I could do anything about the issues with their Little King’s Story port. Despite hearing good things about the game, I hadn’t really followed that particular PC version, since a lot of other titles were released around the same time and it’s not really my genre. Still, I was intrigued to see what was wrong with it, and delighted at how Ken was able to provide me with the source code for the game without too much bureaucracy.

Initial Impression

Before going into the details of how I improved the port, I want to remark on the difficulty of this project for the original team who worked on it. After receiving the source, it was immediately clear that this was not a simple port. Little King’s Story was built on a custom engine designed from the ground up for this particular game, and its particular original target platform (the Wii). Clearly, during its development, it was seen as a one-off project that would be done once it ships, and portability or maintainability were secondary concerns.

In any case, I quickly figured out that the largest issues with the port were overall performance,intermittent stuttering, and a whole host of issues with the 60 FPS mode, and decided to tackle these in order.

Overall Performance

First, I removed the frame limiter to more easily investigate performance issues. Even on my high-end system, I only measured roughly 80 FPS in the overworld area at the start of the game. Basic profiling revealed that it was entirely CPU-bound, and I assumed this was not going to be caused by the original Wii code, given that it ran acceptably on a ~700 MHz processor.

This assumption turned out to be correct after more in-depth profiling: the vast majority of the game’s CPU time was spent interacting with the DX9 API. I won’t go into the full details here, but the crucial point is that many individual objects induced a state change of the rendering pipeline, with its associated CPU overhead. I decided to tackle the issue by implementing various caches (for passes and materials) which prevent state changes unless they are necessary. After a bit of tweaking, this lead to a performance of around 123 FPS in the same testing area, an improvement by more than 50%. More could be done - like always in optimization - but since the game is limited to 60 FPS at most anyway I decided to move on to another issue.

Intermittent Stuttering

On a high-end CPU, stuttering was actually a more fundamental problem than the performance overhead discussed above. While moving around in the world, every few seconds the game would noticeably drop one or even more frames. First, I thought that the culprit could be some timing issue, and while improving the frame sleeping logic helped by making the game play feel better, it still didn’t eliminate the major stuttering.

Profiling an intermittent stuttering issue such as this is far more difficult than working on overall performance. Sampling-based evaluation is almost useless, and that’s by far the most developed category of tools. Ultimately, I resorted to using Nvidia NSight and its integration library, and manually narrowed down candidates for causing stutter by marking individual regions in each frame execution. A somewhat time-consuming process, but it paid off:

In this image, the colorful stacks indicate the stutter causes I ultimately tracked down, and the lower half shows a similar sequence after dealing with the underlying issue. Note that the marked regions, which previously could take up 2 to 3 frames, are now in the 0 to 2 millisecond range. To give you a more visual idea of the improvements I’ve created this comparison video.

Issues with 60 FPS

Offering 60 FPS - or, much better, support for completely arbitrary framerates - is a common demand for PC versions of games, and one I fully agree with. In quite a few cases where it is not offered, mods later demonstrated that the effort to do so would have been very small for the developer, and that the only reason it was not provided is a lack of care for the PC version.

Little King’s Story is not such a case. There are many reasons for this, here are just a small subset of them:

1.    The game does not have a unified system for handling time or animation speed. Many modules act independently of each other, and often time-specific information is encoded in places where it would not be expected.

2.    The central NPC simulation code assumes that it can pre-compute how long it will take (in frames) for an NPC to complete an action, such as moving to another location.

3.    Some bosses, enemies and scenes are moved or designed in custom scripts, which use a custom virtual machine and instruction set that is not intended to share framerate information.

My initial goal was to provide arbitrary framerate support, but point 2 in the list above makes that an infeasible goal. It would basically require rewriting large parts of the simulation, which makes up a significant portion of the entire game’s ~1 million line codebase.  Given that, I shifted to the goal of making locked 60 FPS work as well as possible.

The original port fixed the speed of most NPC animation sequences, but left many other hardcoded animations, and even the gameplay-relevant time progression rate untouched at 60 FPS (resulting in double speed).

I employed a side-by-side 60/30 FPS setup as shown above, and chipped away at framerate-dependent speed mismatches little by little. In the end, I managed to fix the simulation speed,the speed of many hardcoded object animations (such as trees or grass), and the movement speed of NPCs and animals.

However, the custom scripting system used for some boss battles and scripted scenes, point (3) in the list above, still prevents the 60 FPS mode from being perfect throughout the game. However, unlike the initial release, 60 FPS is playable (and a huge improvement in smoothness) during the majority of the gameplay. As a workaround for the remaining situations, I’ve implemented a 30 FPS toggle for the 60 FPS mode, which is engaged using the “F1” key. Note that this comes with some issues due to point (2) above: animations already in progress at the moment the framerate is toggled will run at an incorrect speed until the next movement starts.

Graphics, Launcher and Control Improvements - What I Wasn’t Asked For

While working on the game, I noticed a few things which would significantly improve the visual quality and not really take too much time to implement. So I did. This include multi-sample anti-aliasing (MSAA), anisotropic filtering, transparency supersampling and a few other minor tweaks.

The most complex addition was creating an option for more shadow casters, including trees and grass. I found the lack of tree shadows a bit disappointing given that other objects cast dynamic shadows, so I added this as a (somewhat CPU-heavy) option. While I was at it I also added an option for soft shadows, to better fit with the soft dropshadows cast by NPCs.

Of course, I also had to add options for these features, and since the original launcher was not particularly extensible I replaced it with a new one. As a personal preference I also re-implemented options to be stored as XML rather than in a custom binary format, and added a lot of information about each option in order to hopefully make their impact more clear.

Finally, while playtesting the controls of the game always felt a bit “off” to me. Even though I was playing with an analog gamepad, movement was restricted to 8 directions, which in particular makes precise directional aiming (a significant gameplay component) more cumbersome than it needs to be. To solve this situation, I added support for analog directional controls for Xinput controllers.

Conclusion

The new version of Little King’s Story should perform significantly better on all systems, most sources of significant stutter should be eliminated, and the 60 FPS mode now provides an accurate (and smoother compared to 30 FPS) experience except in some scripting-related cases. Furthermore, the game now features additional graphics options to make better use of high-performance GPUs, and can be more precisely controlled with analog gamepads.

While I couldn’t achieve everything I initially wanted to - arbitrary FPS and even a completely perfect 60 FPS mode prove intractable for this game - I’m happy that XSEED gave me the chance to contribute a lot more directly and meaningfully to the quality of this PC port.

   *  *  *

So Ken with XSEED again here. To celebrate this relaunch of Little King’s Story, we are running a week-long 40% off sale on Steam and The Humble Store starting right now. Though these enhancements only apply to the Steam build at the moment, we plan on applying them to our DRM-free and GOG Galaxy builds soon, so just hang tight for a little while longer and those builds will be updated too.

Thanks to everyone for your patience and ongoing support, and we hope you enjoy the new and improved Little King’s Story for Windows PC.

Ken

It has now been a bit more than half a year since Trails of Cold Steel was launched on PC. That was the first game for which I contributed the majority of the porting effort, and it made me believe that I could also take on a complete end-to-end porting project for its sequel. That sequel - Trails of Cold Steel II - was released yesterday, and in this blog post I’ll talk a bit about all the features it implements beyond what was seen in the previous releases.

Read More: https://goo.gl/njM9gM