Thank you WordPress

March 18, 2010

Google recently decided to drop FTP support for Blogger.  I don’t like the idea of being forced to put my blog on their server, so I went looking for some different blogging software.  I found WordPress and I’m happy with it so far.  Easy to install, easy to import my blog, easy to update my theme, and easy to use.  Two thumbs up.

As for my model ship, it’s coming along, but I haven’t updated it in a while.  I’m sure I’ll finish it up one day when I find some time.  Until then you’ll have to trust me when I say it’s freaking awesome.

posted by james wells at 9:55 am

Rear Turret

February 5, 2010

This evening I put on a rear turret and added some mounting hardware where the wing meets the engine. I also screwed up the body a bit, looks a bit blocky, but I can undo that. I also need to cut away where the turret mounts so you can see the mounting ring. Still, it’s looking better:

posted by james wells at 8:41 pm

Stolen Barrel

January 29, 2010

It’s nice to have models to steal parts from. I wanted to put a huge cannon type thing under my new space ship, so I grabbed a barrel from my turret. I like the result:

You can see I still have to make a mounting bracket for it (currently just using a cube). Also that cylinder on top is where the rear-facing turret is going to be. I’m generally happy with the new body shape. All in all the major pieces are falling into place, it’s just lacking a lot of detail work.

posted by james wells at 8:05 am

New Model

January 28, 2010

I promised myself I wouldn’t do it… but I just started making a new model. This is another one like the big turret. It’s not meant for the game, it’s meant to be very highly detailed and cool looking. This time I’m trying my hand at my own space ship, a sort of fighter model.

It’s still very much a work in progress, but here’s a first image:

It’s still missing a lot of detail, I’m just sort of getting the rough outline in place, figure out where the major parts will go. I’ll post more as it grows.

posted by james wells at 11:12 am

Ray Tracing

November 19, 2009

Ever feel the need to make your browser squeel like a piggy? Well do I have the page for you. The other day a friend of mine pointed me to jQuery. I had never used the stuff before, but it sure looked damned cool. So I started thinking about what kind of web project I could come up with. Well my first couple of ideas seemed neat, but they where pretty graphics intensive, sort of the wrong job for the tool. Another buddy of mine suggested that if I wanted to do graphics on the web I should check out the new canvas tag. Heard of this one yet? It’s a new HTML5 thing, gives you a drawing context to paint directly on the browser from javascript. In of itself it’s kind of a fun toy, but the cooler thing is they’re looking at making a 3D version at some point. So basically your web browser is now just the blank slate where web pages can run apps for you. Multics anyone? It’s a good thing this is all gonna happen with javascript, cause I’d hate for it to be a slow language or anything.

Anyway, armed with a canvas, some jQuery, and a hatred for client side web programming, I decided to whip up a little ray tracer. Here’s some output:

It’s slow as hell, and it only makes balls, but what the heck, it was kind of fun. Feel free to give it a spin:
The Client Render Farm

posted by james wells at 4:30 pm

Dubious Engine

October 8, 2009

Well I went and did the thing I promised myself I wouldn’t do… I started yet another re-write of this thing. This time it’s in the form of a new game engine, the Dubious Engine. What brought this on? Well I just finally admitted to myself that making another space ship model didn’t seem nearly as much fun as fixing the math and physics. Especially the physics. I do enjoy physics. So I started over with a math engine that made some sense. Mostly it’s just a re-write of the vector classes. I got so tired of constantly being confused about whether a vector was normalized, non-normalized, rotation, in world space, in local space, etc etc etc. So the new math library has distinct types for each of those things.

From there it was time to fix the physics. Up until now I’ve been sort of getting by with a “just enough is good enough” engine. I wanted to see what it would take to write a physics simulator that actually made sense. Turns out I wasn’t all that far off before. Mostly this is the REngine physics, but with better book keeping. Instead of just returning the first point that hits and a “best guess” normal I actually take the time to find a point and normal that make sense. The results are encouraging. I set myself the goal of being able to create a demo where a bunch of cubes fall together and bounce around on a table, and I’m pleased to report that I’ve pulled it off. It’s still far from perfect, but it’s worlds better and looks convincing enough. I’m gonna keep working at it, I have some ideas for improvements (better handling of intersecting polyhedra for one) but for now it’s good enough to release.

So, if you are interested in game engines or physics simulators, maybe you will enjoy it. You can grab your copy here.

posted by james wells at 5:09 pm

Using Private

September 25, 2009

My last blog post generated a really interesting comment from one of the folks on LinkedIn. He raised a couple of key issues that really got me to thinking. Eventually what I took from it all was that a Vector and a NormalizedVector are sort of two different things… and sort of the same thing. This post is a look at how to best express and manage this unusual situation.

First let’s consider the obvious part, how are they the same? Well they’re both vectors, so they should both support the kinds of things that vectors do, addition, cross products, dot products, etc etc. No surprises there, but how are they different? Well some of the things that make sense on a plain vector are meaningless on a normalized one. For example, SetLength is stupid, as are dividing and multiplying by a scalar. And if you need to call GetLength on a normalized vector then you’re doing something wrong.

My last post suggested a single template class that sort of ignored all these issues and just created one all-purpose vector that used template tricks to act like 2 vectors. You could happily call GetLength() on a NormalizedVector. The SetLength function existed for both, but would refuse to compile if you tried to call it on a NormalizedVector. While it was nice that it failed at compile time, it still left the interface with a function that didn’t exist, which is sort of sucky. So it became clear that I needed a new solution. Let’s look at the first 3 that sprung to mind.

Option 1: Two completely different classes. This was actually what I went with first. It’s old school and is easy to understand and create. You start with 2 headers and you fill them with 2 different classes. But of course then you have to try not to gag while you’re copying and pasting all the common code. CrossProduct, DotProduct, equality tests, etc etc. You just cut and paste and pray that if you find a bug in one you remember to fix it in the other. Not ideal.

Option 2: Composition. Stick all of the common stuff into one class called VectorCommonStuff and let each vector contain one of these. This is nice because the two vectors are different types, but it sucks because… well because the two vectors are completely different types. Plus you end up having to add an extra layer to get to the common code. So Vector::CrossProduct does nothing but call VectorCommonStuff::CrossProduct. I’m sure an optimizer could clean this up for you, but the code is still ugly and overly deep. Who else is sick and tired of having the debugger step into a one line function and then having to make it step in again?

Option 3: Inheritance. Good old fashioned polymorphism to save the day. Make yourself a BaseVector class which supports all the public stuff, then inherit from it for each vector. This fixes the problem of public functions that just call private functions, but now your two vectors really are the same thing. You open yourself up to creating functions that take BaseVector* and happily take either type of vector. In a way this is nice, but it defeats the purpose of creating separate types.

So what are we to do? Is there a way to combine the clean separation of composition with the common code base simplicity of inheritance? Well I ended up finding a solution that I’m very pleased with. I’m also very pleased to note that after 12 years as a professional C++ developer, I found a keyword that I had never seen before. That keyword is “using” and when you mix it with private inheritance you end up with a slick solution. For those (like me) who have never used private inheritance before, a refresher. As far as the child class is concerned, private inheritance works just like public inheritance, ie you have access to your parent’s public and protected members. However to the outside world you didn’t inherit from anything (and your parent’s public functions are not accessible). According to the docs I read, this is considered a “has-a” relationship, just like composition. In fact, by itself it offers us no real benefits over composition, you still have to create public functions that call your parent class’ functions. And that’s where the “using” keyword comes into play. You can use it to expose your parent’s functions to the outside world. Time for a simple example:

class VectorBase
    float GetXComponent();

class Vector
    : private VectorBase
    using VectorBase::GetXComponent;

Do you see the magic? That “using” keyword makes the inherited GetXComponent() function public. So now I have exactly what I’m looking for. My two different vectors can privately inherit from a VectorBase. To the outside world they’re entirely different classes, which means I can write expressive code that specifically uses the kind I want. But inside the classes I can share common code in a clean, easy to maintain fashion. I can also expose shared code in one simple line.

I continue to love C++. Who would have thought that after so many years I’d still be finding out new things at the fundamental level? What do you think? Had any experience with these 2 concepts before? Did I miss something obvious or not so obvious? Feel free to comment and keep the conversation going.

posted by james wells at 3:11 pm

MPL Madness

August 31, 2009

The time has finally come. For years now I’ve known that of all my C++ shortcomings, the most obvious is my irrational fear of Template Metaprogramming. I’ve been telling myself that when the C++0x standard comes out, Concepts will change the face of metaprogramming, so I should just keep avoiding it until I can learn the new system. Well as Sutter reports, Concepts is out of the (newly renamed) C++1x Standard, and might not make it into the language for another few years. So it’s time for me to bite the bullet and learn something new.

With that in mind I’ve bought the big scary book, C++ Template Metaprogramming and am trying to read it. In the first weekend I managed to get through chapter 1 (mostly background) and struggle through chapter 2. Then I attempted the exercises in chapter 2 and almost gave myself a stroke. I got through half of them before moving on to chapter 3. A few pages into chapter 3 I was bleeding from the ears, so I backtracked and re-read chapter 2. Long story short, it’s gonna take me a lifetime to get through this book.

However I have managed to come up with an example where MAYBE I have put it to good (or at least interesting) use. I’ve been toying with the idea of re-writing the game engine on which Rift is built. So today I thought I’d tinker around with the math a bit, see if anything is interesting. One of the things I’m trying to do is create specific classes for specific purposes (I’m tired of losing track of whether or not my rotation vector is relative to the global coordinate space or the object’s). So I’ve been trying to come up with ways to create 1 template that can then be tricked into being different types for different purposes. So with that in mind, let’s take a look at the humble Vector.

For purposes of this discussion there are 2 kinds of Vectors, regular ones and normalized ones. Obviously a normalized one has a length that’s always 1. So the trick was to write a vector class that can be 2 types, one for regular vectors and one for normal vectors. Before templates I would just include a run time flag, m_IsNormal, and check it to see if I should normalize. Not a bad solution, but a bit prone to error and chews up runtime cycles (okay not a lot, but bear with me). So how do I create a vector that picks the correct type at compile time and normalizes accordingly? Here’s how I started:

template class Vector
    Vector( float X, float Y, float Z )
      : m_X( X )
      , m_Y( Y )
      , m_Z( Z )
    void Normalize();
    float m_X, m_Y, m_Z;

This works pretty well as a regular old Vector. But as you can see, it doesn’t normalize unless you specifically tell it to. So it fails as a Normalized Vector. I could call Normalize in the constructor, but of course then it would always normalize, which would make it fail as a plain vector. So I decided that I needed was a static helper class:

template struct Normalizer;

And of course, what good is a static helper class if it doesn’t perform an action? And not only that, but we have to be able to select that action at compile time. Thankfully this is all what I learned in chapter 2 of the book. You can select different actions by creating different specializations of the static helper class:

struct Normalizer
    static void Perform( Vector& V )

struct Normalizer
    static void Perform( Vector& V )
    {    }

How’s that look? Now if you compile a Normalizer with true then it will call Normalize, and if you compile it with false, it won’t. Just what we need. How do we use it? I’m going to change the constructor a bit:

    Vector( float X, float Y, float Z )
      : m_X( X )
      , m_Y( Y )
      , m_Z( Z )
        Normalizer::Perform( *this );

Do you see the magic? When you set ShouldNormalize to true at compile time it will compile the version of Normalizer that calls Normalize(). If you set ShouldNormalize to false, it will do nothing. My hope is that since it’s a static function the optimizer will get rid of the function call and efficiency will be obtained.

But WAIT! There’s a problem. Now we have 2 vectors that are completely different types. Logically they’re both vectors, one’s just stored normalized, but to the compiler they’re completely different things. So the following reasonable code will fail:

typedef Vector PlainVector;
typedef Vector NormalizedVector;

PlainVector Plain( 10, 20, 10 );
NormalVector Normalized = Plain;

Damn! So close. So what do we do now? Well this is the point where I start to wonder if my solution is clever, or horrible. I hope at the very least it’s interesting. I figured what I needed was a copy constructor to convert between the two types. The clever part is that I only have to write one copy constructor to achieve this goal:

    Vector( const Vector& Other )
      : m_X( Other.m_X )
      , m_Y( Other.m_Y )
      , m_Z( Other.m_Z )
        Normalizer::Perform( *this );

Pretty sneaky huh? That will create a copy constructor for the normalized vector that accepts a plain vector, and vice versa. Pretty smooth…. only one problem, it won’t compile. Did you already figure out why? Feeling smart enough to guess? I’m gonna tell you in the next sentence to you better hurry up. It won’t compile because Vector
is not allowed to see the private members of Vector. Remember, they’re completely different objects. However the fix is pretty trivial. As my old professor used to say “only friends can see your private parts.” You just need to expose each type of vector to the other. You can use the same trick you used with the copy constructor:

    friend class Vector;

And that’s the end of that story. I now have one body of code that compiles cleanly into a normalizing and non-normalizing vector. This leaves one huge question in my mind, was this a good thing? If any of you have experience with this kind of thing I would LOVE to hear your feedback. Maybe when I get to the second half of chapter 3 I’ll learn that I just committed the classic rookie mistake. I’ll let you know.

posted by james wells at 4:49 pm


August 12, 2009

I’ll be damned, it worked! I managed to stick an AVI into the game and have it play on a texture. Turns out it wasn’t so tough. A raw AVI is a pretty straightforward file format, very well documented on MSDN. It’s basically just a bunch of BGR values with some location markers. Turning them into a handful of static textures is trivial. Then you just have to update the timer and pick the right frame.

I also created an animation in Blender. It’s pretty silly, some white rings and flashes and spinning bars. But when you throw it in the game it’s alright. Well, it’s not great, but at least there’s something to let you know it’s warping. It’s much better then the old system, which was just a hard cut to black.

Not sure what to add next. Back to play testing.

posted by james wells at 2:52 pm

Play Testing

August 10, 2009

The last couple of programming sessions have been sort of directionless for me. I wasn’t really sure what I wanted to change, so I opted for trying to make the game more “fun.” I know, I know, a crazy concept. With no idea how to do that I decided to just play a bit and see if there was anything that could be made a bit better. Well it didn’t take too long to start compiling a list of stuff. Right off the bat was the mouse pointer. Every other game with a first person view has a cool little crosshair type thing to chase around, whereas Rift has a mouse pointer. I also noticed that the steering was twitchy to the point of being stupid, which makes it really hard to dogfight. Also, why no shields? Seriously, how did I never get to that?

So these things and others have now been crossed off the list. It’s surprising how little things like this can go a long way. The next thing I decided to add was spawn points. You know how it works, you jump into an area and after a while some bad guys show up. Then a bit later some more show up. And so on until you either leave or die. Well I created a spawn point and immediately ran into a new and interesting problem. I found that when you had about 6 ships chasing me down my refresh rate would drag down to 1 fps.

This was cause for concern. Oddly enough I noticed that my Physics rate was holding steady at my pre-defined 40 frames per second. So how is it that Physics could remain unchanged, while refresh was dragged down? That’s when I started to remember something from those physics articles I posted a while back. The way the physics loop works is every time through the loop I accumulate time. When enough time has passed I chew up that time in physics. This is all well and good when the game is humming along in empty space. However there’s a real problem when things get busy. What happens when it starts taking longer then a second to calculate all the physics for the past second? The shit hits the fan and your frame rate goes down to 1 frame per second.

Just to pound the point home a bit, let’s say you decide to run 10 physics loops a second. At time 0 you start your game loop and your physics takes 0.18 seconds. Then you run your render and that takes 0.02 seconds. Now you start your game loop over and you have 0.2 seconds worth of physics to run. That’s 2 physics loops. So those two loops takes you 0.36 seconds and then you do your render for another 0.02 seconds. Now you start your third loop and you have 0.38 seconds of physics, or 3 full runs. That now takes you 0.54 seconds. You see where this is going. Every loop you get further behind. Eventually your game just becomes a huge physics number cruncher and stops responding to your input. That’s about what Rift did when 6 bad guys jumped into the spawn point.

Thankfully a long time ago I created a neat little utility program for Rift. The idea is that in debug mode you can break into Rift, flip a bit, and then the current state of the physics will dump to an xml file. Then you can open up that xml file in my test program and poke it with sticks to see how it responds. Well it turns out that with 500 lasers on the screen, 40 physics loops was taking around 3 seconds. Oops. What do you do? Well I started off by getting a nice little profiling tool called Very sleepy:
I fired that up and ran through my code, but it didn’t tell me anything I thought was useful. According to it, all of my time was spent doing things like dereferencing smart points and adding vectors. Surely that couldn’t be the problem? So I started adding counters and timers and what not, and looking at the code path. I found some troublesome square routes, and I copied my heavy STL lists into raw arrays. All of that helped a bit, but I was still taking over a second, which was still WAY too long. That’s when I started to wonder about the sheer quantity of calculations.

The thing about lasers in Rift is that they don’t actually collide. This is by design because lasers aren’t supposed to bounce. So why was my physics loop taking so long? I had 500 lasers that weren’t running any collision detections, should be cake. Well it looks like the problem is simply that when you have 500 objects in a container, and they all need to check against each other, and you need to do that 40 times a second, you end up doing over 5 million comparisons. Turns out this takes a bit of time, even in release mode. So yes, Very Sleeps was telling me the truth, all of my time was spent doing fast things. The problem was just that I did so many fast things.

The fix? I split up the physics a bit so that all of the lasers go in their own container that doesn’t bother to check against itself. Is there a moral, a lesson? I guess it’s that sometimes you have to abandon generality when things go wrong. I’m actually running into this a lot more as I try to work less on the engine and more on the game. Suddenly all my nice abstractions are falling down as I try to add specifics. Some of that is just because my engine has flaws, and some of that is just due to trying to make game specific things.

Next on my todo list is video. I want to make an animation for jumping to a new area. There are a number of articles out there about playing an avi on top of a texture. I just have to figure it all out. Looks interesting. Let’s see how far I get.

posted by james wells at 3:37 pm

Older Posts »