Dirt!

MS should feel embarrassed that their platform-exclusive-1st-party-showcase racing sim Forza2 doesn't look half as pretty as the 3rd-party-multi-platform game Dirt (dIRT? DiRT? DIrT? whatever...) I went straight from playing Forza to Dirt and my first reaction was basically the German equivalent of "OMG that looks f*cking AWESOME!". Sure, Forza has another focus, it's a hardcore racing sim for enthusiasts, has a much more realistic driving model, online features and a multiplayer mode which can actually be called "multiplayer". While Dirt isn't an arcade racer by any means, it definitely feels a bit more "arcadey" then Forza2. Still, Forza should at least have tried to come closer to Dirt-level graphics. Compared to Dirt, Forza2 kinda looks like the boring civilian flight simulator with the ultra-realistic flight model and simplistic graphics that only hobby pilots fly.

The graphics in Dirt are truly "next gen", which in comparison can't really be said about Forza. I would go as far and say that Dirt is at the moment the second best looking 360 game after Gears, and the new "other" graphics-showcase on the 360.

PS: Don't judge Dirt's graphics by the demo on Xbox Live. The demo tracks there have hardly any vegetation in them. The European and Japanese tracks in the full version look much much better. And the immersion and sense of speed when racing a wet narrow forest track at 180 km/h in Dirt is simply unbelievable.

Status Update...

Busy...

Working on the Xbox360 is total joy. Unfortunately I can't go into details because of NDA. I did some work on the original Xbox already, so it's not all new to me, but I was once again pleasantly surprised how painless the XDK setup is. All you have to do is plug-in some cables, double-click the installer, and after the installation ends (10..15 minutes) you're ready to compile and remote-debug the samples inside Visual Studio. Very impressive. The APIs basically offer everything a game programmer ever needs (and misses on the PC), the documentation is excellent. There's a wealth of high level APIs, but it's absolutely possible (and relatively painless) to go down to the metal if needed. Both is very important on a console. When the high level APIs are missing, too much time is wasted reinventing wheels (I guess that's one of the reasons why ports from the 360 to PS3 often take so long), and the low level stuff is necessary for optimizing performance-critical code (which is usually not possible or worthwhile on the PC because of all the different hardware configurations).

At the moment I only have 2 or 3 hours daily and the weekends to actually work on Nebula3, but despite that it's coming along nicely.

The Nebula3 Foundation Layer is already up and running on the 360. This is not a quick "just-fix-the-compile-errors" port", but a "proper" port which makes use of the 360's specialties. I had to take 2 things out, and move into a new "Add-On Layer": the HTTP stuff and the Database subsystem. The only other things that needed to be fixed were some data alignment issues and (naturally) byte order issues in the BinaryReader/BinaryWriter classes. I'll add some testing and benchmarking classes next week and then move on to the Render Layer.

Considering the differences between the 2 platforms (different byte order, 32 bit vs. 64 bit, different compiler back ends), everything was completely painless. The usual first experience when bringing code to a new platform is looking at pages of compiler warnings scrolling by. On the 360 SDK most of Nebula3 compiled and ran out of the box on warning level 4 without warnings.

I really wish MS would bring ALL the high level XDK APIs and tools over to Windows! They already started with XACT, XInput and PIX, but there's so much more cool stuff on the 360 that's missing on the PC and which would make a PC game programmer's life so much easier...

PS: Prince Of Persia Classic rocks. Best Arcade game ever :)

It Begins...

CvsMonitor rocks

If you use CVS for version control and don't know CvsMonitor yet you should definitely have a look at it. It provides in-depth stats to cvs repositories and most importantly, provides a changeset view, so you can see immediately who's responsible for breaking the nightly build, hehe...

Here's the link: http://ali.as/devel/cvsmonitor/index.html

More Forza

Holy sh*t. I just discovered that one can download the car setup and the entire replay session of the top 100 players of each career race... No longer guessing how exactly the world's #1 player managed to finish the same race 2 minutes faster, you can watch every single second of it, complete with telemetry information. Awesome. I'm also proud to report that I just finished the Suzuka Circuit at the "Kumho Tire 250HP International" event at position 260 out of roughly 81.000 players who raced there so far. Not too shabby eh? :)

Forza2!

Yo gang, check out my pimped out Camaro :o) It's way overpowered and handles like a container ship, so it's totally useless for racing. But that's what a muscle car is all about, right? Need to improve my paint-job skills though...





Love the game so far... It's much, much deeper then GT4. Could have more tracks though, and the environment graphics are a bit meh for a 360 title. Oh, and definitely not enough BMW models. I'd like to see the new M3 and the Z4 Coupé please.

Tomb Raiding

Being a veteran home computer and PC gamer I was never really interested in the Tomb Raider games. But a lack of good new 360 games in April and May, the fact that I heard good things about Tomb Raider Legends and the unbeatable price tag of 20 Euro (new) seduced me to give ol' Lara a try. And I must say I'm enjoying the game quite a bit. The graphics are relatively simple but next-genish-enough (nice dynamic lighting and shadowing, although overall the game is a bit dark). The character designs differ a lot in quality. Lara is well done, but most of the other story characters ... not so much. I like the fact that Crystal Dynamics went with a clear comic style for the characters instead of going the realistic route or some mishmash style. And Lara's British accent is simply hot, thank the gods they didn't choose one of those typical American mickey mouse voices. The game feels best when climbing around in the levels, controlling Lara is very intuitive and the animations are very well done and connect to each other nicely. But where's light, there's also shadow:

• Interactive cut scenes: this Quick Timer Event crap needs to go. It's the single poorest game play mechanic in all gaming history. The point is, humanity knows this since Dragon's Lair. But those who don't learn from history are doomed to repeat it. QTE's reduce the gamer to a trained lab-monkey who needs to push a button when the red light flashes to get his next cookie. Personally I'm slightly offended by this shit. Why did we suffer through millions of years of evolution when a chimpanzee could do the exact same job??
• Some of the boss fights require heavy guesswork. At one time I even had to look for a walk-through in the intertubes because I was stuck. That's just poor. I don't want to trial-and-error my way through the game, I want to have logical clues presented how to proceed next, please. In contrast, most of the in-game puzzles are very well done and logical, but may require some serious hand-eye-coordination.

All in all, good game, but I guess it was the right decision to wait until the price comes down.

Math lib changes

While working on the new graphics and scene subsystems I eventually came to the point where some math code was needed (managing the view, world and projections transforms and their combinations, and flattening matrix hierarchies into world space). My original plan was to create a low level functional math library which looks much like HLSL and uses SSE intrinsics for performance. I started this stuff and soon it became clear that it would be quite an undertaking to correctly implement and test all this. And then there would only be an SSE implementation, when there's still SSE2..4, 3DNow around, and completely different intrinsics on the Xbox360 and other platforms. Sure, the problem could be solved by throwing manpower at it. But that's never a good idea for solving programming problems. So I looked around for a more pragmatic solution and found it in the form of the D3DX math library. The D3DX math functions are very complete, specialized for games, and support all current (and presumably future) vector instructions sets under the hood, and the 360 math library basically offers the same feature set (although it's much more down to the metal).

There are 2 disadvantages:

• additional calling overhead since D3DX functions are not inlined
• not portable to other platforms except DirectX and Xbox360
  

But I can live with this because it saves me a lot of work *now*, and porting the math library to another platform with platform-specific optimizations is just as much work with the wrapper approach then with the self-made approach.

There a few other aspects to consider:

• With C++ math code, performance shouldn't get into the way of convenience. For instance, a proper operator+() always costs some performance because a temporary object must be constructed (the return value). But it's much more convenient and readable to use C++ operator overloading in generic game code instead of using (for instance) intrinsics. The point is to pay special attention to inner loops and use lower level code there when it actually makes sense.
  
• There should only be very few places in Nebula where heavy math code is actually executed on the CPU (in Nebula2 these are: particle systems, animation code, computing shadow caster geometry for skinned characters). In Nebula3 these tasks are either offloaded to the GPU, or will be obsolete). In general, the CPU should NEVER touch geometry per-frame and per-vertex.
  

While I was rewriting the whole thing, I also did one other radical change which I wanted to do all the time, but wasn't possible in Nebula2 because a lot of existing code would be broken: default constructors no longer initialize the low level math objects. Controversial, I know. But I want to see how it turns out in practice. Math constructors tend to show up quite a lot during profiling, the more light weight they are the better.

Another basic change I wanted to do for some time was to differentiate between points and vectors. There is now a Math::point and a Math::vector class which both derive from the generic Math::float4 class. A point describes a position in 3d space and a vector describes a direction and length in 3d space, generalized to homogeneous 4d space (the w component of a point is always 1.0, the w component of a vector is always 0.0). By creating 2 different classes with the right operator overloading one can encode the computation rules for points and vectors right into the C++ code, so that the compiler throws an error when the rules are violated:

• (point + point) is illegal
• (point * scalar) is illegal
• point = point + vector
• vector = point - point
• vector = vector + vector
• vector = vector - vector
• vector = vector * scalar
• etc...
  

Also, class interfaces become much clearer because the programmer immediately knows whether an argument is expected to be a point or a vector.

So the new math lib basically looks like this:

The following low level classes directly call D3DX functions:
* matrix44 (D3DXMatrix functions)
* float4 (D3DXVec4 functions)
* quaternion (D3DXQuaternion functions)
* plane (D3DXPlane functions)

All other classes (like bbox, sphere, line, etc...) are generic and use functionality provided by the above low level classes. There is also a new scalar type (which is just a typedef'ed float), which helps in porting to some platforms (for instance, on NintendoDS, all math code is fixed point, so a scalar would be typedef'ed from one of the fixed point types). I still have to write a complete set of test and benchmark classes for the math library, but for now I'm quite happy that a very big chunk of work has been reduced to about 2 days of implementation time.