Perhaps I should mention that I've been wanting a civilization type program for about the past three days. What a coincidence...

Frankly, I've found a get-sprite routine wanting multiple times. I'd vote for removing rotCC() if you really think the number of commands should be minimized.

That's what I described

When you're generating the map, you generate a terrain tilemap underneath. Those tiles with two or more open faces are the nodes in the tree that can be traversed using whatever pathfinding algorithm you have.

One thing I've noticed from a lot of people is the assumption that the tools they use are at fault for the errors they observe. While this can indeed be the case (one only has to look at the bugs list of any major project for evidence), the first, second, and third rules of debugging are to assume that the tools are perfect until all other possibilities are disproven as the source(s) of the error(s). One example relevant to the TI is that of OS v. 2.5x, an OS often cited as the cause of many inexplicable errors. However, it is well known that the vast majority of errors are user errors, not code errors, especially in any prominent piece of code. As comfortable as it is to blame the tools, those same tools are debugged very thoroughly for the simple reason that bugs are often far more important in a tool than in a random program. In general, important programs such as Operating Systems, Compilers and Interpreters¹ are among the least buggy programs available by sheer necessity. Before claiming an error is caused by any of the above, please stop and consider whether the errors are valid bugs. Spend time looking at the documentation. Check previous bug reports and your own code carefully. Major bugs in tools are extremely rare, highly publicized, and almost always well documented.


¹: There is almost never a good reason to assume a hardware bug in commercial hardware. Don't do it without extremely strong evidence to back that claim (such as integer addition of 1 and 1 producing 3, in which case you should still be checking your display and register loading routines first).

Sounds more like a TI bug to me if it only happens on MP Oses, especially.

Not everything is a TI bug, shockingly

Actually, are you trying to generate maps or implement a pathfinding algorithm? Those tend to be different domains. However, if I understand your post, I think I may have a solution.

First of all, I notice that your example map fits very well onto a hexagonal grid. That's quite nice, because it allows you to use a "tile" system very effectively. Basically, after or while generating the map, place all the areas of a "unit" size into a grid of interlocking hexagons. For each face of a hexagon that has an opening through which the character can travel, reset a flag. For each face where there isn't an opening, set the flag. After doing this, notice that all valid paths are characterized by a collection of open faces. In other words, every hexagon along a reasonable valid path (except for the tiles holding the endpoints) contains at least two open faces: one for the character to enter through and one for them to exit through. Find the set of those tiles and there are your nodes. That allows you to use a standard pathfinding algorithm for the low level path and use cubic interpolation of that path if you want to generate a smooth path for the character.

I remember coming across an interesting pathfinding algorithm in some papers a few months back. Basically...

EDIT: found it

"Reactive Path-Planning: A directional Diffusion Algorithm on Multi-layered Cellular Automata" by F. M. Marchese, written sometime around 2000. Sorry I can't explain the algorithm, but I have to go. Hope you can find it.

As much as I prefer physical memory, most programmers will be using C, which is much better adapted to virtual memory than physical memory.