Bugslaying!

This past Ludum Dare (26) has really brought out the bugs in my little genesis port.  My entry was a mess, barely functioning and not finishable.  Lots of things went wrong but primarily the problems were with collision and pathing.

I went into detail on the collision problems and fixes on a postmortem on the Ludum Dare site, but apparently only a small chunk of my post made it, the rest being chopped off.  The short of it is the genesis box collider was built to cope with nonconvex leafs, which is why no collision routine I ever wrote would work (mine don’t cope!).

The side effect of coping with messed up leafs is you get some false collisions.  This became apparent when doing some traces to plot where a fireball would hit.  I fixed the leafs and put in a test for convexity and wrote a plane shifting sphere collider to do the fireballs.

Then for pathfinding, I had some mysterious spots that confounded the pather.  Looking into it, the jump from bsp node to path node was coming up blank.  I added functionality to draw everything path related into my handy test program.  Everything still looked like it should work.

Then I noticed something odd, a path face showing up for two different nodes.  I put a search for duplicates and there were some.  I started drawing faces by node and then I remembered, node faces can extend outside the node they are in.  This is done because we never relied on bsp ordering in the software renderer, instead using a span buffer to sort the draws the same way quake did.  It was also a no brainer for hardware rendering.

So I just removed the face merging altogether.  It was one of those big chunks of code that I just did not have a clue how it worked.  Same thing with the radiosity lighting awhile back.  I eventually nuked it because I just couldn’t figure out how it worked.

Nuking face merging fixed pathfinding for good.  The triangle density increased a bit, and I added in a check for small faces to leave them out of the path data.  You need this because the small face might be next to a wall.  If the path goes through that face, a mobile with a big collision box might not be able to reach it due to being too fat.

Not having face merging brought out another bug, one that has vexed me for years.  The lightmaps on certain faces were always off by a little bit.  With merging on it was not really all that noticeable, and the few attempts I’ve made at fixing it failed or just made things worse.

The unmerged face can be seen in the wall’s shadow

So I decided to write a tool that recorded everything in the lighting process and displayed it, so I could figure out where things were going wrong and look at the numbers.  This sort of thing is so fast in XNA.  Round up some raw points, cram them in a vertexbuffer, and render with a basic effect.

After getting it running, I could see that some faces had light trace points that were quite a bit off from the actual geometry.

The little lines are where rays trace to lights

The solution was to find the amount the face drifted away from the quantized light grid, and add a little adjustment into the UVs.  It seems so obvious now, but I could never figure it out until I could see it.

Before the Adjustment

After adjustment

My next major bug you can see in the raw geometry shot of light explorer above.  Those light cages are detail brushes, which means they are not supposed to split other faces.  The genesis split chooser code heavily favors non details but will eventually choose them.

I had a look at quake 3, and it builds the tree without the details first, then filters them down into the leaves.  I might try to do that as well, but I’d need to “unleaf” some of the leafs landed in so everything remains convex.

Here’s a vid of my post-compo game, just a couple minutes of running around:

And a link to the game, which I’ll continue to update as more bugs are fixed.