Google+ Comments reposted…

Posted by | Posted in Game Development | Posted on 22-05-2013

To avoid repeating some of the things I’ve been saying on Google+:

“Overall I’m feeling a little “meh” about the XboxOne. It seems as though it can now do all the things that I’m currently using the PS3 and Xbox360 for… but I already have both of those. In fact whilst the PS3 is on literally every single day I haven’t turned on the Xbox360 in a few months because the PS3 does everything that I could want it to do for the foreseeable future.

All of the extra stuff (skype/facebook/not-always-but-sort-on/video-in+out/etc) is all stuff that I either actively don’t want or don’t like.”


“Yes, it seems as though the new XboxOne will do a lot of the things that they’ve belatedly allowed the Xbox360 to do after the PS3 did them first (NetFlix, LoveFilm, etc).

Only it will also come with a boatload of things that Iactively don’t want it to do (Always on, Kinect+, Facebook, Skype, etc) that they could have enabled on the Xbox360 anyway but haven’t.

Meanwhile they’ve forgotten that the reason I’d have bought an XboxOne would be for the games and instead are releasing a console much weaker than the PS4.

If Halo4 had been good enough then I might have bought one, I’ve been a big fan of the Xbox since developing for the first one (that’s not at all confusing…) was such a pleasure compared to the PS2. The Xbox360 continued that by being much nicer to make games for than the PS3.

Seems to have all gone wrong this time around.”

Pretty much sums up how I feel about it all.


Why a consoles CPU architecture is almost irrelevant.

Posted by | Posted in Game Development | Posted on 22-05-2013

In the aftermath of last nights XboxOne announcement this is probably the least technically literate article I’ve read so far:

Why would the CPU architecture make any difference? Answer: It doesn’t. Ok it might make things slightly different, a tiny bit different but frankly there are much bigger differences between even the XboxOne and PS4 than a little thing like the CPU architecture.

With something like that we abstract it once, occasionally fix up a few issues over the development of the title, spend some time during optimisation and… that’s it.

It’s just a tiny cost compared to the vast hours spent dealing with the rendering pipeline differences. The initial system level bringup and porting of our libraries. Dealing with platform specific TCR/TRC compliance and testing. Balancing system resources and usage. Or managing the different build systems and compilers. You still need to do that for ANY new console even when they all use the same underlying architecture because you’re rarely targetting the ASM level directly.

If anything doomed the Wii U it was holding off it’s launch until the next-gen consoles were due so soon. If they’d launched it earlier they’d have had several YEARS to establish it, to iterate on the hardware to bring costs down and resolve any problems with the OS software. Instead they look like an underpowered, last-gen console with poor software support and a gimmick


Part 3: Many hands make for light work.

Posted by | Posted in Game Development, GLSLPlanet, Pioneer | Posted on 19-05-2013

Well this episode has taken longer than planned to get written, or event started for that matter. So lets not delay as this is part 3 of me attempting to explain the terrain system used in Pioneer Space Sim.

If you want to recap and point out poor grammar or spelling mistakes then go ahead and read Parts “1: Pioneer’ing Terrain” and “2: Now with… no feeling in my arms due to all the typing!”.

How things change:

Since Part 2 there have actually been some developments which make this edition even more relevant. At the end of it I mentioned that I’d be covering my work making the terrain generation multi-threaded using a job based system. Well that has now been merged into master and is available in the latest downloads. It’s got some bugs fixed since then and hopefully this will only get truer in the future ;)

Read the rest of this entry »