A nice quick dev update today to keep you up to date with how we’ve been getting on at Fenix Simulations! Last week, during the Indicating/Recording feature review, I mentioned that we expanded the Alpha team out to get a wider range of system testing – this has yielded some great data for us, allowing us to identify and improve the Fenix A320’s performance on lower-end PCs and laptops.
Some of what we’ve done includes some pretty nifty options with display rendering, which we hope will allow you, the user, to better optimise your own experience based on where your PC is bottlenecked. We noticed, using some of this testing data, that lower-end 4 core PCs with GPUs a few generations old were utilising their resources in a relatively unpredictable fashion, based on user settings. The bottlenecks varied between the GPU and the CPU on these systems, and each unique system configuration deployed it’s resources a little differently.
Now, the largest source of performance draw for us is display rendering. Many of you may recall or be familiar with high-fidelity addons on older platforms like FSX and P3D, where developers needed to pull every trick in the book to try and claw back the performance losses incurred. This included an option to limit the refresh rate of the displays on board the aircraft, being a major source of performance loss.
Taking all the above into consideration, we came up with something a little more… outside the box. The Fenix A320 will allow the user to select how they would like to render their displays depending on where they have the most overhead. If MSFS is hammering your CPU, then you may choose to render your displays via your GPU. If MSFS is hammering your GPU, you may choose to render your displays via your CPU. You can move this performance-drain around based on where YOU have the most overhead to accommodate it.
What if MSFS is hammering both? Well, one more nifty little trick. If you have an integrated GPU on board your processor, we can utilise that instead to try and buy you a few more frames per second. These are often unloved and very rarely used, so it made sense to try and give it some sort of utility. I can’t personally think of the last time I’ve used my i9’s on-board GPU. This is great for laptop users too, because most will have an integrated GPU on board their processor, in addition to some sort of discrete graphics card, allowing the user to spread the load out over unused system resources. If you use SLI, or Crossfire, then you can select which one of your GPUs we use, depending on where the load is, and where the load isn’t.
In other news, Alpha testing continues with our larger group, and now we’ve addressed some of the performance related optimisations, the team is turning their attention to system-side bugs and issues. I’m very, very proud to say that the Alpha team we’ve put together are absolutely voracious in breaking the airplane, and we’re seeing really well put-together reports which are key to tracking and slaying these bugs quickly and methodically. Our developers, testers, and customer support team are working flat-out to carry us through this incredibly intensive and challenging phase of development, and everyone is going above and beyond to help shape the product into it’s best possible final form.
Finally, we are still on the lookout for someone familiar with font work, so if you believe that is you, please reach out, I’d love to hear from you!
That just about brings to close this short little update (I hope I’ve included enough images to make up for the lack of content!).
See you next week,