Frame rate drop after FSUIPC_Process()

[raefly]

I have written a small application (using Borland C++) that uses FSUIPC to write the following parameters into FS9 :

FSUIPC_Write(0x238, 1, &upHour, &dwResult)

FSUIPC_Write(0x23B, 1, &upZulu, &dwResult)

FSUIPC_Write(0x23E, 2, &upDay, &dwResult)

I then call :

FSUIPC_Process(&dwResult)

to update the sim with the parameters. This all works okay, however, I am finding that after the Process call, the frame rates drop significantly (1-3fps in some cases, but in general to about 30% of value prior to calling FSUIPC_Process).

As a newbie, I fear that I may be forgetting something, but even after killing my application, the frame rates do not improve.

Does anyone have any ideas or experience of this?

Thanks,

Richard

[Pete Dowson]

I have written a small application (using Borland C++) that uses FSUIPC to write the following parameters into FS9 :

FSUIPC_Write(0x238, 1, &upHour, &dwResult)

FSUIPC_Write(0x23B, 1, &upZulu, &dwResult)

FSUIPC_Write(0x23E, 2, &upDay, &dwResult)

I then call :

FSUIPC_Process(&dwResult)

to update the sim with the parameters. This all works okay, however, I am finding that after the Process call, the frame rates drop significantly (1-3fps in some cases, but in general to about 30% of value prior to calling FSUIPC_Process).

As a newbie, I fear that I may be forgetting something, but even after killing my application, the frame rates do not improve.

When you change the time, and especially the date, FS will load new textures and so on and this may affect frame rates. If you change the data back to where it was before do the frame rates revert?

FSUIPC isn't doing anything when you are not calling FSUIPC_Process, and in fact when you do in the above case it is only writing those three locations. There's no magic or other activity started up.

It has to be something to do with the change in time or date. Try a process of elimination -- choose somewhere else to write to, then add one only of each of the writes above in turn. The one which I would be most suspicious of is the change of date, as there are quite a few programs which can change the time without a problem (eg FSRealTime).

Regards,

Pete

[raefly]

Pete,

I appreciate you responding as your suggestions have already helped me find a compromise.

Test 1 : No use of FSUIPC and manually changing the time within FS9

Result : LITTLE CHANGE IN FRAME RATES. FPS=12

Test 2 : Only change the local hour using FSUIPC i.e.

FSUIPC_Write(0x238, 1, &upHour, &dwResult) followed by

FSUIPC_Process(&dwResult)

Result : The environment time is not updated but going into the World-Time menu, it can be seen that a new local time has been written. Only when pressing "OK" are new scenery objects etc. loaded and the environment time is updated to reflect the FSUIPC written local time. (Going back into the World-Time menu, it can be seen that a new Zulu time was also calculated to reflect the FSUIPC written local time.). LITTLE CHANGE IN FRAME RATES. FPS=12

Test 3 : Only change the zulu hour using FSUIPC i.e.

FSUIPC_Write(0x23B, 1, &upZulu, &dwResult)

FSUIPC_Process(&dwResult)

Result : Unlike in test 2, the environment time is automatically updated on loading FS9 to reflect the FSUIPC written zulu time. IT IS HERE WHERE THE FRAME RATE DROP OCCURS. FPS=4.5. Changing the time back manually in the World-Time menu resolves the frame rate problem which returns back to around FPS=12

Conclusion : I will adopt the result from test 2, i.e. use FSUIPC to write in a local time (based on a calculated zulu time) and then manually refresh the environment time within FS9 by going into the World-Time menu and pressing OK. I was previously writing local time, zulu time and the date which produced the same result as in test 3 i.e. a frame rate drop. The advantage of writing in zulu time with FSUIPC is that the environment automatically refreshes on FS9 startup but with the frame rate drop.

Note : I installed FSRealTime to check its effect and realised it was also causing the frame rate drop, so it must be writing in zulu time (followed by the automatic FS9 refreshing). I do not think that writing the zulu time is causing the frame rate drop (as simply performing

FSUIPC_Write(0x23B, 1, &upZulu, &dwResult) with no

FSUIPC_Process(&dwResult)

has no effect) but rather that the frame rate drop is due to the effect that writing the zulu time has on causing the sim to automatically reload the environment.

[Pete Dowson]

Test 3 : Only change the zulu hour using FSUIPC i.e.

FSUIPC_Write(0x23B, 1, &upZulu, &dwResult)

FSUIPC_Process(&dwResult)

Result : Unlike in test 2, the environment time is automatically updated on loading FS9 to reflect the FSUIPC written zulu time.

I don't understand where you can "load FS9" here -- if it isn't running already you can't use FSUIPC. What is it you actually mean?

IT IS HERE WHERE THE FRAME RATE DROP OCCURS. FPS=4.5. Changing the time back manually in the World-Time menu resolves the frame rate problem which returns back to around FPS=12

12 fps seems extremely low in the first place. Is that the sort of frame rate you normally get?

I cannot imagine what is happening with this time discrepancy to cause FS to slow down, but you could try sending it the Scenery Reload control via the FSUIPC interface too. Maybe that would do the same as "OKAYing" in the Time menu.

I will adopt the result from test 2, i.e. use FSUIPC to write in a local time (based on a calculated zulu time) and then manually refresh the environment time within FS9 by going into the World-Time menu and pressing OK.

If you are going to go into the time menu in any case, why not change the time there? Or am I missing something here?

the frame rate drop is due to the effect that writing the zulu time has on causing the sim to automatically reload the environment.

But that is a temporary affair. Of course there will be a frame rate drop whilst it is changing the textures, the shadows and so on. (You can reduce this somewhat by turning shadows off). I thought you were implying that there was a permanent drop? If there is, how do you explain that, other than your different time textures are more massive or cause some extra graphics workload?

I must admit I am finding all this rather mystifying.

Regards,

Pete

[raefly]

Hi Pete,

Thanks for checking my post again. Apologies for not explaining clearly. When I talk about loading FS9, I have a DOS compiled C++ executable which I use to set things up for me before loading FS9 e.g. it writes out a fs9.cfg file with the correct situation I want to load. It also calls the fs9.exe file once I am ready to start and once FS9 has loaded, it also writes the correct zulu time based on my system time. The idea behind this is that I don't have to load/set things time etc. once FS9 has started which I find is more time consuming. Furthermore, I want to eventually expand on this front end e.g. to build a world map from which to select situation files etc.

Re the frame rates, well I normally have well over 20fps (3.2 GHz, ATI 9800Pro, 1GM DDR500 RAM) but I have all sliders full, am using UT at 100% AI aircraft and Simflyers scenery in this particular case.

I found that scenery reload (to which I have assigned the TAB key) does not have the same effect as going into the World-Time menu and then "OK" to get out - surprised me as I tried this to avoid going into the World-Time menu seeing as I want to avoid setting things in the sim in the first place, but a quick "ALT W T ENTER" keypress takes an instant - hence the satisfactory compromise for me.

To come back to the frame rate drop, indeed it is permanent i.e. when using FSUIPC to write only the zulu time and then to process it with FSUIPC_Process(&dwResult), the sim automatically reloads - once the sim has reloaded I realise there is a permanent frame rate drop. This is not however the case when writing only the local time and processing it with FSUIPC_Process(&dwResult). In the latter case, the sim does not automatically reload and one has to go into the World-Time menu (where one notices the updated local time) and then press OK to make it reload. After this reload, no frame rate drop is noticed.

I was surprised by this as it tells me that irrespective of the time textures and AI traffic that are loaded for a given time, the resulting frame rate differs between writing & processing only the zulu time as opposed to only the local time.

Pete, I appreciate you taking the time to read through this long post.

Regards,

Richard

[Pete Dowson]

I have a DOS compiled C++ executable which I use to set things up for me before loading FS9 e.g. it writes out a fs9.cfg file with the correct situation I want to load. It also calls the fs9.exe file once I am ready to start and once FS9 has loaded, it also writes the correct zulu time based on my system time.

Two points there:

1. You can set an option in FS to use the system time instead of the Flight time. Have you tried using that?

2. In any case, it would surely be more effective to write the time you want it to load with into the default FLT file?

To come back to the frame rate drop, indeed it is permanent i.e. when using FSUIPC to write only the zulu time and then to process it with FSUIPC_Process(&dwResult), the sim automatically reloads

Ah .. this is what you meant by "load FS" -- the reloading of the textures? This is not an FS reload as such. It has to reload the textures because they change according to time.

- once the sim has reloaded I realise there is a permanent frame rate drop. This is not however the case when writing only the local time and processing it with FSUIPC_Process(&dwResult). In the latter case, the sim does not automatically reload

No, you have to change both local and zulu time, not just one or the other. Maybe you are not getting them in correct synchronisation?

Regards,

Pete

[raefly]

Hi Pete,

I don't want to start the sim with system time e.g. my system time now here in Hamburg is 19h15 or 17h15 zulu. Say I start a flight now in Memphis, I want the situation to load with the local time there now i.e. some time after noon (I don't know the time difference offhand) and not at 19h15. The only way to do this with FS9 at the moment (assuming I load a situation file where I am in Memphis) is to go into the World-Time menu and change the zulu time to 17h15 (as the sim either would start at system time i.e. 19h15 or at the flight time when the FLT file was created).

Your tip to write the local Memphis time into the FLT file and then load FS9 is very useful - however, unless I have a table of time differences telling me the offset of Memphis time from zulu time, I won't know how (what time offset) to calculate the local Memphis time.

Hence, in order to obtain this offset, I load FS9, it starts in Memphis with my system time at 19h15. I can then through FSUIPC (or of course World-Time menu) read the zulu time which would be some time in the morning and calculate the offset. This all works fine. I then want to start the process of writing new times and refreshing the sim environment so as to reflect the correct local time in Memphis and to have the sim running with the correct zulu time i.e. 17h15. Instead of using FSUIPC to write the updated times, I could, using your suggestion, then write a new FLT file with the correct Memphis time (now that I have the time offset) and reload/refresh the sim - can I force a reload of a FLT file using FSUIPC?

To answer your question about the "loading" - yes, that's right - reloading of textures. This happens automatically when using FSUIPC to write the zulu time (followed by FSUIPC_Process() of course) - but is accompanied by a permanent frame rate drop. When only writing and processing the local time with FSUIPC, no automatic reload occurs and one must make it reload by going into the World-Time menu-after reloading, no frame rate drop is noticed! When writing and processing both local and zulu time, one has the same scenario as when only writing/processing zulu time i.e. automatic reload but the mysterious (permanent) frame rate drop. This I have also noticed when using FSRealTime. So to avoid the frame rate drop, the compromise is to only write the local time and make the sim reload (i.e. through World-Time menu or the quick "ALT W T ENTER" keypress).

But, I would like to try the option of using FSUIPC to force a reload of the FLT file - which offset do I use for this? (I see there is 3F00 for reload flight and 3F04 for path select - will try this)

It's been a good week so far - thanks for the chat Pete.

Richard

[Pete Dowson]

Say I start a flight now in Memphis, I want the situation to load with the local time there now i.e. some time after noon (I don't know the time difference offhand) and not at 19h15. The only way to do this with FS9 at the moment (assuming I load a situation file where I am in Memphis) is to go into the World-Time menu and change the zulu time to 17h15 (as the sim either would start at system time i.e. 19h15 or at the flight time when the FLT file was created).

Oh, rightif I wanted to do that sort of thing I'd use the original Setup menu FS faces you with by default on loading -- you can select airport, aircraft, time, weather, etc there.

can I force a reload of a FLT file using FSUIPC?

There's a facility for loading a flight by name, and you can read the name of the current FLT too, so you can do it that way, or you can send the appropriate FS control to do it. But whether FS will use a cached copy of the file or re-read it from disk I don't know, you'd need to test it.

To answer your question about the "loading" - yes, that's right - reloading of textures. This happens automatically when using FSUIPC to write the zulu time (followed by FSUIPC_Process() of course) - but is accompanied by a permanent frame rate drop.

Odd, that -- this is with both Local and Zulu time adjusted? Did you try also updating the time difference at 0246? I really have no idea what FS is doing to slow itself down, but possibly it is somehow confused?

Try also to ensure that all the changes are written together.

When writing and processing both local and zulu time, one has the same scenario as when only writing/processing zulu time i.e. automatic reload but the mysterious (permanent) frame rate drop. This I have also noticed when using FSRealTime.

I've just tried it, and you are correct, there is a drop ..though it seems to slowly pick up again here. However, it should not drop in the first place. This is new, I think, with FS2004. I wonder if it is trying to handle both sets of textures. Maybe it needs the earlier ones "cleared" first, somehow. I might look into this more when I get some time. Seems rather odd.

But, I would like to try the option of using FSUIPC to force a reload of the FLT file - which offset do I use for this? (I see there is 3F00 for reload flight and 3F04 for path select - will try this)

There's also a control (the one usially assigned to CTRL+;) -- SITUATION_RESET. I don't know if that will reload the file from disk though. You can send controls through the FSUIPC interface.

Regards,

Pete

[Pete Dowson]

I've traced through what happens when you confirm a time change in the FS2004 dialogue. it seems it broadcasts a message through the chain system inside FS. I've identified the correct chain and message, and I have modified FSUIPC so, if I detect a change made to offset 023B, I send the same broadcast message.

This seems to stop that frame rate slow down.

I think, without the broadcast, there are parts of FS still working on the unchanged time of day, possibly duplicating textures or similar.

This change will be in version 3.22 of FSUIPC, which I plan to release before the weekend, with luck.

Regards,

Pete

[raefly]

Pete,

Just wrote the FLT file path and forced a reload with offsets 3F04 and 3F00 respectively, so that FS9 now loads the correct zulu time (as written into the FLT file after the correct offset has been determined) and there is no frame rate drop. So obviously, reloading an FLT file sends the appropriate broadcast message through the chain system as expected, which you describe, avoiding any loose, unwanted processes still working.

Thanks for making the adjustment in 3.22 - will try writing the zulu and local times, as before, when you release it and see if the frame rate issue still exists. The effect was probably more pronounced when starting off with low frame rates such as in my Simflyers/UT/full sliders scenario.

Thanks for all your support Pete,

Richard

[raefly]

Pete,

Just tried out writing the zulu and local times using your new version 3.22 and I am not getting the frame rate drops experienced before.

Thanks for the update,

Richard