• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

TODO: New journal tagline

Entries in this blog

Remember The Milk. Task list tool I've discovered relatively recently. Integrates beautifully with iGoogle and Gmail and a few other things that I don't use.

Also realizing how much I've missed C++, having spent so much time in C# in work and college.

Pretty short update this. I plan on going through the various abstraction layers I've had to make to be able to test the engine. Abstracting away the system dependencies from the exposed interfaces. Work is slower than it might otherwise be at this stage, but I'm expecting the clean interfaces to pay off.
Decided that since I was setting this up for my project anyway I'd grab a few screenshots and walk through the process of setting up testing of native code with Visual Studios testing framework.

The working name of the game is Project Baltar. So, the solution I created has that name, and I had no choice but to name the engine Gaius. No choice at all [smile]. The engine itself is a static library. And I inserted the following code to be tested:

So now that I have this native code that I want to test, I create a test project, which in the New Project dialog is under Visual C++ -> Test -> Test Project. I called it GaiusTest. The key thing to note is that you need to set the /clr flag, as opposed to /clr:safe to allow the native interop.

To the default test class that was created by the wizard, UnitTest1.cpp I added the include
#include "../Gaius/example.h"
and inserted the test code you see in the following shot. In order to make this compile I added Gaius as a dependency for GaiusTest by right clicking on GaiusTest in the Solution Browser pane and selecting Project Dependencies.

Finally to run the test, I selected Test->Windows->Test List Editor. There was only the one test on the list, so I ticked the box beside it, and hit the Run Checked Tests button at the top left of the test list editor window. And this is the final result:
Long time since I've posted. The short version of things is I'm still in college, soon to be finished, and want to do something about getting a job in games when that happens.

To that end I'm starting making a game. The design is firming up, beating it out at the moment. Technology wise DX9,C++,Boost,FMOD are some of my choices so far, but that's not particularly interesting.

What's interesting, and what I want to write about here, is my decision to try do this via Test Driven Development. This summer I've been working in Microsoft, and I've been made develop using this TDD method, which I'd never heard of before. Initially I thought it was just unit testing, going under some new buzzword. But it's not at all. It's so much more than that.

A brief summary of the TDD process:

  1. Write a new test.

  2. Run tests and confirm that the new test fails.

  3. Write *ONLY JUST ENOUGH* code to make the test pass.

  4. Run tests and confirm that all tests pass.

  5. Refactor/clean code.

  6. Rerun tests and confirm that they all pass.

To give a bit of an example lets say I needed to develop an Object oriented encapsulation for integers. My first test might be:
void CanCreateNumberWithValue()
NumberClass n(1);

I run this test, and it fails, it doesn't compile, so first let's make it compile so we can ensure the test fails.

class NumberClass {
NumberClass(int n) { }
int GetInt() { return 0; }

Running the tests, it is clear that this will fail. To only just get the test to pass, let's do the following:

class NumberClass {
NumberClass(int n) { }
int GetInt() { return 1; }

And now running the tests this passes. Only enough code has been added to pass the test. This is a very important thing. There is no code that there hasn't been a test written for. Because the tests are a complete description of the features of the program, the tests will ensure that any and all implicit contracts are preserved. While this is a trivial example, I have found that rigorously doing this has caught bugs before they happen.

So now we add a second test, for another value.

void CanCreateNumberWithValue2()
NumberClass n(2);

Obviously, running the tests will result in a pass for test 1, and a fail for test 2. So now we want to make the code pass test 1 and test 2. So now we change the class to this:

class NumberClass {
int value;
NumberClass(int n) { value = n; }
int GetInt() { return value; }

And now test 2 passes as well, and test 1 will still be passing. It's worth noting that before we added test 2, the class was fully compliant with the specifications for what the class should do, with that set of tests.

You might think you'll end up wasting a lot of time with this. But what I found was that I ended up spending so little time agonising over class design decisions. Bugs became incredibly rare. I was much happier with the rate at which final code was being produced.

TDD is an amazing design methodology, with testing built right into it. The thing I had to realise, and it came out of my thinking about whether I should be testing private methods, is that in step 1 of the process you aren't writing a unit test. You're instead specifying a new feature for the program/library. Whether you need to implement that in terms of other existing functions which can lead to refactoring common functionality to private members, or whether it's all new functionality that requires new classes it doesn't matter.

One side-effect of this is, for me anyway, is that my encapsulation is much better. My classes are better designed. Clean interfaces are defined.

And it is this last point that is concerning me at the moment. There are things that can't be tested properly, like creating a window and setting a resolution and a pixel format. Or rendering a model to the screen. These sort of things you can't test like this. Instead you need to abstract away from them. For an example of this I might have a GraphicsKernel class that I'm testing these functionalities with. But to be able to test them, GraphicsKernel has to take an interface to a low level implementation. And the testing methods need to be able to instantiate the GraphicsKernel using a replacement test object, which implements the interface, without the system dependancies.

I think the effort of creating these abstractions should be worth the reward of having a comprehensive

Feeback Request: If this is any interest to people I can write up the process of getting native C++ code tested using the Visual Studio testing framework. Getting it working with managed code is pretty trivial.

(Accidentally posted this in General Programming and not my journal :P)
... I'm not sure if this whole marching cubes thing is the best way to go about things. I want a situation where the players avatar is standing on a 'platform', and can pull a piece of ground in front up them up to form a protective shield. Or raise the ground they are standing on to be able to jump to a higher ledge, or lower the ground etc... And while marching squares can easily generate the outline of these regions, considering the fact that I want to add sides to these regions, sides that aren't of uniform depth, there might be nicer ways to do this. Especially considering how much geometry would have to be sent to the card.

At the moment I'm thinking of a traditional height map stored in a texture, using the vertex shader to displace the mesh vertices and calculate normals. Combine this with some clever texturing and it might result in rather nice looking stuff. No idea how expensive it is to send a new texture to the card every frame though. Experiments will show how good an idea this is.

The thing about this is how I represent it logically. Probably in much the same way. How I manipulate it should be interesting...

As an aside, writing all this stuff down really helps you find the holes in things. At the beginning of writing this post I had planned on writing about a VERY different idea, but it turned out to be just silly.

I would really hope to have more screens soon. And a name. It's not a game if it doesn't have a name. [smile]
So, I have had this idea bumming about for a while. Mostly involving using some of the really nice fluid simulation stuff here, especially the super-viscous fluids stuff to make some nice deformable terrain. And the game as of now should be some kind of platformer, so I think for the sake of making things easy I'm going to tie everything down to a 2d plane.

Before I start messing with navier-stokes and other brain melters, I want to get the rendering out of the way. Enter marching cubes, but since this is going to be tied to a plane, reduce it down to marching squares.

This is the first time I've done anything involving dynamic vertex buffers. So I'm not really sure how I should be courting them. Right now I'm generating the vertex data in an array in RAM and then memcpying it to the locked vertex buffer. Its working grand atm, but I want to look into if it's better to keep the buffer locked for a longer period of time and not have that memcpy. Or hell, if I'm doing dynamic vertex buffers just plain wrong as well.

Well this is what I have so far:

That's from a hardcoded grid of values that is marching-squared, and new geometry generated, every frame. I'll be adding sides to the regions defined by the algorithm, which is trivial enough. It'll be a while before I get things looking the way I want, and after that I can get down to making it fast [smile]

GA fun

Very long time without a post. In college now, doing computer science. Coming to the end of the second year of the course. Fun, fun, fun. But what I really want to talk about is my end of year project that me and a few guys got permission to do and are currently working away on. I'm really excited about this, it's working out much better than I'd hoped.

The project abstract is "To determine the applicabilty of genetic algorithms to the solving of real world phyisical problems". We reduced the problem by choosing to create support latices for structures under complex sets of forces, and then further reduced it for demonstration purposes by creating support latices for bridges, to show some real world application.

So, I think this is really cool. We're currently working away on the systems required to allow us to experiment with the genetic algorithms themselves. Myself I've been developing a distributed network system for processing a scenario. Others have been working on the GUI / Editor and the physics simulator.

We're using XNA in WinForms for presentation, mostly because of the handiness of the content pipeline. The physics is being handled by the Farseer library, though that's requiring some tertiary research into materials to solve problems relating to correct coefficients for materials' properties. And my section, the evolver, is just stright C#. It takes an initial scenario, a specified genetic algorithm script and sorts out all the processing, returning the most successful structure back to the GUI to be presented.

There are a few things I've discovered in the .NET framework that have made everything so much more pleasurable. The XmlSerializer has made developing and implementing a network protocol trivial. The reflection capabilities make deserializing polymorphically a non-issue. I can later swap this out with binary serialization to reduce network traffic, or implement my own formatting without having to change anything in the code that uses the protocol.

The GAs themselves are written as C# script files. Again, I was very pleasantly surprised by how easy it is to compile code stored in memory and load the resulting assemblies, with full error reporting.

I'm not sure how successful we are going to be in creating a GA to solve this problem. The fitness function for how a structure performs is going to be extremely tricky. But no matter I can't wait to dive into that section of the project.

The GUI is coming along nicely, hopefully I'll have screenshots soon, and I very much hope updates on how developing fitness functions are coming. Yes, definitely screenshots soon.

I have the tris being filled. I had a big problem with the edge calculation code that took me a while to figure out. I was using the bresenham line algo that I was using before to work out the edges of the tri. But it would locate more than one edge on each side of the tri on each scanline for lines of certain slopes. It took me a while to figure out what was going on there. Once I figured out that was the problem I wrote up a similar algo to the bresenham that would only ever have one pixel on each scanline and the system worked propperly.

I'm only rendering 2 of the faces of the cube there because, despite how it looks there isn't actually any sorting being done yet and if all 6 faces were being rendered it would just look like a crazy jumble of 4 sided polygons stacked on top of each other.

So my next job should be fairly simple, though from experience those words are the prelude to pain. Sorting the tris. Then I'll have a filled sorted box. After that I'm going to get color gradients working, so I can have per-vertex lighting.

And now I have triangles. Yay! This was very simply added, just an extension of the line drawing I had before, with a bit of processing stuff thrown on top. The real job now is filling the tris. I simply have never come across the algorithms for it, so I get to do some research now. I could probably work it out, but I want to do it somewhat correctly.

You can see from the picture that the tris aren't even being sorted yet. That is going to be the most important job to get done when I have them being filled. Actually, it might be an even higher priority than filling them, but I'll get the filing done first. It sounds like more fun [smile]


Its been a long time since I've posted anything in this journal. Hadn't coded anything for ages for various reasons, but I've just started up a new project that I'm looking forward to. Its more of an educational exercise. I'm writing a software rasterizer. Just to get to grips with the real maths, theory and other misc topics behind 3d gfx.

The first screeny:

I was having trouble finding a source explaining the perspective transform matrix for the last few days so I just decided to work it out using old fashioned pen and paper today in school. It was surprisingly easy and the matrix I got worked without needing adjustment. I'm ever so slightly chuffed [smile]

That is just a box composed of lines that I have rotating and moving around. Next job is to get it rendering the same box using wireframe tris, then I'll get onto filling them and sorting them.

I am Hung Over

And this is one of the few sites I visit with a black background, therefore you get to enjoy my pain. There is a story beind this hang over - one which every guy has probably gone through many times. It started with a girl and ended with a bar - the rest you can figure out for yourselves.

Primarilly I'm looking for replies along the lines of "been there, done that, have the t-shirt".
Nanodude has been finished off and put up on the GDS here. We aren't overjoyed about how it turned out, so we just tidied it up and decided to upload it on the GDS. We aren't even giving it a propper DeliberateGames release.

In the end we learned the following lesson, which we should have learned from both Maul Ball and Jailbreak - no matter how fun the initial versions of the game are you need a design doc or else the gods of gaming will shit down your neck.

So we made a checklist of things that absolutely must be done before work starts on the next game - things we have till now either just avoided, talked around, or hoped it would all sort itself out through "tweaking". Do your tweaking in the design doc.

I'm not going to give too much away yet, because we still have to work our way through the design phase and have to check feasibility and get the idea critiqued and such, but at the moment we are thinking of making Kernel Chaos. Kernel Chaos was one of my very first formal designs, which I wrote a almost 2 years ago. At that stage the game was far beyond my reach. If we do decide to go ahead with this game I am going to use every 3rd party library / tool I possibly can to get the game running as quickly as possible, and also to allow Kev to work on the art / music knowing what formats will be support from the very beginning.

But thats all in the future, right now we have to concentrate on putting together the best possible design doc we can.


You'll never guess what I'm doing right now. Thats right I'm coding! Yes, I've finally broken out of that horrible place I call total and utter appathy. I'm finally getting the tweaks done to nanodude, but that is really beside the point, which is, that I'm coding again. Huzzah!


The Good

I quit my job today - it was easier than I thought. My manager had taken me aside to congradulate me on how well I was working etc., etc. Which I followed with "On that note I'm quitting". I have to work one more week, bet hey...

The Bad

I'm missing the Iron Maiden / Marylin Manson concert thats on at the moment and the universe is doing everything it can to rub it in. Even wikipedia's featured article is Iron Maiden today.

The Ugly

A friend posted a few pictures of me on his blog. Its a classic case of I hate that picture of me syndrome, but I think in this case its merrited. I really don't like those pics.

The Bad

I'm missing IRON MAIDEN. This gets two points because I'm doubly pissed about it.

Day 1

School started today. Its the last year of school, at the end of which I sit my leaving cert and apply for college. I'm teetering between total appathy and seathing hatred of the whole system here. Bah, I'm sure many people here are in the same boat as me so there is no point in complaining, but it is amazingly satifying to give out about random things on the internet for some reason.

And I just saw Dukes of Hazzard with a few friends - one of the most abominably bad films I have ever seen and I loved every minute of it. There is nothing like an unappolagetically bad film for a bit of fun.


Here is what I learned today:

Alchohol == Good.
More Alchohol == Better.

Which is slightly different from what I was thought:

Alchohol == Evil.
More Alcholhol == Eternal Damnation in Hell.
Been messing around for the last few days, wasting time on GDNet. My post count is way too low, so I'm trying to fix that (which makes this a "crap post" I think).

I want to get Nanodude finished, so I'm probably just going to plough through it tommorrow. Its starting to feel like one of those big projects that just won't die. Once its out of the way and not hovering over me and can work out some of the whole motivation stuff. We'll see. Hopefully I'll have a post tomorrow evening describing the amazing feat of coding that took place.

Okay, so I lied.

I don't have a version of nanodude to release yet because, well, I haven't touched code in a few days. One of those periodic "Is coding for me? But there are so many interresting things you can do, and you code?" phases. They are fun enough - I usually just go around doing other things for a while with no real goal in mind, then come back to coding eventually. These burn outs happen every so often. I think I'm going to have to find some regular group activity in real life. I've been going to the gym for a few months now, but there is no real interraction there, and meeting up with friends is a sporadic event.

I did though make damn sure NOT to post an "I'm leaving GDNet forever" post in the lounge, because its a well known fact that once you get into GDNet you stay there.

I have work thisevening, but when I get back I'll start on the list of touch ups I have to do for nanodude.


I sorted out the normal stuff, so the terrain now looks nice and smooth. I was out and about most of today so I didn't get that much coding time.

And I have to get up at 6 in the morning tomorrow because my boss hurt her back. God, I hate mornings.
I didn't get what I wanted done done last night, but I got it done this morning instead. I got stuck on a few small annoying bugs last night. So all I had in the end was a plain grid showing. Here's what I have now.

Today I added heights from an image, diffuse lighting, and a texture splashed over the terrain. I'm doing everything through shaders, which are really cool. The normals could be better though. I'm only calculating them from the four vertices around each vertex, and it leads to some ugly effects when the light intensity is increased. I hope that by increasing the number of verts I use to 8 it should smooth out the normals a bit.

I'm not going to add too much more to this demo, since I didn't code it with any partitioning in mind I'm limited in the ammount of terrain I can render. I'm not going to bother trying to crowbar quadtrees into it. I might make a bigger demo after this one but I still have a bit more to put in, after getting the normals smoothed out. I want to add distance based fog to the vertex shader, and maybe one or two other bits.
3D Game Engine Architecture arrived today from Amazon. Really wasn't expecting it for at least another week, but hey, I'm not complaining. It looks quite complicated, at least from my point of view, but I intend to work my way through it reading up on anything that goes over my head. Have to finish Game Coding Complete first though.

Just started on the actual terrain code a few minutes ago. I was having trouble getting a shader to compile propperly. I didn't realize that the compiler outputted the compiler errors to the debug window, so once I noticed that I got it sorted out - just some small stupid typo that I wasn't seeing.

I'm going to try and get the basic grid rendering before I have to head off for work. Then when I get back I'll start loading heights from an image, and maybe do the normal calculations if everything else goes well.


This DXUT sample framework is quite nifty. You get set up with a testbed in no time whatsoever. The GUI stuff is really nice too in its simplicity.

I think I'm going to write a small terrain demo in it. Simple heightmap based stuff with a single dirt texture thrown over the whole thing. It'll be ugly as hell but I just want to try it out. If it turns out well I'll make a better one, this is just to hack one together, and see how it all works.

I didn't get much work done apart from messing around with the DX framework because I went to see Willy Wonka today with some friends. They didn't seem to like it, but I loved it. It was different enough from the original that I still see them both as completely seperate films, but this improved in one or two areas that always bothered me about the first.


I always found it odd that Charlie CHOOSE his grandfather, especially over his mother who was the sole provider for the familly. At least in this one grandpa volunteers, and there is a valid reason for him doing so.

Also in the original Charlie also makes a mistake, in drinking the fizzy stuff, and yet his handing back the never-ending gob stopper at the end redeems him. It was an opportunity not given to the other children and as such I always felt Charlie didn't really earn his victory.

The one thing that was far supperior in the original film was when they were on the boat going through the tunnel and Wonka had the most entertaining monologue. That is one of my all time favourite movie moments.


All in all, worth seeing, especially if you are Burton fan like me.

Okay then.

Well that didn't take as long as I'd thought it would. I said I'd have the engine finished by wednesday and it is now finished. I have a simple app loading an image and displaying it where your mouse is, rendering text, playing music in the background and asking at run time if you want to use DX or OpenGL. All in all I'm quite happy with how it turned out. Its definately made the prospect of making a bigger engine for porpper use seem much more feasable.

So I'm going to start another mini-project tomorrow. I think I'll finally sit down and learn the DX sample framework, and maybe write something interesting in it. I've been avoiding it for no real reason. I've seen a fair few people on the boards post screenies of their sample apps which use the framework and it seems quite handy.

Finishing up

I managed to get most of what I wanted in the engine in today, and the rest should be done tonight. I have the texture loading/rendering in, the font loading/rendering and the keyboard event system. I wrote the DLLs for both OpenGL and D3D so both are fully functional. There is a slight difference in the size of the fonts, which is odd because they are both created from true type fonts using the same size in their creation functions. Ah well I'm not going to complain over a few pixels since this is never going to be used for anything major.

I'm going to add sounds through FMOD and the mouse input events tonight. Shouldn't take me too long, since the FMOD stuff I can copy/paste in from nanodude and the mouse code is basic Win32 stuff.

Nanodude is mostly finished. All thats left now is tweaking. I will be releasing it by the end of the week, but I don't know if its going to be a final version of a semi-tweaked version yet. It won't really get much work done on it till wednesday for various reasons, but its not like I have any features to add or anything.

Toy engine

I've been messing around with a little toy engine which I'm going to finish up by wednesday. Its just to through around various techniques and designs to get a feel for how an engine should be put together. At the moment I have it creating a window, initializing a graphics API (the API is stored in a seperate DLL, so OpenGL and DX should be completely interchangable), running the main loop, and I'm working on loading textures. I want to get both OpenGL and DX loading textures and fonts and rendering them in 2d. I also intend to make an audio system and a simple input system. When I finish with it it'll be quite a nice, if somewhat basic, engine.

Now back to the code.
Sign in to follow this  
  • Advertisement