Here is the reason I'm trying to avoid saving chunks of data. When the server needs to know something, like if a building can go in a particular spot, it needs to check all the tiles that it will be on to make sure they are buildable. As in not water for instance. If I did chunks, then for each check, it has to build that entire chunk, Suppose a building is 2x2 tiles, and that is right on a division between four chunks. Then it has to build up all 4 chunks of data just to check 4 tile ids.
So it is for the server's sake that I am trying to avoid this.
Some of what that produced was awesome. exactly the types of layouts I would like to see. But it also looks like its building in large chunks, not so much pixel by pixel. (as in a function/pattern will adjust many pixels at a time, so if you didn't preprocess that, how much work would it take to implement something like that per pixel for checking.
(PreviousRandom = where the current code leaves off and was about to return)
X>>3&7&previousRandom = obtaining bits
0 1 2 3 4 5 (giving blocks of 8*8 the same base randomizers), as 0 through 7. It increases the odds for the value to be 0, then 1,2 or 4, then 3,5,6 then 7 from highest to lowest order.
I can repeat the same pattern on the Y side.
Each value can link to something that will alter the odds of particular tile types, for instance, I could make
: 0 grass, just all grass. No more mods.
: 1,2,4 Grass mostly, but with water as an alternative.
: 3 = grass at edges, another tile type massed through the center
: 5 = additional rock focus.
: 6 = additional forrest focus.
: 7 = Forest.
That would be the X effect, and Y could have its own modifying alterations. Perhaps the top corner pieces, can even look up its 2 neighbors to modify its likely hood of a particular type.
I think this gives me some more tweaking room without particularly expanding on the processing level too much.