Designing for 60Hz

So, rendering at 60Hz. For a fighting game. Now, if you do this stuff for a living, this may or may not sound easy or difficult to do (how's that for non-committal?). The truth is, certainly with my bias in mind, this stuff is difficult. I mean, as they say, if it was easy everyone would be doing it.

Okay, the rule with rendering is... know your scenario. If your game designers, artists and creative leads actually know what they're doing, a big part of their job is to define the box the game will need to fit into. If they can't define limitations and stick to them they are not doing their jobs. Simple. One nice thing of having a requirement by our genre to run at 60Hz means that, unlike I guess quite a few of my equivalents on other teams, I can actually push back quite a bit and call people out on their demands (ie, bullshit).

For example, density - how much crap do I need to deal with? Where can the camera go? How close does it get to stuff? Do I need to worry about LOD? How much in the scene is dynamic, or expected to be? Is this dynamic behaviour predictable? How much translucency is in the scene? What kind of effects are needed? And so on...

Anyhoo, like I said, the big deal here is to know the limits of what you need to deal with, because there is only so much time in which to do everything you need (and/or want) to do. This gives you basic requirements you need to work within so you can figure out what features you can support. And sadly, you quickly find out that at 60Hz... it ain't a whole lot.

For example, all sorts of things one would automatically take for granted need to be called into question. Do I do a Z-prepass? Is it worth the CPU overhead, the fillrate burn, the geometry processing... can I fake it out? Can I hand-sort the frame to avoid the Z-prepass work?

How do I light the scene? How complex does lighting need to be? Do I need to light everything? Just the characters? Are my characters normal mapped? If not, can I get away with vert lighting? Or maybe just texture projection? Can I get away with mixing and matching lighting quality? Can I defer lighting? Can I afford all the resolving that goes along with it to build the G-buffer? At the very least it's an extra pass that has a pretty high ROP cost...

And, oh boy, shadows. Shadows are a disaster. Pretty much there's no great solution that isn't stupidly expensive. Either your shadowmaps are too small, badly projected, undersampled, not cleanly enough PCF'd. Whatever. And that's for just basic passable shadows. Texture bandwidth disasters, is what shadows are. And god forbid you need to render multiple shadows. But more on that another time.

Consider something like SSAO. Expensive, hard to do really well so its artifacts aren't distracting. Let's say you do the work at a lower resolution, compromise quality a little, and you're able to get the cost down to... say, 3 ms. In a 30Hz game that's a significant amount of time, but hardly a deal breaker. In a 60Hz game... well, that's about a fifth of the frame (rounding up, obviously). That's a pretty big deal for something that's often pretty subtle, though obviously impactful. So unfortunately while it's really the subtle stuff that makes the scene look more realistic, it's generally the subtle stuff that ends up getting tossed out the window in favor of flashier and more obvious stuff.

Then there's one last really stupid problem - platform bias. For example, move too much of the rendering work from the RSX to SPU on PS3 and you could actually cause more problems than you solve. If you live in a world where all your artists test on 360 and pretty much "the chumps" on the port team are the only people who ever see PS3 running you can probably happily go nuts pushing work to SPU. If you live on a team that tries to be more disapplined about platform support (some of our artists currently only test on PS3, some only on 360, leads test on both) that can somewhat backfire. So you basically have to design solutions to problems that take both platforms' weaknesses into account from the start, rather than treat it as a porting problem afterwards. Certainly less fun, but much safer than the alternative. For example, an SPU-only solution to SSAO to get that 3 ms back probably doesn't really make sense unless the 360 is so far ahead performance-wise that you've got time to burn.

That's enough for tonight. I really wish I could talk about the specific stuff I'm playing with now, as it's pretty darn cool... but hey, I'll bounce more vagaries and continue to hint at things. :) Some more details another time.