Sacred 2: The 1080p/Tech Interview

Our performance goal was a mostly constant 30FPS with 'soft' v-sync. I say 'mostly' because Sacred 2 does not limit the amount of enemies on the screen to keep performance up. This was a conscious decision by the game designers, and everyone was aware that this basically makes it impossible to define a minimum frame-rate. I guess you could run around and collect a hundred enemies and then kill them all with an area-effect spell, although I've never tried that myself.

The problem with a hard v-sync is that once you're not fast enough, you literally "drop frames". What this means is that your frame-rate is 60 divided by some integer, ie. 60, 30, 20, 15, 12, etc. Going from 30FPS to 20FPS is a pretty unpleasant experience, and thus we decided to allow tearing (i.e. not to v-sync) when we go below 30FPS. This is basically the same thing the Sony Liverpool guys were talking about in the WipEout interview.

As to what we missed, it's the 30FPS part. At least on the PS3, it is really a CPU issue. Unless you throw something truly unfriendly at it, the renderer is able to run at 30FPS, but the CPU is holding it back. It is really the classic problem of having PC code and struggling to get it onto the SPUs. On a 33ms frame, you have something like 200ms of SPU time available, of which we use maybe 50ms, so there is still plenty of power available, we just did not have the time to rewrite more systems. On the Xbox, you can basically do the same multi-threading tricks as on the PC, so that's easier for gameplay code. You do however lack the raw power of the SPUs, which makes it harder to offload GPU tasks. That's basically where the advantage in rendering performance that you measured during your performance analysis comes from.

At the end, nobody was really happy with how the performance turned out, but we had - averaged over the project's lifetime - something like four tech programmers on the Xbox and two on the PS3, which was not exactly according to plan. Still, my apologies to all the frame-rate and tearing-sensitive people out there.

There is really nothing resolution-specific about the tools. What you need is to get the best possible rendering performance, but that is the case no matter how many pixels you shade. That said, Sony has some amazing tools for debugging and profiling rendering code and the LibGCM API does not get in the way of performance.

Personally, I think there are two major reasons why 1080p is more of a first-party thing. First of all, the Xbox was first, pretty much as powerful as the PS3, and limited to 720p. So a developer would set the image-quality targets, and especially the pixel shader complexity, to correspond to that situation. When the PS3 was released, nobody in their right mind would have halved the per-pixel work to get the game to run at 1080p. So this is my first reason: current image-quality standards are based on 720p, and if we are honest, even that is a challenge.

The second reason is that the number of people playing on 1080p screens is quite low, so there is little added value to most customers. For Sacred 2 this was a bit different, as we need the resolution to get acceptable image quality.

We are in a quite interesting situation right now, with console gamers playing the same games in 480p through component video cables, and in 1080p through HDMI. It is not easy to create a great experience for all of these people and it at the very least requires custom GUIs for each resolution. So at the end of the day, it is probably not worth it for third-party developers, while it may be a nice marketing tool for first-party studios.

So does it work as a marketing tool? Hard to say. A quick Google check shows that about two per cent of sites mentioning the Sacred 2 console versions also mention 1080p, with 2.7 per cent for WipEout HD. To compare: Assassin's Creed is at 0.9 per cent. Interpret this as you wish.

I usually put it like this: The optimal solutions for both platforms are usually surprisingly equal in performance (Hold it, fanboys! I'm not done!). For everything else, it's reasonably fast on the Xbox and absolutely horrible on the PS3.

Of course, it depends on what your game is doing. If you have lots of overdraw, e.g. from particle systems, the Xbox wins, hands down. If you repeatedly switch a buffer from being a render-target to being a texture, the PS3 will beat up your Xbox and take its lunch money. What we found was that for our game (and this is really not translatable to other games!), what one component giveth, another one taketh away. The Xbox would shade something quicker, but pay during resolve. The PS3 would do shadow filtering on the SPUs, but pay extra for particle systems. We really had a very fun competition for the best frametimes between Stephan and myself. At the end, it came out about equal. Sometimes the Xbox wins, sometimes the PS3 does.

As for forced parity, you are of course considering your options. There is a very real chance that you get a strong negative backslash if one version underperforms. I don't know if that actually affects sales, but as third-party, you do not really want to be seen as favouring one system over the other. I am quite happy that we ended up not having to make that choice. I can tell you, however, that few things motivate you quite as much as your version being the 'slow' one.

Well, resolution is something the console OS takes care of, not the game. But they should probably support per-game resolution settings in some unobtrusive way. As to performance settings on the non-resolution type, this is something I don't consider a good idea. All the tuning should have been done by the developer, not by the player.

I haven't seen it in action, but technically, I like it a lot. For a racing game, where you do not actually have the time to marvel at individual pixels, it's a damn nice solution.

The PC team is being dissolved and as of the first of this month, the studio is closed. Most of the console team formed a new company (Gaming Minds Studios) a few weeks back. Personally, I'm currently at the Royal Observatory of Belgium, working as a programmer in the solar physics department. But I'm looking to get back into the gaming industry towards the end of the year.