http://www.theinquirer.net/?article=21648
It's looking promising for the future of flight simms
;)
IS
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
...or lack of.
My real flying experience is limited to the Solar Wings Typhoon Mk1
see:
http://www.british-hang-gliding-museum.co.uk/acatalog/Online_Museum_Typhoon_196.html
..however, I'm surprised at the apparent lack of roll stability for the
C172P default aircraft in FlightGear.
Is the
* Andy Ross -- Tuesday 08 March 2005 19:52:
Indeed, there is no formatted text mechanism in Nasal right now.
Everything is printed to the precision of a full double.
I've added a rounding function to
http://members.aon.at/mfranz/flightgear/calctile.nas
that should be good enough for most
Time out here!
There are two reasons two throttle frame rate.
1. Conserve CPU time and leave more cpu time for other tasks. Using
sleep() calls you can put FG asleep for a short time if it gets done
drawing a frame early, leaving those cycles for other tasks.
2. Accurately control frame rate.
Quoting Curtis L. Olson :
Time out here!
There are two reasons two throttle frame rate.
1. Conserve CPU time and leave more cpu time for other tasks. Using
sleep() calls you can put FG asleep for a short time if it gets done
drawing a frame early, leaving those cycles for other tasks.
I wrote:
Maybe it is doable to sleep for a millisecond less than computed and achieve
the
targeted framerate with the loop.
Could you try this patch :
cvs -z4 -q diff -u main.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: main.cxx
Frederic,
Your patch helps, but typically the semantics of sleep() commands is
they will sleep at least as long as the requested time (up to the kernel
trap timing resolution) so I am still seeing dropped frames, although
not nearly as bad. If the kernel timing resolution is different than
Sorry to borrow this thread for my own purpose, but I'm trying to
achieve goal 1 with as little impact on goal 2 as possible. I tried
this patch with mixed results.
In Windows, adding this code did absolutely nothing to the processing
time...it remains at 99% usage whether I throttle back to 60,
Curtis L. Olson wrote:
Frederic,
Your patch helps, but typically the semantics of sleep() commands is
they will sleep at least as long as the requested time (up to the
kernel trap timing resolution) so I am still seeing dropped frames,
although not nearly as bad. If the kernel timing
Curtis L. Olson wrote:
Maybe we need separate options, such as
--cpu-friendly-inaccurate-throttle-with-sleep-hz= and
--frame-rate-accurate-throttle=
Thoughts? I think we need to tread a bit more carefully on this one,
especially since I have a side project that employs this option (well,
I asked:
What is the application that needs extra CPU, and are we sure that
it's not being performance limited in some other way?
Aha!
Drew wrote:
In Windows, adding this code did absolutely nothing to the
processing time...it remains at 99% usage whether I throttle back to
60, 30, or 1 Hz.
Wait, that's not a bug report about processing time available for
other proceses at all. That's a bug report about the total CPU usage
being at 99%, which is irrelevant. If the CPU is available, then of
course FlightGear should use it all; you can't save up cycles --
either use them now or
Drew wrote:
I don't think anyone suggested there was a bug...I'm just trying to
improve performance. I'm writing a simulator that interfaces with
FlightGear, using FlightGear as the scenery generator on the same PC.
The program runs great, it's just that FlightGear gets interrupted
easily by
Thanks for the quick response.
I have a specific application that requires better timing than sleep()
can provide, so I need the original busy-wait solution or something very
close to it. I don't mind adding a sleep() based throttling mechanism
as well, but people who use it need to realize
Drew wrote:
The program runs great, it's just that FlightGear gets interrupted
easily by other programs, and is jumpy in my particular application.
If you open and close a window, you can see how FlightGear freezes
momentarily.
I don't wonder, though, if that isn't due to locking inside GDI
I don't wonder, though, if that isn't due to locking inside GDI (or VM
swap -- how much memory do you have?) and not CPU usage. Applications
doing 3D rendering don't coexist well with things that need to draw to
the screen.
Can you try something purely CPU intensive (like a perl script
Drew wrote:
I don't know the answer to this. My computer has 512 megs, which is a
lot more than FlightGear uses.
I'm not really interested in how other 3D apps, including games,
work...I have a specific application, and I want to optimize the code
for this purpose, regardless of what the status
Frederic,
I've been hacking on your patch a bit more and I see that we rarely
oversleep by more than 2ms. So backing off by 2ms (instead of 1ms)
seems to work pretty well here. I also switched to doing all the math
in microseconds rather than milleseconds (and converting at the latest
Drew wrote:
I'm not really interested in how other 3D apps, including games,
work...I have a specific application, and I want to optimize the
code for this purpose, regardless of what the status quo is.
And the proper way to do that optimization is to figure out what the
actual symptom is.
Curtis L. Olson wrote :
Frederic,
I've been hacking on your patch a bit more and I see that we rarely
oversleep by more than 2ms. So backing off by 2ms (instead of 1ms)
seems to work pretty well here. I also switched to doing all the math
in microseconds rather than milleseconds (and
It seems to me that you have gone backwards: you picked a favorite
fix before knowing what the problem is. The bottom line is that
performance analysis is really complicated. You can't cook it down to
a single number like CPU usage (or load -- a equally flawed Unix
favorite) if you really
X-Plane opens in a 1024x768 borderless window, which doesn't fill my
laptop display at 1400x1050. However, when I reduce and restore
windows, I can tell that the X-Plane process preempts the windows
processes because the windows open slowly. X-Plane still yields some
time to the windows, though,
Felix wrote:
Hi,
I've successfully compiled Flightgear from CVS (thanks for the help),
but for some reason it won't run. FlightGear loads and all i see is a
Black screen with a white box in the middle (where the splash screen
should be). The CPU usage goes to 100% and stays there until i kill
23 matches
Mail list logo
