Hi there,

Another week of hard work is gone since my last update. Focus here is still 100% on graphics improvements. The brand new 3D engine is almost finished in its features. In particular, the multitexture FFP (Fixed Function Pipeline) half of it is basically terminated. I am now concentrating on the programmable shader part, and I've got to tell you: it is an exciting revelation! I'll be back on the shader thing in a while.

DRACULA EVOLUTION

The biggest change in the 3D engine is in its "lower" level of abstraction and closer resemblance to DirectX organization. Dracula, the code name I gave to this 3D engine 4 years ago started its life as an OpenGL 3D class library. I begun coding Dracula while I was still in Italy waiting for my transfer to the UK. It was a major rewrite of another 3D I've been using for years. The main feature of Dracula was support for animations. At that time, I was planning to create an engine capable of handling a RPG similar to Ultima X and based in Japan. Character animation was my first priority then. I kept working to Dracula for some months in Italy, then, once in UK, I refined it and started using it in an open source tennis simulator called ATP3 (atp3.sourceforge.net).
Here's a funny video of ATP3 in which I am kicking Anna Kournikova's ass. (I wish ;-) )

ATP3 hmm.. why that "3" you could ask. Well it was actually my 3rd go at a tennis game. The first 2 were 2D with amazing ( :-D it really was) AI that even made AI vs AI matches interesting to watch. ATP3 was to take the same approach and translate it into a full 3D scenario.
As you might imagine ATP3 was never finished because I started being sucked into netKar development. For netKar, I begun using the very same Dracula engine used for ATP3. 2 or 3 months before netKar's first public release I decided to move the entire engine to DirectX. The decision at that time was, ironically, justified by what I am doing now: supporting advanced shading. The movement was a real pain, OpenGL version of Dracula was based on the idea of "display lists", a very easy way to obtain very quick static geometry rendering in OpenGL. Display Lists are heavily dependent on the video card's OpenGL driver. nVidia always had a fantastic driver and to match display list's performance using DirectX was a real challenge. DirectX asks much more to the developer, and Dracula was filled with "hacks" everywhere to hide DirectX complexity behind a class structure I was familiar with.

Now, for the first time in 4 year I've accepted the idea of redesigning the engine's part that neeed more attention to strictly match DirectX's structure. It took a lot of code to be rewritten and re-thought, but I think the advantages will be evident pretty soon, when Outrunner will be able to use all the parameters accesible by the editor.
As you can see from this screenshot:

The window called "Edit Texture Stage" is used to set all those parameters for single texture pass. They're mapping 1:1 the equivalent DirectX calls. Old nK's 3D engine had to "guess" those parameters from the context, not an easy task and not a very flexible approach. Now I will only have to sit down and wait to see what Outrunner will be able to come up with using this editor.

SHADOWS

For static shadow I fell back to the standard "Quake" approach, that is: lightmaps. They look better than anything else, "only" require an additional texture pass with the disadvantage of eating up some video memory. But we're doing it properly, and, of course, the user will be able to switch the shadows off if not needed.
Doom3 just came out and users will be expecting to see realistic shadows everywhere now. For a racing game, Doom's approach to shadows just won't work. Tracks have a big part of their content based on alpha tested texture, as for trees, poles and so on. Doom's shadows won't support alpha testing and they need a close silouette to cast shadow from.
I am starting some experiment with directional shadow mapping, that is a slightly different beast from Doom's shadow, much easier to understand and they have the big advantage of being fully real time. The catch me is that they are a bit tricky to implement for large areas like racing tracks. I think I will stick with lightmaps for nKpro V1.0 and implement this solution in the following versions.

SHADERS
This is a serious revolution. It is difficult to understand the potential of these new generation video cards until you actually play and experiment with it. The differences are also slightly less evident than a difference between a good 3D model and a crap 3D model. That is to say, shaders won't save a bad 3D model, but will only make a great 3D model look better. What difference am I talking here? Well, I've prepared a nice present for you today:
In this video:

You can see a comparison between the "standard" lighting function in DirectX and a shader for per-pixel lighting. In the middle of the video I will switch to per-pixel shader for the car's body. Judge yourself the difference: the specular part (the bright highlight on the car paint) in the shader version is amazing, the car's curved surface appears incredibily soft and it is much easier to understand the shape of the body. I think this example is more explicit than a million words, and this is JUST one of the most basic shaders to experiment with, there are possibility to generate things like fabrics, grass, velvet and, of course, bump mapped road surfaces and better environment mapping.
I really look forward to 3D graphics in the next couple of years when we will be able to move into a full 3D "shaders" world with the new 3D cards on the market.

ciao for now.. see you next week!

stefano