Frame rate slow down using FSUIPC

[ACyLum]

Hello

I seem to have a strange problem with frame rate slow down using FSUIPC.

Everything seems to run fine frame rate-wise until I started doing a read from 088c for the throttle. Once I have this instruction in the loop, I notice a drop of 5 fps.

However, this is the weird part, if I move the mouse around, then the frame rate jumps back up to normal.

Here is my program loop:

...

...

FSUIPC_Write(0x0578, 4, &pitch, &dwResult);

FSUIPC_Read(0x088c, 2, &throttle, &dwResult);

FSUIPC_Process(&dwResult);

...

The loop is simple, so I'm not sure what could be the problem. Any ideas about what it could be?

Thanks for your help

[Pete Dowson]

Everything seems to run fine frame rate-wise until I started doing a read from 088c for the throttle. Once I have this instruction in the loop, I notice a drop of 5 fps.

However, this is the weird part, if I move the mouse around, then the frame rate jumps back up to normal.

I think mouse movement tends to make Windows give more time to the process which should be processing it, same as when you use the keyboard. So what is probably happening is that your program is stealing too much processor time. You don't say how you are controlling the loop -- is it on a Timer, or do you use "Sleep()" to release the processor occasionally?

As to why this is specifically related to the read of 088C I've no idea -- there's no particular action taken on that, the throttle values are provided even if no one reads them.

If anything takes any time at all it is going to be the Write, not the Read -- you look to be changing the aircraft pitch forcibly, on every loop? Why? Normally pitch is controlled by elevator or elevator trim. You are effectively slewing the aircraft, against aerodynamic forces, on every loop. I wouldn't be surprised if that did slow things down a bit.

Regards,

Pete

[ACyLum]

Hi Peter

I'm programming an external program to handle LLAPBH and slaving FS to that data. In the code snippet, I left out the other instructions for brevity...

Currently, I am not using a timer (sleep()) or anything to delay the main loop for another process. I can try that to see if I can normalize the frame rate. Do you have a suggestion for a sleep delay value? I'm currently frame locked at 20FPS in FS.

So far the effect only happens when I do a read operation from the throttle offset (actually from any of the offsets) things are fine if I just Write to an offset(so far doing the forcing of pitch/alt/etc,.. seems to work fine and at the right frame rate). I was also wondering if using the interface for Modules would be better - does this have an effect?

Thank you for your time.

[Pete Dowson]

Currently, I am not using a timer (sleep()) or anything to delay the main loop for another process.

So, basically, you are buzzing round trying to hog the processor with FS only getting a look in when you call FSUIPC_Process so that Windows can change processes? (Yes, I know it should change at timeslice intervals too, but it doesn't quite work as well as that often).

I can try that to see if I can normalize the frame rate. Do you have a suggestion for a sleep delay value? I'm currently frame locked at 20FPS in FS.

Since you certain shouldn't be trying to set LLAPBH values more often than once per frame, you should match FS's frame rate -- 20 fps means one loop per 50 mSecs, so you sleep for 50 mSecs less whatever time it takes to do whatever you do.

This would only be appropriate if your "loop" doing this is in a separate thread from your main Windows program. Otherwise it would be better to drive your code from something like a Windows timer (SetTimer API) so that your other duties as a Windows program are carried out properly -- stuff like processing paint messages, mouse messages etc etc.

So far the effect only happens when I do a read operation from the throttle offset (actually from any of the offsets) things are fine if I just Write to an offset(so far doing the forcing of pitch/alt/etc,.. seems to work fine and at the right frame rate).

Well I don't really understand that. Most programs do reads most of the time, and very few of them involve any processing in FS or FSUIPC, unlike most writes. I don't know of any other program having such a dramatic affect on performance.

I was also wondering if using the interface for Modules would be better - does this have an effect?

Erare you using an FS module for this? If so you MUST use the module interface, the other way is very inefficient from within the same process.

Regards,

Pete