1
0
Fork 0
Commit graph

6 commits

Author SHA1 Message Date
curt
2c20e61b4b Removed some extraneous debugging output. 2003-03-09 12:48:29 +00:00
david
4b78f5305f Ignore generated files. 2003-03-09 03:21:34 +00:00
curt
92cfd383d6 Remove std:: 2003-03-04 00:25:35 +00:00
curt
11e0a3b1f8 Don't remove the named pipe on a "Reset" or position change (i.e. when
FGExternalPipe is destructed.)  This leaves the name pipe hanging around
even after flightgear exits, but assuming we put the files in /tmp that
shouldn't be a big deal.
2003-03-03 17:48:09 +00:00
curt
dbf7218c63 A small optimization, pass the number of iterations to the remote end and
have it do all the work, rather than calling the remote end "iteration"
number of times.
2003-03-03 04:59:41 +00:00
curt
cc269730a5 First stab at a "named pipe" interface to an external FDM. Compared to the
ExternalNet interface:

- allows a much more closely coupled execution.  A remote network FDM will run
  at it's own rate, and maybe a particular data packets will come, maybe it
  won't.  This makes it very hard to control timing and keep the animation
  smooth.  There are also cpu scheduling issues with running multiple
  processes on a single machine.  The linux scheduler by default runs at
  100hz.  If an FDM process uses a sleep/alarm system to avoid wasting
  CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc.  This
  makes it *impossible* to serve a display system running at 60hz without
  dropping frames.

- the downside is that the FDM process must now run on the same machine as
  the master flightgear process.
2003-03-03 04:30:16 +00:00