While still progress is slow I try to tell you guys something about the editor user interface. Decisions where to make the editor in-game for easy access in full screen mode. So far it’s doing it’s job very well. I reworked the editor’s graphical user interface images to some eye-candy that looks pretty good for now.

Currently the editor and UI are able to create, delete and switch scenes, display images, browse through files, transform the camera, and see some logging, browsing and place actors (moving and selecting needs to be implemented at some time). Basically the basics. I try to keep the editor to a minimum as possible and use notepad, paint and other tools to create the game. But eventually you always need some in-game-tweaking. And that’s where our nice user interface comes in handy!!

As we are curious of engine and game performance beyond the “bad” frames-per-second measurement, I started to integrate a benchmark “tool” into the engine. This “tool” only registers the start and the end of a specified function block with a small useful information description.

With a separate benchmark viewer we can analyze the engine performance per function per thread and it shows the actions on a nice time line. What we see are blocks, aligned in time per thread. A large block means something took a shitload of time, a small block means mostly a few milliseconds. Also the engine schedules some update, physics and render, content loading calls on different threads, we now can see what actually happens inside. This also gives us more power for better optimizations and debug capabilities.

As we are busy with a procedural-city-generator that we could use in future games, I created a small simple test building (prefab) to test the building-placement-code. This code is still pretty simple and only puts some buildings on a straight line along each street with a small offset. furthermore we added a sidewalk strip next to each street to give it a better look.

Here are the images created so far. Apart for some bugs it looks pretty neat.

Problem area: we want to have a city. A BIG city. I don’t have the skill or time to build a BIG city in a 3D modeling program. So what to do? Create one from code!

Why do we want to have a city?… Well probably we gonna create a race game (again) through a urban-shaped environment . How or what we don’t know yet, but we now ave another idea for yet another game…again…

Where to we start? First the streets. If we have streets, we have building blocks. On building blocks we can put building or other things like a park. Sounds easy huh.

So far I created a small test-app that defines 5 lines. Those lines are extruded and connected in a way so the look like streets. So here’s a small image of what I made so far. Red is left side of the street, blue right side (debugging purpose only…)

Left: the app as-is
Right: triangulation (draw by hand).

The triangulation in 3D space  is also in place (not shown in the picture) and apart from a crappy test-texture it does it’s job very well!

Next step is to determine (detect) the two triangles in the middle. This would be the building blocks that hold some information like big building, sky scraper or park (and maybe water and other stuff).

Long time no update doesn’t mean we stalled work. We just don’t made any “visual progress”. yet. What kept us busy then?

Well here’s a short list:

• Multi-threading
  • physics and update functions are run simultaneously.
  • (Still thinking on running update/physics simultaneously with the rendering).
• Physics
  • (modified version of JigLibX for the ones who are curious).
• Hierarchical model definition (we just call it model-files)
  • This means we have a file that defines how a 3D model looks like and behaves.
• Particle engine
  • It works and can be defined in the model-file.

Next phase is “The Game”… what game? Well… we speculated a lot at this point but we don’t want to reveal anything at this time. It could be that we suddenly change our perspective to make something completely different.

GeoMipMapped 5x5km terrain without lights. Shows still some cracks, but the result is pretty good for now.

Terrain wireframe and solid

You hear more and more about 3D in movies and games. So after I saw James Cameron Avatar a second time (and still was impressed) I was wondering how it could be implement it in our 3D engine. The only solution I could came up with it using a red/cyan glass and use the Z-buffer to offset some colors – that’s the cheap solution – and also used in Trackmania Nations.

So after browsing “The Internets” I figured my GeForce 8800GTS has the ability enable NVidia’s 3D Vision. I don’t have a shutter or polarized glass, but I have a red/cyan glass (which also works) so I gave it a try. I tried it on several games and I concluded that not every game is ready for this. For example in FUR it’s just totally crap and the in-car view is horrible because you see it twice! But I also tried some other race games like Clutch (Armageddon Riders – Google/Bing for this and you know what I mean) where the effect is basically perfect!

With this game it really got me started to see the use of 3D Vision in games. Everything just flying off before your head. When I smashed into something you almost need to dive from your chair so you don’t get hit by flying debris! And this all should only be better if you *buy* the NVidia’s 3D Vision glasses together with a 22″ 120Hz monitor!

So how does it work? Well, it due to the frame drops I experienced, I guess the world is rendered twice. Once for the left eye and once for the right eye. But I’m not sure because I didn’t dive into it yet…

After all the conclusion for this 3D experience is that we will make our engine ready for supporting 3D vision.

While we are still busy with our next game and engine, I started on terrain rendering.

For now the terrain is brute force rendered, creating a new vertex buffer every frame with no optimizations what so ever. The terrain is infinite, but for now I can only look 200 meters ahead to keep the frame rate up…

Next step is to apply some optimizations so the view distance is 5km+. The technique is still something to dive into and do some experiments.

As for now also we have a basic vegetation engine in place that can place objects (currently a car model from FUR) on the terrain. For now the “cars” are also rendered brute force with frustum culling, we are planning on making some impostor-based approach. Simply said, objects far away, say 100 meters, will be rendered as simple sprites. This reduces render time and thus can we display more tree’s on screen.

Screenshots come soon… stay tuned!

What!? Again!! YES! We started porting the “old” engine from Delphi to C#. The reason is that we’re porting the engine is to cut down development time. Also with the whole .NET framework and CLR less work is needed to achieve more. The architecture of the engine remains basically the same.  Apart from some changes at least I’m quiet happy with the design.

Why .NET and not C++ or brainfuck? Well… C++ would take a lot more development time for me as we are more experienced in C# that C++. Speed is not really an issue with simple games as you have a shit load of processing power under your fingertips. And it that’s not enough, you still have the GPU!

Also an other thing that pulled me over the line is Mono. With mono you can run .NET CLR applications (written in C#, managed C++, VB.NET, etc) cross platform. The supported that took my interest are Sony PS3 and the Nintendo Wii. Also I tested it on Suse 11.2 (Linux) with a demo application and it runs with without a problem. The only thing we need to do is keep the engine mono-compatible.

For Windows I want to use the .NET framework and DirectX 9 and 11 (soon). For the other platforms I need to make a new renderer in OpenTK or something similair. Also I need to switch to a mono-compatible physics engine. I’m thinking on BulletX (Bullet for C#) as it’s open source.

The current status of the engine is that I setup DirectX 9 and can render models and a simple GUI all with shader model 3.0 which is also the minimum I want to use. Also I modified the material system to be more easy to use and has less overhead. Further more the editor will be less advanced and used for basic operations like adding and moving objects on the screen. Also the editor is now in-game so we have only 1 executable. (apart from 32 bit and 64 bit).

Stay tuned as more updates will follow!

Today we where working on tire smoke. Here is a movie that shows the smoke as we have it implemented. The thick smoke was just for fun. Enjoy!