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.