RE: [Flightgear-devel] Shadows and joysticks
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 force feedback devices, it would be nice in FG too. Richard -Original Message- From: Lawrence Manning [mailto:[EMAIL PROTECTED] Sent: 23 June 2003 9:57 pm To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Shadows and joysticks First post to this list... been playing with fg for a few weeks now and I have to say I'm very impressed. It runs super on my 2ghz AMD linux box with Geforce 4 gfx and the Nvidia drivers. Ok, questions... First of all, are there any plans to implement shadows? A shadow of the aircraft over the ground would obviously make judging the height visually much easier, and add to the realism. Of course, the ultimate is to make it so mountains and the scenery itself can cast shadows, even into the cockpit of the 'plane! But a good start would be aircraft shadows. I haven't a clue how feasable this is, and the question has probably been asked many times before, but here's me asking anyway. The second question is to ask if anyone can recommend a good joystick for flightgear use? The only thing it will be used for is fg. Not after anything too flashy; just needs the additional rudder and throttle controls. A friend recommened one of the Microsoft sticks, so I'm inclined to go for that (say all you like about MS, but they make good hardware! I love my MS optical mouse). I haven't bought a joystick since they used 9 pin D-type connectors and did 4 digital directions and a firebutton, so any guidance anyone can give would be great. Anyway, thanks for the superb software. :) I look forward to future versions and helping in any way I can. Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ __ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk __ __ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Adding Taxiways
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] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Adding Taxiways
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/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Again: Threaded FlightGear ?
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 FlightGear more versatile (I'm amazed that the programm still works after all this shuffling ;-) I'd like to ask if someone intends to subdivide the current tasks into different threads in future !? I know that threading inside an OpenGL context is considered to be a no-no, but probably there are already several sub-tasks that could be separated. Please don't consider this as a feature request, it's just me being curious. Sincerely there are more urgent jobs to do - enabling flying below bridges or through the Sutro tower, for instance ;-)) Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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: * Sound thread (should be fairly easy) * FDM thread/process * Maybe (just maybe) an I/O thread? But I guess that's about it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
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: * Sound thread (should be fairly easy) * FDM thread/process Or even multiple FDM threads for when we get mulitple FDM support. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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. Things that come in mind are: * 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, it can hide extremely subtle bugs that are extremely difficult to track down and only show up under rare circumstances. I saw a lot of nifty looking examples of threading in school, but once you hit an application with the complexities of FlightGear, you have to be *really* careful, and *really* know what you are doing, or you end up making a *really* big mess. That is a pretty hefty price to pay. We put in a *huge* amount of work into the threaded tile pager and I spent many, many evenings staring at code, scratching my head, running flightgear for hours trying to track down subtle, rare gotchas. 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 to split that up (which is nigh unto impossible since this is all involving opengl which inherently resists threading without a *huge* amount of effort and complexity[1]) then threading the other 5-10% of the work isn't going to gain you a whole lot. [1] The Performer scene graph has app-cull-draw threads, but you pay the price with an very large amount of complexity, bloat, and some performance loss for single CPU machines. On a single CPU machine, plib will almost always render the same model faster than performer. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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, it can hide extremely subtle bugs that are extremely difficult to track down and only show up under rare circumstances. I agree with this. That's why I prefer a FDM process rather than a FDM thread. But subtle changes (for example moving the sound into a thread) may eventually result in higher framerates even for single processor machines. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 not that fast. Things that come in mind are: * Sound thread (should be fairly easy) * FDM thread/process * Maybe (just maybe) an I/O thread? But I guess that's about it. Dunno if this is valid, but here's my thoughts. 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 processing time? I'm not quite sure how threads can help, except possibly with the simulation of hundreds of aircraft at once? Although threading out scenery loading and sound both appear good ideas. It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 to split that up (which is nigh unto impossible since this is all involving opengl which inherently resists threading without a *huge* amount of effort and complexity[1]) then threading the other 5-10% of the work isn't going to gain you a whole lot. For the record, the top 20 functions as reported by oprofile-0.5.3 are: Cpu type: PIII Cpu speed was (MHz estimation) : 807.98 Counter 0 counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 40 % symbol name 1.02981 ssgSelector::select(unsigned) 1.03343 FGHitList::IntersectBranch(ssgBranch*, double (*) [4], double*, double*) 1.07417 ssgEntity::dirtyBSphere() 1.10563 ssgEntity::getTraversalMask() 1.13437 FGInstrumentLayer::transform() const 1.15995 SGPropertyNode::hash_table::get(char const*) 1.35369 ssgLeaf::cull(sgFrustum*, float (*) [4], int) 1.47658 slEnvelope::applyToVolume(unsigned char*, unsigned char*, int, int) 1.53362 sgXformPnt3(float*, float const*, float const (*) [4]) 1.60288 ssgVtxTable::getNumColours() 1.77896 ssgBranch::recalcBSphere() 2.05825 sgdMakeNormal(double*, double const*, double const*, double const*) 2.1051 SGPropertyNode::hash_table::bucket::get_entry(char const*, bool) 2.2873 sgFrustum::contains(sgSphere const*) const 2.69288 SGPropertyNode::hash_table::hashcode(char const*) 3.03894 ssgVtxTable::getNumVertices() 3.16909 ssgSimpleState::apply() 3.2234 ssgVtxTable::draw_geometry() 4.77468 ssgBranch::cull(sgFrustum*, float (*) [4], int) 4.77513 ssgEntity::cull_test(sgFrustum*, float (*) [4], int) Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 overhead of many context switches. User space threads are pretty quick, but still there is some overhead to switch to a new thread. 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. The only way to utilise those is with multiple threads and/or processes. But I'm definetly not suggesting that fg would gain alot through threads, because the biggest job (rendering) is not suitable. It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? By default, OpenGL will texture, light, and shade the lines of the wire frame so this might not necessarily run as fast as you'd hope... :-) LOL, okay. Stumped :) Hey how about no display at all... Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 type: PIII Cpu speed was (MHz estimation) : 807.98 Counter 0 counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 40 % symbol name 1.15995 SGPropertyNode::hash_table::get(char const*) 2.1051 SGPropertyNode::hash_table::bucket::get_entry(char const*, bool) 2.69288 SGPropertyNode::hash_table::hashcode(char const*) We need to use more pointers to property nodes instead of fgGetString type of function calls. 1.35369 ssgLeaf::cull(sgFrustum*, float (*) [4], int) 1.77896 ssgBranch::recalcBSphere() 1.07417 ssgEntity::dirtyBSphere() 4.77468 ssgBranch::cull(sgFrustum*, float (*) [4], int) 4.77513 ssgEntity::cull_test(sgFrustum*, float (*) [4], int) These are all Bsphere related functons. So the most time consuming functions really are SGPropertyNode::hash_table and ssgBranch:: BSphere Hmmm, this makes me wonder ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 processing time? 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 faster CPU. Unfortunately the tax authorities prevented me from buying the desired CPU upgrade for the Octane It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? Is there a wireframe-mode in FlightGear ? I thought even the shaded terrain display has been removed, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
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 FGFS trying to determine what percentage of time was actually spent drawing This was about a year ago, but I doubt if things have changed much % cumulative self self total time seconds secondscalls ns/call ns/call name 59.20 0.74 0.7440047 18478.29 19976.49 fgRenderFrame(void) 20.00 0.99 0.2539218 6374.62 6374.62 fgUpdateTimeDepCalcs(void) 16.00 1.19 0.20 fgMainLoop(void) Norman Also we need to be careful to consider that actual profiling numbers could vary drastically between platforms, video cards, cpus, operating systems, video drivers, profiling tools :-), etc. And also it should be pointed out that FlightGear has a *very* CPU/time expensive startup and initialization sequence. This also needs to be considered when interpretting the profiling numbers. The longer you run flightgear, the more the actual running app numbers will become dominant, and the less dominant the initialization numbers will be. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 faster CPU. Unfortunately the tax authorities prevented me from buying the desired CPU upgrade for the Octane It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? Is there a wireframe-mode in FlightGear ? I thought even the shaded terrain display has been removed, The wireframe mode got broke somewhere along the way, but I fixed it recently. I haven't tried lately to see if it's broke again, but last I checked it did work. It can be useful for debugging your models/terrain because it will show you the exact triangle layout ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: keyboard mapping - spoilers and zoom
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 patch in the queue that adds keyboard toggling of the speed brakes ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
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 results from the last time I profiled FGFS trying to determine what percentage of time was actually spent drawing This was about a year ago, but I doubt if things have changed much % cumulative self self total time seconds secondscalls ns/call ns/call name 59.20 0.74 0.7440047 18478.29 19976.49 fgRenderFrame(void) 20.00 0.99 0.2539218 6374.62 6374.62 fgUpdateTimeDepCalcs(void) 16.00 1.19 0.20 fgMainLoop(void) Norman Also we need to be careful to consider that actual profiling numbers could vary drastically between platforms, video cards, cpus, operating systems, video drivers, profiling tools :-), etc. This is all very true, the above figures are on a 733mz machine with a geForce2 And also it should be pointed out that FlightGear has a *very* CPU/time expensive startup and initialization sequence. This also needs to be considered when interpretting the profiling numbers. The longer you run flightgear, the more the actual running app numbers will become dominant, and the less dominant the initialization numbers will be. 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 :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
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 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 main loop where it matters a lot more. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] native-ctrls wire format ?
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 it crashes 'fgfs' when combined with other command line switches. But the latter is not the issue here. My first try to get a clue about the wire format was by reading lots of source code, but as I'm not fluent at C++ this didn't deliver the desired result. Now I thought I'd write to a file and have a look at what's going on there. This is not human readable (at least not for me). Is there hope to find a human readable (except from RTSL) documentation on what FlightGear expects on a socket, file (pipe) or serial port for being controlled externally ? Also I'm not quite shure if I can confine on feeding only the 'usual' manual controls into FlightGear to control the flight ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 main loop where it matters a lot more. This is the top 20 of FlightGear CVS on my O2: http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz The nice thing is that it also contains OpneGL calls. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 cockpit of a YF-23. Switching to chase-view in the last seconds before 'entry' makes it easier :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 platform, b) the fact that the bulk of the flightgear application work is in rendering the 3d display, c) the practical problems that things like opengl and our property system is not thread safe, d) the complexity and subtle bugs that threading *very* often introduces when added to large complex applications. I don't want to add a bunch of threads if the only reason is that threads looked cool and fun when we studied them in a computer science class, and there is one person with a machine that could benefit. If someone does want to go thread crazy, please do it in a fork of the source code. I'd be interested in hearing the results and any issues or problems that were encountered as well as any performance gains realized. The only way to utilise those is with multiple threads and/or processes. But I'm definetly not suggesting that fg would gain alot through threads, because the biggest job (rendering) is not suitable. Did anyone say if this multi-cpu machine had an accelerated opengl graphics system? If it doesn't then this whole discussion is pointless. :-) LOL, okay. Stumped :) Hey how about no display at all... You can almost do that ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded 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 doesn't really matter, or during the main loop where it matters a lot more. This is the top 20 of FlightGear CVS on my O2: http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz The nice thing is that it also contains OpneGL calls. Does anyone have any ideas for factoring out the startup/initialization time from these performance reports? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] native-ctrls wire format ?
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 or with other words: Won't I have to worry about the platform FlightGear is currently running on ? I suspect 'double' and 'int' will differ and the whole stuff depends on the CPU's byte order, so I have to take serious bit-shifting into account, when running the application on different platforms. Is an EOL the correct ending of a set of control data over a socket or serial line ? Thanks for dealing with this, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 thread would make a huge difference, or it makes no difference at all: http://www.a1.nl/~ehofman/fgfs/download/io.output.gz Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] native-ctrls wire format ?
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 FlightGear is currently running on ? I suspect 'double' and 'int' will differ and the whole stuff depends on the CPU's byte order, so I have to take serious bit-shifting into account, when running the application on different platforms. Is an EOL the correct ending of a set of control data over a socket or serial line ? Thanks for dealing with this, 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 and a length and it will fill it in with the network data. You may have to worry about endianess if you are communicating between two different architectures, but in this case, the code converts to/from network byte order so that shouldn't be a problem. The whole task is probably a lot easier than you are making it out to be. :-) If you want to know the size of different structures such as bool or int or double, there is a function in C/C++ called sizeof(). So you could do something like cout sizeof(bool) endl; I believe the answer is printed in bytes. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
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 during initialization where it doesn't really matter, or during the main loop where it matters a lot more. This is the top 20 of FlightGear CVS on my O2: 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 :-) 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 anything about speeding up the low level code why do we want it influencing the run time ?? Does anyone have any ideas for factoring out the startup/initialization time from these performance reports? Sure, just let FlightGear run for a minimum of 20 minutes when profilng Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 should also bear in mind the a) typical flightgear platform, b) the fact that the bulk of the flightgear application work is in rendering the 3d display, c) the practical problems that things like opengl and our property system is not thread safe, d) the complexity and subtle bugs that threading *very* often introduces when added to large complex applications. Completely agree. I probably should have kept my mouth (fingers) shut. Only certain applications lend themselves strongly towards threading, and FlightGear obviosly isn't one of them. My sole expereince with threads is on Win32 (C/MFC stuff) and I never want to do it again, so understand completly where you are coming from. I don't want to add a bunch of threads if the only reason is that threads looked cool and fun when we studied them in a computer science class, and there is one person with a machine that could benefit. Definetly agree on that! Had the threads are cool, processes suck, from my OS Theory prof as well. I pointed out that its a nice theory, but dosn't work quite like that in the real world ;-) Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 anything about speeding up the low level code why do we want it influencing the run time ?? Sometimes you can avoid time consuming OpenGL calls this way. Does anyone have any ideas for factoring out the startup/initialization time from these performance reports? Sure, just let FlightGear run for a minimum of 20 minutes when profiling This is always a good excuse to use FlightGear ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] native-ctrls wire format ?
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 and a length and it will fill it in with the network data. 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 other reason is that I'd like to 'know' (TM) what I'm doing here :-) Thanks for your explanation, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] native-ctrls wire format ?
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 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 FlightGear is currently running on ? I suspect 'double' and 'int' will differ and the whole stuff depends on the CPU's byte order, so I have to take serious bit-shifting into account, when running the application on different platforms. By default, everything that is transferred is done so in network format (big-endian). IMNSHO, sending data in any other format is asking for trouble (i.e., how can I send data from my PowerPC to my x86 box if it is not in network format). Look at source/src/Network/native_ctrls.cxx to see how the data is processed. The sizes are: Boolean = 8-bits Integer = 32-bits Float = 32-bits Double = 64-bits Don't forget data elignment. The C/C++ compiler will pad data so that is alighed per the processor's architecture. This means that an array of three bytes that is followed by an integer will *MOST LIKELY* have a hidden fourth byte applied after the array and before the integer. The compiler will align data on its native boundary (i.e., 32-bit numbers will start on a 32-bit boundary). Is an EOL the correct ending of a set of control data over a socket or serial line ? Don't send any line termination. What is being received over the network is a stream of bytes, not text. When the receiver has enough data, it will be processed. Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] native-ctrls wire format ?
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 other reason is that I'd like to 'know' (TM) what I'm doing here :-) If you are doing perl, then look at the pack() and unpack() perl functions. In this case you might want to avoid converting to network byte order unless you are a better perl hacker than I am. I could never reliably swap the bytes back ... probably some sort of binary vs. ascii interpretation which I wasn't able to resolve correctly. Assuming you can read the data packet with something like: $handle-recv($msg, 32768); Then you can do something like: @s = unpack(iiddfffiiiffifff, $msg); ... to extract the message into a perl array i = int, d = double, f = float, etc. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cygwin / Flight Gear Scenery Designer
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 fl_color_win32.cxx:88: 'DC_BRUSH was not declared in this scope fl_color_win32.cxx: In function 'HPEN_* fltk::setpen()': fl_color_win32.cxx:95: 'SetDCPenColor' undeclared (first use this function) fl_color_win32.cxx:95: (Each undeclared identifier is reported only once for each function it appears in.) fl_color_win32.cxx: In function 'HBRUSH__* fltk::setbrush()': fl_color_win32.cxx:119: 'SetDCBrushColor' undeclared (first use this function) fl_color.cxx: At top level; fl_color_win32.cxx:32: warning: 'COLORREF brush_for' defined but not used make[1]: *** [fl_color.o] Error1 Anyone have any ideas? Or is this the wrong mail list for this? Brian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cygwin / Flight Gear Scenery Designer
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] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
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 statement: It _is_ possible to fly through the Sutro tower, but it's not that easy to view from inside the cockpit of a YF-23. Switching to chase-view in the last seconds before 'entry' makes it easier :-) ..uhmmm, does the tower model include the RL brace wiring? ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Cygwin / Flight Gear Scenery Designer
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 declared in this scope fl_color_win32.cxx:88: 'DC_BRUSH was not declared in this scope fl_color_win32.cxx: In function 'HPEN_* fltk::setpen()': fl_color_win32.cxx:95: 'SetDCPenColor' undeclared (first use this function) fl_color_win32.cxx:95: (Each undeclared identifier is reported only once for each function it appears in.) fl_color_win32.cxx: In function 'HBRUSH__* fltk::setbrush()': fl_color_win32.cxx:119: 'SetDCBrushColor' undeclared (first use this function) fl_color.cxx: At top level; fl_color_win32.cxx:32: warning: 'COLORREF brush_for' defined but not used make[1]: *** [fl_color.o] Error1 Anyone have any ideas? Or is this the wrong mail list for this? see http://www.cygwin.com/ml/cygwin/2003-04/msg02572.html HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Linux World Conference
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 propoganda so I had assumed I must have subitted the application and being busy with a zillion other things, didn't really give it much thought either way. Right before my Norway trip I looked on their web site and realized that we had never official applied and thus we don't have a booth. I had no time to worry about it because I was going out of the country the next day and of course couldn't deel with it while I was gone. Ok, so now I'm back home, but struggling to catch up on a huge pile of things, and realistically, I'm just not going to be able to make the time to pursue the application process (if there are any booths even left.) So, if we want to do a booth this year for LWCE out in San Francisco, someone will need to step up to the plate and submit an application *very* soon. I might be able to get myself out there to participate for a day or two, but even that is starting to look a little iffy at this point. So that's the deal ... does anyone want to look into applying for a booth and interfacing with the conference people? Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Again: Threaded FlightGear ?
* 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). Valgrind is only an engine that emulates a CPU. That is, it catches every machine instruction, does some stuff before, lets the real CPU execute the instruction, and does some stuff afterwards. This can be used to check for access to uninitialized memory, but it can also be used for tasks like profiling. All you need is a different valgrind skin. The profiling skin does not execute in real-time, yet its measurement is perfectly proportional. Valgrind + calltree generates a lot of raw data--- kcachegrind (KDE-libs required) displays the data in humanly readable form. You can even see how different data fit into the CPU cache ... The colored fields at the top right of the below mentioned screenshot indicate the time the program counter spent in the respective functions. On the top left you can see chronological phases. The first few slices are the startup phase. The last ones are regular runtime. One runtime slice is selected and you can see its analysis. You can select every single slice or a couple thereof. There isn't much you *can't* do. :-) You can even send signals to valgrind for when it shall start and when it shall stop profiling. HOWTO: 1. make sure you have the KDE-libs installed on a Linux system 2. download and install valgrind from http://developer.kde.org/~sewardj/valgrind-1.9.6.tar.bz2 3. download and install calltree from http://kcachegrind.sourceforge.net/calltree-0.9.1.tar.gz 4. download and install kcachegrind from http://kcachegrind.sourceforge.net/kcachegrind-0.3b.tar.gz 5. execute e.g. (for nVidia cards; leave the environment away for others :-/ ) $ __GL_FORCE_GENERIC_CPU=1 calltree --dumps=1000 fgfs 6. now analyze the generated data by typing in the same dir: $ kcachegrind 7. marvel at the detailed output and click around http://www.unet.univie.ac.at/~a8603365/vg.png (82kB) m. Hint for Andy: the last valgrind version from cvs =does= handle MMX/SSE(2), but that one doesn't work with calltree yet. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] No sound with fgfs on Dell Latitude with RH9.0
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, ac97_codec,and i810_audio are all loaded. Sounds work outside fgfs, but no sound in fgfs. FWIW, I have the fgfs 9.2 binaries running under Win XP Pro on another partiton on this same notebook and sound is working ok there. I also noted that under RH9.0, IRQ 11 is used by several devices including the sound chip. Other than no sound, fgfs is running great with good frame rates. Any ideas? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
