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 I’m fairly busy last few months game development has almost frozen. So to heat things up I will
make a simple post regarding the file format we use in our games and engine.

We had the following demands:

• Easy to read for a human
• Easy to read for a computer
• Easy to extend
• Nesting

So with this in mind we looked at some existing file formats:

• Ini: Easy to read for a computer and a human, but no nesting support.
• XML: Easy to read for a computer, but not for a human.
• Binary: Very easy to read for a computer, not for a human.

So we cam up with our own format: Data Files.
It’s basically a combination of an ini file with the nesting of XML defined as follows:

{Node1
    Key=Value
    {Node2
        Key=Value1
        Key=@(path)Value2
    }
}

We have nodes. Nodes can contain new nodes and key-value pairs. Key-value pairs don’t have a
primary key and can only be one liner. Basic design that’s pretty good readable for a human and a computer!
We also have a special variable defined. The “@(…)”. This defines that there’s a value that contains
a variable value. For example the “@(path)” contains the path the file is located in.
This is very useful for fetching a file in the same directory: Texture=@(path)MyTexture.jpg.

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).

Stripes flow in Genetica

After a few chats with Jens we decided to migrate from Photoshop to Paint.net for 2D art. Why? Paint.net is not so f*cking complicated and expensive as Photoshop.

Also a new thing that we are doing is learning how to make textures using Genetica. We won the basic version in the previous compo, and now we trying to figure out how it works. I must say it’s simply brilliant! Just with a few random mouse-clicks and we managed to create a pretty neat looking seamless texture that we can directly use in our games!

We still have the most basic version of the program but it proves to be very powerful and not so time consuming as Photoshop. Also an other thing is that textures are generated by combining noise, color and other kind of thingies. This makes that if we want to change for example a pattern that we simply change the pattern “building block” to fit our new needs. The texture is automatically updated and seamless!

Seamless texture created with Genetica, copyright 2010 NecroSOFT

The basic version does not have support for normal maps, but we can use (or make) an Paint.net plugin that suit our needs.

Also texture synthesis is available. We didn’t check that one out, but you can make a seamless texture from any photo or image. Can be very powerful also for game designers like us .

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

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!