Re: [Flightgear-devel] Re : Publicity
On Sat, Mar 30, 2002 at 11:18:10PM +0100, Arnt Karlsen wrote: > On Sun, 31 Mar 2002 02:00:55 +1100, > [EMAIL PROTECTED] (Simon Fowler) wrote in message > <[EMAIL PROTECTED]>: > > > On Fri, Mar 29, 2002 at 07:56:10PM +0100, Arnt Karlsen wrote: > > > On Fri, 29 Mar 2002 09:36:47 -0800 (PST), > > > Alex Perry <[EMAIL PROTECTED]> wrote in message > > > <[EMAIL PROTECTED]>: > > > > > > > I'm only familiar with the performance of old cards. The Matrox > > > > G400 is 'ok'. > > ..Simon, you have the same card, with 16 MB? > > > > ...as in V fps at X x Y x Z bpp? > > > > > With the DRI drivers on my Athlon 550 I could get 20+ fps at > > 800x600, 16bpp. This was with low poly-count scenery, though. > > ..ok. How far can you push it on 8bpp, 15bpp and on 24bpp? > I never tried on anything other than 16bpp, I'm afraid - I was mostly interested in getting playable framerates from Q3A when I set it up, and keeping a reasonable look for my 2d applications. Going to 24/32 bpp /will/ slow it down significantly, but I'm not sure how badly. I have no idea about 15 or 8 . . . In any case, running FlightGear at 16bpp isn't too bad. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04738/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] "Enhanced" Magic Carpet
On Sat, 30 Mar 2002 17:27:43 -0600, Jonathan Polley <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Since I spend most of my FlightGear time using the Magic Carpet FDM, I > decided to make some minor tweaks. I have added the ability of the > FDM to change its pitch and roll. This way the carpet behaves like > Disney intended ;) > > Instead of the elevator causing a direct change in altitude, it now > causes a pitch rate. The altitude change is now > sin(pitch)*forward_velocity and the speed is now > cos(pitch)*forward_velocity (this way a climb of 90 degrees will > remove the forward component). Pitch is capped at 90 degrees because > I am lazy and didn't want to worry about adjusting the numbers for > when you try a loop. The aileron determines the roll rate, which > feeds into the new heading. As with pitch, roll is capped at 90 > degrees (barrel rolls are fun, but do require some math). Turn_rate > is now sin(roll)*pi/4 radians per second. > > > The updated file can be found at: > > http://homepage.mac.com/eq_fidget/FileSharing1.html > > A screen shot can be found at: > > http://homepage.mac.com/eq_fidget/MagicCarpet.png > > > Give it a try and let me know what you think. > > Jonathan Polley > > p.s. I just use the keyboard, so I haven't a clue how well the rates > work for a joystick. ..could we do _both_ your New Enhanced Magic Carpet, and the Old Style Basic Magic Carpet too? I suspect the old one may be a bit easier to do with _low_ framerates? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) 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
[Flightgear-devel] "Enhanced" Magic Carpet
Since I spend most of my FlightGear time using the Magic Carpet FDM, I decided to make some minor tweaks. I have added the ability of the FDM to change its pitch and roll. This way the carpet behaves like Disney intended ;) Instead of the elevator causing a direct change in altitude, it now causes a pitch rate. The altitude change is now sin(pitch)*forward_velocity and the speed is now cos(pitch)*forward_velocity (this way a climb of 90 degrees will remove the forward component). Pitch is capped at 90 degrees because I am lazy and didn't want to worry about adjusting the numbers for when you try a loop. The aileron determines the roll rate, which feeds into the new heading. As with pitch, roll is capped at 90 degrees (barrel rolls are fun, but do require some math). Turn_rate is now sin(roll)*pi/4 radians per second. The updated file can be found at: http://homepage.mac.com/eq_fidget/FileSharing1.html A screen shot can be found at: http://homepage.mac.com/eq_fidget/MagicCarpet.png Give it a try and let me know what you think. Jonathan Polley p.s. I just use the keyboard, so I haven't a clue how well the rates work for a joystick. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] OpenGL Billiards
I saw this on OpenGL.org: http://www.billardgl.de/index-en.html It is an astoundingly real looking billiards game. Lots of fun. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Publicity
On Sun, 31 Mar 2002 02:00:55 +1100, [EMAIL PROTECTED] (Simon Fowler) wrote in message <[EMAIL PROTECTED]>: > On Fri, Mar 29, 2002 at 07:56:10PM +0100, Arnt Karlsen wrote: > > On Fri, 29 Mar 2002 09:36:47 -0800 (PST), > > Alex Perry <[EMAIL PROTECTED]> wrote in message > > <[EMAIL PROTECTED]>: > > > > > I'm only familiar with the performance of old cards. The Matrox > > > G400 is 'ok'. ..Simon, you have the same card, with 16 MB? > > ...as in V fps at X x Y x Z bpp? > > > With the DRI drivers on my Athlon 550 I could get 20+ fps at > 800x600, 16bpp. This was with low poly-count scenery, though. ..ok. How far can you push it on 8bpp, 15bpp and on 24bpp? > Visual quality was /excellent/ - better than my current Radeon, and > the DRI drivers were excellent, too. > > Simon -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) 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] Re: Configurable mouse ready to go
On Sat, 30 Mar 2002 17:30:49 +, Alasdair Campbell <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Friday 29 March 2002 09:24, you wrote: > > Andy Ross wrote: > > > Norman Vine wrote: > > > > I have always thought that FGFS development has been primarily > > > > aimed at a RAW OPENGL SURFACE which is considerably different > > > > then any Window ! > > > > > > This isn't the case, even in windows. OpenGL rendering (or > > > DirectX, for that matter), is always directed at a window. > > > There's simply no such thing as a "raw surface", even in windows. > > > > I don;t know. Maybe. > > I have been thinking of placing fgfs in the ~/.xinitrc to start > > FlightGear as a window manager. Has anybody tried it already, and if > > so, did it work? > > > > Erik > > This works fine for me... > ... in .bash_profile > alias fly='xinit .fly" > > the file .fly contains: > exec /usr/local/bin/fgfs --fg-root=/usr/local/FlightGear > --airport-id=KSFO --aircraft=c172-3d > > type "fly" and remove the vagarities of the WM. > > -- > Kind Regards, > > Alasdair Campbell ..this is from a text console? Neat! -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) 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] Throttle movement squared
On Sat, 30 Mar 2002 12:01:01 -0800, Andy Ross <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > > As for the Right Thing analysis, though, we're basically SOL on that > already. Real controls have forces that depend on things other than > control position, and PC joysticks don't (well, there's force > feedback, but even that is really limited). For reference, I > introduced the squaring into YASim originally to deal with nosewheel ..is used in RL in Real rc models. ;-) Leave it in. ;-) > steering. Real wheels caster about a point that is not the center of > the wheel. This causes a centering force that increases the faster > the aircraft is moving, and thus "reduces" the authority of the > steering. Without the squaring, there would be too much authority in > the center of travel and the aircraft would be very "grabby" at high > speeds. The only other solution would have been to reduce the range > of travel of the wheel, but that would have reduced turning radius > unacceptably during taxi. .._lock_ that darn tail wheel. For landings and take-offs. Done in RL too. AT-6, P-51, P-47, and many more. Usually unlocked by pushing the stick/yoke fully forward. For locking, there are far more variants, pull handle, flick switch etc etc. ..unlocked, they either pivot 360 dregrees, or are steered. Some pivot less than 360 degrees, against a (steered) spring. ..P-38, Long-Ezes, RV-6A and many more has pivoting nosewheels. Steered thru assymmetric brakeing. Locked on landing and T/O. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) 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] Throttle movement squared
Andy Ross writes: >David Megginson wrote: > > Julian Foad writes: > > > However, I think it would be a good idea to change the default to > > > "false" because this "squared" feature is not "the Right Thing" for > > > a general input axis. It is, like a "dead band", an arbitrary > > > work-around for normally-centred, low-resolution joystick axes, > > > that some people want and others don't. It is a useful feature to > > > have available, but only when the user asks for it. > > > > The thing is that the default bindings have to be for something. If > > you're rebinding anyway, then changing the 'squared' feature isn't a > > lot of extra work. I find that the squared feature makes an enormous > > difference in usability for regular joysticks on the aileron, > > elevator, and rudder axes, enough that it justifies violating the rule > > of least surprise. What does everyone else > >I think it makes more sense to leave the more intuitive linear mapping >as default and flag the squared axes as "special" than the reverse. FWIW Everytime the subject has come up before the linear mapping was deemed the most appropriate. To bad there isn't a way to search the historical archives as there was a fair amount of 'good' discussion each time Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] More animation
The C172 now has animated yokes, rudder pedals (including toe brakes), throttle knob, mixture knob, and nosewheel, in addition to the previous animations. I already know that panel instruments show through the 3D stuff, so please don't remind me. Enjoy. 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] Throttle movement squared
Andy Ross writes: > There's no pleasing everyone. I'm actually of a mind with Julian here > -- the squaring makes sense for auto-centering controls, where it > provides "fine" control in the center of travel while preserving the > full range of control authority. This is a good fit for ailerons, > rudder, elevator, and nosewheel controls. But others, like throttle, > mixture, prop advance, or nozzle direction (harrier, heh) really don't > make much sense with this feature. The default bindings in joystick.xml use squared only for ailerons and elevator. If it seems to be applied anywhere else, then there's something wrong. 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] MSVC6 Build Progress
Bernie Bright wrote: > > You can keep the enum private if you add the following declarations > immediately afterwards: > > struct mouse; > friend struct mouse; > > It seems that MSVC doesn't grant the nested mouse decl. any special > access privileges to its surrounding class. Following up my own reply, I believe that MSVC is correct and that gcc is wrong. According to Stroustrup and the Standard, members of a nested class have no special access to members of the enclosing class, ie a nested class can only access public members of its enclosing class. Cheers, Bernie PS I notice this change has been commited. Thanks. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Throttle movement squared
David Megginson wrote: > Julian Foad writes: > > However, I think it would be a good idea to change the default to > > "false" because this "squared" feature is not "the Right Thing" for > > a general input axis. It is, like a "dead band", an arbitrary > > work-around for normally-centred, low-resolution joystick axes, > > that some people want and others don't. It is a useful feature to > > have available, but only when the user asks for it. > > The thing is that the default bindings have to be for something. If > you're rebinding anyway, then changing the 'squared' feature isn't a > lot of extra work. I find that the squared feature makes an enormous > difference in usability for regular joysticks on the aileron, > elevator, and rudder axes, enough that it justifies violating the rule > of least surprise. What does everyone else There's no pleasing everyone. I'm actually of a mind with Julian here -- the squaring makes sense for auto-centering controls, where it provides "fine" control in the center of travel while preserving the full range of control authority. This is a good fit for ailerons, rudder, elevator, and nosewheel controls. But others, like throttle, mixture, prop advance, or nozzle direction (harrier, heh) really don't make much sense with this feature. I think it makes more sense to leave the more intuitive linear mapping as default and flag the squared axes as "special" than the reverse. As for the Right Thing analysis, though, we're basically SOL on that already. Real controls have forces that depend on things other than control position, and PC joysticks don't (well, there's force feedback, but even that is really limited). For reference, I introduced the squaring into YASim originally to deal with nosewheel steering. Real wheels caster about a point that is not the center of the wheel. This causes a centering force that increases the faster the aircraft is moving, and thus "reduces" the authority of the steering. Without the squaring, there would be too much authority in the center of travel and the aircraft would be very "grabby" at high speeds. The only other solution would have been to reduce the range of travel of the wheel, but that would have reduced turning radius unacceptably during taxi. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Configurable mouse ready to go
On Friday 29 March 2002 09:24, you wrote: > Andy Ross wrote: > > Norman Vine wrote: > > > I have always thought that FGFS development has been primarily aimed > > > at a RAW OPENGL SURFACE which is considerably different then any > > > Window ! > > > > This isn't the case, even in windows. OpenGL rendering (or DirectX, > > for that matter), is always directed at a window. There's simply no > > such thing as a "raw surface", even in windows. > > I don;t know. Maybe. > I have been thinking of placing fgfs in the ~/.xinitrc to start > FlightGear as a window manager. Has anybody tried it already, and if so, > did it work? > > Erik > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel This works fine for me... ... in .bash_profile alias fly='xinit .fly" the file .fly contains: exec /usr/local/bin/fgfs --fg-root=/usr/local/FlightGear --airport-id=KSFO --aircraft=c172-3d type "fly" and remove the vagarities of the WM. -- Kind Regards, Alasdair Campbell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Throttle movement squared
Jim Wilson <[EMAIL PROTECTED]> said: > David Megginson <[EMAIL PROTECTED]> said: > > > > > The thing is that the default bindings have to be for something. If > > you're rebinding anyway, then changing the 'squared' feature isn't a > > lot of extra work. I find that the squared feature makes an enormous > > difference in usability for regular joysticks on the aileron, > > elevator, and rudder axes, enough that it justifies violating the rule > > of least surprise. What does everyone else think? > > > > You know with my sidewinder pp it might be a little nicer without the squared. Hmmm...after trying a landing, I'm not so sure now. Have to do more testing. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Throttle movement squared
David Megginson <[EMAIL PROTECTED]> said: > > The thing is that the default bindings have to be for something. If > you're rebinding anyway, then changing the 'squared' feature isn't a > lot of extra work. I find that the squared feature makes an enormous > difference in usability for regular joysticks on the aileron, > elevator, and rudder axes, enough that it justifies violating the rule > of least surprise. What does everyone else think? > You know with my sidewinder pp it might be a little nicer without the squared. It's been a long time since I've even touched the joystick bindings, but don't remember ever trying it without the "squared" on. What do people think about sharing joystick bindings? Might be a good idea to have a dozen or so joystick.xml files for the most popular sticks and custom binding ideas in the base package. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Publicity
On Fri, Mar 29, 2002 at 07:56:10PM +0100, Arnt Karlsen wrote: > On Fri, 29 Mar 2002 09:36:47 -0800 (PST), > Alex Perry <[EMAIL PROTECTED]> wrote in message > <[EMAIL PROTECTED]>: > > > I'm only familiar with the performance of old cards. The Matrox G400 > > is 'ok'. > > ...as in V fps at X x Y x Z bpp? > With the DRI drivers on my Athlon 550 I could get 20+ fps at 800x600, 16bpp. This was with low poly-count scenery, though. Visual quality was /excellent/ - better than my current Radeon, and the DRI drivers were excellent, too. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04723/pgp0.pgp Description: PGP signature
re: [Flightgear-devel] Throttle movement squared
Julian Foad writes: > However, I think it would be a good idea to change the default to > "false" because this "squared" feature is not "the Right Thing" for > a general input axis. It is, like a "dead band", an arbitrary > work-around for normally-centred, low-resolution joystick axes, > that some people want and others don't. It is a useful feature to > have available, but only when the user asks for it. The thing is that the default bindings have to be for something. If you're rebinding anyway, then changing the 'squared' feature isn't a lot of extra work. I find that the squared feature makes an enormous difference in usability for regular joysticks on the aileron, elevator, and rudder axes, enough that it justifies violating the rule of least surprise. What does everyone else think? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
