on Nov 17, 2010
Last time I created a texture for the world. It was okay.
The next step is to give this texture a bit more depth and to make it less rigid and mechanical. The first thing I want to do is make the grass edging a little more interesting. I’m going to be basing my efforts on this tutorial. (Halfway down the page.) It shows some grass hanging over onto some dirt. Two things I’m taking away from this:
1) The grass looks much more interesting if it seems to spill over onto the non-grass.
2) The surface looks “deeper” if the grass casts shadows onto the non-grass. The shadows don’t even need to be accurate based on the direction of the light source. (And we don’t have a light source yet anyway.) It just needs a simple drop-shadow effect where it outlines the grass in dark pixels. The eye will do the rest of the work.
Just to recap how I’m drawing the world. I’m putting a splat of texture at each point of the grid, like so:
But I draw the splats large, so that they overlap. I draw all of the deep water ones first, then the shallow water, then the beach, then the grass, and so on. In the end we get a nice layered effect:
But I want that grass that borders the sand to have a drop shadow effect. So what we do is this:
Before I draw the grass splat, I draw a splat that is slightly larger, and colored pure black:
Then once the black is down, I draw the grass splats. Since they’re smaller, the black peeks out a bit around the edge:
But of course that black outline is much too harsh. Let’s make it slightly transparent:
Now, at the end of the last entry I was fiddling with the splat sizes. It turns out that grass looks better if the splats are smaller, while water and beach look nicer with really big splats. So I adjust things so that the splats of each layer can be sized independently.
I like this better. The downside is that internally the game isn’t taking these oversized splats into account. Note the hex I highlighted in the above image. That’s shallow ocean as far as the game is concerned. But we got sand all over while we were drawing. The player will see beach, but find that the game treats it as water. In some games this would be unacceptable. I’m not sure if or how this will impact my game, so I’ll ignore this for now and move on.
The next step is to make the grass hang over onto the beach a bit. Right now I’m using this texture for the grass:
(Again, pink = transparent.)
I’d like the grass to sort of hang over onto the sand, using a texture more like this:
Dropping that into place, it looks a lot more interesting.
Except. There’s a problem here. Not all of the grass is pointed in the right direction. I know it’s hard for you to see in these images. Here, let me illustrate the problem for you:
I took out most of the textures and replaced the grass with a downward facing arrow. If the program was working correctly, then all of these arrows would be pointing out to sea. Or at least, roughly in the direction of downhill. I’ve added some code to look at each grid point, then examine its neighbors (the three points which connect to it on the hex grid) and then compare them to figure out the lowest neighbor. The direction to that lowest neighbor is “downhill”. This code is not perfect, and it’s possible for it to become confused in certain situations. In particular, I know I can’t count on it to come up with the right answer when dealing with saddle-shaped depressions, or when looking at a single point that juts up over its neighbors. But wrong-way arrows should be an occasional aberration, and here we’re seeing almost half of them are way off and pointing directly uphill. This should not happen.
Now, the grass actually looks okay. The problem is so slight that I doubt most people would notice. But this is troubling because it means I have a bug in my code. It’s probably the code I use to examine the grid and determine which points are related to which other points. While it’s harmless now, this same code will end up being used later on, and if it’s malfunctioning then it will cause problems that look like they’re caused by something else. I’m actually lucky to have spotted it now. If this manifested itself later when I added (say) line-of-sight checking, then I would likely blame the LOS code I had just written and end up on a wild goose chase.
So.. let’s fix this bug. Should be easy. Let’s just cover the map in arrows so we can spot which points are misbehaving.
Ugh. This is no good. Too hard to spot “bad” points with the surface this complex. Let’s simplify things. I’ll turn the entire world into a big slope and get rid of the coloring.
|I’ve highlighted some of the obviously incorrect arrows. The slope points down to the lower-right, and these ones aren’t pointing that way.|
After a lot of time-consuming experimentation and scrutiny, I’m still not finding the problem. Hm. Using a simple slope as my test case is probably a bad idea. It will only catch wrong arrows going in one direction. Let’s make the terrain a spike and look at it then.
Wow. This a toughie. I think I need to table this and come back to it later. I’m betting the problem is simple, but I’m not seeing it in the code. Sometimes it’s like proofreading: You read what you think you wrote, not what you really wrote. Coming back to it later will let me see the code fresh again.
Shamus Young is an old-school OpenGL programmer, author, and composer. He runs this site and if anything is broken you should probably blame him.