20,741
edits
Talk:North American P-51 Mustang: Difference between revisions
Jump to navigation
Jump to search
m
Talk:North American P-51 Mustang (view source)
Revision as of 18:06, 11 August 2014
, 11 August 2014→Performance issues on non-high end computers: extra500 comments ...
m (Headings; indentation) |
m (→Performance issues on non-high end computers: extra500 comments ...) |
||
| Line 69: | Line 69: | ||
:::P.S. The Extra500 is a very special case, and its performance issues have nothing to do with a detailed model on old hardware (like some would like you to think), but there the nasal beast rears its ugly head and starts biting ;) (it runs just as bad with a cube replacing the 3d-model) | :::P.S. The Extra500 is a very special case, and its performance issues have nothing to do with a detailed model on old hardware (like some would like you to think), but there the nasal beast rears its ugly head and starts biting ;) (it runs just as bad with a cube replacing the 3d-model) | ||
:: We've had several discussions regarding extra500 performance, and like you say, some things -like the 3D model- seem to have almost negligible impact on performance, while Nasal code is certainly one of the main culprits involved - but even the way the two Canvas textures are updated is fairly expensive. So it's not just due to Nasal itself. Fairly efficient/fast Nasal code can be written, to see for yourself, look at any code written by TheTom, AndersG or Philosopher. As far as I know, the extra500/[[Avidyne Entegra R9]] developers have already adopted some optimizations, and they even looked at some [[NavDisplay]] and [[MapStructure]] techniques to make things faster. | |||
:: But overall, there's quite a bit of slow code remaining - and the whole instrument could definitely be faster by adopting the corresponding frameworks and augmenting slow code with C++ extensions, which is something we've been working towards. We've also posted patches that make it possible to identify "slow" callbacks (timers/listeners) by hooking into FGNasalSys. I think it's fairly safe to say that the extra500 developers are interested in improving performance, but it's not just Nasal that's involved here, the main issue is a structural one, i.e. code organization. To see for yourself, use the "fps_debug" branch and disable all 3D models and even the IFDs. In general, it would help to add our patches to FG and allow aircraft developers to look under the hood and better understand where resources are spent, including stuff in scripting space (especially the GC, but also all callbacks). Just saying "it's due to Nasal" is as unhelpful and non-helpful as it can get: We've also seen the property rules subsystem consuming plenty of CPU cycles. So "bugs" can be introduced in several places, and that alone doesn't make the technology bad per se. Thus, no matter if it's the 777, the P51, the 747, the 787 or the extra500, what people really need is some way to see where all the horsepower is going instead of uninformed musings that lack data to back up such claims.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:06, 11 August 2014 (UTC) | |||
::::quote i4dnf: ''(Would it interest you if I told you I can run trees and random buildings at density 2.9 on an 8800GT with minimal framerate impact? Oh yeah, with dense 'grass' generated nearby too? This requires minimal changes to the source, but its not really prime-time ready yet)'' | ::::quote i4dnf: ''(Would it interest you if I told you I can run trees and random buildings at density 2.9 on an 8800GT with minimal framerate impact? Oh yeah, with dense 'grass' generated nearby too? This requires minimal changes to the source, but its not really prime-time ready yet)'' | ||