Jump to content
The simFlight Network Forums

roch

Members
  • Posts

    2
  • Joined

  • Last visited

About roch

  • Birthday 01/01/1970

Contact Methods

  • Website URL
    http://rosich.da.ru

roch's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Pete, Thanks for a prompt answer. You made the general picture clearer, although leaving it up to me to figure out the details. If it wasn't unclear from my questions, I am not writing an MSFS module, but connecting external program (i.e. aircraft simulation compiled to standalone executable). I used the word "module" just as a general term for any software module - as you suggest, I may try multithreading as well. Also, if you wonder, I use FS2004. I can make my simulation unaffected by delays caused by writing data to FSUIPC, but then, the question is - citing you: "how to ensure smothness, no jerks and stutters". I get that this is the problem that many people have (like scottme in this thread). Why can this happen: external simulation runs smoothly, framerate that MSFS displays is somewhere around 45 fps, but the plane is jerking back and forth (slew mode is on)? The same thing with slew mode off. What can be wrong? Ordering of the data? MSFS overwriting the values? I don't have such problems when using Flight Video (i.e. making the MSFS to playback the data stream in FSR format that I feed from my simulation). I also don't succeed in getting correct display of airspeed and vertical speed in the cockpit, although I write them to correct offsets. Any ideas? Thanks once again, Alexei
  2. Hi all, This is a useful thread, so let me revive it once more. I also work on real-time simulator based on Simulink 6DoF model and MSFS's visualization. At present, I run both the simulation target and the MSFS on the same machine under Win2k. Since I am using generic real-time target, I am trying to achieve "soft" real time by synchronizing the simulation with the system clock. Up to now, I used, with relative success, the "Flight Video" feature of MSFS for driving the aircraft position and other data. On my modest machine (PIV 2.4, 512Mb RAM, FX5200) I am able to keep up with real time at integration step of 5ms (or even less) and FS running at 25-40 fps. As you see, simulation step and FS frame updates are NOT synchronized. However, it is essential to send data to FS at as high rate as possible (as I try to increase the step I get the unexpected result of ruining the MSFS performance). Up to now this was an introduction. It would be interesting to know if anybody has similar experience, but I came to this forum because of FSUIPC. So far, very few people use "Flight Video" that was described in the Netpipes SDK from MS. FSUIPC is far more popular and has some capabilities that "flight video" doesn't - like bilateral communication, more comprehansive set of parameters, and, as I hoped, better performance. The question is, whether it is suitable at all for real-time applications. As I see in the FSUIPC SDK sources, what is FSUIPC_Process doing is sending message to FSUIPC and waiting 100 ms - and so up to 10 times. So, retrying sending the message introduces huge delays to simulation. It would be good to know several things: how often such retris may happen? How long takes SendMessage itself? What is the actual time that processing write request may take? How is synchronization with FS frame rate done? Finally, is there any sense in sending data to FSUIPC at a rate higher than FS frame rate? Since calls to FSUIPC directly from the simulation block the execution, I see the only solution in writing another module that will be able to receive data from simulation at some fixed rate without blocking the simulation and feeding data to FSUIPC as it is ready to receive it. I'll appreciate any advice. Alexei Rosich
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.