Dev Diary Entry #6: Emergency Upgrade

Introduction

I’ve been interacting with many fellow Indie developers through on-line media regarding games running as a UWP App on the Xbox One. Mostly, I just bought my Xbox One a month ago (Black Friday in Canada is in October) and I wanted to “catch up” regarding game development for this console. The most outstanding issue I noticed in most posts I read was a performance concern.

As developers, we all hate surprises during the last phase of a project. Aiming to diffuse the pressure of the last weeks, I went ahead and started doing performance tests. What I found was rather upsetting: the performance of my game engine as a UWP app on the Xbox One was awful: it could only run fluently at 30 fps. For a state-of-the-art device, that was a rather alarming find.

After a thorough analysis (and a lot of cursing), I found out that the source of my problem was the console’s GPU restrictions and the outdated development environment I was using.

Part of my stubbornness about keeping the tools I’m familiar with is due to the fact that I’m one of the few indie developers that use (and praise) DirectX 11. I know of other cases, but all of them are very, very, very quiet about what they do and how they do it. As a result, when I have a critical problem, I’m pretty much on my own.

However, when I chatted with other fellow developers about my findings, Shahed Chowdhuri, a friend and technical evangelist, pointed out that, although old versions of the Windows 10 SDK restricted access to the GPU by half, the latest SDK, known as the “Creator Fall Update”, granted full access to the GPU. As plain as it sounds, this was the solution to my performance problem. However, since the latest SDK runs only on the latest version of Windows 10 and can be used only by the latest version of Visual Studio, this meant that I had to update absolute everything, from my console and PC to the core of my home made game engine.

Here is the article that was pointed out:

https://blogs.windows.com/buildingapps/2017/09/15/resources-universal-windows-platform-games-fall-xbox-one-update/#pEZORfPbzlQU9ft7.97

Upgrading the Development Environment

I was lucky enough to be able to reserve a second development environment with Windows 10. The roadblock here was that the Windows 10 Fall Creators Upgrade is deployed by regions, and my system hadn’t been selected yet. However, I was able to get the upgrade at the following link:

https://support.microsoft.com/en-us/help/4028685/windows-10-get-the-fall-creators-update

I downloaded a fresh copy of Visual Studio 2017, which included the latest SDK. Here is the link I used:

https://www.visualstudio.com/downloads/

One day, without planning, my Xbox One S console updated itself to version October 2017. That was an easy upgrade.

Upgrading my Game to Visual Studio 2017

The next step was to upgrade my games to the new development environment. Here is where this procedure got painful: Although I was able to upgrade my game from Visual Studio 2015 to Visual Studio 2017, I was unable to re-target the target and minimum Windows 10 SDK version to the Fall Creators SDK: Simply put, the option for that version was not available in the drop down list.

I was kind of expecting a surprise like that. No matter, though, for I had a backup plan: Since all my code was encapsulated XNA style, I created a brand new project targeting the latest Windows 10 SDK and copied my code from the old project to the new one. That was what I did when I migrated from Visual Studio 2013 to 2015, so I was very familiar with the process.

I was happy to see that all the changes and enhancements in the new Visual Studio 2017’s “DirectX 11 App (Universal Windows)” Application Template were encapsulated and properly implemented. For instance, all the DirectX managers and handler classes are new and improved, but encapsulated in the DeviceResources wrapper class (see my previous post about the inside of a DirectX application). This made the upgrade so easy to implement.

Once this process was finished, I ran my tests one more time and I noticed a considerable improvement in the Xbox One console: I was now able to run my games at the desired frame rate of 60 fps, although it still stuttered frequently. The improvement was good, but not good enough to fulfill the expectation of gamers around the world.

Shader Compilation

After running the Graphic Debugger, I identified the bottleneck of my game engine as a particular pixel shader that draws in batch the background elements of the game (part of the DrawIndexedInstanced function implementation). For example, this is the one in charge of drawing the buildings in my third-person shooter. I re-wrote this shader so the code would be even more efficient, but I still couldn’t reach the desired performance. I was looking at some branching warning notes when I noticed something weird in the Visual Studio environment: By default, projects in “Debug” mode are compiled in such a way that all shader optimization options are disabled. Also, some debug functions are added to the shader. Likewise, projects in “Release” mode are compiled in such a way that all shaders are compiled with the optimization features enabled and all debug features are excluded from this code. In other words, projects need to be compiled in “Release” mode prior deploying it to the console for good performance.

I was about to test this theory when my Xbox One suddenly upgraded itself to Windows 10 NOVEMBER 2017 version. These upgrades are not exactly optional if we want to continue on-line, so I went ahead and upgraded my console.

Once I got all these changes done, I can say that my home made game engine now flies on the Xbox One S: It runs smoothly at 60 fps, it doesn’t stutter and when it does is because of my code, not the GPU. I have the capture video features on and I can record without jeopardizing performance.

Conclusion

For a desired 60fps game experience, we only have 16 milliseconds to draw a frame. Having half of that was a huge challenge for amateur developers like me. However, the Fall Creators Upgrade granted us full access to the GPU, and that is a huge improvement. Still, to be fair and objective, I have to be accountable for the lame HLSL code I wrote, along with the compilation configuration settings of the deployed executable.

Performance drop is a very complex issue and takes a lot of man power to solve. Most of the time, you don’t know you have a performance issue until you see your game stutter. I cannot say which upgrade / optimization (or combination thereof) fixed my game engine, but I’m really happy that it did. Still, this dev log entry has the steps I took documented, hoping that it will help other Indies with their projects.

Advertisements