FS2004 / FSUIPC 3 to drive FS

[pub00515]

Hi folks!

I want to write a small program that will drive FS via UDP from a different FS.

My question is, is FSUIPC fast enough to render smoothly (provided the data comes in fast enough).

My program will be a simple FS DLL that has a second thread reading/writing FS's lat, lon, alt, pitch, bank and heading.

Would this work ok?

Thanks for any hints!

Oh and I'd be happy to release this as freeware / open source if it works out well :D

Mark

[Pete Dowson]

is FSUIPC fast enough to render smoothly (provided the data comes in fast enough).

It isn't whether FSUIPC is fast enough, it's the frame rate you can achieve in FS. FSUIPC cannot feed data into FS faster than its frame rate and to try to do so merely has the opposite effect.

There are only two areas of overhead in this interface - first is process switching, if you have the interfacing program running in the same PC. The other is simply the normal Windows message queuing system, which can also of course sometimes defeat they synchronicity.

>> My program will be a simple FS DLL that has a second thread reading/writing FS's lat, lon, alt, pitch, bank and heading. <<

Having it as an FS DLL helps reduce the process switching overhead, and by using the module access method you avoid the message queuing problems, mostly, too.

But take care not to introduce stutters in FS by using its processing slot too much. Your "second thread" should be the main thread -- i.e. the same one as FSUIPC and most of FS is running in, otherwise you won't be able to lock into the frame rate and there may well be other problems if you manage to make FSUIPC try to use non-re-entrant parts of FS from the wrong thread whilst they are being executed from the main one.

Make the UDP part the separate thread.

Regards

Pete

[pub00515]

Hi Pete,

thanks for your answer! I've been playing around for a bit and I see your point about writing too often (I'm already using the module access method)

FS indicates ~ 40 fps and writing values at ~ 25 Hz was pretty jerky.

How would I be able to lock onto FS's thread Is there a way to get FS to call a callback function in my dll at its internal rate? ('m new to the FS SDK and getting my DLL to load was already a little work :) )

Thanks!

Mark

[Pete Dowson]

thanks for your answer! I've been playing around for a bit and I see your point about writing too often (I'm already using the module access method)

FS indicates ~ 40 fps and writing values at ~ 25 Hz was pretty jerky.

Well, that's not so much "too often" as "off the beat". If you are writing comfortably at 25 try limiting FS's frame rate to 25. Really the main enemy you have is FS's own simulation engine trying to do its thing -- every beat you miss it will fill in. You are fighting it all the way.

I think the usual way to get things smooth is to defeat the sim engine by putting FS into slew mode, or possibly pause mode. If you only want the views not the gauge readings then either might work better for you. Another alternative is zero sim rate (actually setting the sim rate value to 0).

Otherwise you have to beat the Sim Engine into submission by matching the frame rate, and one way to do that is to limit FS's. This also has the good side effect of generally making it more constant, easier to match.

How would I be able to lock onto FS's thread Is there a way to get FS to call a callback function in my dll at its internal rate? ('m new to the FS SDK and getting my DLL to load was already a little work :) )

There are ways but they involve hacking to hook into the right routines, and they are different in each version of FS. Best these days to use FSX -- then you get official SimConnect support for all this stuff. There are no SDKs for DLLs in FS2004 or earlier.

Regards

Pete