Some fractal terrain questions

[waldronate]

I can't stop notice though that a lot of tools and erosion are in wilbur but not in fractal, why that ? Why not just bring all tools in FT too

There are a lot of features in FT that aren't in Wilbur, too (multiple image overlays, dynamic fractalization, and so on). It's partly product differentiation and partly that there are some things that work well enough for a static-resolution system, but translate very poorly into a dynamically-generated one. For example, the precipiton erosion feature: in Wilbur, the user can see exactly what they're going to get; in FT, the parts that can get eroded are only a small part of the final display. There's also a big fugly hiding in FT that most people don't notice right away, but that colors everything: editing data is defined in the Equirectangular projection, but most of the algorithms assume a flat equal-area map. Things in FT (rivers, erosion, editing, and so on) pucker strangely near the poles because much of the code came straight from Wilbur and Wilbur doesn't know or care about spheres. If I were starting out to write FT today I would implement things MUCH differently (not least because hardware is so much more powerful now thanit was back in 1997 when the FT ball started rolling). However, I'm a little stuck between adding new features and allowing people to keep their existing worlds. I try not to add features that highlight the ugliness of FT's spherical handling. If I ever get a few months where I can work on code (highly unlikely until the new baby is mostly grown), then I might work on fixing things. I'd probably sleep, though, so no promises.

and also why I can easily save maps in right size while in FT i have to cut and then enlarge the map couse it not saves the actual told dimensions but the window taking also the empty areas.

When you request that FT saves an image, it tries to save the viewed area of the world. What you see should be what you get unless you specify window (export) proportions different than the screen area. FT's Zoom Extents feature assumes that your main window is square and sizes things for that. I don't think that there is a "zoom to active pixels" thing in FT anywhere, but it would probably be a useful feature.

Also a very usefull thing woulkd be the possibility to pan around even when having open a window like for the incise flow function , so that while watching the preview , in other parts of the world , a lot of time I had to scrap what was done and go back because what looked good in a zone didn't in another, and I was in a zoomed in because from max zoom out is not possible to see details.

FT uses modal dialogs to do most of the user interaction. Changing how the UI works to allow pan and zoom tools to operate on the main display but no others would be a major architectural change. A smaller change of adding a preview window to the various features with an option to update the main view from the preview would be slightly less work, but only slightly. The problem is that FT would need to keep a local copy of the world state to work on and the renderer would need to... Anyway, it's really ugly to implement and would take a very large amount of effort to try to force the current framework to allow for that sort of thing (you'll notice that there's not a preview on the FT version of Incise Flow: it's for very good technical reasons; you may also notice that the incise flow dialog has an odd blank spot at the bottom where Wilbur's has some controls - very suspicious, if you ask me).