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.
Yesterday an article I wrote about UWP/UWAs got published at PC Gamer.
I actually asked about writing this 3 weeks or so ago, but with my real job interfering it took a while to get done. In the meantime, the topic blew up with Tim Sweeney weighing in, which isn’t something I expected.
I go into details on the current state of things, my concerns about future developments, and 2 questions I’d like Microsoft to answer in that article. One thing I don’t discuss, mostly because it requires technical background to understand which would take a long time to explain from the bottom up is the technical details of application signing. I also won’t do that here – on my blog I can afford not to – but I will provide my more philosophical thoughts on the matter.
Signing, in general, is a good thing. At the very least, it makes man-in-the-middle attacks far more dangerous to execute. On truly open platforms like Linux it is even a great thing, with all the control still resting with the user and no one interested in making some particular commercial signatures “more trusted” or “better” than the rest.
On a commercial proprietary platform, it is a double-edged sword. Yes, ideally, it provides all the same advantages it does on the open platform with no additional drawbacks. However, when ultimately controlled by a commercial interest its potential for either subtle or obvious abuse is extremely high. From simply showing a small warning pop-up if some software is not corporate-approved all the way to restricting some functionality only to a subset of signatures. Compared to that, the somewhat more dangerous wild-west environment of Win32 does not offer the same capabilities – even to its creator.
Anyway, many people have told me that they appreciate the article, either for the information contained in it about current UWA limitations, or for the message it sends, or both. There are also those who think I am overreacting or painting too grim a picture. And in this particular case, I’d be ecstatic if they were right and I am wrong: if in 10 years I can still as easily mod a game as I can do with a Win32 executable today then I’ll join them in laughing about just how silly I was. Happily.
I wrote a pretty in-depth port analysis of FF Type-0, for PC Gamer as usual. The game is intriguing: it’s clearly a far more technically competent port (it even uses some compute shaders!), with none of the random performance drops, but held back by a baffling regression in output resolution choice.
It also got a very bad rep initially on Steam because the options perhaps aren’t labeled expressively enough – the “high” and “highest” AA options perform 2.25x and 4x downsampling, basically, so they have a very significant performance impact. Many expected to just “max everything” in this port, so that came as a surprise.
What I didn’t expect is that the game actually has some decent improvements over the console version beyond just rendering resolution, including a high-end shadow option, a very fully-featured screenshot mode, and a speedup toggle.
I wrote an article about DX12 for PC Gamer. It discusses the differences between high-level and low-level graphics APIs and what that means for gaming. It also features some insight gained from talking to Dan Baker at Oxide games about a few related topics, which was a big help.
I went a bit wild in terms of technical detail in the middle section of it, but it could be up your alley if you read my blog (and hopefully also interest some PC Gamer visitors).
I wrote an article about The Witcher 3 for PC Gamer. I focused primarily on some tips for achieving the smoothest possible gameplay, but what I’m really surprised by is the CPU results I obtained.
I might have chosen a bad location for that benchmark, and perhaps I’ll repeat it somewhere else, but I really expected an open world DX11 RPG to be more CPU-heavy. Certainly not playable with two 2.2 GHz cores at 30 FPS and 4 at 60 FPS. Very well done, and another indicator to me that seems to hint towards the gains with future low-level graphics APIs being less pronounced than some expect, outside of very specific use cases.
Of course, that level of control will at the very least be a huge boon to VR rendering, which inherently requires a high framerate, low-latency and extremely consistent performance.
So, much earlier than I expected to, I’m able to present what everyone was waiting for: DSfix 2.3 supporting the Steamworks version of the game!
There is only one change, and that is updating the address offsets for the FPS fix to work with the new version. All other features still work as expected, at least according to my testing.
That this is possible so quickly is thanks to the contributions of boowoo90 on this very blog. Is he an undercover From Software operative? Just a talented reverse engineering guru? Who knows, but he supplied the required addresses in no time at all.
Get the latest version of DSfix here.
As all but the packaging of this update is the work of someone else, don’t donate just for that! However, if you are just now getting into Dark Souls after it is freed from the scourge of GFWL and find DSfix helpful you can donate here.
And remember, if you use the FPS unlock, you need to use some other method to achieve Vsync. Options include your graphics card’s control panel, D3DOverrider, or simply running Dark Souls in borderless windowed fullscreen mode using DSfix.
In unrelated news, my latest article on PC Gamer just got published. It discusses the Final Fantasy 13 and 13-2 ports. Busy day today!
An article I wrote for PC Gamer has now come online:
The features PC gamers want — an open letter to developers and gamers
I really liked the idea for this article when I was first approached about writing it. While writing, I turned it from something addressed mostly at developers into also trying to make gamers understand the cost of features and how to interpret comparative performance across games.
The final article is about 50% longer than initially planned, but I still missed at least two important features, which I will shortly discuss here. I’d add those to the “important” category.
- Audio support: Just like with display devices, people use a lot of different audio setups on their PCs, both in terms of output and in terms of processing. Decent positional audio should be supported for at least the common speaker configurations and headphones.
- Custom Server Hosting / Server Browsers: For online games, supporting match-making is nice, but it should never be the only option in a PC game. Traditionally, PC games which offer the option to host custom servers and browse servers by various criteria have a much longer active online life and foster a stronger sense of community.
One thing I did certainly not expect is to get feedback from some developers within a few hours of the article going live. I know of at least three who are forwarding it to the relevant parts of their team (some having it translated even), and others have said that it’s nice to have something “official” (even if it’s just an article) to show the decision makers when discussing PC features. This is honestly already a much better outcome than I had expected!
Development on GeDoSaTo and PtBi
As some of you might have noticed, development on these projects has slowed down considerably over the past few weeks. This is primarily due to my “real world” work load, which has increased significantly due to the unfortunate confluence of the semester starting in October here (teaching), paper deadlines (research), and project proposals in-flight (shit).
I still try to merge external contributions to both projects regularly, so please help out if you can. My own situation should normalize somewhat in November, and allow me to work on them once again. (By the way, I actually wrote most of the article discussed above roughly two weeks ago)
EDIT: If you came here from some external link, don’t get this, get the latest version. And please don’t report issues in outdated versions.
Well, this is it.
Get it while it’s hot. (link to outdated version removed, see above)
UPDATE 1: Download link changed to version 0.1a, fixing (hopefully) .dll dependency.
UPDATE 2: It seems like Steam Overlay popups break the graphics in DS2 with GeDoSaTo currently. Disable the Steam overlay as a workaround for now.
For more information about the background and development of GeDoSaTo, read my earlier blog post about it.
For an in-depth description of what it can do for Dark Souls 2, do read my PC Gamer article. I really enjoyed working with the people at PC Gamer, and not just because they gave me early access to the game
Please remember that this is an initial public alpha release, as such it’s almost certain to be buggy.
And please read the readme file carefully. It is included in the download. And if you want to quickly get an idea of the state of things in-game, press the “+” button on your numpad. It should show you GeDoSaTo status information.
Oh, and if you enjoy what I’m doing and have lots of disposable income, consider donating to further GeDoSaTo development. There’s a lot yet to be done.