Re: [Flightgear-devel] Re: Never ending story: Building SimGear CVS under Cygwin
On Sun October 2 2005 10:39, Alex Romosan wrote: Richard Harke [EMAIL PROTECTED] writes: freeglut is an alternative to glut, not to OpenGL mesa is an alternative to OpenGL but it does not have the performance required for FG Normally you need to get 3D accelerated drivers from the vendor of your video card, Nvidia or ATI, for example. this is wrong. i use mesa and the open source radeon 3d drivers (out of mesa) together with xorg and drm from cvs and i can run flightgear on my laptop (an ibm thinkpad t40 with an ati firegl 9000 card) without any problems. the open source drivers are actually faster than the ati ones because i can run them at 16bpp (the ati drivers run only at 24bpp). oh, and i can suspend my laptop which is impossible with the ati drivers. so please don't spread such nonsense. first of all, mesa as an opengl implementation is completely different from mesa providing 3d acceleration. second, for supported cards (which are quite a lot of them, with the exception of nvidia cards) the open source 3d drivers are very good. --alex-- I guess I should have stopped after saying that freeglut does not replace OpenGL. I didn't realize that there was such an improved 3D mesa. I run an Nvidia card and have had reason to look into it. Richard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Never ending story: Building SimGear CVS under Cygwin
freeglut is an alternative to glut, not to OpenGL mesa is an alternative to OpenGL but it does not have the performance required for FG Normally you need to get 3D accelerated drivers from the vendor of your video card, Nvidia or ATI, for example. But I have no idea how to install them under Cygwin On Sat October 1 2005 19:21, Georg Vollnhals wrote: Hi Dave, I installed *all* Cygwin stuff after I got the first errors some time ago because I did not really know what I need. I reinstalled it all now before trying again Graphics (one of many entries, but this should it be) 2.2.0-1 169k freeglut: OpenSourced alternative to the OpenGL Utility Toolkit (GLUT) library but the error did not change afterwards. Regards Georg Are you sure you installed openGL support when you installed Cygwin? It's not installed by default, but is definately needed. I think it's hidden away in the graphics section. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML.cxx
I don't have the original post in front of me but if I remember rightly, just a couple of values from the object are needed for the throw. Why not copy them to local vars, do the XML_ParserFree and then the throw using the local vars? Richard On Tue September 13 2005 00:45, Erik Hofman wrote: Richard Harrison wrote: Surely the XML_ParserFree should be after the throw? (I appreciate this is 99% safe, but it probably isn't the way that things should be done). The problem is that the program doesn't return to the function after throwing an exception. I assume it's best to add the XML_ParserFree() function to atexit() somewhere. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Sun July 31 2005 01:13, Paul Surgeon wrote: On Saturday, 30 July 2005 23:57, Paul Surgeon wrote: There is still a problem. If I roll back extensions.hxx and RenderTexture.cpp then I can compile SimGear. I'll try figure out what's causing it but I'm not very strong at C or C++ Paul GLXPbufferSGIX and GLXPbuffer are not defined anywhere in my nVidia GL headers although they are used throughout the GL headers! I've checked Mesa - same thing. The following lines in extensions.hxx cause a problem because GLXPbufferSGIX is not defined. #ifndef GLXPbuffer #define GLXPbuffer GLXPbufferSGIX #endif That is why I get a : ../../simgear/screen/extensions.hxx:441: error: ISO C++ forbids declaration of `GLXPbufferSGIX' with no type This is confusing. Are GLXPbuffer and GLXPbufferSGIX both supposed to be programmer defined? On my system, I find that both are defined in GL/glxproto.h I have a Debian testing system and I run Nvidia. I don't think this file is from Nvidia, however, but I don't know the exact package. Apparently belongs to some part of glx Richard Harke ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: fgjs bug
On Wednesday 30 March 2005 02:40, Fridtjof Busse wrote:
* Melchior FRANZ [EMAIL PROTECTED]:
I'm trying to use fgjs to calibrate my joystick [...]
You put calibrate under quotes. So you know that fgjs doesn't
calibrate anything?
Yes, I do. Assigning axis/buttons would have been a better
description.
For calibrating use jscal. If you don't have it
and your distribution doesn't offer a package for it, go to
http://sourceforge.net/cvs/?group_id=3063, check out the ruby
module, and find jscal in ruby/utils/. This is from the author of the
Linux kernel joystick system. (There's another calibration utility
based on xml that you better try to avoid. I haven't heard much
positive about it. Nothing, actually.)
The default joystick-calibration-tool on my system is libjsw, though I
have no idea if flightgear is actually able to use it.
So I fetched a package called ff-utils, which contains an (older)
version of jscal:
$ ./jscal /dev/input/js0
Joystick has 11 axes and 34 buttons.
Correction for axis 0 is broken line, precision is 7.
Coeficients are: 896, 1150, 698141, 698141
Correction for axis 1 is broken line, precision is 7.
Coeficients are: 896, 1150, 698141, 698141
Correction for axis 2 is broken line, precision is 0.
Coeficients are: 112, 142, 5534751, 5534751
Correction for axis 3 is broken line, precision is 0.
Coeficients are: 112, 142, 5534751, 5534751
Correction for axis 4 is broken line, precision is 0.
Coeficients are: 112, 142, 5534751, 5534751
Correction for axis 5 is broken line, precision is 3.
Coeficients are: 448, 574, 1394469, 1394469
Correction for axis 6 is broken line, precision is 0.
Coeficients are: 112, 142, 5534751, 5534751
Correction for axis 7 is broken line, precision is 0.
Coeficients are: 0, 0, 536870912, 536870912
Correction for axis 8 is broken line, precision is 0.
Coeficients are: 0, 0, 536870912, 536870912
Correction for axis 9 is broken line, precision is 0.
Coeficients are: 7, 7, 76695844, 76695844
Correction for axis 10 is broken line, precision is 0.
Coeficients are: 7, 7, 76695844, 76695844
Running fgjs afterwards doesn't change anything.
I'll have try a CVS-snapshot though.
The joystick itself works fine, but I'd still like to use fgjs.
$ js_demo
[...]
+JS.0--+
| Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 Ax:5 Ax:6 Ax:7 Ax:8 Ax:9 Ax:10 |
+--+
| 100 -0.0 -0.0 +1.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 +0.1 +0.1 |
[...]
Anything I can do to fix this?
Yes, calibrate the joystick. And forget fgjs, which is IMHO only
useful to get at least rudimentary support in fgfs from unsupported
joysticks. Better take an existing configuration file ($FG_ROOT/Inpur/
Joysticks/), make a copy where you set the correct name (as reported
by fg_demo), adapt the axes and buttons if necessary, and then add a
line for this file $FG_ROOT/joysticks.xml. Then check with this line
if fgfs finds the joystick:
Already did that to get at least basic support for my joystick. But I
have really lots of axes and there's no joystick that's related to
the one I'm using (the X45 has much fewer axis/buttons).
I thought fgjs might be able to help me.
$ fgfs --log-level=info 21|awk '!/^ /{i=0}/^Looking for/{i=1}//
{if(i)print}'
OK, I'll try that, thanks for the help.
I'm not familiar with your joystick model but apparently it is similar
to the X45. fgjs will not work with X45 because of the way a couple
of mode switches work. They always have at least one of the bits on
which fgjs sees as a button push so that it just skips down the list.
The problem is that fgjs just checks for a button being on, not a change
of the bit value. It other words, fgjs assumes that normally all buttons
are off. I was going to fix this at one time but then I realized I didn't
really need fgjs.
Richard Harke
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C++ question - solved
On Wednesday 19 January 2005 06:53, Christian Mayer wrote:
Thanks for all the replies.
They brought me on the right track.
The solution I've got now is also known as the Barton and Nackman Trick.
It's a bit pervert - but totaly legal C++ code:
templatetypename leaftype
class A
{
leaftype asLeaf()
{ return static_castleaftype(*this); }
public:
bool foo( leaftype bar )
{ return asLeaf().foo( bar ); }
};
class B : public AB
{
public:
bool foo( B bar )
{ return /*...*/; }
}
The Barton and Nackman trick is important to avoid virtual function
where they are too slow (i.e. when the additional pointer lookup hurts
performance)
CU,
Christian
Thanks for sharing this. This prompted me to go look at my copy
of Barton and Nackman (Scientific and Engineering C++). Reminds that it
is a rather good book and I should read it more often. But I couldn't find
this trick in more than a half day trying.
Richard Harke
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thursday 16 December 2004 04:06, Jon Berndt wrote: True, I've seen both. JSBSim has used both, and we accept both, but normalized units are anything but normal - you have to provide a range for it to mean anything, and as far as I can tell, there is no standard here. It's defined on a per-aircraft basis. And, as I have pointed out above, for aerosurfaces it requires an intermediate conversion twice. A rotation whether in degrees or radians only makes sense if the axis of rotation is specified. This would have to be on a per aircraft basis. Also I'm sure that many if not most control surfaces do not simply rotate about a single axis but involve sliding motion and rotation of multiple parts and often, rotation while sliding. I think a normalized value makes good sense. For complicated cases, on the FDM side, it can be converted into an index into a table of effective force while on the GUI side, it could index into a table of drawing routines. Just my 2 cents. Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nurbs headaches
On Monday 08 November 2004 13:28, Christian Mayer wrote: Curtis L. Olson schrieb: Christian Mayer wrote: Well, googling for bezier 2d gave me: http://www.cs.wpi.edu/~matt/courses/cs563/talks/surface/bez_surf.html (not exactly what you are looking for, but it looked like an easy to read memory refresher) It would be great if I didn't have to write and debug my own bezier library, are you aware of any existing code that could help me out here? I don't know any implementations, but I'm sure Norman's sources are as good as they allways are. :) OpenGl has some NURBS support. Look for gluNurbs* These are listed in my 1.1 reference manual so they are not that recent. Also, the book An introduction to NURBS promises C code at http://www.mkp.com/NURBS/nurbs.html I have never looked at that site so I make no promise. Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Rebuild
I have found a bug in libGLcore.so from Nvidia for ia64. I think I have a work-around that involves a small change (temporary) in simgear. after making the changes, I deleted the .o and corresponding .a and ran make. Seemed to work fine and just re-compiled the one file and did the one link. Then I deleted fgfs and ran make on flightgear and it seems to be recompiling the whole world. I didn't change any flightgear files so I am rather puzzled. Is this normal bahavior for flightgear make? Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rebuild
On Tuesday 29 June 2004 09:57 pm, Tony Peden wrote: If you change an oft-included header in simgear, this is pretty normal. Well, that would explain it. I did do a make install on simgear I guess I should have just cp'ed the relevant .a file. On Tue, 2004-06-29 at 20:02, Richard Harke wrote: I have found a bug in libGLcore.so from Nvidia for ia64. I think I have a work-around that involves a small change (temporary) in simgear. after making the changes, I deleted the .o and corresponding .a and ran make. Seemed to work fine and just re-compiled the one file and did the one link. Then I deleted fgfs and ran make on flightgear and it seems to be recompiling the whole world. I didn't change any flightgear files so I am rather puzzled. Is this normal bahavior for flightgear make? Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction(patch included)
On Sunday 27 June 2004 03:28 pm, Alex Romosan wrote: Frederic Bouvier [EMAIL PROTECTED] writes: Alex Romosan wrote: Frederic Bouvier writes: The fact that you are using the function pointer *after* dlclose is as broken as Erik's version. This is not good practise to bet on side effects that are beyond your control. _NO_, because the pointer now points to an object in memory in the scope of the program which is guaranteed to be always the same. this is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish i still had an irix machine So you're just guessing. The cvs version is assured to work on any system. guessing about what? the version in cvs is ugly because it never calls dlclose(). the last version i proposed assigns a pointer in the scope of the program which is guaranteed to stay same for the lifetime of the program (even after calling dlclose()). no guessing there. the irix 5.3 man page states that dlopen(0,...) is supported on irix as well so that solution is portable. i wish i still had an irix machine so i could look if RTLD_DEFAULT is defined in dlfcn.h. if it is, we can then call dlsym(RTLD_DEFAULT,func) directly. --alex-- In dlfcn.h we find: /* Unmap and close a shared object opened by `dlopen' The handle cannot be used again after calling `dlclose'. */ extern int dlclose (void *__handle) __THROW; Also RTLD_DEFAULT is a gnu extension and requires __USE_GNU to be defined Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction(patch included)
On Sunday 27 June 2004 07:18 pm, Alex Romosan wrote: Richard Harke [EMAIL PROTECTED] writes: In dlfcn.h we find: /* Unmap and close a shared object opened by `dlopen' The handle cannot be used again after calling `dlclose'. */ extern int dlclose (void *__handle) __THROW; Also RTLD_DEFAULT is a gnu extension and requires __USE_GNU to be defined are you talking about linux or irix? the above looks like the dlfcn.h from glibc on linux. --alex-- This is on Linux ia64 My main point was intended to be the comment which says don't use the handle after dlclose Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear runs cleanly on AMD64 in 64 bit mode
On Saturday 12 June 2004 01:47 pm, Arnt Karlsen wrote: On Sat, 12 Jun 2004 10:00:44 -0700, Andy wrote in message [EMAIL PROTECTED]: Alex Perry wrote: I just noticed that the Debian autobuilder had quietly gone off and made AMD64 packages to run FlightGear 0.9.4 and all its dependencies in 64-bit. I did sudo apt-get install flightgear and fgfs ... and it ran fine. ..anyone else on 64-bit iron out there? I have been running FG on ia64 since last Sept. I had a problem (don't remember what) with the deb package but I was able to build the CVS version just fine. A weirdness with joystick, (Saitek X45) had to physically connect to UBS port after modprobe'ing joydev. Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autoconf, autoheader, automake, etc.
Actually There is a book from NewRiders GNU Autoconf, Automake, and Libtool By Gary V. Vaughn, et. al. www.newriders.com Before you rush out and buy it, the Linux Users Group of Davis had a presentation on autotools in March. Try www.lugod.org/presentations/autotools/presentation/autotools.pdf There is also a sibling file autotools.sxi which I think is for the Openoffice.org presentation app. I think this presentation is a much better starting point than the book. Richard Harke On Saturday 29 May 2004 12:45 pm, Jon Berndt wrote: I've looked in a few places, but can't find a definitive reference on automake, autoconf, etc. There don't seem to be any O'Reilly books on this, either! Anyone have any suggestions? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] whitepsace in filename
On Linux or unix machine, you should be able to do: mv eicas background.rgb eicas_background.rgb Richard On Wednesday 31 March 2004 01:53 am, Martin Spott wrote: Hello, would someone please rename the following filename: Aircraft/737/Instruments/Textures/eicas background.rgb and modify the references it belongs to ? Martin. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bizaare happenings at KSMF
I noticed these things last fall and posted to the users forum, refering to a low rider effect I have tryed again to see if the problem is still there. It is, but the symptoms fluctuate so much its hard to be precise. Starting with things that seem to be more consistent, is the drift in yaw. This is just after fg starts and with power at idle This even occurs with the engine off and also with the brakes on. The direction does go with the rudder but is not zero even when the rudder is neutral. The other consistent thing is the ball jumps erratically. Less consistently, I have had it start rocking longitudinally, sometimes so bad it flips over or stands on its prop. Earlier this evening it seemed to be related to the drift in yaw I would alternate the rudder and when it drifted thru line up with the runway, it would begin to rock. In several instances, the tail hit the ground. In one particularly bizaare move, it jumped about 30 feet off the end of the runway, tho remaining upright. While typing, I have fg run and the plane has wandered off into the weeds. Amazingly, the frame rate has more than doubled as a result. Is the runway really such a difficult graphic? Also, I had two light planes land over my head while doing this. This a CVS version from about two weeks ago. The Entries file in source/CVS is dated Feb 18 Command line is fgfs --fg-root=FG/data --airport=KSMF --timeofday=noon Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Seg fault in nasal
I have found the bug leading to a seg fault that I reported previously (on the flightgear-users list). Though this is on an ia64, the bug is not completely architecture dependant. In misc.c in simgear/nasal in the function naNum add the line r.ref.reftag = ~NASAL_REFTAG; ahead of the line r.num = num; For several architectures, reftag does not overlay num and needs to be explicitly set. Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
