Re: [Flightgear-devel] [OT] Developer configuration under Linux
Hi Guys! Yerstaday i had to reinstall my linux and my second CD from mandrake linux distribution was scratched so i download missing developers (zlib,jpeg,png) packets from internet in rpm format and install them using rpmdrake utility but when i run ./configure script i see this results . checking for jpeg_destroy_decompress in -ljpeg... no configure: warning: *** JPEG library not found *** checking for zlibVersion in -lz... no Under Debian, the headers for the compiler are separate from the binaries for runtime. Did you install both parts ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Geoff: It appears that your machine may not be capable of running FlightGear properly. This stuff should not be happening. ... ... I ran into similar things to what you are seeing a year ago when I had a seriously underpowered machine/display card. SUMD = 'seriously underpowered machine/display' = SUMD EXACTLY! I am happy that you today have a 'machine' that has 'power', but do NOT be sad for me with my little machine. Year by year i grow, hopefully ... More specifically 'this' machine - Back at the end of 1999 this latest-so-far pc (i hv 4 if i do not count those that just gather dust) was a 'big store' off-the-shelf bargain 'package' with 'genuine intel' PIII at abt 500+ MHz. The mark is 'Unika', with only 64 MB RAM, but with a 256 MB upgrate waiting in the wings, running Windows 98 SE ... stock standard stuff. I would respectfully say some very good parts of FG do run 'properly' in my system. Simply, the CPU (and io bus) resources can meet the demands of the application, and have lots of spare cycles left over ... DirectX 8.0a updates (video and sound) are smooth ... inputs (kb,js) are read and acted upon 'immediately' ... and as i say, the - :-)) the simulator FLIES :-)) Maybe 'this' pc system is below what you consider the MINIMUM requirements are for a 'Flight Simulator --fdm=jsbsim' to successfully run. If so, stop reading now ... this does not concern you ... ... I haven't seen reports (...) that comes close to the chaotic mess you are reporting ... But I think your problems are beyond my control. Now preference everything with - when running in a SUMD - Well, yes and no. You can certainly do little about the approx. 2 minute start-up time for FG in my system, with any FDM. This is loading, mapping, sorting, cacheing, indexing, etc etc ... and the disk light is constantly on ... time to get coffee ... Interestingly enough, one of the first indications that my SUMD is settling down is I hear the 'sort-of-thump', which I have always presumed is the gear coming into contact with the runway ... I wish I could 'find' that event ... call it SUMDUP To try to 'wait' such system-equilibrium, or SUMDUP, in FGMagicarpet::update( multi_loop ) I experimented with a simple do not even run the EOM until at least 5 real seconds have elapsed ... but i agree there should be a better trigger than time elapsed ... You see. Here is a place where you could maybe help ... re:JSBout - in a way i was asking why all those calculations when I have not even started the engine yet? Sure you still need to check wind/weather effects, but once wind say is seen to be zero do NOT go off and set the property tree with values that are already there, if your code does that ... This seems especially true when some of the 'calculations' do not seem 'clamped' to a sort of minimum-changed-before-more-calcs. Or simply stated, avoid the 'slower micro-coded on chip' FPU instructions as much as possible to help in the general system resource use ... But one piece of code you do have that I like very much is that you start in a 'dead' ac. I really like that i have to get in and remember to do some things to get the ac rolling ... That is also 'good' in the sense, since the ac should not move (no wind) there will be no changes in lat/lon/alt, and no change in pitch/roll/yaw, and the 'scenery/tile' manager can get on with its task ... but do you also avoid EOM-FPU calcs at this time? Again taking the sample of 'magic', it seems the PLIB js read of what is the 'throttle slider', on the very early, maybe only first read yields a value above ZERO, thus if you 'ignored' the mags setting (and starter) like magic (and JASim also) you sort of hit the runway running ... 'magic' has no problem with this since if the FDM finds itself below ground it pop itself back to the top ... and in JASim it is only about 60% power, some the ac only moves slowly ... All in all i hope you understand my comments are sometimes related to all FDM's run by FGFS ... not 'singling' out any ... and i hope they help. rgds, Geoff. ps: just to mention, after a similar 2/3 minute start-up my FS2000 runs fine in this system ... so it can not be all bad. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
More specifically 'this' machine - Back at the end of 1999 this latest-so-far pc (i hv 4 if i do not count those that just gather dust) was a 'big store' off-the-shelf bargain 'package' with 'genuine intel' PIII at abt 500+ MHz. The mark is 'Unika', with only 64 MB RAM, but with a 256 MB upgrate waiting in the wings, running Windows 98 SE ... stock standard stuff. Tell me about the display car dyou have, how much memory there? re:JSBout - in a way i was asking why all those calculations when I have not even started the engine yet? Trimming is done, for one thing. Really, the FDM takes a very small amount of computation time. Most of the time is spent in the display routines, IIRC. Or simply stated, avoid the 'slower micro-coded on chip' FPU instructions as much as possible to help in the general system resource use ... Do you have some particular examples? That is also 'good' in the sense, since the ac should not move (no wind) there will be no changes in lat/lon/alt, and no change in pitch/roll/yaw, and the 'scenery/tile' manager can get on with its task ... but do you also avoid EOM-FPU calcs at this time? This is a non-issue, as far as I am concerned. Like I said, these calculations have a very small impact on the program. Geoff. ps: just to mention, after a similar 2/3 minute start-up my FS2000 runs fine in this system ... so it can not be all bad. The same thing was true of my machine, which was less powerful than yours. My problem, I think, was that I had only 8 MB of video RAM. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Geoff McLane wrote: More specifically 'this' machine - Back at the end of 1999 this latest-so-far pc (i hv 4 if i do not count those that just gather dust) was a 'big store' off-the-shelf bargain 'package' with 'genuine intel' PIII at abt 500+ MHz. The mark is 'Unika', with only 64 MB RAM, but with a 256 MB upgrate waiting in the wings, running Windows 98 SE ... stock standard stuff. I would respectfully say some very good parts of FG do run 'properly' in my system. Simply, the CPU (and io bus) resources can meet the demands of the application, and have lots of spare cycles left over ... DirectX 8.0a updates (video and sound) are smooth ... inputs (kb,js) are read and acted upon 'immediately' ... and as i say, the - :-)) the simulator FLIES :-)) FGFS does *not* use DirectX. It uses OpenGL. And most performance critical part of the PC for FGFS is your 3d accellerator. Oh, and 64 MB RAM might be a very good reason for having a *very* slow FGFS. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Geoff McLane wrote: And as I have often repeated, it seems to me the main fgfs problem in WIN32 - using my msvc6 compiled debug exe - is all to do with memory of course, and disk io ... And i am sure some of that is due to using the windows memory mapping of files (in metakit at least). That's definitely not the problem. The problem is that FGFS has to wait till the current scenery tile is loaded. And interestingly that delays FGFS quite a bit under MSVC (and is better under CygWin). So when starting FGFS you should hit pause and wait until your harddisk calmed down. Then you should have an easy takeoff. (Again: It's defintely not Metakits fault as the effect was there already as we didn't have Metakit) fdm 'magic' is far less 'jittery', thus the system's memory managment, including cached io, mapped io, ..., etc catch up more frequently, and then i can see 30 fps plus. The maths that are done for magic are *much* simpler and thus require much less CPU. So it's expected to have the best performance. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Creating a sub window
Dawn Ellis wrote: Andy wrote: Platform? FlightGear's main window is an OpenGL rendering context. I'd be surprised if there was any portable way of getting an OS subwindow. You'd be better off working with the PUI library inside the context instead. We are running on a Windows 2000 machine, using the cygwin environment. I've used the glutCreateSubWindow function, and I do get two windows, but FG seems to be overriding the display callback for the subwindow. If you want an additonal window from the OS to display OpenGL you also need a new OpenGL context. Have a look at PLIB as that's responsible for that in our case. Maybe you should also have a look at PPE (prettypoly.sf.net) as it uses PLIB and creates multiple windows. We are using Jon's shuttle model for a landing simulation that we are developing for the Challenger Center at the school. We are using a modified HUD display with special audio to simulate mission control, and the sub window will be used to display text. In that case you can have a much simpler solution. Look at PLIBs PUI and create a new (permanet) PUI window that outputs the text. Should be quite easy. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Developer configuration under Linux
Roman, Did you also install the *-devel packages? For some things they are the ones with the header files. From your comments I think you've already done this, but just to be sure check /etc/ld.so.conf and make sure the line /usr/local/lib is in there. Then run /sbin/ldconfig -v. THX/BDH On Sun, 2002-01-27 at 01:46, Roman Grigoriev wrote: Hi Guys! Yerstaday i had to reinstall my linux and my second CD from mandrake linux distribution was scratched so i download missing developers (zlib,jpeg,png) packets from internet in rpm format and install them using rpmdrake utility but when i run ./configure script i see this results . checking for jpeg_destroy_decompress in -ljpeg... no configure: warning: *** JPEG library not found *** checking for zlibVersion in -lz... no configure: warning: *** zlib library not found *** checking for png_init_io in -lpng... no configure: warning: *** PNG library not found *** checking for ANSI C header files... no checking for GL/gl.h... yes checking for GL/glut.h... yes checking for png.h... yes checking for jpeglib.h... yes ... as I understand ldconfig works only with .so modules and doesn't maintain .a libs gcc knows about header files but not about libraries. What should I do? Thanx in advance Roman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: YASIM Options
* Andrew Ross -- Saturday 26 January 2002 20:20: There's also a complication with the Harrier. You'll need to map a joystick axis to the /controls/thrust-vector[0] property in order to work the thrust vectoring. Works also reasonably well when mapped to the low/high properties of a joystick hat switch. :-) I've been playing/practicing with the Harrier a lot recently. I really should write up a training guide or somesuch, for folks just getting into it. The learning curve on the VTOL stuff is nasty and steep, kind of like being a real life test pilot on the things. Loads of fun. I can *almost* reliably land vertically now -- but hovering still eludes me. It's really nice to play with it! I once watched a Harrier at an airshow. It didn't really look like it were difficult to fly. ;-) I assume that the real thing is stabilized by a computer, no? Otherwise we would read about crashed Harriers every day. Lifting off in fgfs is already a hairy operation. But turning (yawing) at the place seems impossible. Is this modeled? How is it done in a real Harrier? With steering jets, coupled to the rudder? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3-D model (partial)
Ah, not bad! Just out of curiosity, how much time did you need (including learning Blender) and how many polys does it have? Maybe a bit early to ask, but: Do you plan to add animation, inclusive adding it to the FGFS code? David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New graphic chip
Hi Guys, I know you hate it... and this topic seems to be endless on FGFS-Devel group, AND this discussion does not belong in here, but you guys are the only ones I trust... so here goes: am I going to replace my TNT2Ultra with a GeForceMX2 ? (you are going to decide for me) FGFS runs nicely on my TNT2U (I think it's the latets debianized packacge, 0.7.8), but the MX is cheap (60$) and, seems to be a lot better. However, no benchmark actually put both cards on the row and see which performs better. Hope you have some tips for me :) All the best, Elady. ___ Elad Yarkoni (Elady for friends or Oh my god - it's him ! for fans or turbofans) eMail: [EMAIL PROTECTED] WWW: http://www.ee.bgu.ac.il/~elady Dept. of ECE, BGU, Beer-Sheva, Israel. 972-8-647-2417. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New graphic chip
Elad Yarkoni wrote: Hi Guys, I know you hate it... and this topic seems to be endless on FGFS-Devel group, AND this discussion does not belong in here, but you guys are the only ones I trust... so here goes: am I going to replace my TNT2Ultra with a GeForceMX2 ? (you are going to decide for me) I can't decide for you. FGFS runs nicely on my TNT2U (I think it's the latets debianized packacge, 0.7.8), but the MX is cheap (60$) and, seems to be a lot better. However, no benchmark actually put both cards on the row and see which performs better. The big advantage of a GeForce [whatever] to a TNT [whatever] is the TL setup - something that makes FGFS much faster. But the difference in speed depends totally on your CPU. I guess that a TNT2Ultra might be faster than a GeForce2MX on a 2 GHz Athlon. But on a Pentium 100 the GeForce2MX is much faster. If FGFS runs fast enough for you on your TNT2U, why should you change it? Wait a bit longer and save a bit more money. Then you'll perhaps get GeFroce2Ti for a bit more. Or even a GeForce3 or whatever. Time is working for you (and after you've bought it it's sort of working against you...) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3-D model (partial)
Wolfram Kuss writes: Ah, not bad! Just out of curiosity, how much time did you need (including learning Blender) and how many polys does it have? I'm not sure how much time I spent learning Blender, but it was definitely under 12 hours, spread over a few weeks. There are a *lot* of online tutorials (build a castle, build a pencil, etc.) and the best way to learn is to work through those. I have probably spent about 4 hours on the DC-3 so far, and a lot of that was learning. I could probably make a new one from scratch much faster now that I've learned the techniques. I expect to spend much more time now on the smaller details, though. I don't know how to tell how many polys it has -- I don't know all the intricacies of Blender yet. Perhaps someone could load the VRML model into PPE and tell me. Maybe a bit early to ask, but: Do you plan to add animation, inclusive adding it to the FGFS code? I've considered it. The rudder, elevator, and gear (such as it is) are all separate top-level objects, and the aileron and flaps will be too when I get around to it. If there's some way to tag nodes in Blender/VRML, it wouldn't be hard to move and rotate those objections from inside FlightGear, but for now I'm going one step at a time. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Developer configuration under Linux
- Original Message - From: Alex Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 27, 2002 11:29 AM Subject: Re: [Flightgear-devel] [OT] Developer configuration under Linux Hi Guys! Yerstaday i had to reinstall my linux and my second CD from mandrake linux distribution was scratched so i download missing developers (zlib,jpeg,png) packets from internet in rpm format and install them using rpmdrake utility but when i run ./configure script i see this results . checking for jpeg_destroy_decompress in -ljpeg... no configure: warning: *** JPEG library not found *** checking for zlibVersion in -lz... no Under Debian, the headers for the compiler are separate from the binaries for runtime. Did you install both parts ? yes i've installed all parts from rpm packages I have library libpng.a and libpng.so in /usr/lib directory and when I installed runtime and developer packages during install process of linux all works fine but when i installed separatly - no luck :((( What should I do? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: YASIM Options
On Sun, 27 Jan 2002 13:48:44 -0600 (CST), [EMAIL PROTECTED] (Jon Berndt) wrote: It's really nice to play with it! I once watched a Harrier at an airshow. It didn't really look like it were difficult to fly. ;-) I assume that the real thing is stabilized by a computer, no? Otherwise we would read about crashed Harriers every day. Lifting off in fgfs is already a hairy One of the most incredible things I've seen an aircraft do was during some kind of celebration, like an anniversary of the Statue of Liberty, perhaps. Two Harriers (British craft launched from the Invincible?) flew at low speed up to the front of the Statue of Liberty, turned 90 degrees to face it, *bowed* (dropped the nose and returned to horizontal), then turned back and flew off. A very moving and spectacular maneuver. I'm almost certain the early generation (GR1/GR3/FRS1/AV8A) harriers don't have a stabilisation system in the hover and pretty certain the later gen (GR5/GR7/FR2/AV8B) don't either. Which version is the model based on? There are BIG differences between the various marks. Wing size and planform is different, LERX were added to the GR5 after delivery and thrust/weight ratio is improved on the later marks. Even the outriggers are in a different position. Oh, and there were a fair number of crashed Harriers in the early days, esp, I understand, with the AV8A - something to do with different pilot selection and training policies between the RAF and USMC I believe. BTW, one Farnborough airshow (98?) we were treated to a bow by SIX Harriers :) Rick -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - [Post attack] crew changes would have been based on crew availability.' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiple monitors
Is it possible to run FGFS with multiple monitors doing something like that ? Is there any module that supports it? http://www.projectmagenta.com/design/index.html Thank's Sergio Roth ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiple monitors
Sergio Roth wrote: Is it possible to run FGFS with multiple monitors doing something like that ? Yes Is there any module that supports it? Run one instance as server that drives as many other PCs that you want. For out-of-the-window views you can use FGFS w/o modifications. If you want to split the cockpit instruments you'll just have to create new cockpits (should be quite easy when you only modify the existing ones). Or have a look at the OpenGC project for the additional instruments and drive it via FGFS. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New graphic chip
On Sun, 27 Jan 2002, Elad Yarkoni wrote: FGFS runs nicely on my TNT2U (I think it's the latets debianized packacge, 0.7.8), but the MX is cheap (60$) and, seems to be a lot better. However, no benchmark actually put both cards on the row and see which performs better. Hope you have some tips for me :) Running full screen at 1280x1024 on a dual PIII 866 with Creative 32MB GeForce2MX I get around 60-70fps, and everything is very smooth. At smaller resolutions the framerate increases (at 640x480 it's up to about 150fps). This us using the nvidia provided drivers, with nothing done to tweak performance in any way. -- Jon Stockill Public Key: C6BD585D [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: internet socket server (aka telnet)
* Melchior FRANZ -- Sunday 27 January 2002 00:43: [...] Anyway, here is my diagnosis::-) simgear/sg_socket.cxx doesn't accept(2) [...] Forget this nonsense. I'm working on it ... m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Alex warns: JSBSim actually works very hard to simulate realistically and uses the processor; with logging turned on, it does significant disk I/O. If you're short of memory and having to swap, the extra disk load can crucify the performance of Windows to keep the application running. Jon comments: And we are investigating making logging a positive-action-required feature, so unwitting users will not run into the disk IO bottleneck. I've found that each %f format conversion is relatively expensive, and (under linux) many sprintf followed by a single write is much faster than a lot of successive fprintf. I'd assume that the C++ version has the same performance impact. So, how about having the logging system giving the user the choice of (a) At crash or exit, the last ten seconds of flight are written to file, or (b) redirect the JSB log stream through the simgear networking interface ? The former eliminates the performance impact at the cost of a fairly small memory array that acts as a queue of doubles. The latter gives the option of making the data accessible from a second computer for real time plotting. I've been using xoscope recently, quite successfully, for such things. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Developer configuration under Linux
From: Alex Perry [EMAIL PROTECTED] Under Debian, the headers for the compiler are separate from the binaries for runtime. Did you install both parts ? yes i've installed all parts from rpm packages I have library libpng.a and libpng.so in /usr/lib directory and when I installed runtime and developer packages during install process of linux all works fine but when i installed separatly - no luck :((( What should I do? Sorry, in that case I have no idea. Under Debian, just asking the package manager to install plib-dev works and is sufficient. Did you try that option that asks the package manager to verify all dependencies are ok ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3-D model (partial)
David wrote: I don't know how to tell how many polys it has -- I don't know all the intricacies of Blender yet. Perhaps someone could load the VRML model into PPE and tell me. PPE says 2608 triangles! 3D Exploration says 867 faces ?!? Also, in PPE, I see all faces from both sides, in 3D Exploration only from 1 side. Maybe this is a PPE bug, I will investigate. But the flipping of some faces seems to be wrong (normal 180 degrees wrong). BTW, I think the engine nacelles and especially the wheels have very high resolution. Have you looked at the profile of the wing yet? :-). I've considered it. The rudder, elevator, and gear (such as it is) are all separate top-level objects, and the aileron and flaps will be too when I get around to it. If there's some way to tag nodes in Blender/VRML, it wouldn't be hard to move and rotate those objections from inside FlightGear, but for now I'm going one step at a time. Good! All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
I've found that each %f format conversion is relatively expensive, and (under linux) many sprintf followed by a single write is much faster than a lot of successive fprintf. I'd assume that the C++ version has the same performance impact. Right now, FGOutput.cpp uses cout. We direct output to cout, and after we are finished with a record, we flush() the stream. There is likely a better way to do this, but I haven't spent too much time on it. Ideally, it won't come into play unless someone is doing debugging - which most users will not. We're open to suggestion, though. So, how about having the logging system giving the user the choice of (a) At crash or exit, the last ten seconds of flight are written to file, or (b) redirect the JSB log stream through the simgear networking interface ? This sounds appealing, but I am not sure how we'd store ten seconds of constanlty refreshing data. The former eliminates the performance impact at the cost of a fairly small memory array that acts as a queue of doubles. The latter gives the option of making the data accessible from a second computer for real time plotting. I've been using xoscope recently, quite successfully, for such things. Real time plotting is something I've always wanted to do. There is the remnant of a socket interface in FGfdmSocket, and it is/was used in FGOutput. I actually wrote a small program that accepted data from a JSBSim output stream a couple years ago. I haven't seen xoscope. What is it? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Developer configuration under Linux
Roman Grigoriev writes: yes i've installed all parts from rpm packages I have library libpng.a and libpng.so in /usr/lib directory and when I installed runtime and developer packages during install process of linux all works fine but when i installed separatly - no luck :((( What should I do? Did you check to make sure the corresponding .h files also were actually there in /usr/include? Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] 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] msvc6-win32-0.7.9 Ok
Real time plotting is something I've always wanted to do. There is the remnant of a socket interface in FGfdmSocket, and it is/was used in FGOutput. I actually wrote a small program that accepted data from a JSBSim output stream a couple years ago. I haven't seen xoscope. What is it? http://xoscope.sourceforge.net/ But I'm using a significantly patched version, currently. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
On Sunday 27 January 2002 06:43 am, you wrote: Geoff: It appears that your machine may not be capable of running FlightGear properly. This stuff should not be happening. ... ... I ran into similar things to what you are seeing a year ago when I had a seriously underpowered machine/display card. SUMD = 'seriously underpowered machine/display' = SUMD EXACTLY! I am happy that you today have a 'machine' that has 'power', but do NOT be sad for me with my little machine. Year by year i grow, hopefully ... More specifically 'this' machine - Back at the end of 1999 this latest-so-far pc (i hv 4 if i do not count those that just gather dust) was a 'big store' off-the-shelf bargain 'package' with 'genuine intel' PIII at abt 500+ MHz. The mark is 'Unika', with only 64 MB RAM, but with a 256 MB upgrate waiting in the wings, running Windows 98 SE ... stock standard stuff. FWIW I demo FGFS on a 400Mhz K6-2 with 128 megs of RAM. It's gets marginal performance with a Riva TNT or Voodoo II PCI video, but with a GeForce IIMX AGP it's actually nice and smooth.. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3-D model (partial)
On Sunday 27 January 2002 01:09 pm, you wrote: Wolfram Kuss writes: Ah, not bad! Just out of curiosity, how much time did you need (including learning Blender) and how many polys does it have? Snip Maybe a bit early to ask, but: Do you plan to add animation, inclusive adding it to the FGFS code? I've considered it. The rudder, elevator, and gear (such as it is) are all separate top-level objects, and the aileron and flaps will be too when I get around to it. If there's some way to tag nodes in Blender/VRML, it wouldn't be hard to move and rotate those objections from inside FlightGear, but for now I'm going one step at a time. In Blender... Add Armature All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
