Graphic jitters, FSX reading non mutex'd values?

[Simon853]

I'm using FSUIPC4 to slave FSX to a UAV control system, where FSX is being used to generate the camera view. It works really well apart from that I get regular graphic jitters.

I'm updating the aircraft position and virtual cockpit direction 20 times a second, and using the zoom function to zoom the "camera"'s field of view. When zoomed in to about FS's zoom level of 30 I regularly see the view jump for a frame before it snaps back. I've logged the values I'm setting and they're smooth. The problem is also noticeably worse if FSX is not the focused application, which indicates it's not a problem in the data.

What I'm wondering is whether FSX could be reading from the values as they're being written, and sporadically reading out invalid values as this occurs? The bad frames are only a fraction of a degree out though, so its probably a least-significant byte that's getting temorarily corrupted. (i.e. I never go from a stable view of the ground to a single frame of sky, it only jumps a small amount, but enough to be an annoyance when zoomed in looking at a building or vehicle.)

Any ideas?

Thanks,

Si

[Pete Dowson]

I'm using FSUIPC4 to slave FSX to a UAV control system, where FSX is being used to generate the camera view. It works really well apart from that I get regular graphic jitters.

I'm lost already. What's a "UAV control system"?

I'm updating the aircraft position and virtual cockpit direction 20 times a second, and using the zoom function to zoom the "camera"'s field of view. When zoomed in to about FS's zoom level of 30 I regularly see the view jump for a frame before it snaps back. I've logged the values I'm setting and they're smooth. The problem is also noticeably worse if FSX is not the focused application, which indicates it's not a problem in the data.

With the current FSX performance I'm rather surprised you get it as good as that sounds. Are you limiting FSX's frame rather to your data rate, to try to get the whole thing synchronised? How are you preventing FSX's own simulation engine moving the aircraft instead of you? Are you sure it isn't FSX trying to fly the aircraft too? Or are you setting it into slew, paused or zero frame rate mode?

What I'm wondering is whether FSX could be reading from the values as they're being written, and sporadically reading out invalid values as this occurs?

Sorry, I'm not sure what you mean there. But don't forget the SimConnect connection is aysynchronous, via TCP packets from FSX to SimConnect, then via Windows messages to the client (in this case FSUIPC4). And then, aynchronously again, via messages and (in a single core at least) process switches to your program.

You could eliminate some of that by writing your application as a direct SimConnect client, of course. I'm sure that's what Microsoft expected folks to do.

Regards

Pete

[Simon853]

Sorry, UAV is Unmanned Aerial Vehicle. (Think autonomous spy-planes..)

Since the movement of the aircraft is being controlled by a separate simulator, FSX is put into slew mode, and the aircraft's position is updated via FSUIPC4.

It doesn't really matter how frequenty I update the data. Running it anywhere between 2 and 20 Hz still gives an occasional flicker on the graphics. But if the actual update of the variables within FSX is down to MS's programming, rather than FSUIPC poking values in - which I had assumed, then I guess there's probably nothing I can do about it.

Thanks,

Si

[Pete Dowson]

FSX is put into slew mode, and the aircraft's position is updated via FSUIPC4.

It doesn't really matter how frequenty I update the data. Running it anywhere between 2 and 20 Hz still gives an occasional flicker on the graphics. But if the actual update of the variables within FSX is down to MS's programming, rather than FSUIPC poking values in - which I had assumed, then I guess there's probably nothing I can do about it.

Well, even if FSUIPC4 was "poking values" as it used to in previous versions of FS, there would still be some asynchronicity due to the nature of Windows messaging and process scheduling, but I guess the answer then would be to send the updates a *lot* more frequently than the FS frame rate, assuming this didn't cripple anything.

The problem with the greater separation from your program to the Sim is greater latency, and the possibility of queues "bunching" requests sometimes, with corresponding lapses in others. I would have thought that the use of the TCP stack for the communication between SimConnect and FSX would be a main source of such behaviour, and I did campaign against this. In fact I am still hopeful that some short-cut method will be found to speed things up.

At present, your best bet would be to try using the SimConnect interface directly. It won't bypass the TCP stack, but it would at least remove the message latency between you and FSUIPC.

Have you considered using FS2004 until the FSX performance issues and other bugs are resolved?

Regards

Pete