Performance problem

[pub00515]

Hi Pete (again)

I have another issue - I'm in the process of writing an external artificial horizon in OpenGL. It already works, and I want to connect it to FSUIPC. This I have been able to do thanks to your help on the other thread. The horizon correctly displays FS pitch and bank. My issue is, that when a pitch or bank change is big, the motion is no longer fluid. While the framerate of the display is set to ~ 64 fps (and this is also verified by fraps), the motion of it is sstill laggy. Could it be that FSUIPC can not read the necessary data fast enough and jumps? What would be a very fast way of reading pitch/bank info from FS?

Regards,

Mark

[Pete Dowson]

My issue is, that when a pitch or bank change is big, the motion is no longer fluid. While the framerate of the display is set to ~ 64 fps (and this is also verified by fraps), the motion of it is sstill laggy. Could it be that FSUIPC can not read the necessary data fast enough and jumps? What would be a very fast way of reading pitch/bank info from FS?

FSUIPC is reading and setting the value of the pitch and bank for the attitude indicator on every single frame. It sounds like not so much FSUIPC not keeping up, but your program not getting enough processing time to see all the values in such busy periods. And if you are alllowing FS itself to get up to 64 fps, I am not surprised!

If you are using a Pentium 4 with hyperthreading you can try assigning FS to one of the virtual processors and your program to the other. That can work. But otherwise, if you want both FS and your program to run smoothly I can only suggest that you force FS to share resources by limiting its frame rate -- Options-Settings-Display-Hardware. Set the Frame Rate Limiter to something acceptable but far more reasonable, like 20, 25 or possibly 30 fps, depending on your processor.

The general method of obtaining fluid and consistent performance with FS is to set the Limiter to unlimited initially, and try to assess the average frame rate you get. Then set the limiter to something below that. This advice is from Microsoft themselves, and is for FS running alone. With other programs needing time I'd reduce the limit further.

Regards,

Pete

[pub00515]

Hi Pete!

Thanks for your reply!

When I run my display, I run it when FS is minimized, so it shouldn't be drawing anything and therefore use much less CPU (according to 2000, its using 11%)

FS isn't running at 64 fps, that's the rate my EADI is running at. Basically, it should be similar to Project Magenta or any other external program accessing FSUIPC. Project Magenta runs just fine when FS is minimized, so I doubt its my PC that is running slow.

I have included a function into my EADI that make it turn in a circle at a high rate, and that's perfectly smooth even with MSFS running in the background, so I doubt the issue has to do with the EADI.

What else could it be?

Regards,

Mark

[Pete Dowson]

When I run my display, I run it when FS is minimized

Ouch!

When FS is running minimised most of the information which it would normally provide for panel gauges and so on is not supplied very often -- the calls it makes into FSUIPC notifying of these are completely diminished and FSUIPC switches over to timer based operation and maintains an effectively low update rate.

FS isn't running at 64 fps, that's the rate my EADI is running at. Basically, it should be similar to Project Magenta or any other external program accessing FSUIPC. Project Magenta runs just fine when FS is minimized

Really? That's odd as FSUIPC won't be running at more than about 5 fps ("frames" here in terms of values being updated) whilst FS is minimised.

Regards,

Pete

[pub00515]

Hi Pete!

Once again, you were right :-)

I use threads within my program, and a thread calls for redrawing the display. I set this thread to high priority and it seemed that this setting took away CPU time from FS when it was minimized. I just ran a test with FS in the background and the EADI in the foreground, and bingo, everything extremely smooth!!

Thanks for your help!

Regards,

Mark

[Pete Dowson]

I use threads within my program, and a thread calls for redrawing the display. I set this thread to high priority and it seemed that this setting took away CPU time from FS when it was minimized. I just ran a test with FS in the background and the EADI in the foreground, and bingo, everything extremely smooth!!

Great! Glad you got it sussed!

Pete

[vdkeybus]

When FS is running minimised most of the information which it would normally provide for panel gauges and so on is not supplied very often -- the calls it makes into FSUIPC notifying of these are completely diminished and FSUIPC switches over to timer based operation and maintains an effectively low update rate.

Hmm,

I found (with FS2002 and FS2004) that I can perfectly run them minimized. In fact, I often did programming while FS was running in the background and someone in the cockpit was flying on instruments. He did not notice much difference.

I measured the FSUIPC update rate in that case and I achieved something between 31 and 47 per second. I cannot see the rate when FS is in the foreground, but the FS frame rate is then 20.

Perhaps the high update rate is due to FSUIPC quickly returning non-updated values ?

J.

[Pete Dowson]

I found (with FS2002 and FS2004) that I can perfectly run them minimized.

...

I measured the FSUIPC update rate in that case and I achieved something between 31 and 47 per second. I cannot see the rate when FS is in the foreground, but the FS frame rate is then 20.

...

Perhaps the high update rate is due to FSUIPC quickly returning non-updated values ?

You've almost hit the nail on the head.

FS actually does a lot less when minimised. It also (as implied earlier in the thread) gets a much lower timeslice priority from Windows.

One of the things it does less is call the gauges in the panels with updated values for display. In fact, I don't think it even bothers to do this.

Now, FSUIPC uses these same calls (well, the same origin) to maintain many of the values -- not all of them, as FS itself does still provide some directly (very few these days, less with each release), and others have been mapped by FSUIPC directly into the memory locations where they are updated by FS. But there are quite a few values which FSUIPC actually has to get at regular intervals by calling FS procedures or by calculating them from other things, or both.

When FS is minimised, FSUIPC reverts to the FS timer tick calls (18 per sec) for operations -- it uses these in any case for all of its time-related operations. But because it then knows FS is minimised, it only goes and gets the variables at about a 4-8 fps rate.

None of this affects how fast you can call FSUIPC and get a response. All that will happen is that, for the now infrequently maintained variables, out of your 31 to 47 calls per second, the same values will be provided for perhaps 4 to 11 calls in a row. (The attitude indicator values are such variables BTW).

This is part of the reason you will get a higher rate with FS minimised -- FSUIPC is doing less. The other reasons are that FS is doing less, and your program gets a higher priority, being foreground, so gets control back quicker after each call.

Regards,

Pete