Event driven, polling etc.

[metalnwood]

Hi all, I haven't done any pc development for a long, long time. I am now writing some software to talk to fsx and the chosen language is C# as it's the closest to java which I have been using for a long time as well.

I know there is a java interface to fsuipc but I am not planning on using it as I know it's going to be easier to distribute an app based on c#.

For the last 8-10 years working with java most systems have been event driven in the areas that I work. I have been working with simconnect which is also event driven, like the lua plugin you register an interest in an event and your code is called when something happens. I am looking to move from simconnect to fsuipc and it seems the general practice is to poll for the information. So I have a couple of questions based on my possibly antiquated ideas of how polling was bad way back :)

I have looked through the posts and documentation but I haven't seen any guidance on the subject. I want to poll for changes in most of the switches, all the autopilot, com, nav, transponder, dme displays/knbos/buttons etc. This adds up to a lot of different things to monitor.

Performance is what I am worried about - there may be nothing to worry about, I don't know yet. Would it be advisable to get all the information every time or break it up in to groups, e.g. get the radio displays every 200ms and the lighting panels every 500ms as they are less often used and it wont matter so much if my external screen is out of sync for that much longer. I have read that one call with many vars is better, but up to a certain point?

With simconnect I know when something has changed because I get an event, I then read the value and pass it off to my display. Is the standard practice with fsuipc to keep a copy off all values in your app and compare with every polling cycle, I haven't seen if there is a different way.

Sorry, this has turned in to a longer post then I expected but I want to start the right way from the beginning.

Thanks,

Jason

[Pete Dowson]

I am looking to move from simconnect to fsuipc and it seems the general practice is to poll for the information.

This is only because the original IPC interface, designed by Adam Szofran way back in FS95 days, worked that way. When he stopped development after FS98 (moving on to work for the Microsoft FS team) I continued the same interface with the sole intention of getting all my FS6IPC-interfacing programs working on FS2000. And so it has gone -- no chance, or no point, in changing the interface because it's main purpose is for continued compatibility.

I have looked through the posts and documentation but I haven't seen any guidance on the subject. I want to poll for changes in most of the switches, all the autopilot, com, nav, transponder, dme displays/knbos/buttons etc. This adds up to a lot of different things to monitor.

Yes, but if you read them all in one request they aren't any more inefficient than a single item.

Performance is what I am worried about - there may be nothing to worry about, I don't know yet. Would it be advisable to get all the information every time or break it up in to groups

All in one request per cycle. The difference in the transfer of 1 byte or 4000 bytes, or whatever, is negligible. The cost is the process switching and message processing. You only want to do that once per cycle. You do all the "FSUIPC_read" calls (and "FSUIPC_write" is any), in the order you need them, then call "FSUIPC_Process" once, per cycle. Only the Process part takes any time -- it has to send a message and wait for a response.

e.g. get the radio displays every 200ms and the lighting panels every 500ms as they are less often used and it wont matter so much if my external screen is out of sync for that much longer. I have read that one call with many vars is better, but up to a certain point?

Well, you could only add such calls to the process at sparser intervals -- the main point is to only do one process call per cycle. The "point" at which the amount of data in a single call becomes noticeably slower is quite high.

With simconnect I know when something has changed because I get an event, I then read the value and pass it off to my display. Is the standard practice with fsuipc to keep a copy off all values in your app and compare with every polling cycle, I haven't seen if there is a different way.

If updating your display costs performance then by all means only do it when it changes, but yes, your understanding is correct. I do this in my PFC display drivers.

Regards

Pete

[metalnwood]

Thanks Pete, thats fine. Happy to know I was on the right track. Now, back to the code.

Thanks,

Jason