Driving an external system using FSUIPC

[glasseuph]

I am trying to create a program to read data from Flight Simulator 2004 and then drive an external visual system. I need things like attitude, altitude, airspeed, engine parameters, gps data, etc....

I am concerned with update rates to my visual system. What types of update rates can I expect from FSUIPC. Since I will be reading a lot of data from FSUIPC and it appears the data I will need is scattered throughout the offset table, I was wondering if it would be faster to read individual items calling FSUIPC_Process() after each item or reading all the data and then calling FSUIPC_Process().

The computer I will be using will have at least the following specs:

2Ghz processor

1G ram

High end video card

Thanks for all your help.

[scruffyduck]

use many read requests and one process request.

Pete will advise but my undersatnding is that FSUIPC operates at the framerate of the host FS system so you could read that many times per second. I read a lot of positional and aircraft data in my program and do it twice per second on a 2.6GHz machine with no problems to date and this give a pretty smoot output on my display window

[Pete Dowson]

I am concerned with update rates to my visual system. What types of update rates can I expect from FSUIPC.

FSUIPC can supply distinct data for everything that changes in each frame at the frame rate. Somethings it could supply more often, but there's little point -- if the frame rate is so horrendously low you wouldn't be able to run anything fast enough to get the data faster in any case.

Since I will be reading a lot of data from FSUIPC and it appears the data I will need is scattered throughout the offset table

I wouldn't worry about that -- even data adjacent in the table is often scattered in wildly different places inside FS. The contiguity you see is an illusion.

I was wondering if it would be faster to read individual items calling FSUIPC_Process() after each item or reading all the data and then calling FSUIPC_Process().

Each Read or Write call merely adds the request to data internal to your program. That is negligible in terms of performance, a few nanoseconds at most. Every Process call is a process change, a message in a message queue, an interruption. You want as few of those as possible.

Therefore do all the reads and writes you want, per frame, then issue the Process call. One such call per frame. Time your loop to approximate the frame rate in FS -- you can regulate the latter using the Frame rate Limiter in FS.

The computer I will be using will have at least the following specs:

2Ghz processor

2Ghz is okay for FS2004 as long as you don't turn things up full. I use a 3.2 Ghz P4 and an Athlon 64 FX 53 -- the latter is super, but even the 3.2 is stretched.

Regards,

Pete

[glasseuph]

Thanks to both scruffyduck and Pete.

Your comments were along the lines I was hoping for. Just for a little more clarification, what approximate time duration should I expect from the time I issue a FSUIPC_Process call to the time it returns and my variables have been updated?

One last thing, this might be trivail but how do I setup the frame rate liminitor in Flight Simulator? Also, if my software is not synced up with the frame rate in flight simulator will there be any adverse effects. Meaning, if I am calling my loop faster than the frame rate what will happen. My guess would be that I would be bogging down my application since it would have to wait for FSUIPC_Process to return, which will only return in a one-to-one relationship with the frame rate. I would assume if my application was running slower than the frame rate I would possibly end up with jerky display.

Thanks again.

[Pete Dowson]

Your comments were along the lines I was hoping for. Just for a little more clarification, what approximate time duration should I expect from the time I issue a FSUIPC_Process call to the time it returns and my variables have been updated?

Hmmm. That's a "how long's a piece of string?" sort of question. From the time FSUIPC actually receives the message (which is via the FS message queue) to the time it exits the Message procedure having filled in your data will, for reads only, be much less than a millisecond (it gets difficult to quantify such values).

However, the time for Windows to place the message in the correct queue, process change from your program's process to the FS process, then for FS to reach that message in the queue along with all the other messages it deals with, then for Windows to change from the FS process back to yours -- is unpredictable, and, what's more, will vary from time to time depending upon all sorts of other things going on on the system.

If you are using Win98don't. Its multiprogramming is simply not good enough.

If you are using WinXP, then it's good enough at multiprogramming and timeslices quite fairly. But some time do a CTRL_ALT_DEL and take a look at the list of processes awaiting attention.

In other words, it's a very complex system. I'm afraid there's no guarantees.

One last thing, this might be trivail but how do I setup the frame rate liminitor in Flight Simulator?

Check the menus. Options-Settings-Hardware-Display.

Also, if my software is not synced up with the frame rate in flight simulator will there be any adverse effects.

It may appear more jerky than it should. Obviously, for smoothness you want your visuals to be timed the same as FS's would-be visuals.

Meaning, if I am calling my loop faster than the frame rate what will happen. My guess would be that I would be bogging down my application since it would have to wait for FSUIPC_Process to return

Since your process isn't running after you call FSUIPC_Process, until it returns, that question cannot arise, at least not in that form -- unless you are multi-threading. But you don't want to multi-thread calls to FS. That makes things worse, not better.

If you get results too often they won't have changed so you'll not only waste processor time but produce micropauses, too infrequently and you'll miss some intermediate values and get jerks.

Regards

Pete