Today I’m working on trying to finishing up better support for the myriad of graphics cards out there.
The main issue is that many graphics cards report themselves as working with DirectX 11, but they seemingly don’t fully support it. There’s all sorts of random crashes occurring in draw calls, and many times crash reports show the game dying in the graphics driver DLL itself, with no call stack, leaving no opportunity for meaningful debugging.
On my development machines, with DirectX in debug mode, I get no errors or warnings, so I don’t believe the code is doing anything bad that would cause this issue. I could still be doing something wrong at initialization, but so far I can’t track it down.
Most all video cards drivers that exhibit this problem work just fine with DirectX 9. In hindsight, having the game start in DirectX 9 mode would have been a better choice – but since DirectX 11 provides a much better frame rate, I decided that should be the default. Even so, if a player were to change to DirectX 11, there’s a chance that the game would then crash.
DirectX 10 and 11 have much stricter feature requirements than DirectX 9 did, so I’m not sure where this issue comes from. Especially since the frame outputs of the two modes should be nearly visually identical, and at the lowest level the native commands sent to the video cards should be the same, except for the method of instancing support. And in most cases the crash occurs before any instanced geometry renders.
There are a few other edge cases that I’m taking care of, such as monitors that don’t have 60Hz output modes, machines with multiple graphics adapters, the game getting stuck in undisplayable video modes, and exception handling and recovery for video drivers that crash on initialization.
Too that end, I’ve added more video options and a front end launcher to the game, instead of players having to use registry hacks or deleting dlls from the game directory when things do go wrong.
In some ways this is annoying. Many users have no issue with their video cards, so this is just an extra click when starting to play. I’ve considered adding a ‘Don’t show this dialog at startup’ type check box so that players can just jump into the game, but in the event of a crash, it would have to come back up to allow the player to change settings – it’s hard to know if a crash was caused by a graphics event.
But this launcher is also a good place to allow users to select which mods are going to be loaded (when I finish support for that…) so in the end it’s not terrible. I’ve seen other games with this sort of setup.
From the launcher, all video settings can be changed, and there are now options for picking which video adapter to use and what refresh rate to use in full screen mode.
Coding wise this isn’t as clean as I’d like it to be. This interface requires an additional set of UI code that basically does the same thing as the in game configuration. While a lot of code is shared, if I add more video options at any point, the interface needs to be changed in two places.
But since the in game UI requires the graphics hardware to render it, an operating system backed UI is really the only option to be able to display and change settings before the game engine fully initializes.
In game, the video options are the same as the launcher, and can be changed without shutting down the game. I’ve tried to make this system more robust so that invalid video modes can’t be selected, but in the event they do, players can make changes and fix the issue next time the game starts by using the launcher.
When the game gets ported to other platforms, the front end launcher will require more similar UI code – or none at all, depending on what system it is. I plan on using a cross platform UI library for the widgets, but there will still be differences – for example there’s no need to pick between DirectX versions or switch to a different graphics adapter on a Mac, it’ll just use OpenGL, and assume usage of the video card that drives the system.
I had it much better than I realized back when I did console programming. Once a game was rendering on the development machine, you knew it would run on every system at the same frame rate. The land of PC development is much rockier. I’d like to get back to making console games for that reason, but at this point with a fairly robust game engine I’d imagine I’ll always release games on PC’s as well.