In the 3 months before Christmas, we assembled a small tiger team of 4 programmers to port a prototype demo we created with the N2-based Drakensang engine on the PC over to the 360 running on top of N3. We had the demo up and running in 720p rendering resolution with 4xMSAA at 30+ fps right before Christmas, exactly as planned. The primary goal was to have something nice to show to publishers running on the 360, but we also wanted to bring our technology a few steps forward. We could have opted for doing a quick’n’dirty port: just use the existing N2-based source code, and make it run on the 360. This would have solved the primary task - have something to show on the 360 - but underneath the hood the demo would still run on an “old” PC engine, hacked to run on the 360. We wouldn’t have benefited on a technological level from this. Instead we decided to start a real “engineering project”, and re-build the demo from scratch on top of N3, only reusing the existing art assets.

In hindsight, this was exactly the right decision. Nebula3 was developed with the 360 in mind from day one and the multithreaded rendering pipeline was already up and running on the 360. To my slight surprise we had very good performance right from the start. Due to the relatively complex pixel shaders and postprocessing effects in the PC demo I was expecting to see a framerate of somewhere between 15 and 25 frames, and then optimize from that point on. Instead we were very well north of 30 frames through the whole project with a 1280x720 render resolution and 4xMSAA. For a 3 year old graphics chip, this is remarkable. The prototype is very light on the game logic side so the main thread is basically idling on the frame synchronization point all the time. The rendering is fully limited by the GPU’s fill-rate, and we have a nice chunk of CPU time free on the render-thread side. We basically have a perfect graphical benchmark now to play around with and get a feeling for what the 360 can do, with most of the CPU still free for game logic, physics and dynamic rendering effects.

There’s still a lot of opportunity to fine-tune the CPU/GPU interaction in the render thread, but with the rendering performance out of the way this early we could concentrate on adding missing features to N3, like the new animation, character rendering and particle subsystems. We had the luxury to do a complete and clean rewrite for those, and I’m quite happy how they turned out (well, except for some parts of the particle system where we had to be bug-compatible with N2 to make the rendering result look identical using the existing source parameters). We have SQLite running on the 360 using the in-memory-database feature now, which we will probably back-port to our PC projects as well since it’s generally a nice-to-have feature. zlib, TinyXML and Lua had already been brought over before.

Finally, we now have a completely identical new PC-version of the prototype as a “side effect”. Our entire build-pipeline is now multiplatform-capable, a specific target platform is selected by a simple command line switch when running the MSBuild script. This is very nice even for a pure 360-project. Game logic code and even most of the engine code is platform-agnostic and can be implemented and tested on the PC, without the programmer hogging one of the ever-precious devkits. Switching to the 360-build for testing, debugging and optimization work is just a matter of seconds.

The next (and I think - final) big thing for N3 is a proper asynchronous resource streaming system specifically optimized for console platforms. N3 already has the concept of loading resources asynchronously through the managed resource system, but that is only one fairly low-level building block. What’s missing is a resource streaming system which basically acts as a fixed-size memory cache between the graphics chip and the disc.

The main disadvantage of consoles (compared to the PC) is the slow data rate and poor seek times of DVD and Bluray. But the good thing on consoles is, that the resource setup process has been opened up to the programmer. On the PC, DirectX and OpenGL are both very black-boxy when it comes to resource handling. The programmer never really knows what happens inside the API and graphics driver when a new texture is created or prepared for rendering. This black box is unlocked and documented on pretty much all consoles platforms, so that it makes very much sense to write platform specific resource streaming systems.

All in all I’m now very confident that N3 can handle a real-world project on the PC and/or 360. We have a very good feeling for what the 360 can and can’t do, the 360 is now integrated into our build pipeline, and N3 itself is pretty much feature-complete from our point of view.

I’d really love to put up a screenshot of our prototype since it looks pretty sweet on the 360. But it’s currently under cover and for publisher’s eyes only, so unfortunately I can’t.

I’ll try to get a new N3 SDK out soon (of course without the 360 stuff, as usual).

Oh, and The MAW is awesome. Definitely give it a try!