I’ve been playing around a bit with random number generators and heightmaps. My goal is at some point to procedurally generate as much of a limited landscape as possible. I haven’t done much work as I’m currently setting up the renderer at the same time too. But I did make some progress with the heightmaps.

I currently have three different algorithms that generate the heightmaps, with some additions and hybrids planned for later. The fault formation algorithm is the one I’m most pleased with so far. It creates pretty varied generations that end up looking pretty good in 3D.

The algorithm for the above results is as follows:

// Allocate a buffer for the height map.
// Iterate a pre-define number of times over this array and...
//        Generate a random line (two points) in the height map.
//        Calculate the height modifier for this iteration.
//        For all the points in the height map on ONE side of the line
//                Add the modifier value to the height.
//        (optional) Filter the height map.
// (optional) Apply a final filter pass.
// Normalize height map.

I store the heightmap as an array of floats. I don’t care much about memory at the moment though so it might be worth thinking about other formats. The height modifier is changed every fault iteration as

modifier = max – ( ( iteration * ( max – min ) ) / numIterations )

in order to gradually smooth it out. This won’t be enough though, hence the filtering. For filtering I use a simple FIR filter applied to every band of the heightmap in all four directions. For the random lines I use a Mersenne Twister implementation that has a great distribution and gives some kick-ass random numbers.

The perlin results I’m not so proud over, but that’s mainly my fault. I still need to find some proper values for the seeds. The implementation is fairly naive and at core uses a simple pseudo random number generator instead of proper lookup tables. The algorithm goes as follows:

// Allocate a buffer for the height map.
// For every element of the array...
//        For every octave...
//                Modify the frequency by a pre-defined modifier.
//                For the current (floating) point and its 3 discreet neighbors in the other quadrants...
                          Sample the 8 points around the current point and average the result.
                  Use the fractions of the coordinates of the (floating) point to bilinearly interpolate the four values.
//                Amplify the result of the interpolation by the current amplitude.
//                Accumulate the result.
//                Modify the amplitude by a pre-defined value.
//        Save the final value as the height at the current element in the heightmap.
// Normalize height map.

When “sampling” the 8 points the algorithm actually generates 8 pseudo random numbers with the given coordinates. Since the coordinates are effectively the seed, the result will always be the same and we don’t need to store lookup tables. The interpolation is a bilinear cosine interpolation. I tested linear and cubic too but in the end stuck with cosine. I don’t believe I have a reason for that though.

The plasma algorithm is a vanilla midpoint displacement implementation. I’m not going to bother writing it down since I’m not doing anything special, other than applying some heavy filtering to smoothen out the results.

At the moment the results are OK but I’m not terribly impressed. The generated meshes look tame and I’d like to expand them a bit more. Perhaps blend between different heightmaps or otherwise use some sort of heuristics to mix different types. I can imagine a low octave perlin map could be used to blend between other heightmaps to create cliffs and the like. More on this later…

How do I overload macros you ask? Well, you can’t! But that would be a short post so I’ll show something else you can do.

Imagine working with a code base that uses a function call for a specific purpose, for instance AllocateMemory( Heap h, int size ) is used to do all your allocations. One day, you decide that you want to do some memory tracking and would like to print out where all the allocations happen from. Since you don’t want to change how this function is called in your entire code base, you go ahead and modify the actual function to do something like this:

void* AllocateMemory( Heap h, int size ) {
#if defined( MEMORY_TRACKING )
    printf( "%s:%d: Alloc %d bytes on heap %d", __FILE__, __LINE__, size, h );
#endif

    // do normal alloc here
}

This would work just fine and it would require only a quick modification to one function and a define to be set in order to get this primitive memory tracking working. Only it wouldn’t give you much useful information since __FILE__ and __LINE__ will always give you the same values. When these two tokens are replaced by the preprocessor, it will aways be in the AllocateMemory function, probably somewhere in a memory manager class. It won’t tell you where the allocation comes from. Ideally what you’d want is for the preprocessor to replace the call to AllocateMemory with a call that contains the __FILE__ and __LINE__ variables as arguments. You don’t want to change every instance of AllocateMemory in the entire code, so you decide to use macros.

#if defined( MEMORY_TRACKING )
void* _AllocateMemory( Heap h, int size, const char* file, int line );

#define AllocateMemory( h, size ) \
    _AllocateMemory( h, size, __FILE__, __LINE__ );

#else
void* AllocateMemory( Heap h, int size );
#endif

There you go. When the tracking define is used, rename the core function and give it its new signature which includes the file name and the line number. Define a macro with the function’s original name which catches the calls and forwards them to the function, appending the preprocessor variables as arguments. Since the macro will be expanded in place, __FILE__ and __LINE__ will correctly contain the filename and line number of the AllocateMemory() call.

Now to the actual point. What if the original AllocateMemory function was overloaded? What if in addition to the version above there’s a second version with the signature AllocateMemory( int alignment, int size )? This would obviously work when calling the two functions but replacing them with a macro will cause compile errors since macros can’t be overloaded. Turns out there’s an easy way around this.

#if defined( MEMORY_TRACKING )
void* _AllocateMemory( Heap h, int size, const char* file, int line );
void* _AllocateMemory( int alignment, int size, const char* file, int line );

#define AllocateMemory( ... ) \
    _AllocateMemory( __VA_ARGS__, __FILE__, __LINE__ );

#else
void* AllocateMemory( Heap h, int size );
void* AllocateMemory( int alignment, int size );
#endif

Above we replaced the tracking macro with a variadic one. This uses the ellipsis to indicate that the macro can receive zero or more arguments as input. The __VA_ARGS__ variable expands to the sequence of symbols that were passed in between the parentheses of the above macro. Since these arguments get inserted just like you’d have typed them, the _AllocateMemory() function can have any signature and it would compile correctly.

Not really overloaded macros, but it gets things done. The example in this post was off the top of my head. For a memory tracking system it’s worth it to spend the time and write some solid code. You won’t regret it when the leaks and corruptions start showing up.

We’ve finally released some actual gameplay videos of Brink. It’s been great to see how much people liked them so I thought I’d put them up here too.

I just remembered I never put up the Airborn teaser here. So here goes… The great soundtrack is made by the awesome Ian Dorsch.

Seems like I’ve had some database issues the last couple of days but luckily it wasn’t anything bad and I could quickly fix it. Site is back up and I thought I’d celebrate by posting a semi useful post.

I’m not much for reading assembly but sometimes it’s fun to do it, mostly because I like to learn new things. Studying the assembly that’s output by your compiler is usually a good idea in order to get a better grasp of what’s happening with your perfectly written code after you press the compile button.

While I usually tend to debug in Visual Studio and switch to Disassembly mode whenever I feel the urge to go wild, you can do it outside of the main editor if you so choose. In fact, sometimes it’s more handy to study small pieces of code outside of the debugger.

I just read a post by Jim Tilander that inspired me to write a small batch file to aid me in this process and I thought of sharing that here. Perhaps someone will be able to get any use out of it.

You need to change the two variables at the top. The first one should point to a text editor of choice and the second one should point to the Visual Studio vcvarsall.bat file. It should be found some place looking like this “C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat” for VS2008 and most likely something very similar for other VS versions. Oh, I should probably mention that this will only work with Visual Studio. However, there are instructions for doing the same thing with GCC at Tilander’s blog linked to above.

Paste the above code in a bat file and call it something nice since the file name will be the command you have to use, e.g. “code.bat” and put it somewhere on your system path. To use it, launch a new command line window and type first

to setup up all the paths. Afterwards, you can use the following commands in that window:

to open myfile.asm in your editor for viewing,

to compile myfile.cpp file into assembly or

to compile myfile.cpp and open the resulting asm file in your specified editor all in one go.

The resulting .asm file will be placed in the directory where you currently are when you type in the commands. You should also have a look at the compile commands and tweak those to your liking.

See the previous ones here…

So with MSUC phase 4 starting, we had to make our first submit to the competition. It’ll be interesting to see what happens since I have a feeling we are way behind most entries when it comes to playable content. But nevertheless, it was a fun experience. And hopefully it will continue to be one. While you wait for a playable version of the mod, look at this:

This has taken me way too long but I finally managed to post it. Lately I’ve made a habit out of reading various interesting blogs. Most of them are from incredibly talented developers from the games industry. If you’re remotely interested in game or graphics programming there’s a high chance you already have these links bookmarked.

If I’ve made any mistakes or you have any other blog recommendations please let me know. Here goes…

• .mischief.mayhem.soap.
• Atom
• Aurora
• Beautiful Pixels
• Blackpawn
• bv2
• C0DE517E
• Code Fortress
• codersnotes
• Diary of a Graphics Programmer
• Diary of an x264 Developer
• EnterTheSingularity
• fixored?
• good coders code, great reuse
• Game Angst
• Game Rendering
• Graphic Rants
• Graphics Size Coding
• Gustavo Duarte
• Humus
• level of detail
• Lost in the Triangles
• Malte Clasen
• Meandering Thoughts of an Addicted Games Programmer
• meshula
• Pete Shirley
• Real-Time Rendering
• Real-Time Collision Detection
• RenderWonk
• repilogue
• Sander van Rossen
• Some Assembly Required
• Stumbling Toward Awesomeness
• Sutter’s Mill
• Swedish Coding
• The Daily DIP Count
• TomF’s Tech Blog
• What Makes You Think I’m Not
• What your mother never told you about graphics development

With QuakeCon and Gamescom showing public demos of Brink we’ve released a few more screenshots for everyone to see. I’m really happy with what we got. Our art team has managed to create a really unique look and it all fits perfectly together. I’m looking forward to see how people react when we release game play videos. I really doubt anyone will be disappointed.

For now, here are some screens. More info can be found on brinkthegame.com.

It’s been a while since I had the time (and material) to post anything here. Work on BRINK is nice and cool now after E3. We’re all busy making the game more awesome everyday, but not too busy. I’ve had a great holiday week on Tenerife and now I’m back and fully refreshed.

I’ve done some work on my small 2D engine I’m work on from time to time. It’s starting to shape up now with a fairly scalable data definition language and a parser that loads content into the engine. It’s really easy to define object properties and such now. I’m hoping I can expand this into a system where I can script large parts of a game, but we’ll see how it turns out when we get there.

As there’s not much point in writing an engine without a game, I’m trying to write some game related code while working on this project. Unfortunately it doesn’t feel like I’m progressing much but that’s mostly because I have to do a lot of architecture coding right now. The project is still pretty young so I can’t write much game specific code. I might be able to get some player/enemy interaction in now since I have the entity and object manager up and running, but we’ll see. I’ll try to post a video soon just so I can can keep track of how the project evolves.