I use a Saitek Cyborg 3D Rumble Force, and it is better than any other PC joystick I
have used (not that many in the comparison group though, and no MS products).
OK, so the rumble effect doesn't get used in FG, but it is a very nice indication of
WOW in IL2, and if plib ever gets to support
I know if I add a totally new airport I have to re-generate the scenery...
If I want to add taxiways to an existing airport can I just edit the airports
file, default.apt.gz?
TIA
WillyB
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
WillyB writes:
If I want to add taxiways to an existing airport can I just edit
the airports file, default.apt.gz?
No, you still need to regenerate scenery.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run
FlightGear on this machine. This won't work out as long as most of the
processing in FlightGear is done in a single thread because each of the
CPU's is not that fast.
As Curt is moving lots of code around to make
Martin Spott wrote:
I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run
FlightGear on this machine. This won't work out as long as most of the
processing in FlightGear is done in a single thread because each of the
CPU's is not that fast.
Things that come in mind are:
*
Martin Spott wrote:
I'm about to purchase a used 8-way RS/6000. Coltish as I am
I'd like to run
FlightGear on this machine. This won't work out as long as
most of the
processing in FlightGear is done in a single thread because
each of the
CPU's is not that fast.
Things that come
Erik Hofman writes:
Martin Spott wrote:
I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run
FlightGear on this machine. This won't work out as long as most of the
processing in FlightGear is done in a single thread because each of the
CPU's is not that fast.
Curtis L. Olson wrote:
Erik Hofman writes:
* Sound thread (should be fairly easy)
* FDM thread/process
* Maybe (just maybe) an I/O thread?
But I guess that's about it.
Personally, I'm not a huge fan of threading unless absolutely
necessary. Threading adds a tremendous amount of complexity,
On Tue, 24 Jun 2003, Erik Hofman wrote:
Martin Spott wrote:
I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run
FlightGear on this machine. This won't work out as long as most of the
processing in FlightGear is done in a single thread because each of the
CPU's is
On Tue, 24 Jun 2003 07:46:39 -0500
Curtis L. Olson [EMAIL PROTECTED] wrote:
[snip]
Think about this another way ... do a profile of flightgear. I bet
you will find that the graphics rendering portion of FlightGear takes
90-95% of the entire application work load. If you can't find a way
On Tue, 24 Jun 2003, Curtis L. Olson wrote:
I'm not quite sure how threads can help, except possibly with the
simulation of hundreds of aircraft at once?
In the case of simulating 100's of aircraft, threads might provide a
convenient programming abstraction, but they would add the
Bernie Bright wrote:
For the record, the top 20 functions as reported by oprofile-0.5.3 are:
The problem is that (as Norman pointed out in the past) optimizing may
result in a much larger increas in framerate due to the way OpenGL can
handle processor and graphics tasks simulataniously.
Cpu
Lawrence Manning writes:
It would be interesting to do some tests in wireframe mode on a low spec
machine and see how it performs?
I think you wil find that wireframe mode is slower
esp if you turn off the cloud textures
Norman
___
Lawrence Manning [EMAIL PROTECTED] wrote:
It would be interesting to profile fg and determine exactly where the time
is spent. I'd guess that even a low spec machince could handle the
simulation aspects of the program; is it not the the rendering that
consumes the majority of the
Norman Vine writes:
Curtis L. Olson writes:
Think about this another way ... do a profile of flightgear. I bet
you will find that the graphics rendering portion of FlightGear takes
90-95% of the entire application work load.
FWIW here are my results from the last time I profiled
Martin Spott writes:
This was my initial thought when I bought an SGI Octane with bells 'n
whistles. But I was proven to be wrong. Erik's O2 is definitely faster with
FlightGear even though the O2's graphics subsystem is much slower. This is
hardly texture-related, his machine simply has the
Melchior FRANZ [EMAIL PROTECTED] wrote:
The keyboard settings should eventually be organized hierarchically:
1. global keyboard.xml: defines stuff that matters to (almost) all
aircrafts: (Esc-Quit; g/G-gear; f/F-flaps; ...)
Oh yes, I'd definitely support this idea. Does anyone have a
Curtis L. Olson writes:
Norman Vine writes:
Curtis L. Olson writes:
Think about this another way ... do a profile of flightgear. I bet
you will find that the graphics rendering portion of FlightGear takes
90-95% of the entire application work load.
FWIW here are my
Norman Vine writes:
Note fgUpdateTimeDepCalcs() and fgMainLoop() are *only* called after
all initialization is done, so if anything, they actually consumed a bit more
then their recorded usage time whereas fgRenderFrame is the opposite :-)
True ... what I was trying to communicate is that if
The structure is defined in src/Network/net_ctrls.hxx
Regards,
Curt.
Martin Spott writes:
I'm currently trying to 'reverse engineer' the native-ctrls wire format by
writing to a file:
--native-ctrls=file,out,10,Bla
This is quite interesting, but far from being 'readable' :-) Aside
Curtis L. Olson wrote:
True ... what I was trying to communicate is that if something like a
property string fetch shows up high in list of time consuming function
calls, we don't necessarily know if most of those calls were made
during initialization where it doesn't really matter, or during the
Martin Spott [EMAIL PROTECTED] wrote:
Sincerely there are more urgent jobs to do - enabling flying below bridges
or through the Sutro tower, for instance ;-))
I have to correct this statement: It _is_ possible to fly through the Sutro
tower, but it's not that easy to view from inside the
Lawrence Manning writes:
Well, with threads you can spread the load across CPUs. So it is not just
a convience for the programmer. Afterall, the original poster bought up
the matter of big boxes with lots of slow processors.
Right, but we should also bear in mind the a) typical flightgear
Erik Hofman writes:
Curtis L. Olson wrote:
True ... what I was trying to communicate is that if something like a
property string fetch shows up high in list of time consuming function
calls, we don't necessarily know if most of those calls were made
during initialization where it
Curtis L. Olson wrote:
Did anyone say if this multi-cpu machine had an accelerated opengl
graphics system? If it doesn't then this whole discussion is
pointless. :-)
Maybe not, threaded MESA?
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Curtis L. Olson [EMAIL PROTECTED] wrote:
The structure is defined in src/Network/net_ctrls.hxx
Yep, I already read this, but I'm not shure about the the data format of the
values I have to put in there.
I assume the bools have exactly one bit anytime but how large are the
variable values
Erik Hofman wrote:
I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like
to run
FlightGear on this machine. This won't work out a
Things that come in mind are:
* Sound thread (should be fairly easy)
* FDM thread/process
* Maybe (just maybe) an I/O thread?
Hmm, either an I/O
Martin Spott writes:
Yep, I already read this, but I'm not shure about the the data format of the
values I have to put in there.
I assume the bools have exactly one bit anytime but how large are the
variable values or with other words: Won't I have to worry about the
platform
Curtis L. Olson writes:
Erik Hofman writes:
Curtis L. Olson wrote:
True ... what I was trying to communicate is that if something like a
property string fetch shows up high in list of time consuming function
calls, we don't necessarily know if most of those calls were made
On Tue, 24 Jun 2003, Curtis L. Olson wrote:
Lawrence Manning writes:
Well, with threads you can spread the load across CPUs. So it is not
just a convience for the programmer. Afterall, the original poster
bought up the matter of big boxes with lots of slow processors.
Right, but we
Norman Vine wrote:
You have to let the process run much longer
until things like ssgMakeMipMaps don't show up in the top 100 :-)
The nice thing is that it also contains OpneGL calls.
That is good and bad
the bad part is that it takes time to instrument the profiling
and since we can't do
Curtis L. Olson [EMAIL PROTECTED] wrote:
One big question is what language/platform are you connecting to?
The easiest thing to do would be to write the other application in
C/C++ and just use the exact same structure. If you look at the
socket calls you will see that you provide a buffer
On Tuesday, June 24, 2003, at 11:53AM, Martin Spott [EMAIL PROTECTED] wrote:
Curtis L. Olson [EMAIL PROTECTED] wrote:
The structure is defined in src/Network/net_ctrls.hxx
Yep, I already read this, but I'm not shure about the the data format of the
values I have to put in there.
I assume
Norman Vine wrote:
http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz
You have to let the process run much longer
until things like ssgMakeMipMaps don't show up in the top 100 :-)
There is a new file after running FlightGear for about 23 minutes.
Erik
Martin Spott writes:
The prototype is in Perl, aside from Pascal (o.k., and Basic) this is the
only programming language I'm capable of writing a whole program from
scratch This is one main reason why I prefer to having a bit scheme I
can stick to - whatever language I'm writing in. The
I'm curious as to has anyone been able to compile FGSD in Cygwin. I have been trying
to for quite some time and the error I recieve when I try to compile the CVS version
of FLTK 2.0 is:
In file included from fl_color.cxx:97:
fl_color_win32.cxx:87: 'DC_PEN' was not declared in this scope
Please disregard the last message about compiling. I have fixed that issue however,
I'm having trouble loading the scenery from flight gear to modify it. Has anyone
tried this program yet?
Brian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
On 24 Jun 2003 16:32:17 GMT,
Martin Spott [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Martin Spott [EMAIL PROTECTED] wrote:
Sincerely there are more urgent jobs to do - enabling flying below
bridges or through the Sutro tower, for instance ;-))
I have to correct this
Dicks Brian writes:
I'm curious as to has anyone been able to compile FGSD in Cygwin. I have been
trying to for quite some time and the
error I recieve when I try to compile the CVS version of FLTK 2.0 is:
In file included from fl_color.cxx:97:
fl_color_win32.cxx:87: 'DC_PEN' was not
I want to apologize for dropping the ball on this, and point at it
(the ball) in case someone else would want to pick it up and run with
it.
Essentially, no one from the FlightGear project has applied yet for a
booth at the Linux World conference in August.
I have been getting all the exibitor
* Curtis L. Olson -- Tuesday 24 June 2003 18:44:
Does anyone have any ideas for factoring out the
startup/initialization time from these performance reports?
Risking that I go on everybody's nerves already: this is again
the job of valgrind + the calltree skin (see below for the urls).
Sunday, June 22, I put fgfs from cvs on my Dell Latitude
2.2 GHz P4 with 512 MB, on board nvidia GF4, and RH9.0 Linux.
HW Browser shows 82801CA/CAM AC'97 Audio with i810_audio driver
dmesg shows the driver can support 6 channels but then defaults to 2
channel mode.
lsmod shows that soundcore,
42 matches
Mail list logo
