My Dear Mr. Duk:
A brief Q & A before I collapse for the night:
Q: "What's your reasoning behind including in the new list the 'sea-adjacent-to-land' locations?"
A: When smoothing a shoreline sometimes we want to make convex bulges and sometimes we want to make concave bulges. That is, sometimes the shoreline should extend part way out into a "sea" coordinate, and sometimes the sea should extend part way into a "land" coordinate. Thus the "active region" of potential pixel redefinition will include both land and sea coordinates along the coastlines.
Q: Can you give a more precise definition of the shoreline region?
A: Identifying shoreline coordinates is easy. Examine each coordinate in the initial map one by one. For each coordinate, examine its eight neighboring coordinates. Whenever a land coordinate has a sea neighbor or a sea coordinate has a land neighbor, then add that coordinate to your list. The final list will comprise the shoreline region (at least as far as the macro-coordinates are concerned). I wonder how big this list will be. 10% of all coordinates? 20%?
Q: "Is your intent to blow up the *entire* world to high resolution, and run the algorithm the second time against the new hi-res world?"
A: Yes. However, it should not be necessary to work with the ENTIRE hi-res map during smoothing. All we need is a list of available micro-coordinates in the "Shoreline Region". This, in turn, is easily derived from the list of macro-coordinates in the Shoreline Region defined in the previous answer.
If macro-coordinate 15,43 is in the shoreline list, then the corresponding block of micro-coordinates will extend from 141,421 to 150,430. Thus there will be 100 times as many shoreline micro-coordinates as there are shoreline macro-coordinates. It should be possible to avoid dealing with micro-coordinates located inland or deepsea.
Q: Oh really? And just how do I do that?
A: In your existing algorithm you already have tests in place to prevent continents from extending beyond the edges of the rectangular map. The only difference here is that your edge test will be slightly trickier.
Instead of testing to see whether a neighboring micro-coordinate is less than 0 or greater than the maximum value allowed, you will convert the micro-coordinate to its corresponding macro-coordinate (subtract 1, divide by 10, and add 1), and then check to see if that macro-coordinate is on the shoreline region list. If not, you have reached an edge of the shoreline region and so can skip redefining that pixel.
Q: Won't this consume unpleasant amounts of memory and processing time?
A: That's a very good question. Essentially, that's what you have to find out. My rough guess is that micro-generation should not take up more than about ten times as much resources as macro-generation, and with a little clever programming and maybe a few compromises, we should be able to whittle that down considerably.
For example, we could consider going to an eight by eight coordinate size instead of a ten by ten. That would lop a third of the size right off the top (64 vs. 100).
Better yet, instead of converting an ENTIRE macro-coordinate to a block of micro-coordinates, we could just convert half of it. This will probably be necessary anyway in order to ensure that "land" coordinates are at least half land. In terms of the algorithm, this would simply involve a further refinement to the edge testing process. We could even experiment with converting, say, 30% of all land shoreline coordinates and 60% of all sea shoreline coordinates (a convex bias).
As far as memory consumption goes, aren't you going to have to represent every pixel of the map anyway? I don't quite understand how you are planning to represent the full map. Can you create one enormous PICT resource and view parts of it? Or do you have to swap hi-res pieces in and out of memory? If need be, it might be worth looking into different ways of representing the map.
Well, that should be enough to keep you busy for awhile. I'll plan on seeing you in Alexander room Wednesday night.
Yours in haste,