> What *is* the baseline hardware fg ought to be aiming at? I guess in practice every developer works such that stuff runs well on his own system. What else can we do? I'm not buying a second computer just to test how it would run on a Mac.
> Advances in quality always requires more resources. Period. If your > hardware doesn't support it, bad for you but be grateful FlightGear at > least provides an option to turn to less nifty rendering. Actually, as Stuart or Mathias have demonstrated here, that's not always true. We seem to be getting more random buildings for less framerate impact for instance. Same was true with the clouds or with the geodinfo() which suddenly was a factor 50 faster. There are sometimes clever ways of doing a task much faster, and one has to spot them. More often, there are clever ways to do a task a bit faster. Taking a week to streamline shader code, I have typically gained 10-20% improvement in the past, at the expense of making the code difficult to understand. Not much, but I notice it, especially summing up several such effects. I didn't get the impression we usually make things as efficient as they could be. Many slow-changing quantities are determined per frame, or when it's clear that they're not needed for instance. An example is ridge lift which is updated per frame at agl altitudes of 20.000 ft when its value is ~1e-5 and it's clear that there can't be any real lift. Many distance calculations in Nasal scripts in the visible scene use spherical geometry while they could be in local Cartesian geometry which is about a factor 5 faster to compute. The problem with making things efficient is that you have to understand well what you're doing. If you approximate an expression by something that works faster with the same accuracy in most cases, you need to take care of the case when it doesn't work. It's a weakness of the modular structure of the Flightgear project that there's hardly anyone with the 'big picture' who knows enough to realize where computations are repeated and how we could streamline the whole. So, I think we can agree that spending performance on improvements, optionally implemented, is reasonable and desirable, burning performance in inefficient code is not desirable, but how to translate this into practical consequences isn't as easy to see. People are trying as a rule. Cheers, * Thorsten ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
