Tech Analysis: Bulletstorm Demo (360)

We've been performing our in-depth tech analyses for around a year now, covering some impressive multiplatform conversions, such as the superbly handled Vanquish, to the extremely poor Mafia II. But our look at Bulletstorm is a little different.

Previously, for all our tech-based features we relied on various screen grabs posted by various forum members and by two rather generous German sites (Cynamite.de and Videogameszone.de). While this worked out very well - and indeed continues to do so - it does limit just what we can cover and how we can cover it. This means that we often couldn't perform anaylsis on specific points of interest, nor could we back up some of our findings with a decent image of what we are seeing.

Bulletstorm marks the first game using actual capturing equipment, grabbing lossesly-compressed gameplay along with pixel-perfect HDMI screenshots. As expected, with Blogger's limiting 1GB image hosting allowance, all shots will be compressed down in order to save on space. Plus, videos, when we start using them , will unfortunately be reduced in quality to enable decent YouTube playback in 720p.

Still, it's a start. And there's more to come once I've sorted out a string of issues, all of which have sabotaged short-term plans for a few other features in the pipeline. But take this as a test.

Also, seeing as I've got some serious issues with my HDCP decrypter box, I've been unable to capture any PS3 gameplay footage or screenshots. So, in that case, rather than go head-to-head, today we're going to be looking at the make-up of Bulletstorm's engine, and just how much of it, if anything at all, has been tailored for cross-platform, PS3 and 360 optimisation.

But without further ado, lets get on with our look at the game, high-quality screengrabs in tow, but minus any gameplay video montages.


Starting off, without any pixel counting, Bulletstorm appears to be rendering in 720p on the 360 without any form of anti-aliasing. So, as expected there is plenty of edge shimmering and sub-pixel artefacts to be found - at times the screen can literally crawl with jaggies. This can clearly be seen in the high contrast portions of the game, demonstrated perfectly in the shots taken from the demos's opening segment below.

Seeing as the AA resolve is performed near the begging of the rendering cycle in UE3, when MSAA is present it normally only manifests itself on certain edges in some scenes. Or, as some titles, such as Gears Of War demonstrates, only in static scenes specifically. With that being the case, there's little point in actually including it - the additional memory bandwidth and GPU cycles saved, could be spared for other tasks.


By and large, most of the time when dealing with UE3 games on PS3 we find that getting the engine up to the standard of the 360 build, even getting it running smoothly, is more often than not an afterthought. For every Mass Effect 2 or Singularity, we have a Bioshock 2, whereby various cuts have been made in order to accommodate reduced levels of memory bandwidth and lower vertex shading throughput of the console’s RSX GPU.

Occasionally, developers will choose to pair back the 360 build in order to gain a matching performance on PS3, optimising their code and asset quality so that it favours both systems, rather than just the one. And that's exactly what is apparent with Bulletstorm. While performance isn't a complete match - the PS3 version has slightly more slowdown - we can see that many concessions have been made (on the 360 and on the PS3) in order to accommodate the game's real-time lighting and shadowing system, along with attempting to maintain parity across both platforms.


Take the game's use of texture mapping for a second. Here we have a distinct mixture of clearly normal mapped surfaces in combination with many flat looking areas that go without. Normal mapping has been used efficiently, but also sparingly compared to the likes of, say, Gears Of War.

At the same time, actual texture detail and resolution is decidedly a mixed bag of sorts. Bulletstorm uses a range of low and mid-res assets, with many surfaces featuring some very poor looking textures from a distance, but up close descending even further into blurriness. It seems that the most detailed art-assets in the game, are the ones which are used on key normal-mapped surfaces; more detail, plus depth and resolution.


You can't fail to notice this in motion, and in still screens the various cutbacks stick out like a sore thumb. There is also a lack of AF (anisotropic filtering) present. The game favours the more traditional, and far less performance heavy - on the 360 at least - bilinear approach to filtering.

That said, the fast-paced nature of the game, keeping you constantly moving, always in the flow of hectic and heavy combat, yearning for you to make that next 'killshot', means that this isn't something you'll care to spend time complaining about. In Bulletstorm’s case, it's all about comboing up various killing techniques, from lassoing an enemy from across the screen, before grenading him into oblivion, or delivering a quick kick to head, gunning them down afterwards.



On the one hand, the use of lower res textures for many surfaces along with a more controlled use of normal-mapping, allows for minimum cuts being made to get the game to run in the PS3's more limiting memory confines, whilst comfortably working in 360's fast EDRAM bandwidth. But on the other, it also allows the developers to break free of the Unreal Engine's historic lineage to using pre-backed lighting techniques.

While the UE3 is suitably based around handling lots of pre-backed lit and shadowed environments, it slows down considerably when graced with plentiful amounts of real-time calculations. For those who aren't aware, shadows calculated on the fly, in particular eat up copious amounts of bandwidth used for alpha-channel effects: lots of transparencies equals lots of bandwidth heavy alpha. So, to that end, the more memory saved by chopping back on normal mapping and higher res textures, plus alpha effects res, the more that’s left for other things such as this.




As a result, we see that People Can Fly's latest features a real-time lighting and shadowing implementation, going beyond the pre-backed elements found in Epic's own triple-a titles. And the result is very impressive indeed. Whilst not quite measuring up to Crysis 2's level of accuracy - it's not GI - it's still instantly apparent in how much it improves the overall look of the game.

As you can see in the shots above, and later on this page, both gunfire and your electric whip light up both the environment and the characters contained within. Light is also reflected from the muzzle flash of your gun, back onto your gun itself.



In addition, the surrounding lighting and shadowing composition of the environment also lights and shades your gun accordingly. In Bulletstorm this isn't simply a case of darkening an object at one end, and lightening it on the other; the changes are wholly dynamic in nature, whereby different parts of an object is lit up according to the affecting light source, and of course the shade present in the environment.

The change from pre-backed to a real-time solution - although, it does look like some pre-calculating is still being done in places - basically allows the artwork to not only stand out more, but it also adds some additional depth to the scene. HDR in particular, in combination with the low to high transition, helps with this.



All this comes at a price however, and as a result we can see further tweaks and changes made to the game to accommodate the lighting solution. The alpha buffers, for example are rendered in a lower resolution, thus saving on memory bandwidth needed for things such as real-time shadows. This compromise also ensures a more comfortable transition to the PS3, whereby alpha effects are usually downgraded in resolution to work in more restricted memory environment.

Smoke, fire and particles are all rendered in a lower-res. However, this is barely noticeable in motion, when playing from a reasonable distance on your HDTV - say, about 6ft from a 32" LCD in my case. In addition, all effects have been adequately filtered, meaning that no aliasing is present. The differing layers of 2D sprites which make up such things are also blended nicely - much like in KZ3, although they do look noticeably flatter here.


In terms of performance, Bulletstorm runs at a smooth 30fps for most of the time, only slowing down mildly when the load increases beyond what the engine can cope with. Usually having several enemies on screen at once, along with a few explosions usually is the root cause. But this rarely happens for long periods, nor are the drops severe in nature.

Some people have also posted claims that the game is actually running at a higher framerate than 30fps, as it appears to run very smoothly indeed compared to a number of other 30fps titles. However, this isn't the case at all. Without any equipment to measure this observation, other means of testing are required.

All I did to confirm the 30fps update, was to look down at the floor whilst running forward, before aiming back up to the horizon again whilst moving. Doing this, whilst very un-scientific, allows you to see the characteristic features of a 30fps update - when looking down the lower refresh is obvious - but as you aim upwards and back to the default position, you can see that fluidity does not increase - it's wholly perceptual, and not I might add an actual change in real-world smoothness.

The game also looks like it is v-synced, with tearing only occurring when the engine struggles to cope with rendering the next frame in time. Rather than drop frames, the developers have chosen to disengage v-sync instead, thus maintaining a higher screen refresh rather than drop down to 20fps for short extended periods when the screen is awash with enemies and particles.

You can clearly see this above, in the mid-part of the first section of the demo. Here, the explosion of alpha heavy particles, fire effects, and amount of enemies on screen put the engine under stress. As a result we see a drop in framerate, but also the loss of v-sync as the engine attempts to preserve overall smoothness at the expense of having clean frames displayed.

Outside of these admittedly small blips, Bulletstorm is very solid in this regard. And in terms of what framerate drops and torn frames there are, they represent a very small part of the overall experience whilst playing. In addition while we are just covering the 360 demo, we can also say that the PS3 build looks to be very much the same, being mildly behind the 360 game when stacked up against it.


Back to the graphical make up of the game itself, and we can see a range of further cuts and improvements.

The amount of specularity present in most titles using the UE3 has been paired backed considerably, with less in the way of surfaces that features an overly shiny appearance. Plus, objects that are reasonably far away, but still pretty close when viewed from certain parts of the environment, are displayed as what looks like flat 2D sprites, with on occasion some flat, textured geometry being used instead.



By contrast, we also see the inclusion of a very convincing depth of field blur effect, used to focus your eyes onto the enemies and environment, and away from your weapon. Also, not all effects are rendered in quite as low resolution of the smoke and fire. The lighting from your electric whip looks to be full-res, or at least pretty close to, as does the electric particles that come flying off when used. Whereas, on the other hand, any smoke given off is obviously of a lower quality.



But overall, by the look of things, it's pretty clear that with Bulletstorm the dev team have balanced out the overall load accordingly, speccing out a range of tangible improvements - such as real-time lighting and shadowing - along with a few well-considered downgrades - texture resolution, reduced normal mapped surfaces etc. The use of a combination of low and high-res effects also point towards a firm commitment towards a multiplatform approach to development, while benefiting the game in terms of allowing a more advanced lighting scheme to be used.

At 720p with no AA, the game’s framebuffer comfortably fits into the 360's EDRAM - yet another consideration - while the other memory saving techniques makes the game well-suited for running on the PS3 'as is' without the need to really pair it back any further. That said, I haven't looked at the PS3 build in-depth, in full detail just yet. Although, it does look nigh-on identical, if not so, with lighting being the same, and only a slight difference in performance separating them.

If we get a chance, we should be taking another look at People Can Fly's latest just after release. But, with both Killzone 3 and the Dreamcast collection both incoming on the same day, there are no promises mind. That week will be all about Guerrilla Games' triple-A sequel.

So far, Bulletstorm seems to be reasonably fun, if not a potentially repetitive ride into juvenile shooter exposition. Sexual references and Duke Nukem level humour aside, it's basically what you expect from a FPS that has left its public work persona at home.

Tech Analysis: Crysis 2: Multiplayer Demo (360)

Crysis is synonymous with graphics… that much is obvious. With each instalment in the series, Crytek subsequently included everything but the kitchen sink in their approach to real-time rendering. If performance suffers, then you simply throw in a new graphics card, or two. Now, while that might be fine in the PC space, consoles on the other hand, are somewhat more limiting. That said, with Crysis 2, the developers are still implementing their ‘as much as possible’ philosophy, perhaps only downgrading certain parts of the game in accordance with memory and performance restraints.

To that end, the recent multiplayer demo of Crytek’s upcoming tour-de-force, demonstrates that with a bit of chopping and editing, that is possible to deliver some of the high-end visual components usually seen in either the top-end of real-time rendering, or found in lower-quality CGI, but on consoles. We only have the 360 demo to hand – there isn’t a PS3 one yet, nor has there been anything shown of the Sony version since the initial unveiling of the CryEngine 3. But what we have here is a mightily impressive showing of just what can be done.

So, just how good does Crysis 2 look on consoles, or more specifically, on the Xbox 360? Well, before we begin a proper, it’s fair to say that the game is running on the console with what looks like ‘medium’ detail settings on the PC; which means that you get most of the good stuff, but not without some very obvious pairing back of overall image quality as a result. There have also been a few added effects over and above that of the ‘medium’ setting found in the original Crysis, although not compared to the same setting in the sequel.

Let’s take a closer look.



As always, we start off by looking at the framebuffer. Straight away, via both looking at the screens and by playing, it appears that Crysis 2 seems to be rendering in a sub-HD resolution. Initially, this looks like being somewhere in between that of the Call Of Duty games (1024x640) and Halo Reach (1152x720). However, pixel counting reveals that Crysis 2 actually features a 1152x720 FB just like that of Bungie’s title.

Why on first impressions, it doesn’t look as clean around the edges, is down to the fact that Crytek are using a lot of post processing effects on the screen, along with a low resolution depth of field implementation, whereby objects either in front or behind the DOF feature an addition cut in resolution. This means that Crysis 2 does look slightly softer than other games with similar resolutions. Although, there are other factors which also affect this.

In addition, like with many games operating on the more bandwidth restricted PS3, Crysis 2 uses low-res buffers for all its visual effects. Things such as water, smoke, fire, and other effects are all rendered in a resolution that is significantly lower than that of the framebuffer. Sometimes this goes unnoticed, like in the case of small particles and such, but with the larger effects it is far more apparent.


Moving on, in terms of anti-aliasing, when we first looked at Crysis 2 it appeared that the game seemed to have no AA at all. However, initial looks can be somewhat deceiving, as the screenshots tell us a slightly different story. There seems to be evidence of 2xMSAA on some surfaces, but not on others. Perhaps Crytek are using some kind of selective MSAA routine? Although, delving deeper confirms that a selective, plus temporal approach is what is being used.

The effect of this is clearly evident in the screenshot below. Here, we can see a manifestation of double-image ghosting, a common side effect of the frame blending used in creating temporal anti-aliasing. Where Crysis differs, is that the engine is performing AA on both static and dynamic scenes: selective AA is applied to certain parts of the scene in motion, and on more of it when there is no movement. In comparison, games such as Halo Reach on 360, and DMC4 on the PS3 only apply AA on static scenes.

For the most part, the end result is that Crysis 2 looks like it has no AA at all. There is plenty of edge-shimmering and sub-pixel artefacts that extend across the whole scene. Furthermore, this isn’t helped by the high-contrast nature of the stage present in the demo, nor the upscaled FB, both of which accentuates this further.


Image quality then, leaves a lot to be desired. And this isn’t helped by the use of what looks like an aggressive LOD and texture streaming system, in combination with poor quality texture filtering. Though it is comparable to titles such as Halo ODST, which sacrifice IQ for more advanced effects in other areas. Crysis 2 does the same.

In the demo, we can see a few high-resolution, detailed texture maps, alongside many lower quality ones. In fact, to balance out memory usage Crysis 2 actually has more lower res textures than higher res ones. Most look good all things considered. However, actual filtering is decidedly basic. Crysis 2 appears to be using bilinear filtering for most of its textures, with what looks like the occasional bias towards certain surfaces. Then again, the LOD could be affecting this.

As a result of this, and the LOD, many details in the distance are blurred, and lack sufficient sharpness, which isn’t helped by the consistent, and sometimes varied nature of both geometry and texture pop-up.


While playing, you can notice that various textures, and geometric environmental details – such as grasses, metal railings, etc, tend to pop-up as you come close to approaching them. It’s very obvious in nature, with a few instances of high resolution textures not actually appearing until we got around a metre away from the effected surface.

That said, memory constraints, along with the desire to include real-time lighting and shadowing techniques, means that some compromises have had to be made. Even with the Xbox 360’s fast, bandwidth monster that is the Xenos GPU, there still isn’t enough available in order to have hi-res effects, mild LOD, and top-end IQ. But the choice that Crytek have made, appears to be the right one for the game, especially it seems, when you see how most surfaces are normal mapped, and are affected by the surrounding lighting.

You also have to consider the 360’s 10MB EDRAM limit, by which you have to fit the entire framebuffer into, or get an additional penalty in terms of having to use tiling. And, that’s exactly what Crytek are doing for Crysis 2. By opting for a 1152x720 FB they can avoid tiling.


But as I said earlier, this compromise appears to be worth it given the advanced, tech-heavy lighting engine used throughout every area of the game. For those who don’t know, Crysis 2 – on both consoles and the PC – uses a real-time global illumination system for all the main lightsources in the game. We have hear what Crytek are calling ‘single-bounce global illumination’, whereby, as one lightsource casts a light, it is then reflected once back out into the environment on another surface, casting dynamic shadows as it does this.

Not all light sources in the game cast shadows, nor would you expect them to. However, when there is a few lightsources on screen at once in close proximity, a single, main lightsource – of the few - will cast a dynamic shadow onto the environment instead, thus partially negating this. As a result, there is not only a greater sense of depth to the environment and everything in it, but also a more natural look to any given scene as a whole.


The level of accuracy present from this advanced rendering technique is stunning to see compared to other games which simply fake it, using pre-baked environmental lightmaps, or many local dynamic lights – and a fair amount of baked ones too – in order to emulate this. Crysis uses both a single GI solution, along with additional local lights, thus yielding the best results when processing power is a limited commodity.

For example, there are some really cool touches, such as the light reflections coming off the barrel of your gun when fired, or as it passes through other lightsources in the environment. We can also see light reflected off of shiny surfaces, weapons fire, explosions, etc. and sunlight. All of which is very impressive for a console title using what equates to five year-old technology. But then, that’s the magic of closed box architecture; being able to push the envelope in ways not possible on the PC with similar specifications.


Also impressive, is the use, albeit quite limited, of secondary – or indirect – shadowing on a few surfaces. However, seeing as this comes with a heavy impact on performance, in order to keep the game running smoothly, and in-line with memory contrasints, there is a very aggressive LOD controlling the display of these effects. In-direct shadows only appear mere feet away from the player, often too late to really be noticed when playing the game. They are there however, but in limited amounts.

Complementing this, we have the expected return of SSAO (screen-space ambient occlusion), which features heavily in the core make-up of the CryEngine technology – it’s actually a custom implementation I believe, one that works with the company’s GI solution, and as usual bringing additional depth to the scene.


Other nice touches include high quality specular reflections, whereby the actual light point is reflected more sharply than as a simpler rounded shape. The light reflection has less spread, being more focused. Although, this in turn also depends on the level of specularity of the surface light is supposed to be reflecting from. Either way, specular, and indeed diffuse reflections – the two combined – are handled much more convincing than in most titles.

In addition to the standout GI solution, and the lighting in general , we also have a high-quality implementation of high-dynamic-range lighting (HDR), which not only creates a strong bloom effect when the player is facing the sun, but also a nice transition between both the top and low end of the spectrum. Although, as is evident in the screenshots, Crysis 2 definitely favours the extreme top end in various parts of the demo stage – bloom appears almost too overblown at times, with colour tinting on surfaces that this shouldn’t be occurring on.


We can also see that occasionally, and on some surfaces – mainly on background objects – that the game’s use of lighting appears to be simplified, perhaps even paired back by LOD again. Take the buildings in the distance for example, while appearing slightly basic in construction (textured, polygonal boxes basically), the lighting surrounding them has been reduced - It almost looks like the GI lighting model doesn’t apply to them, or that in some cases, real-time lighting isn’t present.

A fogging effect is also present, no doubt to help hide/blend in the distant low-detail objects produced by the LOD system. Perhaps, this is having an additional affect on the lighting in these areas. In addition we see what looks like a basic skybox. Plus, the smoke effects that cover the sky are flat, and also inconsistent in the way they cover the scene compared with the accuracy of the surrounding lighting.


That said, there’s no doubt that Crytek’s use of such an advanced lighting scheme pays dividends to the overall look they are trying to create. The Crysis 2 multiplayer demo is home to some of the most accomplished lighting seen on a console title. It’s not just the use of dynamic lighting – which many games have now anyway, but the extra level of realism provided by the GI system.

Given the limitations in working on aging, memory starved hardware (compared to today’s top-end, even mid-low-range PC’s), some cuts are always going to be made. Although, when you see just how well the demo performs, these look like being worthy compromises.

Crysis 2 targets a 30fps update, and for the most part, manages to near constantly hold it all throughout the entire experience of the demo. The game only very rarely slows down, and even then, it’s only for a split second or so, dropping what looks like a very small amount of frames. Impressively, it even manages to achieve this feat when there is not only a varying amount of particle effects on screen, but also on the rooftops with several people in one place, where the full force of the game’s GI lighting can be felt.

However, on occasion, when outside and there is lots going on, or as I’ve found, after getting killed and seeing a third-person replay of my death when combat is still breaking out, some slowdown will occur.

So, performance in terms of framerate is solid, but here we also see evidence of the game being fully v-synced too. Without equipment to measure if there are any frames being torn – even if it is just a single one in the whole rendering cycle – we can’t say for sure, 100%. But, what is clear, is that throughout the time spent in the company of the demo so far, no screen tearing seemed to be apparent.

In any case, even if one or two frames were being torn, unless there is a steady succession of torn frames in a row, then any screen tearing simply won’t be visible to the human eye. So, it stands to reason that Crysis 2 maintains some kind of v-sync: either a hard sync, or a soft v-sync dependant on rendering load.


One thing that doesn’t feel quite right though, alongside Crysis 2’s smooth 30fps refresh rate, is the noticeable input lag felt when jumping or performing other moves. You can also feel the very same thing as you aim and fire too. So, what could be causing this?

Well, my best guess - seeing as the game appears to be v-synced - is that Crytek could be using a frame buffering technique in addition to a soft v-sync, such as double buffering, whereby two frames are rendered for every one displayed with one being held in reserve just in case the first tears. That would at lest explain the additional latency that we seem to be feeling, although this isn’t a solid conformation on the matter.

Looking at how the game performs under load, the solidness of the 30fps update, we can understand just why some of the less attractive compromises were made. The experience as a whole is a smoother, more succinct one. It’s very impressive on the whole. There has been a balancing act between trading off certain elements in order to get others up and running in budget, per frame no less, and without increasing overall cost in other areas to do so.

In that respect, this is all to be expected on a console release dealing with GI solutions and plenty of dynamic lights. Crytek’s engine does indeed render various parts of the pipeline in different passes, and with varying degrees of quality. Although, it also delivers many high-end effects all in one package, which is something that most console releases fail to do.


The fact is, Crysis 2 currently looks great on consoles. And that can only be a good thing. Sure enough, there have been some downgrades. But, realistically, when you’ve got GI, SSAO and object-based motion blur, that is only to be expected. Plus, in any case, the admittedly low quality IQ does little to spoil the experience, considering what’s included.

Like with the very sub-HD framebuffer in Alan wake, the lack of AF plus a solid AA solution in Crysis 2, are all negated somewhat – though not completely - by the sheer beauty of the game’s real-time lighting, and the interactivity between it and various surfaces present in the world. Near rock-solid performance at 30fps with no screen tearing doesn’t hurt either.

Perhaps all that’s left, is to wax lyrical about the possibilities surrounding the currently MIA PS3 version of the game. However, if you’re looking for talk of the system’s bandwidth limitations potentially resulting yet further downgrades, loss of IQ, then you’ll be somewhat disappointed. If a recent, internal config file of the game is to be believed - the info contained within specifically puts the two versions on a par with each other, with the implementation of v-sync in relation to performance separating them – then this shouldn’t be the case.

The most likely scenario, in the weight of no further evidence being available at this point, is that the compromises found in the 360 demo have been brought about by optimising the engine to run comfortably, and within range of both systems specs, taking into account various nuances, such as 360’s EDRAM, and PS3’s additional CPU processing power. But then gain, we’ll just have to wait and see.

With the demo out of the way, it will be interesting to see what the final game has in store for us - specifically the single-player campaign. Usually, the multiplayer aspect often sees some graphical cut backs in order to maintain better performance for online purposes, and unpredictable load. The demo also showcased a definitive improvement over the old campaign code I played at the EG Expo back in October. So, by that reasoning, it is entirely possible that we could see additional improvements to the game in the final retail version.

Thanks go out to Mazinger Dude for the pixel counting and Shinnn for the screenshots.

Tech Analysis: Little Big Planet 2 (PS3)

Little Big Planet was a game that really got those creative juices flowing. On the surface it was a simple, physics-based platformer. But under the hood it became apparent that it was so much more. The tools given to create and design your own levels could be used in such a way that went well beyond the platform confines Media Molecule had envisioned for the title. And for LBP2, things have been taken a step further, with a complete set of tools designed to allow for just that: building your own creation that bypasses platforming altogether.

Of course, outside of the successes such unique custom content has found - and indeed there are millions of user-created downloads to be hand - the engine powering the game was always there to facilitate a natural realism, bound by real-world properties, and developed to augment the title’s physics-based approach. To that end, the original LBP featured both a realistic lighting and shadowing system, even emulating light passing through dense objects, along with a range of impressive, though perhaps restrained, visual effects.

For LBP2, Media Molecule have gone back and re-written most of their original engine, expanding on various graphical concepts simply toyed with in the first game, to delivering a fully-realised implementation here. This sequel incorporates comprehensive changes to nearly every part of the engine: lighting and shadowing for one, anti-aliasing and core rendering make-up to name but two more. All these tweaks and upgrades have not only made for an impressively organic visual look, but are also far more accurate in nature.


Take the baseline framebuffer for a second. LBP2 renders in 720p, like the original, but ditches the standard 2xMSAA (multi-sampling anti-aliasing) for Sony’s custom MLAA (morphological anti-aliasing) solution instead. The end result is a clean and sharp look, with incredibly smooth edges, free from most obvious edge shimmering and other such artefacts. Here, we see up to 16x MSAA on some surfaces in-line with the level of edge-smoothing this technique regularly provides, along with 4x and 8x on other smaller pieces of geometry.

The only aliasing that we can frequently notice on some areas, appears to be from various sub-pixel edges. There are also examples of what we like to call ‘soft’ edge shimmering on a few AA’d edges at certain angles. Although, most have competently been dealt with. Indeed, a lot of the aliasing present on screen is very similar to the kind seen in supersampled, in-game trailers; that is to say, its impact is very small in diminishing the high level of image quality we can see in Media Molecule’s sequel.


A change in the method of AA used is but one upgrade LBP2 has seen. The developers have also completely re-written their engine to work as a standard forward renderer, thus making certain visual effects much easier to do. Previously, parts of LBP1’s core rendering make-up was differed, meaning that some elements of the engine were sufficiently bottlenecked – use of alpha effects for example, had to be done via the less desirable A2C method, thus inducing a screen-door effect on many transparencies, like smoke and fire.

In LBP2, this isn’t at all the case. Here we see that all transparent effects are rendered using the more standard alpha coverage, with alpha blend method, free from the dithered, pixelated look they had before. Not only are these effects now easier to do, they are also better blended too. Particle effects, other elements, such as smoke and fire, are still rendered in a lower resolution. However, they are nicely smoothed over to avoid any pixelation, or other similar side-effects, much like the use of alpha in both Killzone 1&2.


Far more interesting, is the way that these effects now interact with the game’s light sources, in changing the intensity of the lighting and in turn, the way shadows are cast as a result. This is down to the game’s brand new lighting engine, which accurately simulates global illumination in how the entire game is lit and shaded. LBP2 uses something called volumetric lighting, whereby individual lights affects how other objects all around them are lit, with elements such as reflections and specular highlights changing dynamically.

A single light source in LBP2 now has the ability to change the lighting composition of the entire scene. Shadows are cast via every light source – and indeed every object - and move accordingly with changes to the lighting present. This is best observed as Sackboy traverses his environment, moving in and out of contrasting areas of brightness, and through more subtle changes in environmental shadowing, along with when there is lots of objects being randomly thrown around the screen, each with their own shadow.

We can also see evidence of ambient occlusion. Previously, we thought that LBP2 was simply using SSAO to deliver AO on various surfaces, characters etc. However, that isn’t the case. LBP2 actually features real-time ambient occlusion as a consequence of its volumetric lighting engine. For most games, this would perhaps be too resource intensive to do. Although, the simpler nature of LBP’s world, and being far more tightly controlled in terms of the rendering workload on screen, allows this to be possible.


In addition, we can also see that LBP2 also makes use of volumetric alpha effects, whereby flat, 2D spites can contain three-dimensional volume, having an incredibly obvious, depth look to then, whilst controlling the light output through the effect. A series of values contain that volume inside say, a cloud of smoke, giving the object depth, but more importantly accurately limiting/changing the amount of light that passes though it.

It’s a nice effect, one that appears to be only subtly used in what I’ve played of the game so far. On some downloadable, user-created stages however, ones with plenty of explosions, smoke and particles, the result is more obvious. Seeing the amount of light reduce underneath, or very mildly to the side of a cloud of smoke or mist, but not simply a pre-calculated dimming, but what looks looks like physically less light output is a key demonstrator of the effect in action.

In combination with the game’s use of light and shadow, this helps to emphasise the realistic look that MM have sort to create for the fantastical world of LBP2. Added depth is one consequence, but mostly, having all objects accurately look like they exist tangibly in the world is another.


Going back to LBP2’s use of shadowing, we’ve already mentioned that the game engine casts shadows for every object on screen, wherein a clear example of shadowing would realistically take place. Although, what we’ve failed to mention is that the game also uses soft shadows for all objects too.

These shadows, like with the game’s alpha affects, are rendered in a lower resolution to the framebuffer. However, this is negated somewhat – though not totally – by the use of high quality shadow filtering, which helps blend in the lower res soft shadows onto their environment and other objects.

There are still some examples of flickering shadows, and jittering edges where the use of filtering isn’t enough to hide their low-res nature. But, then again, outside of a in-engine, pre-rendred cut-scene, or in the obscenely high-end PC space, shadowing errors are simply part and parcel of current real-time rendering with performance-sapping, hardware limitations.


Another impressive part of LBP2’s technical make-up to look at, is the game’s use of real-world physics in how objects in this artificial world react. Swing on a rope, and you can almost feel the pull of gravity; push over a stack of lightweight boxes, and watch the ease of how they tumble, knocking others over, pushing and falling in accordance to their physical properties. Heavy objects also have weight behind them: Sackboy himself, bounces and flows through the air like stuffed and stitched toy – all of which adds a sense of real tangibility to the world these items and characters inhabit.

Also, these elements allow you to have an understanding of how many of the objects, challenges and puzzles work, before even attempting them. Once you know which objects have which properties – and some are obvious as soon as you see them, then all you have to do is master their usage, but using your own worldly understanding to do so. And of course, the technique required with the Dual Shock controller.

Occasionally, objects, characters etc, react with a ragdoll-like effect, which partially breaks the illusion that Media Molecule have created. Although, with so much going on technically, you can’t expect perfect representation of physics. Even in high-end CGI productions, replicating certain properties flawlessly, even just accurately, is a lot of the time, beyond what is feasible, let alone possible in a real-time rendered environment. In which case, the developers have done an absolutely stellar job with LBP2 as a whole, carefully balancing out what works and what doesn’t.


Moving on, and in addition the numerous advancements in lighting and shadowing, we can also see the inclusion of both a depth of field effect present in the background on some stages, and motion blur on fast moving objects.

Interestingly, the implementation of motion blur seems to be relatively simple – it affects the whole screen, rather than being done per-object, like in Killzone 3, and the original LBP. The reason for the downgrade – even though the effect still looks very good – seems to stem from having such an accurate, and performance-heavy lighting system as part of the core rendering engine. As such, there is less rendering time per-frame left for object-based motion blur. Instead, blur appears to be done as a simpler post-process effect.

On the off-set, all these advanced visual effects; the accurate, real-time nature of the game’s shadowing and lighting, motion blur, and depth of field, you would assume to have quite an impact on performance – that a heavy performance hit wouldn’t be unusual. Although, whilst sampling a few levels from the game’s campaign and some additional user-created stages, that doesn’t seem to be the case


Little Big Planet largely runs smoothly, simple dropping a few frames when the load increases beyond the engine’s capacity to resolve it, with v-sync being completely absent and some noticeable screen tearing sometimes being apparent. Media Molecule targets a solid 30fps update, and rather than allow for the framerate to drop heavily whilst encountering a heavier load, prefers to go over budget with rendering the next frame instead. Thus, we can see that a 30fps update is maintained in situations whereby if the game was v-synced, would drop down to 20fps for a brief moment or so, maybe longer, with some screen tearing being apparent as a result.

While the engine does successfully attempt to hold a steady 30fps for the most part, we can see that it does occasionally slow down, sometimes quite obviously down to around what looks like 20fps or so for a brief second or so, sometimes far less so. However, for much of the time what we are seeing as framerate drops, are actually manifestations of very mild tearing, in which the screen wobbles briefly for a split second or so, instead of tearing noticeably.

The engine frequently misses its window for rendering the next frame however, and as a result, we see a large amount of tearing on fairly frequent occasions, where the effect is clearly visible across the middle of the screen when it happens, sometimes mostly to the left, or all the way across, depending on how much the engine stalls.

At it’s worst, there can be many torn frames manifesting one after the other: the end product is what looks like a juddering in combination with a tearing of the screen. When this occurs it looks like the game is both dropping frames and tearing, but in reality is still holding a mostly solid 30fps.

But despite this, the overall engine’s performance is largely solid - sans perhaps the screen tearing, but otherwise, given the strain due to the complexity of the game’s core graphical, and indeed physics-based make-up, you can’t really complain too much. All that additional oomph goes a long way to further immersing you in Sackboy’s world, so I think that the performance trade-offs are worth it.


At first it might seem surprising to see such a technically accomplished rendering engine, for such a quaint, although very impressive platformer. But, when looking at how the core graphical make-up really adds a sense of immersion, a sense of increased believability to the world contained within, then it becomes completely beneficial.

Many of the elements that make LBP as magical as it is to play – not to mention to watch up close or from a distance – is down to how most elements in this virtual world act according to what we know about reality, the physical world around us. Things such as objects casting shadows which change as a result of the direction of a light source, or the smooth edges found throughout (MLAA) that hides the per-pixel, blocky nature of digital rendering. All definitively add something to the table, however small they initially appear to be.

In which case, Media Molecule has done a stellar job at creating a game that is as technically advanced as it is visually accurate. I doubt anyone will actually play LBP for its superb graphical make-up, but instead be fully engrossed in its fresh and addictively unique gameplay. The visuals, as it were, are simply there to facilitate the atmosphere and add an extra sense of realism to a cute, but cool, fantasy world. In that respect, LBP2 can be really nice to look at, but even better to play. And that’s exactly the point, really.

Thanks to Cynamite.de (gamesaktuell) for the screens and AlStrong for the pixel counting. Various galleries can be found here. Plus, a special no thanks to my phone cam, which failed to pick-up a very clear example of volumetric fog in a really dark area of the game.

Up Next: Crysis 2 analysis due for late tomorrow evening.

Retro Tech Analysis: Virtua Racing (MD vs 32X)

Well, here’s the final part of our Christmas/New Year holiday coverage. Having mostly been put together after hours outside of a busy period at work this week, you’ll find a comprehensive and in-depth head-to-head analysis of Sega’s Virtua Racing.

I guess you could have see it coming from our earlier post. Regardless, it's certainly been fun putting it together. Anyway, we’ll be back after this sometime next week for the start of our regular 2011 updates, but for now, have a Happy New Year and enjoy!

Virtua Racing wasn’t the first 3D racing game to properly make use of polygons in the make up of both its cars and environments, although it did firmly set the president for all other arcade racers to follow. With a decidedly unique approach to realism – slidey handling mixed with spin-outs and flip-over crashes – it not only played differently to similar sprite-based games, but also delivered that 3D ‘wow’ factor by giving players four different viewpoints to choose from, and three highly detailed tracks to immerse you in its world.

It was also one of the first fully featured 3D titles to arrive on home consoles, battling against the likes of Starwing and Stunt Race FX on the Super NES for domination of the early 3D arms race before it really kicked off with the 32bit generation.

Sega first produced a version of the VR for the MegaDrive, using a similar method of in-cart enhancement as Nintendo, courtesy of the SVP (Sega Vitual Processor) chip - which handled all the geometry calculations and drew all the polygons for the game - but then transformed the idea into the fledgling 32X, a full blown add-on for the aging 16bit MD, along with a expanded release of the game, dubbed Virtua Racing Deluxe, in time for the machine’s launch in November 1994.

Today we shall be looking at both the MD and 32X ports of the game, comparing and contrasting the two for a special retro tech analysis of sorts. However, in order to capture screenshots for this feature, and to compare direct performance via (sadly unpublished) videos, we’ve had to use emulation for the basis of our analysis rather than actual hardware. Thankfully, in order to keep any rendering errors, and artificial performance anomalies to the bare minimum, we are running both games using Kega Fusion - the most accurate of all the MD emulators out there - with settings that closely represent the game running on original hardware.

So without further ado, let’s get on with it.


MD


32X

Like with the latest titles on both the Xbox 360 and the PS3, framebuffer resolution was as important back then when it came to image sharpness and clarity as it is now, with many games boasting a range of differing native resolutions. Virtua Racing is no exception. Rendering in 256x240 on the MD and 320x240 on the 32X, both versions feature the same overall 240p vertical resolution with the MD sacrificing some horizontal resolution for performance reasons.

However, both versions are also clipped to a 192 vertical resolution, with black boarders being used for the remainder of pixels rendered on screen. This means, that like in SF2:SCE, there are small boarders visible at the top and bottom of the screen that appear in PAL and NTSC versions of the game – the boarders are just larger in PAL 50hz mode owing to the extra unused screen resolution on display.

As expected there is also no anti-aliasing to be found - a visual effect which didn’t appear in home console graphics architectures until the debut of the N64 in late 1996. Instead polygons are presented in one of their rawest forms, flat shaded with pixel edges clearly being visible throughout.


MD


32X

In screenshots, the difference in native resolution comes across with one image looking smaller than the other. Although, on the TV this manifests itself with the MD version looking softer than the 32X game. As there is no scaling involved at any point, it’s instead up to the TV to manually stretch out the picture to the correct aspect ratio of the screen, which is done on a CRT by the electron bean scanning the lesser amount of pixels across a greater number of phosphors without any digital processing.

Softness is also increased by the MD version’s use of heavy dithering, used to simulate more colours on screen at once than what the system is capable of. Essentially, the MD game uses 15 colours for the polygon layer – 4bit pixels paired as single 8bit pixels, whilst the 32X version uses the system’s direct colour mode with 15-bit RGB and 16bpp in order to deliver 256 plus colours on screen at once. Using this mode, its actually possible for the machine to display up to 32,000 colours on-screen. Although, VRD doesn't do this.


MD


32X

As a result VR on the MD uses lots of selective dithering for representing many different shades of geometry for both the scenery and the actual cars, while on the 32X dithering is reserved purely for transparencies, with multiple shades and colours being used for polygon details.

In the screenshot above, you can see that on the 32X transparent objects such as shadows and selected smoke effects are dithered, whereas on the MD everything from the cars, the environment, and the effects use the technique. There are comparatively few areas of the stock VR game that don’t use dithering to balance out the lack of available colours for suitable 3D rendering. Unlike fully textured geometry, objects using flat shaded geometry require a greater number of colours to represent detailed imagery.

The downside to this, is that the heavily dithered image composition of the MD game leads to some noticeably fuzzy edges being present, along with making it more difficult to read the road up ahead – something which also isn’t helped by the game’s short draw distance.


RAW FB


Filtered FB

Dithering however, is largely only visible in unfiltered images. For example the above screenshots show, roughly, how the game would have looked via the MD’s – and indeed the 32X’s – video outputs using RGB SCART cables on a SD CRT. As you can see, dithering is greatly reduced due to the blending effect created by the filtered FB output, although some sharpness is lost as a result.


MD


32X

It’s fair to say then, that the Megadrive wasn’t set up with 3D rendering in mind. The system has no geometry processor, and features a CPU which is insufficient in rendering anything but the most primitive of polygonal shapes in small amounts. However, Virtua Racing manages to push around 6,500 polygons per-second via the use of Sega’s SVP chip – a DSP created by Samsung that handles all the geometry transform and rasterisation.

By contrast, the 32X has the benefit of featuring two Hitachi SH-2 CPU’s running at 23MHz in tandem, thus being able to churn out up to 50,000 polygons per-second in a best case scenario. How many PPS Virtua Racing Deluxe is pushing on screen we’re not exactly sure. However, it is definitely apparent that the number is significantly higher than what the MD using the SVP is doing.

On the other hand, the arcade version – powered by Sega’s Model 1 board – can deliver up to 180,000 flat-shaded PPS in-game, and does so with Virtua Racing at 30 frames per-second, so obviously it still has a sizable lead over both the MD and 32X games respectively.

In fact, the 32X game has much more in common overall with the MD version than with the coin-op. Although the cars themselves more accurately represent the arcade game in terms of raw detail, the trackside scenery, and the level of detail overall looks far more like an expansion of the modelling done on VR for the limited capabilities of the SVP chip powering the MD game. That said, the 32X version does a great job of representing the arcade on much weaker hardware.


MD


32X

The differences between each system’s hardware capabilities naturally have a great impact on just how well each version is replicated onscreen, with the added polygon pushing power of the 32X resulting in more detail cars and trackside scenery. Whereas the MD game just about resembles the coin-op, the 32X version on the other hand manages to replicate it a lot closer in certain areas.

The cars for example, are massively paired back on the MD. For comparison purposes we can only look at the stock formula 1 car, as the 32X game features the inclusion of two exclusive vehicles not in the arcade original or the MD game – the stock car, and prototype car. However, the formula 1 vehicle is bar far the most complex, featuring small interconnecting parts with more intricate geometric shapes making up its polygonal design.


MD


32X

Looking at the player’s car, we can see that its design on the MD is simply made up on more angular, square and rectangular-like shapes, with the wheels being directly attached to the side of the main body of the vehicle.

Around the front, and we can see examples of the curved design iconic to that of F1 and IndyCar vehicles, although decidedly blocky and very low poly. It can be quite hard to recognise the individual details which make up the various parts of the car in the rear, chase-cam view in comparison to both the 32X game and the coin-op.

The 32X version on the other hand, has a main vehicle that is not only more intricately detailed but also one that better represents the ones found in the arcade original as a whole. As you can see above, the wheels are now connected to the main body via individual rods, just like they would be on a real F1 car.

In addition, the front structure is more curved, and features an increased cone-like design, which better replicates the aerodynamic chassis required for high-speed racing. There is also better separation of the front, cockpit, and rear of the car, with the individual elements being more identifiable than on the MD version.

Despite the more detailed nature of the cars in general in the 32X game, there are some elements of the blocky MD vehicles that more closely represent the arcade version in some scenes.


MD


32X

In terms of the environment, both versions are at times reasonably close to each other, with the overall landscape holding similar shape and geometric composition despite the differences in polygons used throughout. The 32X version however, features bulked up parts of the environment using more geometry and a greater number of on-screen colours to smoothen off the rougher edges. Mountains in particular not only look larger on the 32X, but also feature much smoother transitions between gradients.

In other areas we can see more in the way of smaller environment details. In particular, the ferris wheel on the fairground is noticeably more complex in VRD compared to the MD game. While similar things can also be seen with the stands throughout the opening section of the Expert course, along with additional extras such as more in the way of metal railings and other trackside structures.


MD


32X

The pit crew look largerly identical, with only minor tweaks and featuring a different colour scheme. They appear to be constructed from various rectangular and square shaped boxes in combination with strips. Obviously, due to the poly starved nature of both the MD and the 32X, neither version showcases anything near approaching a human-like representation of people.


MD


32X

Strangely, there are areas in which the 32X game seems to feature less in the way of trackside detail than the MD one. In the above screenshots we can see what looks like a group of small white buildings upon the mountains in the MD version, while in the 32X version, although the mountains themselves appear fuller in terms of size and complexity, the buildings have been removed.

Across the whole game there are other such discrepancies between the two versions, in which some subtle details have been removed in the 32X version in order to accommodate the higher poly - and in itself more detailed - baseline scenery instead. On the plus size, the courses themselves are made up of larger objects which bring a far greater sense of scale to the proceedings compared to the standard VR on the MD.


MD


32X

Of course not all of the changes between VR and VR Deluxe are technical enhancements and compromises. A few differences appear to be purely cosmetic. Take for example, the sign pictured above from the Expert Course: on the MD it says “Sonic”, whereas the same one is displaying “32X” for Sega's upgraded Deluxe version.


MD


32X

The Course Select screen has also been updated in the 32X version from both the MD and the arcade. Each course has been given a rotating 3D model on the selection screen, along with the cars being given the same treatment on another menu. However, in the original arcade and MD games, the course select screen simply features a still 2D bitmap image instead.

The improvements don’t have a baring on the overall conversion quality of the two console conversions, although the spruced up presentation elements of the 32X game makes initial experience feel a little fresher and more in-keeping with the early 3D revolution that was taking place at the time.


MD


32X

Draw distance however, does greatly impact on the level of enjoyment you’re likely to get from each game, not least of all because the dithered nature of the MD version also further affects this, sometimes adversely – the fuzzier overall look makes seeing distance objects somewhat more difficult.

While both versions initially appear to have similar levels of polygon pop-up, there are instances where the 32X game suffers from closer on screen draw-in of certain objects, whilst the MD version features a more consistent level of draw-in on the whole. Smaller environmental details tend to pop-up later on the 32X, while the larger chunks of scenery usually appear at the same time, or slightly earlier than on the MD.

However, this peculiar observation seems to be track specific, with most of the offending examples happening on the beginner course. On most of the other tracks, pop-up seems to be near identical for both games; that is to say, while it can be rather intrusive at times, it is for the most part tolerable once you get used to it. Although, using the in-car view is pretty much useless, with the default, and higher viewpoints providing by far the best gameplay experience due to the closeness of the draw distance and overall image quality as a whole.


MD


32X

Moving on, and performance is rather interesting in Virtua Racing, not least of all because the game runs at such low framerates by modern standards, but because it still feels rather smooth on both formats despite this. Obviously, as already mentioned, the arcade game runs at a solid 30fps with full v-sync enabled - something that neither of the two home console conversions could manage without further heavy cuts in detail, and even then it would be virtually impossible on the MD using the current SVP chip implementation.

Instead, we see the framerate on the MD version halved in comparison to the coin-op. Virtua Racing runs at a solid 15fps on Sega’s 16bit platform, right in accordance with the SVP chip’s 6,500 polygons per-second at 15 frames per-second in-game limit. Even when spinning out of control, or crashing with other vehicles before flipping your car over in a similarly ridged fashion to that of the arcade game, VR never slows down.

By contrast, similar games from the time – like the Super NES’ Super FX powered Stunt Race FX – run at anything between 12-15fps depending on engine load and scene complexity, making Sega’s conversion to the MD all the more impressive. This feat is further enhanced when you consider that the game allows you to select all four views from the original arcade game – one of which sees you looking down on the race via an ‘eye in the sky’ type position, pushing engine load without faltering.

Interestingly, when playing this version of the game first, self-contained and away from other versions, the framerate feels pretty smooth despite being so low. It’s only when put up against Virtua Racing Deluxe does the lack of fluidity strongly manifest itself.

Jumping to VRD on the 32X, and the difference in smoothness is instantly noticeable. Like with VR on the MD, Deluxe is fully v-synced with no visible screen tearing occurring at any point. However, unlike the MD game, it comes even closer to matching the arcade game’s 30fps benchmark. Here, we see a solid 20fps update providing a clear extra level of fluidity above that of the MD version. Control not only feels smoother but also more responsive.

In any case, both home versions of the game pale in comparison to the coin-op, which not only boasts a much smoother framerate, but also vastly superior levels of detail. However, both the MD and 32X ports are incredibly accomplished, and for their time represent some of the very best in arcade to home experiences any console could offer.

Overall performance across both home versions is solid, free of any screen tearing, but most of all, smooth enough to allow for a fully playable experience, even if the MD game feels more than a little rough around the edges after sampling the 32X version.


MD


32X

What is surprising, is that Virtua Racing still holds up relatively well after all these years... on the 32X at least. Sure, the draw distance is a bitter reminder of the mixed travesty that was in some areas the Saturn conversion of Daytona USA - often impeding your ability in reading the road using the cockpit view - but the overall modelling of the environments, the look of the cars, and the crisp, responsive control, means that the game, to this day, is still very playable.

On the other hand, the MD version isn’t quite so lucky. The heavily dithered nature of the scenery, and the blocky, low poly enemy cars means that both sharp turns and other vehicles are sometimes very hard to spot before colliding straight into them. However, the game’s 15fps update still feels surprisingly smooth considering just how low it really is. Most of the problems don’t stem from the lack of overall fluidity, but from poor image quality and a large amount of polygon pop-up. Both of which do far more harm than good.

That said, getting Virtua Racing running on both of these consoles to a playable, even enjoyable, standard is somewhat remarkable. But whether this was the right thing to do, instead of focusing on the Saturn in the first place, is anyone’s guess. Either way, for most people Sega’s 16bit console and 32bit mushroom add-on was the only way to play Virtua Racing at home.

Of course, today that’s a moot point. Seeing as a definitive version of the game has been available for the last few years on the PS2 - its 60fps, and with the arcade game being near perfectly emulated in MAME, you could argue, is there really any reason to pick up such archaic conversions?

For anyone who likes to play games on proper hardware, free from the glitches and disconnecting feel sometimes offered up by emulation, then yes, I would certainly say so. In which case the 32X game is clearly the one to go for. Representing a fine balance between heavily cut down home console port and excellent arcade conversion, it manages to out perform the botched Saturn version in both graphics and gameplay overall, whilst still being a thoroughly faithful adaptation of Sega’s first 3D gaming sensation.