Date:	1993-10-31
		From:	John
		Subject:	Smoothing Note

Congratulations on your progress toward a working C++ continent generator. The beast seems to run just fine and is generating some beautiful worlds. I eagerly await all the functionality of the previous incarnation (especially the save as text). This new version does misbehave when you resize the window, but I assume you are already working on those bugs.

As for its speed, I can detect only a slight decrease. The previous version took about 2.5 seconds to create a world on my Centris; the new version seems to take about 3 seconds. Out of curiousity, why is C++ slower?

I do not know how to go about providing a better about box. Unlike the settings dialog, there appears to be no DITL or DLOG resources associated with the about dialog box. I don't know what method you use to provide that box, but perhaps you could change your procedure and create a second DITL resource. I already have a smaller version of the PICTure which graces our T-shirts; it could serve as a first try. Shall I send that to you?

I like the idea of having a scrollbar from "Mostly Sea" to "Mostly Land." But for simplicity's sake I would argue against asking players to provide spark clumping patterns. Instead I think we should first do the necessary experiments to determine how much of a difference the clumping pattern makes and then automatically choose a pattern based in part on the Sea-to-Land scrollbar setting. If it turns out there is a dramatic difference we could consider adding a second scrollbar, something like "Chunky" to "Stringy."

One correction to the wishlist. The current suggested coordinate size is 18x14, not 18x12. Are you planning on putting in gridlines? I think we definitely should. In my OracleCard maps I have been seperating each coordinate from its neighbors by a single pixel; this creates horizontal and vetical lines across the map. The maps as they are currently drawn are actually 17x13 with the extra pixel in each dimension used for the lines. This is probably not correct; the gridlines should not be treated as part of the coordinate squares. Thus when working with neighboring pixels during smoothing we should probably "hop over" gridlines at the boundaries of each coordinate.

The other goals look fine. What are the prospects for COLOR?

You will be elated to hear that I have started to explore the smoothing algorithm. Attached is my second Microsoft Word document. This paper examines the key problem of defining which pixels fall in the shoreline area and which pixels comprise the initial set of micro land sparks (a set I call the "proto-shoreline"). I have included a table and two diagrams, one of them in color.

I have also created an OracleCard stack to hold full-sized color maps. Since OracleCard apparently limits its card size to just under a million square pixels, I was forced to settle for a 50x70 coordinate map at 18x14 pixels per coordinate (including the gridlines). At present the stack simply imports (half of) an Alex text map. Now that I have worked out the details of defining the shoreline area I will start work on implementing the smoothing algorithm. I am desperately eager to see what a smoothed coastline looks like.

According to my calculations, the shoreline area will contain roughly 100 times as many points as the macro-level map and thus will take at least 100 times as long to draw. YIKES! Off the top of my head I see two possible strategies for dealing with this problem. The first is to make the generation algorithm more efficient (if possible). Instead of proceeding until the sparklist rises and falls back to zero we might try keeping sepatate land and sea sparklists. As soon as the land sparklist falls to 0 we could then set all remaining coordinates to sea in one fell swoop. It's not clear how much (if any) time this would save.

The second idea is not to smooth the shorelines ahead of time, but only smooth each individual coordinate as it is uncovered by the player. I presume we could smooth a single coordinate almost instantly and thus the player would not notice the delay. Just a thought...

As soon as I achieve actual smoothing I'll send you the fullmap stack. Keep on coding!

Yours in haste,

Epicurious