What a great day! I got it almost all worked out. There are some subtleties. Since my blog topic is "really boring game development minutae" I'm going to lay it out for you.

I got this just now:

@p CODE: texcoord_ratio = (rep_size - 1) / mkrloc (tex_size, tex_size);

@p ERROR: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second

@p Interesting! I have no idea what it means, but the trick was that (rep_size - 1) was supposed to convert the 1 into a mkrloc (1, 1). Oh well.

The previous post lays out how the automap works. The thing is, we actually need to section it. Why? Because the player only sees about 1/3rd as far as the actual area stretches. So if we go auto-mapping the entire area (50x50 blocks) then it will be hard for the player to really know where they went.

@p The solution is to section each 50x50 block further into 3x3. But there's a catch! What this means is when we step on a ? block, we figure out what 17x17 section we are in. But we can't compute the visibility only limited to that 17x17 section, because what that would mean was if there was an impassable fence (that opened up later on) we wouldn't be able to see it. Ugh! I know this is horribly complex and boring but it's funny how subtle this actually was.

@p So what you do is when the player steps on a ? block, you compute the visibility temporarily for the entire 50x50 area. Then, you only take and copy into the automap from the appropriate 17x17 section of THAT.

@p What you get is a pretty natural seeming automap.

This is all well and fine, but it ends up with a pretty high-resolution automap. It starts to feel artificial, to me, something like a high resolution image in the middle of a pixellated indie RPG.

@p So what we want to do is filter it, i.e., thicken the lines. This can happen when we're preparing the texture for rendering of the minimap, and it's not hard. You just run a filter on the minimap data that will take the maximum (brightest) line value from each 3x3 surrounding block for each pixel.

Close, but even that's still not enough! Why?

@p Because you're going to get a lot of "dots" on your map, anywhere there is a tree. Tree's are 1 block impassable things, but having them show up on the minimap is irritating. Worse, they get thickened in the previous step so they start to look very significant. In some cases, it looks like a pathway is blocked off.

@p Remember: we are still computing the minimap and storing it on a per-pixel (per-block) high resolution level. This filter is just for the purposes of display.

@p So what you do is, similar to the above filter you go through and look for any "loners", i.e., single pixels without any neighbours, and you clear them. Simple enough.

@p However, you need to run this filter BEFORE the line thicken filter.

And... minimap! In case you think I'm crazy, and that this much detail is overkill...

@p Here is the "too fine resolution" minimap:

Here is the thickened, but not despeckled minimap:

And here's where we are at the end of the day:

What's left is really mainly to color it blue, move it to the right and down, and then put a system in place where you can click it and get a special-UI scrollable minimap. Maybe you will access this from your watch, but I think it will be a better choice to put a "GPS" button on the minimap itself. More intuitive!

@p Then I have to make it know to pop in and out, tie it to ownership of the GPS watch item, and give the watch item the ability to turn the display ON and OFF.

@p Voila!

2009-10-02

◀ Back