On Saturday 23 February 2013 12:21:02 Emilian Huminiuc wrote:

> So in the default scheme we load 9 tiles at startup, then we keep loading
> tiles in the direction we're traveling, and those initial tiles remain
> resident in the tile cache for a while (in case you decide to double back).

So there's a bug in the tile cache. When caching stuff leads to an out of 
memory condition, the cache is at fault. The whole purpose of such a cache is 
to improve performance. A crashed application has the worst performance of 
all. So this cache should be fixed to automatically reduce the number of cached 
tiles in low memory conditions.

> Well, our average user might have read the manual, might have mucked about
> with the visibility setting before, and he remeber that all things being the
> same, visibility is what impacts performance/memory the most, so he decides
> to try again, this time trying to use z/Z to limit how far the visibility
> goes, maybe he gets lucky and it won't crash again, but he's in for a
> surprise... z/Z doesn't work...

So the manual is wrong as well. Like you said yourself, trees give a larger 
memory hit than terrain. So the first thing to do should be to disable trees.

> You might argue that he should know better, go into the advanced settings
> dialog, figure out what all those sliders and selection boxes do, etc,
> etc... But remeber, our user is an average one, he wants things to just
> work (with time, he might find a use for the more advanced configuration
> stuff, but for now he's not interested, he just want to click something,
> and be done with it), The z/Z case above might be a lucky one where he
> might have read the manual.

Since advanced weather seems to have a slider for maximum visibility, why not 
change the key binding to make z/Z control this maximum visibility? This still 
leaves control of visibility with advanced weather but should satisfy the 
people using this key for memory management (however wrong that approach may 
be in my opinion)

> You look at view-distance/fog just as an atmospheric phenomenon, that you
> think should be represented verbatim, well it's not. It's not just that in
> any case, and if for it to fulfil all its roles you need to abdicate from
> the verbatim aproach, well then I'm sorry but my opinion is that you
> should. I never claimed that it's the only resource management device, I
> only claimed that it's role is  much more than just visual cue to the
> environment, and that role should not be underestimated, or thrown aside...

>From this whole discussion I get the impression that FG's memory management 
simply sucks. We have caches eating too much memory at times, several memory 
intensive features but no information about how much memory they really use. 
Yet still we push responsibility for keeping memory requirements within the 
limits of his machine to the user. The one who has the least chance of getting 
it right.

The solution is not to give crude tools like limiting visibility to the user. 
The solution is to fix FG to be consious about how much memory is available and 
make the best use of it. Yes, many games simply limit visibility if memory or 
performance pressure gets high. But FG is a flight simulator. Visibility is a 
very important part of flight (at least for me as a VFR pilot).

Stefan

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to