
Originally Posted by
waldronate
30000x16000 images require 480Msamples. At a minimum 8 bytes per sample (4 bytes for terrain and 4 bytes for color), that's 3.84GB before allowing room for the program or for the operating system. That's just for holding the output data. The working data takes much more than that for handling the editing data (4 bytes per sample for each of offset, scale, climate, water, ). 32-bit Windows programs get 2GB to work with per process (3 GB if you do ultra-special things behind the scenes to windows and the programs). Assuming that the full 2 GB of process space is available (which it really isn't), then that would give you a maximum output size on the order of 10000x5000 or so. FT isn't hugely efficient, so you'll probably get a little less than that.
Implementing a good virtual memory system was a bit outside the scope of the planned FT development. FT originally made some assumptions about maximum data sizes and further assumed that everything would fit into memory (yes, I was sloppy). Rewriting the system to work with a paged system would be a bit non-trivial because it would require rewrites of huge chunks of the system, with the attendant new bugs and likely breaking changes in some areas. Add in the performance wall when you run out of physical memory and it was just a bit risky for FT3 in my opinion.