I’ve been a rather busy beaver the last week or so. It became apparently early on that the best way forward with the G1000 would be to quite literally rip the existing code out and replace it wholesale.
The last few days I decided to take a real stab at performance and I have some amazing results I’m so very excited to share. Update times for the G1000 were absolutely awful, coherent render times around 3-6ms depending on the frame, frequently in the order of 5ms. Since these seem to stack on main thread times (don’t know why), this is a collosal performance degradation.
Well…2 days later
I still have a couple of instruments to get working on the PFD, because I am having to rebuild them from scratch, but I have no reason to believe I’ll even hit 1ms for total PFD and MFD update times. For the sake of comparison, I’m now updating the PFD at around 2000fps versus about 250fps for the base game. The end result is that I’m seeing anywhere from a 5-10fps boost, and more importantly extremely stable frame pacing.
I have no reason to believe at this point that even the airliners could easily be running sub 1ms update times with some actual effort, especially considering the G1000 is rendering just as much or arguably more.
Did I also mention that these are updating even more frequently than the base game which frequently lies about actually rendering per frame? The result is that instruments now feel so buttery smooth you’ll wonder how you ever put up with the base game.
Unfortunately I took this video after a while of reloading which drops my fps a lot but I’m sure you can see what I mean.
I think that’s the most exciting part of my work perhaps, but there is an absolutely stack more I’ve done on creating pages for the MFD (again, all from scratch). I will update the thread with. As a very minor addition that’s easy to show, though.
This has been fixed in 0.3.1, we sequester our avionics in their own directory with that one. It looks like the pre-release has soaked without any more troubles so we’ll be formally releasing that shortly.
There is support in it for doing this to any plane, but currently only the G36 has been enhanced to take advantage of it. It would be nice to have other planes configured, too, but that’s a lot of individual work since you need to find the performance numbers and a model of what the MFD actually looks like to do it right.
There is documentation in the package on how to configure a custom panel file if anyone is really passionate about it and wants to work on a particular plane. Otherwise we’ll probably get to them one by one but it might be a little while.
Yep, that’s working as expected. In the real world the G1000 calculates wind information based upon relative movement of the plane vs the ground. When the plane is on the ground there is no relative movement so it can’t tell you what the wind is.
pre2 seems to have fixed the two big issues found in the original release. We’ll be releasing a final 0.3.1 shortly and it would be good to update then.
We’ve been working with @aznricepuff already to do some joining of forces. They’ve adapted their changes to the WT file structure and pulled in a few of our enhancements and there’s a PR to pull it all in. I’m hopeful we’ll be able to release the next version of this as a Working Title project managed by a new team member and help each other improve both mods.
That said, I think that version 0.3.1 of the G1000, which I’m about to post here as an update, should remove any conflict between the current G3000 mod and this one, but I’ll need to double check on that.
We have a new version that takes care of the two biggest bugs that were reported with v0.3.0 – the broken synthetic vision on G3000s and map overflows on WPT/NRST pages when running track (I mean heading) up.
As part of the solution to the G3000 problem this update does something we have been meaning to do for a while. It moves any of the files we touch that are shared between avionics or airframes into their own location where only modified code can access them. This will avoid the sort of conflict we saw with the G3000 synvis. It will also improve our compatibility with other mods out there, and hopefully serve as a good example for others to follow.
For this reason everyone who has v0.3.0 is encouraged to upgrade to v0.3.1. Please be sure to delete your existing workingtitle-g1000 directory before installing this if you haven’t already tried the pre-releases.
Hi! Thanks for the update.
Just wanna report that there are some files missing in comparison to 0.3.0. The files are still listed inside layout.json, but not present on the 0.3.1 release. AttitudeIndicator.js for example, and other files.
Thanks for the info I almost asked this same question. I don’t necessarily have an interest in the G36 (though maybe I should check it out) was hoping more to use it in the DA40’s. I do have a question though, other than the now fixed G3000 conflict, in the off chance I do use the G36 mod and this together, are there any other planes that may potentially be affected? Similar to how the A32NX project apparently interferes with the anti-ice buttons on the CJ4 for instance? (both the WT and stock suffer the same issue). I have no problem swapping mods around when I want to fly a particular one, just want to make sure of which mods need to be swapped around
Can you double-check that? Some files moved between 0.3.0 and 0.3.1, but from what I can see they’re still in the zip file. Here’s that portion of layout.json as I see it:
Not that I can think of, no. Unless I overlooked something, every file that we modify should now be outside of the stock location with the exception of a stub HTML file what we use to load the instruments. For example, this is the entire contents of the HTML file in the stock location for the G1000 PFD in this mod:
That loads code from our own location and everything else boots from there.
That said… I did just double-check my inventory as I was writing this and I’m reminded how there is one stock file we still modify in place, html_ui/Pages/VCockpit/Instruments/Shared/Utils/XMLLogic.js. That’s because it’s referenced in the “base” HTML that loads everything in the cockpit and for now we’ve decided against messing with that and potentially causing larger issues.
I don’t know of anything else that touches this file but there could always be something. I’m hopeful that by the next major version we’ll have a safe way to take care of that one as well. In the interim, as long as no other mod you have changes that file you should be good.
Now I got it, they are inside “WorkingTitle” folder, not on the default directory. Now I see what you mean by “It moves any of the files we touch that are shared between avionics or airframes into their own location where only modified code can access them.”
Thanks!
In the real world the G1000 calculates wind information based upon relative movement of the plane vs the ground. When the plane is on the ground there is no relative movement so it can’t tell you what the wind is.
