[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Mathias Fröhlich <> writes:
> Please use this one. And I believe, without looking into the code,
> that there are likely more of them ...
please apply the attached patch which uses static_cast:
Index: src/MultiPlayer/tiny_xdr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/MultiPlayer/tiny_xdr.cxx,v
retrieving revision 1.2
diff -u -r1.2 tiny_xdr.cxx
--- src/MultiPlayer/tiny_xdr.cxx 2 Dec 2005 00:10:25 - 1.2
+++ src/MultiPlayer/tiny_xdr.cxx 2 Dec 2005 07:12:41 -
@@ -122,42 +122,24 @@
xdr_data_t
XDR_encode_float ( const float & f_Val )
{
-xdr_data_t* tmp;
-
-tmp = (xdr_data_t*) &f_Val;
-return (XDR_encode_int32 (*tmp));
+return (XDR_encode_int32 (static_cast(f_Val)));
}
float
XDR_decode_float ( const xdr_data_t & f_Val )
{
-float* tmp;
-static xdr_data_t dummy;
-
-dummy = XDR_decode_int32 (f_Val);
-tmp = (float*) &dummy;
-return (*tmp);
+return (static_cast (XDR_decode_int32 (f_Val)));
}
/* double */
xdr_data2_t
XDR_encode_double ( const double & d_Val )
{
-xdr_data2_t* tmp;
-
-tmp = (xdr_data2_t*) &d_Val;
-return (XDR_encode_int64 (*tmp));
+return (XDR_encode_int64 (static_cast (d_Val)));
}
double
XDR_decode_double ( const xdr_data2_t & d_Val )
{
-double* tmp;
-static xdr_data2_t dummy;
-
-dummy = XDR_decode_int64 (d_Val);
-tmp = (double*) &dummy;
-return (*tmp);
+return (static_cast (XDR_decode_int64 (d_Val)));
}
-
-
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Mathias Fröhlich <[EMAIL PROTECTED]> writes:
> By the way: the right fix would be:
>
> float
> XDR_decode_float ( const xdr_data_t & f_Val )
> {
> union {
> float f;
> xdr_data_t x;
> } tmp;
> tmp.x = XDR_decode_int32 (f_Val);
> return tmp.f;
> }
>
> Please use this one. And I believe, without looking into the code,
> that there are likely more of them ...
well, this is c++ so the appropriate fix would be
float
XDR_decode_float ( const xdr_data_t & f_Val )
{
return (static_cast (XDR_decode_int32 (f_Val)));
}
i.e., we should be using static_cast.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Selon "Ampere K. Hardraade":
> On November 30, 2005 08:22 pm, Curtis L. Olson wrote:
> > Perhaps explain to them what our code is attempting to do, and then ask
> > if they know of a GLX supported way to do it.
> I would do that if I can. However, I am not a programmer, and nothing in
> RenderTexture.cpp makes any sense to me. :(
>
> What exactly is our code attempting to do?
I won't look at the RenderTexture code. I'd rather do something like :
cvs -z4 -q diff -u bbcache.cxx (in directory
I:\FlightGear\cvs\SimGear\simgear\scene\sky\)
Index: bbcache.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky/bbcache.cxx,v
retrieving revision 1.7
diff -u -r1.7 bbcache.cxx
--- bbcache.cxx 5 Sep 2005 08:17:37 - 1.7
+++ bbcache.cxx 2 Dec 2005 06:58:29 -
@@ -122,7 +122,7 @@
// rt->Reset("rgba tex2D ctt");
// rt->Reset("rgba tex2D");
- if( rt->Initialize(256, 256, true) ) {
+ if( !problemOnRenderTexture && rt->Initialize(256, 256, true) ) {
SG_LOG(SG_ALL, SG_INFO, "bbcache:Initialize sucessfull");
if (rt->BeginCapture())
{
And at other location where RenderTexture is used.
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
By the way: the right fix would be:
float
XDR_decode_float ( const xdr_data_t & f_Val )
{
union {
float f;
xdr_data_t x;
} tmp;
tmp.x = XDR_decode_int32 (f_Val);
return tmp.f;
}
Please use this one. And I believe, without looking into the code, that there
are likely more of them ...
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
On Freitag 02 Dezember 2005 02:29, Melchior FRANZ wrote:
> Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
> this function;
>
> float
> XDR_decode_float ( const xdr_data_t & f_Val )
> {
> float* tmp;
> xdr_data_t dummy;
>
> dummy = XDR_decode_int32 (f_Val);
> tmp = (float*) &dummy;
> return (*tmp);
> }
>
>
> And it turned out that when compiled with gcc 4.0.2 the return
> value wasn't safe. When called three times in a row with different
> values, we would get three times the same result. None of those
> correct. This placed MP aircraft somewhere around the middle
> of our Earth. For those understanding x86 assembler, here is
> the resulting code (why does it not call _Z16XDR_decode_int32RKj?
> "Optimized" away?):
Try with -fno-strict-aliasing
:)
I for myself really like this feature in C/C++ called 'aliasing rules'. It
enables the optimizer to do really good jobs in reodering instructions and
eliminating dead stores which in the end keeps the CPU piplines full.
But be careful with casts like this one ...
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfaults with recent and latest CVS
On Freitag 02 Dezember 2005 04:02, Jim Wilson wrote: > I just checked and this problem is in the 0.9.9 release. > > August 14th there was a patch from Mathias: > > - Introduces a FGScenery::get_elevation_m method which queries the altitude > at a given position. In constrast to the groundcache functions this is the > best choice if you ask for one *single* altitude value. Make use of that > thing in AI/ATC classes and for the current views ground level. At the > current views part the groundcache is reused if possible.- The computation > of the 'current groundlevel' is no longer done on the tilemanagers update > since the required functions are now better seperated. > > I'd put money on the problem originating here. Problem is I don't have > time to look into this right now, but if someone wants to fix what is > probably a source of multiple bug reports this is a good place to start > investigating. Melchior and I are currently investigating. We already have something but not yet something to check in. Sorry that I did not respond to that thread earlier ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
On 12/1/05, bass pumped <[EMAIL PROTECTED]> wrote: > Hi, > > I'm glad to report that I am an idiot and that there is nothing wrong > with the data transmission code. It works fine except > when trying to write throttle over udp. > > For some wierd reason it takes values of one or zero at random when > the throttle is pushed from 0 to 1. For example, when sending a > throttle value of 0.3459 the throttle gets set to 1 but stays at 0 at > most points before and after that. I do remember seeing this same > problem with 9.8 and also remember mentioning to me that this might be > a bug. Would someone be able to give me some pointers on how I may be > able to fix this? > > Thanks, > Is there anybody out there?? << follow up with pink floyd sound effects>>:-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Segfaults with recent and latest CVS
> From: AJ MacLeod > > Last night (using completely up-to-date CVS) I noticed that fgfs segfaults > reliably if one relocates the a/c to KOAK using the "position a/c on ground" > menu. > > After a bit more investigation, it appears that this is caused by a nan in > the > yasim turbulence stuff, because it's being fed garbage. Using a JSBSim a/c, > one is unceremoniously dumped into the sea. > > Starting the sim at KOAK does not display the problem, one must start > somewhere else (anywhere, as far as I can tell) and relocate for the problem > to show. > I just checked and this problem is in the 0.9.9 release. August 14th there was a patch from Mathias: - Introduces a FGScenery::get_elevation_m method which queries the altitude at a given position. In constrast to the groundcache functions this is the best choice if you ask for one *single* altitude value. Make use of that thing in AI/ATC classes and for the current views ground level. At the current views part the groundcache is reused if possible.- The computation of the 'current groundlevel' is no longer done on the tilemanagers update since the required functions are now better seperated. I'd put money on the problem originating here. Problem is I don't have time to look into this right now, but if someone wants to fix what is probably a source of multiple bug reports this is a good place to start investigating. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Curtis L. Olson -- Friday 02 December 2005 02:55: > Here you are just returning the contents of a memory location, not the > pointer itself (aka a value). I know. That's why I had written > > * Melchior FRANZ -- Friday 02 December 2005 01:43: > > > But ... we weren't really returning the address of an auto var. I was just overwhelmed by the joy. And the not so early hour did the rest. 02:00 here in Europe then. Even later now ... -/ > So this should be perfectly safe. My bet is that the value didn't > get decoded properly, but whatever got decoded > incorrectly was returned correctly. XDR_decode_int32() seemed OK, judging by the assembler code. It's a simple byte swapper and I couldn't imagine that the compiler wouldn't get it. But, of course, a compiler bug could also be there. > I'd check the value if (*tmp) before it get's returned to see if > it looks like what you think it should. Yes. I'll do that. It works now, but the fix doesn't make sense. And depending on silly hacks isn't a pleasure. > I'll bail out here before I get to the x86 assembler portion of your > message. :-) I was fluent in 68000 assembler. But I always detested little endianness and couldn't imagine to learn x86 assembler. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Include Saitek X36 with X45 joystick xml file
Take this back.. I'm playing with the X45 now and things are completely different. Might be best to have a seperate X36.xml file. On Thu, 2005-12-01 at 14:42 -0800, [EMAIL PROTECTED] wrote: > >From what I'm seeing, the Saitek X45 is almost identical to the Saitek > X36 > joystick. > > I own both of them and the only differences I'm seeing (from just > looking > at them) is the X45 has a candy blue decals along with more fancy red > lights. > > All in all, they look and almost perform identical. > > This patch merrily adds the X36 system device naming scheme to the > top of the file of > the /usr/share/games/FlightGear/Input/Joysticks/Saitek/X45.xml file. > > I've been testing it & seems to work exceptionally well. > > > -- > Roger > http://www.eskimo.com/~roger/index.html > Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 > > Thu Dec 1 14:39:29 PST 2005 > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Thu Dec 1 18:06:04 PST 2005 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 02 December 2005 01:43:
But ... we weren't really returning the address of an auto var.
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
float
XDR_decode_float ( const xdr_data_t & f_Val )
{
float* tmp;
xdr_data_t dummy;
dummy = XDR_decode_int32 (f_Val);
tmp = (float*) &dummy;
return (*tmp);
}
Here you are just returning the contents of a memory location, not the
pointer itself (aka a value). So this should be perfectly safe. My bet
is that the value didn't get decoded properly, but whatever got decoded
incorrectly was returned correctly. I'd check the value if (*tmp)
before it get's returned to see if it looks like what you think it should.
I'll bail out here before I get to the x86 assembler portion of your
message. :-)
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Melchior FRANZ -- Friday 02 December 2005 01:43:
> But ... we weren't really returning the address of an auto var.
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
float
XDR_decode_float ( const xdr_data_t & f_Val )
{
float* tmp;
xdr_data_t dummy;
dummy = XDR_decode_int32 (f_Val);
tmp = (float*) &dummy;
return (*tmp);
}
And it turned out that when compiled with gcc 4.0.2 the return
value wasn't safe. When called three times in a row with different
values, we would get three times the same result. None of those
correct. This placed MP aircraft somewhere around the middle
of our Earth. For those understanding x86 assembler, here is
the resulting code (why does it not call _Z16XDR_decode_int32RKj?
"Optimized" away?):
non-static "dummy" (-O2) --> doesn't work
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp
0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp
0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x10,%esp
0x0831081c <_Z16XDR_decode_floatRKj+6>: flds 0xfffc(%ebp)
0x0831081f <_Z16XDR_decode_floatRKj+9>: leave
0x08310820 <_Z16XDR_decode_floatRKj+10>: ret
End of assembler dump.
The following was compiled without optimization. The resulting code
works.
non-static "dummy" (-O0) --> works
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x083be33a <_Z16XDR_decode_floatRKj+0>: push %ebp
0x083be33b <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp
0x083be33d <_Z16XDR_decode_floatRKj+3>: sub$0x18,%esp
0x083be340 <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax
0x083be343 <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp)
0x083be346 <_Z16XDR_decode_floatRKj+12>: call 0x83be1b4
<_Z16XDR_decode_int32RKj>
0x083be34b <_Z16XDR_decode_floatRKj+17>: mov%eax,0xfff8(%ebp)
0x083be34e <_Z16XDR_decode_floatRKj+20>: lea0xfff8(%ebp),%eax
0x083be351 <_Z16XDR_decode_floatRKj+23>: mov%eax,0xfffc(%ebp)
0x083be354 <_Z16XDR_decode_floatRKj+26>: mov0xfffc(%ebp),%eax
0x083be357 <_Z16XDR_decode_floatRKj+29>: mov(%eax),%eax
0x083be359 <_Z16XDR_decode_floatRKj+31>: mov%eax,0xffec(%ebp)
0x083be35c <_Z16XDR_decode_floatRKj+34>: flds 0xffec(%ebp)
0x083be35f <_Z16XDR_decode_floatRKj+37>: leave
0x083be360 <_Z16XDR_decode_floatRKj+38>: ret
End of assembler dump.
and this hack (committed to cvs) works with and without optimization.
Making "dummy" static shouldn't be necessary, but
static "dummy"--> works
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp
0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp
0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x4,%esp
0x0831081c <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax
0x0831081f <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp)
0x08310822 <_Z16XDR_decode_floatRKj+12>: call 0x83107e2
<_Z16XDR_decode_int32RKj>
0x08310827 <_Z16XDR_decode_floatRKj+17>: mov%eax,0x8560e00
0x0831082c <_Z16XDR_decode_floatRKj+22>: flds 0x8560e00
0x08310832 <_Z16XDR_decode_floatRKj+28>: leave
0x08310833 <_Z16XDR_decode_floatRKj+29>: ret
End of assembler dump.
clueless
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenGL and new video drivers
On 12/1/05, Richard Bytheway <[EMAIL PROTECTED]> wrote: > Use the latest drivers from the chipset manufacturer's website (nVidia > or ATI). The card manufacturers have been known to "optimise" the > drievrs that they ship on the CD. > > Richard > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Jon S Berndt > > Sent: 01 December 2005 12:09 > > To: Flightgear-devel@flightgear.org > > Subject: [Flightgear-devel] OpenGL and new video drivers > > > > I just installed a new video card (eVGA GeForce 6800) on my > > Windows 2000 box and after installing the drivers I find that > > OpenGL applications crash. I've uninstalled (in safe mode) > > and reinstalled (in safe mode) earlier versions of the > > drivers, but no luck, so far. I am trying to find the > > solution through the manufacturer's web site and support > > mechanism, but any suggestions given here would be much > > appreciated, as well - I know many of you may have gone > > through the same thing. > > > > Jon > > > > > > > This e-mail has been scanned for Bede Scientific Instruments 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 > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Try this as an idea... I did it for the same card, but on win XP box. I installed the version of drivers needed for nvidia stereo graphics... did it in regular mode... i don't know... maybe it might help. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Melchior Franz -- Friday 02 December 2005 01:10: > Modified Files: > tiny_xdr.cxx > Log Message: > returning addresses of auto vars is *dangerous* [...] But ... we weren't really returning the address of an auto var. Making dummy "static" fixes the problem, but the reason must be another one. gcc 4.0.2 bug? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 30, 2005 08:22 pm, Curtis L. Olson wrote: > Perhaps explain to them what our code is attempting to do, and then ask > if they know of a GLX supported way to do it. I would do that if I can. However, I am not a programmer, and nothing in RenderTexture.cpp makes any sense to me. :( What exactly is our code attempting to do? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Curtis L. Olson wrote: John Wojnaroski wrote: One of the knocks from the May show ( which is totally my fault) was the cheezy joystick. So here we were with a full scale 747 glass cockpit with a large screen plasma OTW display running top of the line flight dynamics (JSBSim), world class scenery (FlightGear), high fidelity subsystem models (Mathworks), and a "noodle" for control. If we had had a decent control system, we could have faked the rest ;-) Come on Jack, when are you going to drive up to Mojave with your hacksaw? I can get you past the fence, the rest is up to you. :-) I hear you. There is also a boneyard at El Mirage which has some hulks that go back to WWII. I understand the tv series LOST got some of the props from that site. I ought to give Tom a call now that the daytime temps up there have become bearable. Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim twist/incidence fix
On Thu, 1 Dec 2005, Andy Ross wrote: AN-225/AN-225-yasim.xml The patched Yasim spitted it out again. No twist set in that file, only incidence (4° positive).___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Steve Hosgood wrote: > On Thu, 2005-12-01 at 14:15, Josh Babcock wrote: > >>Just as a note, this functionality already exists. You can use the mouse >>to look around and zoom in. Zoom in, click, zoom out. I do it all the time. >> > > > That's a very good trick (just tried it). Never thought of that one, and > yes, I can even read the buttons on the autopilot by doing that. > > The only trouble with that approach is that you can't both look out of > the window *and* read the autopilot without quite a few mouse-clicks and > some x/X keypresses. > Oh, I forgot to mention, I can do it without any key presses because of this: http://jrbabcock.home.comcast.net/flightgear/scripts/mice.xml I bound my scroll wheel to zoom in look mode. It takes me at most two mouse clicks, two mouse movements and two scroll wheel movements to get there and back. I also changed the head motion bindings a bit. Also, have you considered looking into OpenGC? It won't give you the MSFS like functionality of dragable sub windows, but I think it would allow you to make arbitrary windows to display instruments in cutouts. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] Include Saitek X36 with X45 joystick xml file
>From what I'm seeing, the Saitek X45 is almost identical to the Saitek X36 joystick. I own both of them and the only differences I'm seeing (from just looking at them) is the X45 has a candy blue decals along with more fancy red lights. All in all, they look and almost perform identical. This patch merrily adds the X36 system device naming scheme to the top of the file of the /usr/share/games/FlightGear/Input/Joysticks/Saitek/X45.xml file. I've been testing it & seems to work exceptionally well. -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Thu Dec 1 14:39:29 PST 2005 --- /usr/share/games/FlightGear/Input/Joysticks/Saitek/._X45.xml.orig 2005-12-01 05:30:52.0 -0800 +++ /usr/share/games/FlightGear/Input/Joysticks/Saitek/X45.xml 2005-12-01 05:32:05.0 -0800 @@ -56,6 +56,10 @@ Saitek Saitek X45 Saitek X45 Flight Controller USB Saitek X45 Flight Control Stick + Saitek X36 + Saitek Saitek X36 + Saitek X36 Flight Controller USB + Saitek X36 Flight Control Stick Aileron ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim twist/incidence fix
On Thursday 01 Dec 2005 21:08, Andy Ross wrote: > I've been short of time recently, but Curt is keen on getting > the twist/incidence fix into YASim in time for the next > release. So I've committed it more or less blind. :) > > A quick grep through the source code gives a list of affected > aircraft configurations that I've attached below. The fix is > *supposed* to either do nothing or improve handling of each of > these aircraft, but problems do happen. If anyone is > interested in QA work, could you load up and play with > some/all of these aircraft to validate that nothing weird has > happened? Just make sure that (1) it solves and (2) doesn't > have handling bugs like odd stalling, snap rolls, etc... (or > at least handling bugs that weren't present before). > > The one exception is (I think) the Citation, which had its > twist and incidence numbers negated in CVS prior to the 0.9.9 > release. That one will have to be re-negated now that the fix > is in code. > > Planes affected: > > MiG-15/MiG-15bis-yasim.xml > B-52F/B-52F-yasim.xml > b29/b29-yasim.xml > Hurricane/hurricaneIIb.xml > Citation-Bravo/Citation-Bravo-yasim.xml > dhc2/dhc2F.xml > dc3/dc3.xml > Hunter/hunter-yasim-2t.xml > Hunter/hunter-yasim.xml > YF-23/YF-23-yasim.xml > pa28-161/pa28-161.xml > tu154/tu154.xml > seahawk/seahawk-3d-yasim.xml > seahawk/seahawk-yasim.xml > Citation/Citation-II-yasim.xml > j22/j22-yasim.xml > 747/747.xml > p51d/p51d.xml > AN-225/AN-225-yasim.xml > j3cub/j3cub.xml > Spitfire/spitfireIIa.xml > Spitfire/seafireIIIc.xml > A-10/A-10-yasim.xml > TU-114/TU-114-yasim.xml > b1900d/b1900d.xml > > Thanks, > Andy I'm expecting several of the ones I've done to break, in fact I'm surprised some of them fly at all in view of the -ve incidence they've apparently had but it's better to have the s/w right. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Segfaults with recent and latest CVS
> From: AJ MacLeod > > Last night (using completely up-to-date CVS) I noticed that fgfs segfaults > reliably if one relocates the a/c to KOAK using the "position a/c on ground" > menu. > > After a bit more investigation, it appears that this is caused by a nan in > the > yasim turbulence stuff, because it's being fed garbage. Using a JSBSim a/c, > one is unceremoniously dumped into the sea. > > Starting the sim at KOAK does not display the problem, one must start > somewhere else (anywhere, as far as I can tell) and relocate for the problem > to show. > I cannot rememeber exactly what it is about KOAK but on more than one occasion teleporting it revealed bugs in the tile(manager|cache)/ground elevation parts of the code. It has been a while since I've been into that, but I see that a few months ago some work was done with ground elevation. I'm away from my pc right now, but I wonder: does this problem exist in 0.9.9? Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
John Wojnaroski wrote: One of the knocks from the May show ( which is totally my fault) was the cheezy joystick. So here we were with a full scale 747 glass cockpit with a large screen plasma OTW display running top of the line flight dynamics (JSBSim), world class scenery (FlightGear), high fidelity subsystem models (Mathworks), and a "noodle" for control. If we had had a decent control system, we could have faked the rest ;-) Come on Jack, when are you going to drive up to Mojave with your hacksaw? I can get you past the fence, the rest is up to you. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Curtis L. Olson wrote: Ralf Gerlich wrote: Heh, I'd like to see you looking at the Autopilot _and_ out of the window in a real plane. ;-) As was mentioned, the nearest you could come to the "flow" in the cockpit IRL - not looking at the instrument and still changing its setting - is probably using the keyboard...at least as far as I see that as a pure simulation pilot ;-) You could have *perfect* flight dynamics that nailed all the numbers and all the nuances of the model exactly right, but if you are sitting at your desk, holding a $20 joystick in one hand and typing on your keyboard with another, while peering at a 17" monitor ... it's just not going to ever be all that realistic of an 'experience.' One of the knocks from the May show ( which is totally my fault) was the cheezy joystick. So here we were with a full scale 747 glass cockpit with a large screen plasma OTW display running top of the line flight dynamics (JSBSim), world class scenery (FlightGear), high fidelity subsystem models (Mathworks), and a "noodle" for control. If we had had a decent control system, we could have faked the rest ;-) JW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] YASim twist/incidence fix
I've been short of time recently, but Curt is keen on getting the twist/incidence fix into YASim in time for the next release. So I've committed it more or less blind. :) A quick grep through the source code gives a list of affected aircraft configurations that I've attached below. The fix is *supposed* to either do nothing or improve handling of each of these aircraft, but problems do happen. If anyone is interested in QA work, could you load up and play with some/all of these aircraft to validate that nothing weird has happened? Just make sure that (1) it solves and (2) doesn't have handling bugs like odd stalling, snap rolls, etc... (or at least handling bugs that weren't present before). The one exception is (I think) the Citation, which had its twist and incidence numbers negated in CVS prior to the 0.9.9 release. That one will have to be re-negated now that the fix is in code. Planes affected: MiG-15/MiG-15bis-yasim.xml B-52F/B-52F-yasim.xml b29/b29-yasim.xml Hurricane/hurricaneIIb.xml Citation-Bravo/Citation-Bravo-yasim.xml dhc2/dhc2F.xml dc3/dc3.xml Hunter/hunter-yasim-2t.xml Hunter/hunter-yasim.xml YF-23/YF-23-yasim.xml pa28-161/pa28-161.xml tu154/tu154.xml seahawk/seahawk-3d-yasim.xml seahawk/seahawk-yasim.xml Citation/Citation-II-yasim.xml j22/j22-yasim.xml 747/747.xml p51d/p51d.xml AN-225/AN-225-yasim.xml j3cub/j3cub.xml Spitfire/spitfireIIa.xml Spitfire/seafireIIIc.xml A-10/A-10-yasim.xml TU-114/TU-114-yasim.xml b1900d/b1900d.xml Thanks, Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: GPS/Autopilot
On Wed, 30 Nov 2005 21:27:15 -0600, you wrote: >> aircraft (like GPS in MSFS). Given that the wiring can be potentially >> different with each aircraft, the autopilot code may need customizing >> each time it is placed on a panel. >> > >Ideally the instruments will be as multi-usable as possible, and nasal is >probably ideal to do the plumbing. But the more complex the systems we are >modelling, inevitably the more complex the sim integration will become. Let >me know what you need exported from the GPS and I'll try to oblige (but bear >in mind I sometimes can't get online for a few days at a time). > >BTW, can you remind me again where I can download your autopilot from. http://www.city-gallery.com/vpilot/flightgear/ I've stopped work on it until I learn the new electrical system. I do not need any code from the GPS. I need to know the properties it uses. The digitrak can accept a GPS data signal. It can even work off a Garmin 35, which is a GPS built in to an antenna that just provides ground track and speed. I do not pretend to know how they communicate, but there is no equivalent to a data connection in FlightGear GPS, I have to watch properties in the GPS. If you look at digitrak.nas, it uses properties from /instrumentation/gps/ to maintain GPS track. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Ralf Gerlich wrote: Heh, I'd like to see you looking at the Autopilot _and_ out of the window in a real plane. ;-) As was mentioned, the nearest you could come to the "flow" in the cockpit IRL - not looking at the instrument and still changing its setting - is probably using the keyboard...at least as far as I see that as a pure simulation pilot ;-) This touches on one of the *big* differences between a 'toy' and a real pilot training tool. Having the entire instrument panel available at it's correct scale and location as well as having all the cockpit controls in their right location with the right amount of force feedback is a *huge* thing in terms of making the simulator realistic. This is why all those oddball home/hobby cockpit builders aren't as far off their rockers as it might first appear. They are taking a huge step towards a more realistic simulation environment. And I'm sure all these people have spouses who understand the importance of a realistic flying experience. You could have *perfect* flight dynamics that nailed all the numbers and all the nuances of the model exactly right, but if you are sitting at your desk, holding a $20 joystick in one hand and typing on your keyboard with another, while peering at a 17" monitor ... it's just not going to ever be all that realistic of an 'experience.' I will even go so far as to assert that when creating a 'realistic' flying experience, having the flight model right exactly on, is less important than having a full scale cockpit with controls that have the right amount of force feedback at the right times. An enclosure is a huge addition because it blocks out many of the real world distractions that can snap you back to reality. In addition, assembling a wrap around visual system that projects a field of view that exacatly matches the field of view covered by your display device is also very helpful. All of this is said from the perspective of creating a realistic flying experience. If you are using flightgear for other purposes (such as an engineering simulator or visualization tool, running it on a desktop PC or laptop may be exactly what is needed.) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Steve Hosgood wrote: [SNIP] The only trouble with that approach is that you can't both look out of the window *and* read the autopilot without quite a few mouse-clicks and some x/X keypresses. Heh, I'd like to see you looking at the Autopilot _and_ out of the window in a real plane. ;-) As was mentioned, the nearest you could come to the "flow" in the cockpit IRL - not looking at the instrument and still changing its setting - is probably using the keyboard...at least as far as I see that as a pure simulation pilot ;-) Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plugins, Was: KLN89 GPS added
On Thursday 01 December 2005 11:12, Erik Hofman wrote: > Joacim Persson wrote: > > On Thu, 1 Dec 2005, David Luff wrote: > >> I have no experience of plugin architectures, and don't feel competent > >> to attempt it at the moment. > > > > First of all: there's obviously no panic. (If there were fifty-seven > > hard-linked GPS models, AP's etc it would be a problem, ;) > > Personally I'd much rather see the rest of FlightGear advance in a > direction that this kind of stuff can be done using Nasal (ultimately). > The bonus is that others gain from those additions too. > > Erik I'd hate to see full blown graphical GPS units like the Garmin GNS430 running purely in Nasal unless there are lots of generic C/C++ functions that are being called to do the hard work in the background. In MSFS the GPS units and complex instruments are coded in C and you should see how many CPU cycles they require to update. It would only be a lot worse in Nasal. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
> > So I'm unsure if it is a good idea to include those patches. > > They are harmless, but according to what Melchior has pointed out, some of > the code (what I added to the exceptions classes) is redundant (basically, > what is written there is auto-generated by the compiler unless it has > problems). For the other parts of the patch, it is still relevant. > I'm going to rework it later by eliminating the above redundancy when > I have time (probably this weekend). Actually, I've looked at them now myself, and I ask the patching powers that be to apply it, save for the redundant parts patching the files SimGear/source/simgear/structure/exception.cxx and SimGear/source/simgear/structure/exception.hxx for which Melchior has voiced rightful objection. The 2nd revision of the patch is just a cleanup of some exception throwing and catching, sometimes providing additional diagnostics (e.g., the mysterious "Failed to open file" is now augmented with the actual file location caught). Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Segfaults with recent and latest CVS
Last night (using completely up-to-date CVS) I noticed that fgfs segfaults
reliably if one relocates the a/c to KOAK using the "position a/c on ground"
menu.
After a bit more investigation, it appears that this is caused by a nan in the
yasim turbulence stuff, because it's being fed garbage. Using a JSBSim a/c,
one is unceremoniously dumped into the sea.
Starting the sim at KOAK does not display the problem, one must start
somewhere else (anywhere, as far as I can tell) and relocate for the problem
to show.
AJ
GDB shows;
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225333040 (LWP 32321)]
yasim::Turbulence::getTurbulence (this=0xfc39620, loc=0xa1e0c008,
alt=nan(0x40), up=0xbfc60cc0, turbOut=0xbfc60d10) at
Turbulence.cpp:100
100 static inline float c2fu(unsigned char c) { return
(c+0.5)*(1.0/256); }
(gdb) bt
#0 yasim::Turbulence::getTurbulence (this=0xfc39620, loc=0xa1e0c008,
alt=nan(0x40), up=0xbfc60cc0, turbOut=0xbfc60d10) at
Turbulence.cpp:100
#1 0x081d2843 in yasim::Model::localWind (this=0xfc31bac, pos=0xbfc60df0,
s=0xbfc60f10, out=0xbfc60e00, alt=-1.52296607e-18) at Model.cpp:537
#2 0x081d2113 in yasim::Model::calcForces (this=0xfc31bac, s=0xbfc60f10)
at Model.cpp:399
#3 0x081cf70c in yasim::Integrator::calcNewInterval (this=0xfc31bb0)
at Integrator.cpp:176
#4 0x081c79d4 in yasim::FGFDM::iterate (this=0xfc31ba8, dt=0.0083377)
at FGFDM.cpp:91
#5 0x081c1b70 in YASim::update (this=0xbc03698, dt=0.22352000276247658)
at YASim.cxx:213
#6 0x08051b45 in fgUpdateTimeDepCalcs () at main.cxx:168
#7 0x08052714 in fgMainLoop () at main.cxx:476
#8 0x08089ac9 in fgOSMainLoop () at fg_os_sdl.cxx:232
#9 0x080551b0 in fgMainInit (argc=2, argv=0xbfc61824) at main.cxx:1007
#10 0x080515da in main (argc=-1579106296, argv=0xa1e0c008) at
bootstrap.cxx:193
(gdb)
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3Dcockpitinstruments
Norman Vine wrote: Steve Hosgood writes: Agreed, but if we've got a better scheme, why keep the dialog boxes? Every disjoint aspect to the GUI is just another thing waiting to go wrong, as with the Cessna autopilot where the dialog box is invisibly disconnected from the real autopilot. Steve Apparently I wasn't clear in my initital response FlightGear is more then just a first person sim These other uses may have reasons to want dialog box displays. Again if you don't ike the dialog boxes don't use them but please do not advocate taking them away. FWIW they are also the simplest interface to build and as such are useful in development and debugging And just to put words in Norman's mouth (which I'm sure he will appreciate) :-) ... Norman isn't saying blindly keep dumb or broken stuff. What he is saying is entirely compatible with a discussion about fixing bugs or making the gui work better or be more intuitive or less confusing. There is ample room for this sort of thing. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Possible new thinking for 2D/3Dcockpitinstruments
Steve Hosgood writes: > > Agreed, but if we've got a better scheme, why keep the dialog boxes? > Every disjoint aspect to the GUI is just another thing waiting to go > wrong, as with the Cessna autopilot where the dialog box is invisibly > disconnected from the real autopilot. Steve Apparently I wasn't clear in my initital response FlightGear is more then just a first person sim These other uses may have reasons to want dialog box displays. Again if you don't ike the dialog boxes don't use them but please do not advocate taking them away. FWIW they are also the simplest interface to build and as such are useful in development and debugging Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
> windowmanagers have a "magnifier tool". It can't magnify beyond the screen > resolution of course (640x480 would still be 640x480), but it solves the > problem with blurred tiny characters on small weathered monitors, like is it not the same effect as if the characters are rendered w/o antialiasing? Is it possible to do from within flightgear (to render them in this way)? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenGL and new video drivers
Use the latest drivers from the chipset manufacturer's website (nVidia or ATI). The card manufacturers have been known to "optimise" the drievrs that they ship on the CD. Richard > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jon S Berndt > Sent: 01 December 2005 12:09 > To: Flightgear-devel@flightgear.org > Subject: [Flightgear-devel] OpenGL and new video drivers > > I just installed a new video card (eVGA GeForce 6800) on my > Windows 2000 box and after installing the drivers I find that > OpenGL applications crash. I've uninstalled (in safe mode) > and reinstalled (in safe mode) earlier versions of the > drivers, but no luck, so far. I am trying to find the > solution through the manufacturer's web site and support > mechanism, but any suggestions given here would be much > appreciated, as well - I know many of you may have gone > through the same thing. > > Jon > > This e-mail has been scanned for Bede Scientific Instruments 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenGL and new video card
Jon Berndt writes: > > I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. > Unfortunately, > now OpenGL apps give an application error - they don't even start up. I'm > trying to get > some answers out of the card and driver manufacturer, but if anyone here has > any > suggestions, I'd appreciate hearing them Try installing the latest driver from NVIDIA http://www.nvidia.com/object/winxp_2k_81.95.html HTH Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenGL and new video card
Jon Berndt wrote: I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. Unfortunately, now OpenGL apps give an application error - they don't even start up. I'm trying to get some answers out of the card and driver manufacturer, but if anyone here has any suggestions, I'd appreciate hearing them I could be trying too hard to read between the lines here, but generally with nvidia based cards, it's a really good idea to skip the manufacturer provided drivers (in this case eVGA) and go straight to the nvidia site and get the latest drivers from there. The manufacturer drivers typically are buggy and lag horribly. And I wouldn't be surprised if you'd be hard pressed to find an engineer inside eVGA who's ever heard of opengl. :-) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 14:15, Josh Babcock wrote: > Just as a note, this functionality already exists. You can use the mouse > to look around and zoom in. Zoom in, click, zoom out. I do it all the time. > That's a very good trick (just tried it). Never thought of that one, and yes, I can even read the buttons on the autopilot by doing that. The only trouble with that approach is that you can't both look out of the window *and* read the autopilot without quite a few mouse-clicks and some x/X keypresses. I'll grant you that it does allow you read small buttons and things, it's a great workaround for my main gripe. > I also recognize that > there are a lot of people out there (myself included) that would much > rather use the keyboard, dialog box or pulldown menu. > > In short, It's all well and good to add a functionality, but talking > about taking away a functionality that someone wanted enough to go to > the trouble of creating is not productive. Yeah, OK. Several people have said the same thing now, so obviously the dialog-box option is regarded as a must-have. As you say, let's not throw out something that works. However, can the implementation be changed so that repeats of the autopilot snafu "can't happen"? I suggested in a different reply that maybe the "instrument object" should be in charge of all its related displays - whether that's the OpenGL one, the dialog box or (if it was accepted as a good idea) my separate pop-up window alternate-view idea. > If you don't like it, don't > use it. I get the message! (And I have no problems with that.) Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL and new video drivers
I just installed a new video card (eVGA GeForce 6800) on my Windows 2000 box and after installing the drivers I find that OpenGL applications crash. I've uninstalled (in safe mode) and reinstalled (in safe mode) earlier versions of the drivers, but no luck, so far. I am trying to find the solution through the manufacturer's web site and support mechanism, but any suggestions given here would be much appreciated, as well - I know many of you may have gone through the same thing. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL and new video card
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. Unfortunately, now OpenGL apps give an application error - they don't even start up. I'm trying to get some answers out of the card and driver manufacturer, but if anyone here has any suggestions, I'd appreciate hearing them Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 11:56, Buchanan, Stuart wrote: > > I propose then that every single instrument on the cockpit has the > > ability to be double-clicked, and if so then a separate draggable window > > appears containing a magnified view of that same instrument. > Personally I think this is a fine idea, and indeed gets around the > challenge of having generic dialog boxes that don't match specific > instruments. I'm not sure whether it would need to be magnified, it would > be sufficient just to display them at "normal" resolution (e.g. 128X128 > for most round gauges, 256x60 (ish) for radio stacks). > On my screen I can just about read the round gauges and radios and can't read the compass (on the 3D Cessna). The 2D cockpit is much more legible. Hence the comment about magnification. > However, I don't know whether we can easily display the gauges in windows > by themselves - I'm not familiar with the graphics routines we have, but I > suspect that we are stuck with a single rendered window (as opposed to > dialogs created using GUI widgets), unless we want to take huge perf hits. > I was thinking of using the machine's underlying windows system for these popup per-instrument displays. So that would be GTK or similar on X-Windows and native MS Windows API on M$Windows machines. Alternatively, FlightGear could standardise on GTK for writing the things, and use the fact that there already are "GTK-on-M$Windows" and "GTK-on-MacOS" libraries out there that would take care of the platform-dependencies. > I think the main issue here is with the radios, GPS and autopilot. One > simple solution would be to create a "radio" panel for the plane > containing these components, the visibility of which could be toggled > either from the menu, or from a keypress. > I would leave the OpenGL engine to display the panel as it does now, but some instruments (at the users' discretion) may get duplicated in their draggable, scalable windows. > - The panel couldn't be dragged and dropped - though it could be shifted > using the normal controls. It could, if it was written to employ the ordinary windows-system windows, not be part of the OpenGL main display window. > - I don't think we'd be able to use the double-click idea, as that > normally causes two increments/decrements. > Double-click is normally detected as such really low down and doesn't normally get confused with two single-clicks. > - You can bind the key normally used for the radio dialog to displaying > this specific panel. > Indeed. And there's another possible plus side. There was a thread here a few weeks back about the serious flightsim-heads who like to build physical cockpits and have "real" instruments. Apparently, one way to get the effect of real instruments on a budget is to fit an LCD panel behind cutouts in a fascia plate and display the instruments on that LCD panel. Well, doing this gets a load easier if we've already written the code for every instrument to be able to render itself (magnified) in photo-realistic style in individual windows. The builder of a fake cockpit can then drag all the magnified instruments to wherever they're needed behind the cutouts in the fascia, and hey presto! Job done (pretty much). FlightGear would need to be able to remember at start-up how the user wants to display any instruments that have to start in this "windowed" mode: i.e their magnification (or window-size) and window location (X and Y coords on which physical screen). Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Possible new thinking for 2D/3D cockpitinstruments
On Thu, 2005-12-01 at 11:52, Norman Vine wrote: > I agree that it would be nice to have all instruments etc have interactive > interfaces ala a mouse click, if that is at all realistic, but this does not > necessarily > mean that the dialog boxes should go. > [Flightgear has] a much broader vision then a first person experience of > flight !! > > So if you don't want to use the menu or dialog box interface don't > and they won't spoil your experience :-) > Agreed, but if we've got a better scheme, why keep the dialog boxes? Every disjoint aspect to the GUI is just another thing waiting to go wrong, as with the Cessna autopilot where the dialog box is invisibly disconnected from the real autopilot. Now, maybe if the autopilot dialog box was part of the "autopilot object" so to speak, then such a mistake couldn't happen, and I'd retract my complaint on those grounds at least. It would be neat if the instruments were objects in that way (I suspect they're not currently). If your airplane uses one, its instantiation code would to hook any dialog box interface that it may have into the list of things on a given menu, to start feeding polygons and textures reflecting its state to the OpenGL engine. Later, if that object sees a double-click on itself, it pops open a draggable, scalable window containing a photorealistic image of its front panel, maybe allowing clicks on that window to set its parameters. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
On Thursday 01 December 2005 09:48, Steve Hosgood wrote: > I knew there was an autopilot on the cockpit display, but on my monitor > at home (1024x768) it was a bit difficult to read. This is a "problem" for many instruments in many a/c - on higher resolution screens too. The "solution" is to make frequent use of the FOV keys and the mouse controlled view direction - in other words, "look at" the relevant instrument with the mouse and "zoom in" a little with the x key. Usually, you can find a balance between keeping some kind of visual reference to what the a/c is doing and being able to see the particular instrument or device clearly enough to use. With a little practice, this becomes almost automatic. Outside of a clever head and eye tracking system, I doubt there's a much better way of replicating what your eyes and visual processing systems do so effortlessly IRL. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL and new video card
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. Unfortunately, now OpenGL apps give an application error - they don't even start up. I'm trying to get some answers out of the card and driver manufacturer, but if anyone here has any suggestions, I'd appreciate hearing them Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Steve Hosgood wrote: > Makes me wonder whether there's an excuse for some new thinking on the > subject of UI design, regardless of whether a cockpit is 3D or 2D. > Here's what I propose - please be kind with your comments, I'm not > trying to dictate terms or tread on anyone's toes: > > I propose then that every single instrument on the cockpit has the > ability to be double-clicked, and if so then a separate draggable window > appears containing a magnified view of that same instrument. Obviously, > it will be a *lot* easier to click on buttons and knobs on this > magnified instrument, though some people with colossal screens won't > need to bother and can carry on with the normal-size instruments. > Just as a note, this functionality already exists. You can use the mouse to look around and zoom in. Zoom in, click, zoom out. I do it all the time. > > Just my $0.04 > Now just off to don fireproof suit Heh, I'll try to keep the temperature down :) My personal view is that clicking on a little box on the screen is nothing at all like reaching out and touching/feeling a knob or switch. I don't think that the mouse can come anywhere close to providing a real experience, nor is it capable of even supplying the kind of effectiveness that a ergonomically designed (real) cockpit can provide. This is not to say that I am against making everything in the cockpit clickable, I think it's great that the functionality is there and I try to provide it when I am designing a cockpit, but I also recognize that there are a lot of people out there (myself included) that would much rather use the keyboard, dialog box or pulldown menu. In short, It's all well and good to add a functionality, but talking about taking away a functionality that someone wanted enough to go to the trouble of creating is not productive. If you don't like it, don't use it. If you want something that doesn't already exist, add it. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
I just struck me that it's already possible to get a better look at the instruments, both 2D and 3D, in a very simple way: I think all OS's and windowmanagers have a "magnifier tool". It can't magnify beyond the screen resolution of course (640x480 would still be 640x480), but it solves the problem with blurred tiny characters on small weathered monitors, like mine. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
> Flightgear (and any other flight sim) is trying to reproduce the > experience of flying, both in terms of the flight dynamics and (to a > limited extent) "the whole experience". > > As such, many of the instruments in the virtual cockpit can be > configured with mouse-clicks on the instruments themselves. Some can > also be configured through dialog boxes. > > If FG wants to try and model the "flight experience", these alternative > dialog-box UIs must go. There are no pull-down menus on a real plane, > and no dialog-boxes. Providing them therefore breaks the "flight > experience". > I disagree with the fact that it breaks the flight experience. On the real plane, you extend your hand and twist a knob. Unless you're building an external hardware to augment your flight simulation experience (i.e., actual radio stack panel with the knobs to twist that will interface the PC), you will not have the same experience. Touchscreen might be smth, but most of us don't have a touchscreen either. Doing a mouse click on a radio knob (that is rendered to a tiny circle less than the natural size as the whole screen is less than 1:1 at the default zoom where you see both the window and the radios) is thus significantly more difficult and a more time consuming task. BTW, I am comparing it to real flight experiences. Mostly you even twist these knobs BLIND in the real life, only occasionally glancing at the frequency displays when you make the approximately correct amount of clicks, and look outside. No way to model that w/o a real knob. There is a concept of "flow" in real flying, referring to the flow of your hands around the cockpit, and the only way to train these is to do it in 1:1 scale 3D physical environment. Clicking will not give you the correct flows, because your hand doesn't move the same. Therefore, a way to do it via keyboard shortcuts/dialogs is a reasonable compromise --- you want to be able to make it with an approximately same ease. If, however, you want to do the clicking, that's all right, too --- but please back off from the idea that everything but the clicking must go. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Possible new thinking for 2D/3D cockpitinstruments
Steve Hosgood writes: > > Makes me wonder whether there's an excuse for some new thinking on the > subject of UI design, regardless of whether a cockpit is 3D or 2D. > Here's what I propose - please be kind with your comments, I'm not > trying to dictate terms or tread on anyone's toes: > > Flightgear (and any other flight sim) is trying to reproduce the > experience of flying, both in terms of the flight dynamics and (to a > limited extent) "the whole experience". > > As such, many of the instruments in the virtual cockpit can be > configured with mouse-clicks on the instruments themselves. Some can > also be configured through dialog boxes. > > If FG wants to try and model the "flight experience", these alternative > dialog-box UIs must go. There are no pull-down menus on a real plane, > and no dialog-boxes. Providing them therefore breaks the "flight > experience". Steve I agree that it would be nice to have all instruments etc have interactive interfaces ala a mouse click, if that is at all realistic, but this does not necessarily mean that the dialog boxes should go. Please note the following from http://www.flightgear.org/introduction.html """The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in contributing."" Is a much broader vision then a first person experience of flight !! So if you don't want to use the menu or dialog box interface don't and they won't spoil your experience :-) Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
--- Steve Hosgood <> wrote: > I propose then that every single instrument on the cockpit has the > ability to be double-clicked, and if so then a separate draggable window > appears containing a magnified view of that same instrument. Hi Steve, Personally I think this is a fine idea, and indeed gets around the challenge of having generic dialog boxes that don't match specific instruments. I'm not sure whether it would need to be magnified, it would be sufficient just to display them at "normal" resolution (e.g. 128X128 for most round gauges, 256x60 (ish) for radio stacks). However, I don't know whether we can easily display the gauges in windows by themselves - I'm not familiar with the graphics routines we have, but I suspect that we are stuck with a single rendered window (as opposed to dialogs created using GUI widgets), unless we want to take huge perf hits. I think the main issue here is with the radios, GPS and autopilot. One simple solution would be to create a "radio" panel for the plane containing these components, the visibility of which could be toggled either from the menu, or from a keypress. The downside to this approach are: - each plane would need to have the panel created specifically (unless someone wants to write a generic routine to pick up all the appropriate controls and automagically generate a panel on the fly) - The panel couldn't be dragged and dropped - though it could be shifted using the normal controls. - I don't think we'd be able to use the double-click idea, as that normally causes two increments/decrements. On the plus side: - I think this is quite easy to implement using the existing code, so is fairly "safe" for v1.0.0 - Just about anyone could do it - it's just a bit of messing around with panels, so we can all pitch in. - You can bind the key normally used for the radio dialog to displaying this specific panel. -Stuart ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote: > >It'll still be the same. The C172 doesn't use the generic autopilot code > >- it has a KAP140 autopilot model - which is controlled by clicking the > >buttons on the device in the cockpit. > > This confusion will raise its head every time a person comes to > FlightGear for the first time. They will start with the Cessna and > reach for the Autopilot dialog on the toolbar and wonder why it does > not work. How could they know it is not hooked up for the particular > aircraft Steve Knoblock is replying to my query about bizarre inconsistent autopilot behaviour on the default Cessna. Makes me wonder whether there's an excuse for some new thinking on the subject of UI design, regardless of whether a cockpit is 3D or 2D. Here's what I propose - please be kind with your comments, I'm not trying to dictate terms or tread on anyone's toes: Flightgear (and any other flight sim) is trying to reproduce the experience of flying, both in terms of the flight dynamics and (to a limited extent) "the whole experience". As such, many of the instruments in the virtual cockpit can be configured with mouse-clicks on the instruments themselves. Some can also be configured through dialog boxes. If FG wants to try and model the "flight experience", these alternative dialog-box UIs must go. There are no pull-down menus on a real plane, and no dialog-boxes. Providing them therefore breaks the "flight experience". I'm not saying get rid of the menu-bar as such, because the menu bar has a valid raison d'etre in that it allows you to control aspects of the world outside that are not part of the flying experience. For instance, setting the weather, time of day, type of plane, lat, long and altitude of the plane. That sort of thing has to stay on the menus. Everything else (autopilot, comms and navigation radio settings etc) must go. Trouble is, as Steve comments above (and as caused me to get messed over by the Cessna autopilot fake dialog-box bug in the first place), you can't always read the virtual instruments on the 2D/3D cockpit on smaller screens. For instance I can't read the compass on my screen - the numbers are too small. I propose then that every single instrument on the cockpit has the ability to be double-clicked, and if so then a separate draggable window appears containing a magnified view of that same instrument. Obviously, it will be a *lot* easier to click on buttons and knobs on this magnified instrument, though some people with colossal screens won't need to bother and can carry on with the normal-size instruments. Being able to double-click the comms radio, click on the buttons to tune it and set it up will remove the need for the dialog-box option for setting it. Likewise the autopilot. The user will be able to choose to declutter his/her screen by dismissing the magnified instrument once they're done with it, The smaller version on the instrument panel will of course reflect the same information. Any time you want a closer look, you double-click again. In my case, I'd probably double-click the magnetic compass at takeoff time, drag it to a convenient corner and leave it here for the flight. At least I'd know where I was going! In my case, I'd expect to double-click the altimeter at takeoff time to adjust it for QNH, then dismiss it (I can read the altimeter OK on my screen anyway). The user would have the option to double-click *every* instrument on the panel of course - they'd end up with an awful lot of draggable windows and probably nowhere to put them all, but that's their choice. Users of 'gimp' will know what I mean by this sort of idea. Just my $0.04 Now just off to don fireproof suit Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
On Wed, 2005-11-30 at 16:55, Jon Stockill wrote: > Steve Hosgood wrote: > > > 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried > > it in 0.9.9 with the same results. Not sure. Can't check right now. > > It'll still be the same. The C172 doesn't use the generic autopilot code > - it has a KAP140 autopilot model - which is controlled by clicking the > buttons on the device in the cockpit. Others wrote with much the same info. Guys, this is a 1.0.0 killer. I knew there was an autopilot on the cockpit display, but on my monitor at home (1024x768) it was a bit difficult to read. So, like any random punter would, I figured that the (fully functioning) autopilot dialog box would be an alternative interface to the *same bloody autopilot*. Not so, it appears. If we want to have FG 1.0.0 laughed at by one and all on release day, this is the way to go. Pleeese fix it? Can anyone else point out instances where a non-greyed-out menu item or dialog box offers what looks like an alternative UI for a cockpit instrument, but actually does nothing of the sort? Any other related inconsistencies? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plugins, Was: KLN89 GPS added
Joacim Persson wrote: On Thu, 1 Dec 2005, David Luff wrote: I have no experience of plugin architectures, and don't feel competent to attempt it at the moment. First of all: there's obviously no panic. (If there were fifty-seven hard-linked GPS models, AP's etc it would be a problem, ;) Personally I'd much rather see the rest of FlightGear advance in a direction that this kind of stuff can be done using Nasal (ultimately). The bonus is that others gain from those additions too. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NASAL Scripted Pushback
Carsten Hoefer wrote: BTW: How do I play sounds by Nasal scripts? The same way one would do animations using Nasal; Adjust properties in Nasal (they may be "private" properties in your own subtree of the property list, say /tmp/) and let the sound configuration file act on those properties. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Win32 binary (Was: KLN89 GPS added )
There is a Win32 binary that include the KLN89 here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-win32-20051130.zip As always, it needs a matching base package ( same date ) that you can get via CVS. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Mathias Fröhlich wrote : On Sonntag 27 November 2005 13:14, Frederic Bouvier wrote: Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? Well, ist this possible? I was very excited about that idea, but found in the documentation that the error handler needs to call exit otherwise the calling function of the error handler will call exit past return of the error handler ... And what about a command line option, or a preferences.xml entry, that would disable the whole feature when the end user knows that there is a problem ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
