The GTN is nearly ready for release, and in the meantime, I've decided to open the curtain on different aspects, while at the same time, debunking some myth about FS and performance!
Here is a modest screenshot of 4 GTN unit1 at 2560x1418 pixels in P3D3.
NB: It is slightly reduced to save bandwidth (75%), but it illustrates a couple points nonetheless.
First myth: to save performance, display 1 gauge at a time only.
Most often than not, you read you can't have a popup gauge displaying the same content as the VC at the same time, and this is a 'design' decision to 'save frame rate'...
Why end up with half of your gauge, instead of getting the complete picture all around?
This screenshot shows one GTN 750 Unit1 (1 gauge, not 2) displaying 4 different instances of the gauge in different sizes at the same at the same time, at 60 FPS locked.
This is massive amount of gauge pixels to refresh, and believe me, using the mouse wheel on the screen (which simulate screen pinch in/out) there is no stutter at all and this refreshes at native GTN speed.
Second myth: you can't display images with gradients because of colour banding...
Well, I'm sorry to prove this is wrong (see the area within the yellow circle), but thanks to our unique technology capable of rendering 32bits images in FS gauges, in real time, you really get THE complete GTN screen picture only with the Reality XP GTN Touch.
Third myth: this is just a gauge which bridge the Garmin trainer, what's so special about this? Can't everyone do the same frankly?
It might look the same on the surface, but it is more than just 'bridging' flight sim and the Garmin trainer. Suffice to say, if this was easy, there would be a lot of Garmin trainer based products on the market!
First, once done the bezel, the screen, and start/stop the Garmin trainer in the background, which a lot of developers could manage to do, there are key differences in how you put and how you get data to/from the sim and the trainer.
Implementing the technology to grab the screen in a highly efficient way, and then displaying it in FS in a highly efficient way, and in 32 bits colours, it something which is much harder to do than it may seem.
Then, the scope of input/output to the trainer is paramount to a sound simulation, especially for our professional customers using our technologies everyday for training. For example, our TAWS-A implementation in the GTN takes in account the actual flaps and gear position, which have a dramatic impact on the TAWS algorithm, and the alerts it returns. Speaking of this, I've recently read on avsim someone saying there is no way to 'inhibit' the TAWS because, well... In fact, not all GTN are born equal and the Reality XP GTN Touch offers the 'TAWS Inhibit' input, in addition to the OBS and the CDI toggle inputs.
I could write a lot more about all this, but enough said for now, time for the screenshot:
NB: this is running on an old 3.4Ghz Intel I5 (2013) and an Nvidia GTX 775M with 2GB, more specifically a Late 2013 iMac in bootcamp, which is our average test reference computer.