I can't remember the last time I had to spend any time finding a memory stomp. This was not always the case -- I have spent many an hour with data breakpoints. Man was I happy when those finally started working on the Wii. Today I thought I'd share a couple little things I use to eliminate overflows in my code.

I always hated working on games that didn't have a working debug build. On some the framerate was too low. Some didn't even build. There was always one real reason for it: somebody in charge didn't think it was worth having a running debug build. But the cost of a broken debug build is a huge increase in bugfixing time. Debugging a non-debug build results in misleading values in your debugging windows, bad callstacks, and heavy reliance on static analysis of trace output to figure out what has gone wrong. In short: it has a huge cost in developer time.

I've been stuck on this for a week, so I'm putting it out as a Friday puzzle challenge. Can you tell me what I'm doing wrong?

I added the normal mapping code from Followup: Normal Mapping Without Precomputed Tangents. I have other normal mapping code which uses the usual method of passing the tangent vector with the vertex data and that works great. There's no vertex shader code on The Tenth Planet, so I had to figure that out myself.

The problem I have is that if I use the normal from perturb_normal, the lighting rotates with the model so it is always the same side of the model that is lit (beautifully) no matter how the model is oriented relative to the light source. If I light the model with the interpolated vertex normal I get smooth n dot l lighting which works as expected.

In my quest to increase draw distance, I needed to find a way to reduce the number of triangles in my terrain block meshes from 7938 to something much smaller but that still retained the overall shape of the original block. I found lots of algorithms for decimating (reducing the number of triangles in) meshes but nothing specific to terrain meshes.

I read this post on AltDevBlogADay which made me decide to finally post this:

I was approached by a fresh-faced rep from Hansoft at Game Developers Conference a couple years ago. She asked me if I used project management tools, and after replying that I used their software, she was really excited and asked me what I thought of it. I told her I had never seen a product so thoroughly designed to make people feel bad about their work. She stared at me blank faced, then handed over one of every tchotchke they had in their booth.

The toys didn't make me feel any better about Hansoft. Do you have a happy team? Hansoft may well drive it into the ground.

I spent a couple hours reading pages of Google results trying to figure this out last night. There are a lot of people who seem to have problems with this. The pictures are all reasonably clear, but the implementations are quite variable for a non-math guy. Here's the resulting vector code which seems to be good. Maybe this'll help someone. Note that you can replace Vector3 with Vector2 and this will work for 2D lines.

p1 and p2 are points on a line. DistancePointLine returns the perpendicular distance p3 is from that line. It returns true if p3 is perpendicular to the line segment from p1 to p2, false if not. It also returns the distance from the infinite line going through p1 and p2 (because I found that more helpful.)



IntersectionPointLine returns the point on the infinite line that runs through p1 and p2 that is perpendicular to p3. Some variations of IntersectionPointLine return either p1 or p2 as the intersection point if p3 is not within p1 to p2 (u is out of range 0.0-1.0) which would give the distance to a point which is on the line segment, but in this case it is no longer the perpendicular distance. If this is what you want, in IntersectionPointLine return p1 if i < 0.0 and p2 if u > 1.0. That wasn't helpful in my case (I'm using this to decimate meshes) hence the code below finds the perpendicular distance from the infinite line.

Here is the C++ code:

    bool Geometry::DistancePointLine( const Vector3& p3, const Vector3& p1, const Vector3& p2, float32 *distance )
    {
        Vector3 intersection;
        bool withinLine = IntersectionPointLine( p3, p1, p2, &intersection );
        if ( distance != NULL )
        {
            *distance = ( p3 - intersection ).Magnitude();
        }
        return withinLine;
    }

    bool Geometry::IntersectionPointLine( const Vector3& p3, const Vector3& p1, const Vector3& p2, Vector3 *intersection )
    {
        Vector3 diff = p3 - p1;
        Vector3 dir = p2 - p1;
        float u = Vector3::DotProduct( diff, dir ) / Vector3::DotProduct( dir, dir );
        if ( intersection != NULL )
        {
            *intersection = p1 + dir * u;
        }
        if ( ( u < 0.0f ) || ( u > 1.0f ) )
        {
            // closest point does not fall within the line segment
            return false;
        } 
        return true;
    }

I was talking to an artist buddy on the weekend about post effects. I wanted to add a heat refraction effect for my hottest biome, and we got to talking about what other post effects I might want to consider. There are a ton of possible post effects, but as a non-artist, I'm often unsure as to whether they're really worth the effort of implementing. Color Correction came up as very worthwhile, and as it turns out, it is super easy to use (even for the artistically challenged.)

I needed to accurately determine the distance of particles from other scene geometry in order to fade out particles that are too close to things (which gets rid of nasty seams in the particles.) I'd used a method copied from somewhere but I noticed that particles got faded the further you got from them. This felt like a math error.

This week I did some digging around and found not one, but two methods to get the distance (in world coordinates) of a pixel from the camera.

I'm looking for my next game after Skyrim so I thought I'd try out some new games.

I had 20 minutes to play Thursday, so first up was Magicka on Steam. I'd heard nothing but good things about it and I'd installed and started it before, so I figured it should be good to go. But no. Steam told me that before I could play it needed to convert my files to a more efficient format for 15-20 minutes. Like it's so important to do that right away. So that was the end of that. I ended up browsing news sites.

Friday I got Magicka going, only to discover that it only lets you save about once an hour. This isn't rocket science people, you already have checkpoints in the game. The game idled most of the night while I put together bits of time to get to the end of the second chapter when I could quit without losing progress. It was fun, but I'll probably never play Magicka again.

Saturday morning game time: I pick Starcraft 2 to start on the single player campaign. I'd installed and started it before so I should be good to go. (I tried to start playing Starcraft 2 last year but there was a problem with my battle.net account and I couldn't log in to play it at all for about a week.) It isn't on Steam so color me shocked when it insisted it needed to optimize my files for 15-60 minutes and download 6GB before I could play. Fail. Fail! Fail!

How about an oldie but a goodie. I played Crysis a couple years ago and it was sort of pretty. I know it's installed and working! Maybe it's time to get into a little shooting. Started it up, black screen, no sound. It worked fine the last time I played it! I started downloading newer video drivers and the latest Crysis patch when I realized I was again not having fun!.

Last up, Borderlands. I'd installed it previously using Steam but never tried it. Pressed Play and what happens? Steam starts installing 4 more things! Shouldn't Install have done that?

Play time is precious. When I want to play, I want to play. I don't want to fix bugs. I don't want to download drivers. I don't want to optimize my files (whatever the hell that means.) I don't want to patch my single-player game. All of these issues could have been avoided if the companies behind these games had a lick of common sense and any respect for the player.

Back from vacation for three weeks now, productivity hasn't quite returned to normal levels. I'm used to having several uninterrupted hours every day, but with the family home that hasn't been happening. I think I've figured it out now though. Anything big or complicated that I've tackled has gone poorly, but a couple little features have come out just perfect.

The main feature I've been working on this summer is vehicle movement and pathfinding. I decided my original plan to replace the navmesh with a grid based on the terrain mesh wasn't going to work. Instead I have done some work on my original navmesh implementation and am working towards adding a steering system for units based on the collision data.