Benchmark tool
by z0r on Jul.05, 2010, under Development blog, Hell Tech
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.
Procedural city (part 3)
by z0r on May.17, 2010, under Development blog, Hell Tech
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.
Procedural city (part 2)
by z0r on May.13, 2010, under Uncategorized
As seen in part 1 we are building a procedural city. So far we have the generation of the street network in place. Now we where working on the generation of blocks, the places we can but building or parks or whatever on. It’s basically an open space between the streets.
Here as a screen shot of everything in “action”.
Next step: buildings!
Procedural city (part 1)
by z0r on May.11, 2010, under Development blog, Hell Tech
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).
Tool migration
by z0r on Apr.18, 2010, under Development blog
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!
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
.
Busy!
by z0r on Apr.08, 2010, under Development blog, Hell Tech
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.
Terrain screenshot
by z0r on Mar.06, 2010, under Development blog, Hell Tech
GeoMipMapped 5x5km terrain without lights. Shows still some cracks, but the result is pretty good for now.
3D vision
by z0r on Mar.05, 2010, under Cool stuff!, Hell Tech
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.
Terrain
by z0r on Mar.02, 2010, under Development blog, Hell Tech
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!
New engine!?
by z0r on Feb.03, 2010, under Development blog, Hell Tech
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!











