Oh, how many times has that predictable pun been used when discussing games and/or computer graphics?

Anyway, I’ve been asked before why I decided to go 3D for FSU.  After all, when the game was conceived it was going to be a 2D beat ‘em up in classic arcade style, so why the change?  The answer includes technicalities as well as practicalities.

Let it be known that I love 2D games.  There is an intuitiveness that has never been met in gaming (until, arguably, Wii’s introduction) when you plop someone down in front of a controller and a monitor.  Up moves your guy up, down moves him down.  There is never any question of inverted controls, no messing with camera angles.  The game industry’s move to 3D hurt the beat ‘em up genre a great deal, as very few developers ever managed to come up with a targetting system that felt as natural as the 2D classics like Final Fight or Streets of Rage.

Unfortunately, as I discovered, it is difficult to do a 2D sprite-based game at today’s HD resolutions unless you have the luxury of only targetting high-end PC systems with massive amounts of texture memory.  It’s not impossible; Super Street Fighter II HD Remix looks very pretty.  But the developers have admitted they only just squeezed the game into the available memory on the PS3 and 360, and a beat ‘em up generally requires a larger amount of graphic tiles (the backgrounds are usually bigger than a versus fighter, and there are more than two large animated characters at once).  Even though I developed an efficient tile-based renderer for the characters, I was still at two 1024×1024x32 textures for the player with only half of the animations implemented.  Multiply that by four for the different player characters, then add multiple enemy sprite pages, then the background tiles, all this on top of the already large amount of memory for the screen buffer, and you can see the problem.  Aside from the in-memory requirements, I also have to consider this is going to be distributed online, so the amount of content has to fit under the Community Games limit of 150mb.  Sure, compromises could be made - make the characters smaller, use paletted graphics, and so on - but I was not willing to make those changes.

And then you have the practical issues.  We’ve seen that a 2D game needs a lot of art, and of course that art actually has to be drawn.  Not only does this take a long time (how late was SSF2HDR again?) but it requires a very particular set of talents and different artists make it harder to keep the art consistent.  That’s hard enough to manage when you’re a giant developer like Capcom, it’s nigh on impossible when you’re just one guy with some friends.  3D is much more forgiving here; work from multiple contributors is much easier to integrate, and without wishing to insult anyone, it is simply easier to get an acceptable level of quality in 3D art.  I certainly do not consider myself an artist, but I do think I can produce adequate 3D assets, whereas I HAVE to use outside artists for 2D work.

So, 3D it is, then.  But how do I create the classic arcade beat ‘em up feel now?  That goes in the next post.

Another cross-platform release, another clear example of the PS3’s graphical weaknesses.  Based on the demo, Mirror’s Edge is a pretty awesome game that will hopefully provide an exciting first-person experience without being focused on combat.  It’s also filled with lots of straight lines and outdoor lighting, which means it’s easy to see that the PS3 version has no anti-aliasing while the 360 does.  Aliased lines are not as bad in HD as they were when comparing PS2 and Xbox games, but it’s still noticeable.  So the 360 version would be an easy choice.. ..except I prefer the PS3’s controller for this game.  Ah well.

Speaking of aliasing, I’m still hard at work on my game’s renderer.  As it is using deferred shading, I can’t use multisampling, so I think I’m going to have to try some sort of shader-based edge-detection anti-aliasing if it looks too bad.  I’ve added HDR output and blooming though, and it’s looking pretty spiffy.  I just need to get a game out of it.

After finally getting it right (instead of the first two efforts, which were basically enhanced edge detectors) I’m unhappy with the speed hit I’m getting to keep SSAO enabled.  We’re talking 20fps on the 360, which is obviously not good.  I managed to get it up to a stable 30fps by reducing the size of the SSAO buffer (as I’m blurring it anyway it’s not much of a loss) but unless I can keep that when the game is further developed I’ll keep SSAO off.

Besides, my last change broke it anyway :)  I added directional light shadows, but I was unable to get the “reconstruction of the world position from the depth” right so I switched from keeping a depth buffer to storing positions, which mandated moving to HalfVector4 floating point surfaces.  With SSAO disabled I’m still getting 60fps on the 360 (and a not-too-bad 20fps on my 6600GT) so I’ll probably put that problem off for a while and keep with the easier-to-use FP buffers.

I’ve moved to a 32-bit depth buffer packed into R8G8B8A8, and the increased precision looks to have helped.  It’s still not perfect, but I’m reasonably happy with it for now anyway.

As you may know, I’m developing an XNA game.  While originally a 2D game, I’ve embraced the advantages of 3D* and am currently attempting to do screen-space ambient occlusion (SSAO), a technique first shown off in Crysis.

This is my first halfway-successful attempt, but there’s quite a way to go before it’s actually usable:

* I’ll make another post about why 2D just isn’t feasible for some HD games even if you’re trying to obtain a retro/classic feel.

So with the addition of the Xbox 360, I now have every one of the current generation of game systems.  I don’t know how I’m lucky enough to have these fall into my lap; I certainly couldn’t afford the retail price for all of them!

Anyway, because I’m in the minority of people who has had a PS3 a lot longer than a 360 (rather than the other way around) I thought someone somewhere might find it interesting to get my impressions, comparing to the PS3, with what will hopefully be a balance between “more comfortable with the old” and “oooh new and shiny it’s the best ever”.

Read the rest of this entry »

Greg Stephens is gonna be pretty pissed off when he reads this.

Hope you got your GTAIV from somewhere other than your usual Nottingham branch of GAME, Greg.

_{Why yes, this is a sneaky attempt to get jbury’s post to show up in a Google search for Greg Stephens..}

Play more with Konami ID

hahahaha.
LET ME IN DAMN IT, I WANT MY METAL GEAR ONLINE

Yeah, so that was a waste of time.  Trying to use MP3 audio, I mean.  It’s just not suitable as game music if you want to give people the ability to use their own files.  So I went back to libmikmod, which is fine, especially once I realised you have to allocate a couple of channels manually if you want sound effects to play..

Still, the redesign of the piece code to use the GL-like API certainly was time well spent.  Piece manipulation is much smoother now, and I can go back to shuffling tiles around instead of the fade out/in I had to settle for with the software blitting.  I think I’ll make a release soon.

I had expected to get the first update to Puzl out by now, but I got a bit more ambitious with the music options.  See, everybody wants to use their own music, but most people don’t have mods.  They do, however, have lots of mp3s.  So why not play mp3s?

Well, honestly, the DS isn’t particularly suited to streaming/decoding mp3s while doing anything else, like running a game loop.  I’m using Noda’s excellent AS_Lib (essentially a wrapper for Real’s Helix decoder) and it’s playing back, but I can only handle low bitrates and mono.  This isn’t really a problem considering the poor audio playback from the DS without headphones, but I’d be happier if people could just drop the mp3s they want into the music directory without having to reencode.

So I need to speed up Puzl itself.

Read the rest of this entry »