The Rocket Knight Render Loop

Posted on 18 July 2010

Rocket Knight is now comfortably out of the door; and the memories of long, late nights and almost missed winter holidays sufficiently faded for some useful retrospection. Something that was a little unusual in Rocket Knight, and that we paid particular attention to, was the 3D-as-2D art style. Between that style, practical requirements and the NPR nature of the game it soon became clear I would be building something a little unusual.

Although non photo realistic (NPR) rendered games are nothing out of the ordinary now, they still represent a path less well trod compared to ultra-realistic graphics typical of, for example, Crytek and UE3 based titles. Peculiar to Rocket Knight is a graphical quirk of 2D platformers from times gone by, which ended up having quite a significant impact on the organisation of the render loop.

The details are a little sparse, partly because I’m erring on the side of caution in terms of what might be considered private information and partly because this is about the high level construction of the render loop and not a line-by-line description of the gory details of a NPR renderers innards. The idea is illustrate the considerations involved in building the Rocket Knight render loop in order to properly support the games design and artistic vision.

Loop Phases

0. Lighting

The key to getting a cartoon/comic-book look is essentially to limit the granularity of the tonal range. This is exactly what a basic cell-shader does – instead of applying the result of the lights N.L calculation directly, it generally uses a lookup texture to map the result down to one of a much smaller range of values (there is hundreds of examples on the net, including one from my graduate self many years ago here). A side-effect of this, is that a scene tends to require fewer, stronger lights to make sense. Lots of lights put through a cell shader actually looks quite confusing. This is great news for a graphics programmer, because it means they can do something more interesting than solving shader combinatorics problems and optimising lighting calculations.

That doesn’t mean the lighting is totally trivial though. There are still plenty of variables to experiment with in the lighting – and you still need shadows. It’s really quite rare to see even NPR renderers without some kind of shadowing. Although the enhanced realism is no longer relevant, shadows still provide important visual cues both in terms of “grounding” the characters in the scene and the overall depth and richness of environments.

Rocket Knight shadows used a reasonably standard projection scheme with the usual tweaks for “real world” applications. Shadow map encoding was based on a statistical approximation of the step function – which is an obtuse way of saying we used Exponential Shadow Maps. I first came to ESMs via Marco Salvi’s (excellent) blog [1]; but I also found some useful academic literature [2]. Exponential Shadow Maps were good for us – the filtering and intrinsic algorithm parameters lended themselves to getting the right look and feel for the shadows. You also get relatively good bang from each pixel buck, which meant there was no desperate need for exotic projection schemes – although there were one or two locations that perhaps would have benefited ;).

RK with shadows

Shadows help tie the scene together and establish context between features and surroundings.

Without them, there is a sense that the scene is simply a collection of separate actors.

1. Background world

Traditional 2D platformers always have some attractive but not too distracting background art, rather like desktop wallpaper. We also included another very important item in our “background” geometry data set – platforms! The background environment had precomputed lighting applied, but was also considered for dynamic lighting, including receiving and casting shadows.

2. Characters

Characters is where things start to get a little interesting. If you play a “real” oldie 2D platformer you may notice that jumping onto platforms often involves physically passing through a platform. This doesn’t seem to damage the players suspension of disbelief, probably because the player character always draws on top of the platform.

Since we’re running in a 3D engine though – there is a problem. The characters are going to intersect the platforms in 3D space – meaning they will be briefly drawn in the middle of, and obscured by, the platform they’re jumping onto. This would clearly be rather jarring to the player, so I ended up drawing all the characters twice – once with Z testing off but Z writes on, and then again with Z as normal. The first pass essentially clears the background depth values from the buffer in the region of the character and the second pass correctly draws the character on top of the background environment in the usual manner.

Jumping through platforms is a 2D staple. The same mechanisms allowed defeated enemies to "fall" offscreen.

Foreground layer art added interesting extra features to each level, such as these sewage pipes in 1-1.

3. Foreground world

So far, it’s all good. We’ve got a great looking background in place and character rendering is freed from the real world limitations of both physical reality and 3D maths. Except, actually, we don’t want characters to render over all of the environments. Running in a full 3D renderer creates the opportunity for  foreground environment artwork that scrolls past with correct parallax and creates extra visual depth and interest. So once all the background and characters are drawn, then we come back and draw another set of environment artwork on top.

4. DoF & other post processing

The main full screen effect in Rocket Knight is the Depth of Field. This effect started out life as a physically approximate piece of code (it was concerned with the circle of confusion and what-not) and ended up being 4 planes the artists could shift at will. These four planes defined an in-focus region, and the near and far minimum focus planes. This bears no relation to the physical world, but bears a lot of relation to how our art department liked to think about things. Fortunately, we were making game and not a reality simulator – so it was no problem :). Depth of field was included in Rocket Knight mostly because it allowed us to clearly delineate the play area from the eye candy, and also because it looked nice. In fact, the depth of field was with us from almost day one – if I remember rightly I lifted the original code from a previous project the very same day we put the first grey box into the game.

The other relevant post-process step selectively applied some fog, to further separate eye candy from play area.

Without Depth of Field and fog effects, the scene looks flat and less interesting

Both effects contribute to giving the scene depth and separating gameplay from incidental prettiness.

5. Translucent objects

Environment artwork was able to have complex static SFX artwork embedded, and any SFX requiring translucent rendering are gathered up and applied last. Transparency often causes quite a few problems in a renderer. Anything that alpha-blends with the existing scene (as opposed to e.g. additive alpha) can cause artifacts related to rendering order – and even spending a lot of time on detailed sorting doesn’t guarantee you won’t see artifacts. You also typically don’t render translucent objects into the depth buffer, which can be an issue if you’re using the depth buffer for other effects too.

For Rocket Knight, we chose to render the alpha pass after the post processing. This avoided several depth buffer related problems with the DoF and made no odds in most cases (since SFX were typically happening in the focus region). Our artists were able to make good use of the no-DoF property of SFX – particularly when creating little nuggets of foreground eye candy (they’re quite versatile really, artists).

Summary

So that’s it, the Rocket Knight render loop – give or take some irrelevant and less interesting phases; one or two platform specific steps and a few more bits I’d rather not admit too ;). The render loop was specifically built to accommodate old-school 2D platform motifs and game-play practicalities more specific to our 3D implementation. Often game developers now rely on heavy duty middle-ware to act as high quality graphics black-boxes, but sometimes your best option is to roll your sleeves up and get stuck in.

References

[1] Exponential Shadow Maps @ pixelstoomany blog http://pixelstoomany.wordpress.com/category/shadows/exponential-shadow-maps/

[2] Annen T, Mertens T, Seidel H-P, Flerackers E & Kautz J, 2008, “Exponential Shadow Maps” [online] Available from http://research.edm.uhasselt.be/~tmertens/papers/gi_08_esm.pdf [Accessed 17/07/2010]


No responses yet. You could be the first!

Leave a Response

Recent Posts

Tag Cloud

bin2h

Meta

WayOutHere.co.uk is proudly powered by WordPress and the SubtleFlux theme.

Copyright © WayOutHere.co.uk