Problem Aerobrake MFD map glitch

[Sky Captain]

I have a problem with Aerobrake MFD map function. When I switch on the map in aerobrake MFD Orbiter drops framerate to 3 - 4 fps. All other modes work fine. I suspect it`s something to do with MFD refresh rates because if I in orbiter launchpad reduce refresh rate to 1 second or longer orbiter freezes a bit only at the moment aerobrake MFD map function is refreshing data which is very annoying.

 

[TSPenguin]

What operating system are you running?
What hardware do you have?
What framerates do you usaly get?
Did you test if this occurs on a fresh install?

 

[Sky Captain]

What operating system are you running?
What hardware do you have?
What framerates do you usaly get?
Did you test if this occurs on a fresh install?

1. Windows vista ultimate
2. Intel core 2 duo 2 Ghz, 4GB RAM, GeForce9600M
3. Depending on addon generally 20 - 50 fps
4. I just tested on clean orbiter install and the problem still occours

 

[Sky Captain]

Really no ideas why Aerobrake MFD map is not running smoothly?

I`m doing some rocket racing and without help of Aerobrake MFD map it`s difficult to drop right over the base. So far with help of Basesync MFD I have managed my best time in a Cape canaveral - Ascension island flight 18 min. 35 sec. I`m sure with help of Areobrake MFD it might be possible to do this flight in ~18 min.

 

[tblaxland]

Maybe it is a Vista/GDI issue related to the way Aerobrake MFD is blitting the map bitmap? Do you have this problem with the normal Map MFD? If you're game, Aerobrake MFD comes with source code.

 

[Tommy]

Do you have Vista Boost installed? (Get it from Doug's Orbiter Page)

 

[Hielor]

Maybe it is a Vista/GDI issue related to the way Aerobrake MFD is blitting the map bitmap? Do you have this problem with the normal Map MFD? If you're game, Aerobrake MFD comes with source code.

It wouldn't surprise me. If Aerobrake MFD is doing a lot of GDI stuff (as I imagine the map would need), it won't work very well on Vista.

 

[Sky Captain]

Maybe it is a Vista/GDI issue related to the way Aerobrake MFD is blitting the map bitmap? Do you have this problem with the normal Map MFD? If you're game, Aerobrake MFD comes with source code.

Normal map MFD works without a hitch. I also have Vista Boost installed, but it did not help with this problem.

 

[tblaxland]

As a matter of interest, have you ever used Radu's Extended Map MFD? I'm curious because they should use similar GDI techniques and hence should show similar symptoms. If not, it might be worth looking at the Aerobrake MFD code a bit harder to see what can be improved (although I admit that I am getting out of my experience when comes to the GDI graphics operations).

EDIT: Radu's Extended Map MFD here: http://library.avsim.net/search.php?SearchTerm=Extended+Map+MFD&CatID=orbmisc&Go=Search&Cookie=1 (you'll need to log in to download - sign up if you don't already have a login).

 

[Sky Captain]

As a matter of interest, have you ever used Radu's Extended Map MFD? I'm curious because they should use similar GDI techniques and hence should show similar symptoms. If not, it might be worth looking at the Aerobrake MFD code a bit harder to see what can be improved (although I admit that I am getting out of my experience when comes to the GDI graphics operations).

EDIT: Radu's Extended Map MFD here: http://library.avsim.net/search.php?SearchTerm=Extended+Map+MFD&CatID=orbmisc&Go=Search&Cookie=1 (you'll need to log in to download - sign up if you don't already have a login).

After some trouble (avsim is sooo slow) I managed to download Extended Map MFD and it runs fine, no freeze when MFD refresh.

 

[agentgonzo]

AerobrakeMFD does a lot of internal calculations at every call to the MFD::Update function (it's performing a numerical integration of the path your vessel will take). This takes up a lot of CPU cycles that would normally get used for the orbiter core and graphics. It also does quite a lot of GDI drawing (as mentioned above) that is slow on Vista. This is what lowers your framerate. The same thing happens on mine, except that my framerate isn't quite so low as I'm using a beefier computer.

Orbiter is single threaded, so your multicore processor won't make much difference. You'll just have to live with it, unless you want to modify the code for AerobrakeMFD to make it multithreaded (something I have planned to do but haven't got around to yet)

 

[Sky Captain]

So the freeze happens because of limitations of my hardware not because of a bug?

Then it seems I will be stuck with Basesync MFD for some time.

 

[agentgonzo]

So the freeze happens because of limitations of my hardware not because of a bug?

Then it seems I will be stuck with Basesync MFD for some time.

I think that it's mostly the way that Orbiter runs on Vista and the fact that AerobrakeMFD and Orbiter are single threaded.

 

[tblaxland]

I don't notice a significant drop in frame rate between the different display modes on my XP system but I do notice a significant drop in frame rate when Aerobrake MFD is active. So, as you say, it seems both factors are at play here.

BTW, instead of making AerobrakeMFD multi-threaded (I have zero multi-thread experience so I don't know how hard that would be) would it be easier to spread the integration out over several time steps? For example, if MFD::Update is called every 20 frames, do the integration over the previous 20 frames (or maybe 10, to ensure the integration is finished?). I toyed with that for State Vector MFD but it turned out that there were not sufficient iterations required by my Newton-Raphson root finder to justify it.

 

[agentgonzo]

BTW, instead of making AerobrakeMFD multi-threaded (I have zero multi-thread experience so I don't know how hard that would be) would it be easier to spread the integration out over several time steps? For example, if MFD::Update is called every 20 frames, do the integration over the previous 20 frames (or maybe 10, to ensure the integration is finished?). I toyed with that for State Vector MFD but it turned out that there were not sufficient iterations required by my Newton-Raphson root finder to justify it.

You could do that, but then after a AOA change on your reentry, it would take many updates of the MFD to draw the change to the map, which if you have a low update rate would make it virtually useless.

Also, Newton-Raphson isn't exactly the best numerical integrator. Runge-Kutta(4) is much better (and I believe that Jarmo uses something different again for IMFD). I don't know what aerobrake uses, but I'd take a guess at RC4.

 

[tblaxland]

You could do that, but then after a AOA change on your reentry, it would take many updates of the MFD to draw the change to the map, which if you have a low update rate would make it virtually useless.

What I mean is to do the integration (or part thereof) at each sim time step using opcPostStep. By the time MFD::Update is called you will already have the result because there are many calls to opcPostStep between calls to MFD::Update. Jarmo uses that method for the IMFD Map program I think (that is the reason for the "Legs per frame" setting I believe...).

Also, Newton-Raphson isn't exactly the best numerical integrator. Runge-Kutta(4) is much better (and I believe that Jarmo uses something different again for IMFD). I don't know what aerobrake uses, but I'd take a guess at RC4.

It works as a sufficiently efficient root finder for Kepler's Equation in KOST. I found I only needed 3-4 iterations to get an error smaller than double precision for most orbits. It gets less efficient for high eccentricities (>0.95?, my memory is a bit vague on the testing) but I decided it was good enough. It is also easy to get a good starting point to solving Kepler's Equation from the mean anomaly.

Anyway, I thought RK was better for solving ODEs, which Kepler's Equation is not (EDIT: remember I am doing Keplerian orbit propogation in KOST, not numerical integration of Newton's laws).