|
From: Thorsten R. <tho...@sc...> - 2016-11-28 16:00:31
|
> - Have you considered moving the AW or Shuttle canvas code to C++? In > both cases it should be quite easy, manipulating properties from C++ is > not much harder than Nasal and I would be very curious to know if the > overhead is property IO in general, or specifically from Nasal. It would > also be good to have some examples of driving the Canvas from C++ > instead of Nasal, though the NavDisplay code is another potential > example of that. Not really. In the particular case of the ADI, it would mean hard-coding an instrument that has pretty much zero other applications in FG (the complication is that spacecraft can actually assume pretty much any yaw attitude with the velocity vector so you can have beta of 90 degrees no problem - so the instrument needs to show the complete range of yaw motion which transforms a 2d into a true 3d ADI - aircraft don't need any of that, or at least I'm not aware of any aircraft instrument that displays a huge beta range. If I ever get around to it (the Shuttle is sort of a black hole into which huge amounts of work time can just disappear without leaving a noticeable trace - the sheer amount of switches on the flightdeck is insane). I plan to cut out the middle-man (canvas) and just let the ADI ball be drawn by a special-purpose shader - graphics cards are actually made to solve this sort of thing, that should work at near zero performance impact. For AW... yeah, it's a 'would be nice to have' scenario. The problem is that I don't have a team of programmers at my disposal ready to assist and too many unsolved issues waiting. I might eventually re-write AW to encode plenty of meteorology I've learned since I wrote the current (I worked through an introductory course of late) - so we might get AAW one day. Maybe... * Thorsten |