Monthly Archives: April 2011

Not the Last Programming Language

3 Replies

Uncle Bob Martin is a well respected figure in the software development industry, and the chief driving force behind the Software Craftsmanship movement. His talks on methodologies, languages, and the state of our industry are always entertaining and insightful. Uncle Bob tends to make a lot of analogies to other professions as a means to bring our industry to maturity, such as doctors, lawyers, etc. There are a lot of very valuable analogies to make there; Here’s some of what he has to say on the topic:

“Do you think the only time musicians play their instruments is when they are on stage? Do you think the only time that batters hit balls is during games? Do you think the only time lawyers give a closing is at trial? Of course not. These people are professionals; and professionals practice! Professionals study the minutia of their disciplines. Professionals know all the little tricks and quirks. They know the history, the theories, the anecdotes. They know techniques and methods. They know good options and bad options and how to tell them apart. And they know all this stuff because they practice, practice practice.” source

We as a profession must agree to a set of disciplines, a set of rules that we will follow. Doctors always wash their hands rigorously before doing anything, and if they didn’t, we would not consider them to be a ‘professional’. During an operation a doctor follows his discipline, does not allow fear to take over in the shadow of a deadline, and follows his rules step by step, carefully adhering to his disciplines. To this point in the history of software development, we have not technically had a ‘profession’ in the truest sense of the word. As Bob Martin tends to say in his talks, to this point we’ve operated a lot like this:

“All we knew about what programmers did was that for weeks/months we threw meat in the room, and later code came out.”

In the past several weeks however, he made another observation which I find myself disagreeing with. He postulates that we may have reached the point in our industry where there are no more programming language paradigms to explore. His analogy to other professions this time around, is that of notation. Electronics, Chemistry, Biology, Mathematics, etc have agreed on common notations, and therefor so should we. I have to disagree with this. In those professions, the purpose of notation is purely communicating the ideas. Source code is not purely about the communication of ideas (although that is a large part of it). I think a better analogy here is that source code is like a wood craftsman’s tools. You don’t use the same tool for all jobs (unless you enjoy cutting large pieces of wood in half with your chisel). In software development, source code is your tool, and you must use the right tool for the job, and evidence of this is widespread. It doesn’t make sense to code up a thick C++ application just to parse logs, so you choose perl. It doesn’t make sense to create a GUI application in PHP, Basic, or Fortran, so instead you choose C#, Java, or Python.

I’d love you hear your thoughts on this, so leave a comment.

Collision Detection in 2D Games

Leave a reply

Implementing per-pixel collision detection in a 2D game can be accomplished using a variety of methods:

  1. Sprite image rotation, bounds intersection
  2. Sprite translation, per-pixel comparison of of non-alpha-transparent pixels
  3. Sprite translation, maintaining a bounding box, per-pixel comparison of of non-alpha-transparent pixels

The first method assumes that you are rendering your image verbatim, and the image is actually what you are manipulating. This is typically the way you’d be doing things in a Java Swing game. The bounding box of your sprite is effectively the bounding box of your image.

Here’s what that might look like:

    if (sprite.boundingBox.intersects(otherSprite.boundingBox)) {
        //collision!
    }

The second method utilizes matrix transforms (location, rotation, scaling) to figure out where and how to render pixels. This transformation is the most common scenario in C# XNA game development. Since you are essentially plotting pixels right to the screen, no bounding box exists. Each time your game loop runs, it’s necessary to ask the sprite where its pixels currently are and compare them with collidable pixels in the scene. This is VERY expensive, since you have to ask all your sprites on the screen for their current pixel information, ask your player sprite for its pixel information, and then do combinatorial math to determine if any non-alpha-transparent pixels are true for both sets of pixels.

Here’s what that might look like:

public bool CollidesWith(Sprite entitySprite)
{
    Matrix myMatrix = this.Sprite.GetMatrixTransform();
    Matrix theirMatrix = entitySprite.GetMatrixTransform();

    Color[,] myColorArray = this.Sprite.ColorArray;
    Color[,] theirColorArray = entitySprite.ColorArray;

    Matrix myMatrixToTheirs = myMatrix * Matrix.Invert(theirMatrix);

    int myWidth = myColorArray.GetLength(0);
    int myHeight = myColorArray.GetLength(1);
    int theirWidth = theirColorArray.GetLength(0);
    int theirHeight = theirColorArray.GetLength(1);

    for (int x1 = 0; x1 < myWidth; x1++)
    {
        for (int y1 = 0; y1 < myHeight; y1++)
        {
            Vector2 pos1 = new Vector2(x1, y1);
            Vector2 pos2 = Vector2.Transform(pos1, myMatrixToTheirs);

            int x2 = (int)pos2.X;
            int y2 = (int)pos2.Y;
            if ((x2 >= 0) && (x2 < theirWidth) &&
                (y2 >= 0) && (y2 < theirHeight) &&
                (myColorArray[x1, y1].A > 0) && 
                (theirColorArray[x2, y2].A > 0))
            {
                return true;
            }
        }
    }

    return false;
}

The third method is essentially the previous method, with the optimization of a bounding box being maintained around your drawn pixels. Checking for a collision has an early-exit optimization, in that you first check which sprites bounding boxes intersect with eachother, and then only do the per-pixel collision detection on those sprites. This is a much better way to do things, and many orders of magnitude faster.

Here’s what that might look like:

public bool CollidesWith(Sprite entitySprite)
{
    if (!entitySprite.BoundingBox.Intersects(this.Sprite.BoundingBox))
    {
        return false;
    }

    ...
    //rest of above method here
    ...
}