Re: [Flightgear-devel] Licensing issues
John Check wrote: Theres nothing abot the licensing terms of the base package that would prevent the scenario of which he speaks. FWIW Erik, I understand how you feel, but OTOH thats the GPL. Yep, GPL covers almost anything, but I'm not so sure LGPL does. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing Unveils Bird of Prey Stealth TechnologyDemonstrator
Norman Vine wrote: FYI http://www.boeing.com/news/releases/2002/q4/nr_021018m.html Heh, the next thing will be to remove that glass shell in the front and call it a AUV ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Wright flyer wing warping (Jim Wilson
Dear Jim, I checked myself several times but cannot find a mistake at the moment. Somebody else with a FEM package could check my calculations. I fiddled a bit around with the constraints but these do not make much difference. I also got your model running. It looks very nice indeed. The model is also behaving much more friendly then the java script program from the Internet as was already mentioned before. kind regards, Marcel Wittebrood ADSE -Original Message- From: [EMAIL PROTECTED] [mailto:flightgear-devel-request@;flightgear.org] Sent: vrijdag 18 oktober 2002 19:36 To: [EMAIL PROTECTED] Subject: Flightgear-devel digest, Vol 1 #1081 - 15 msgs Send Flightgear-devel mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://mail.flightgear.org/mailman/listinfo/flightgear-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Flightgear-devel digest..." Today's Topics: 1. Re: runway lighting (Curtis L. Olson) 2. Re: runway lighting (Curtis L. Olson) 3. Re: Wright flyer wing warping (Jim Wilson) 4. Re: Elite Simulator (Alex Perry) 5. Re: Elite Simulator (Alex Perry) 6. Re: Licensing issues (Alex Perry) 7. Re: Elite Simulator (Curtis L. Olson) 8. Re: runway lighting (David Megginson) 9. Re: runway lighting (Curtis L. Olson) 10. Change in runway type... (Fabien ILLIDE) 11. Re: Elite Simulator (David Megginson) 12. Re: Elite Simulator (David Megginson) 13. Re: runway lighting (Frederic BOUVIER) 14. re: Change in runway type... (David Megginson) 15. Re: Licensing issues (Brandon Bergren) --__--__-- Message: 1 Date: Fri, 18 Oct 2002 07:35:34 -0500 From: "Curtis L. Olson" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] runway lighting Reply-To: [EMAIL PROTECTED] John Check writes: > > If you want to fly this yourself, you can grab: > > > > http://www.flightgear.org/tmp/KSFO.btg.gz > > > > Does anybody have a copy or a proper link? it seems to be 404. My fault, didn't push my change out to the web server ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org --__--__-- Message: 2 Date: Fri, 18 Oct 2002 07:38:23 -0500 From: "Curtis L. Olson" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] runway lighting Reply-To: [EMAIL PROTECTED] Martin Spott writes: > Curt, > > > No one commented on my last runway lights message so I figured I'd > > send some more picts of the latest: > > Yesterday night it was simply too late to give appropriate comment > I am _really_ amazed. In my eyes this this is the most valuable visual > feature in FlightGear since I'm watching this project. > > > Essentially the state of things is that if we regen all the airports > > they will all get as much lighting as I've implimented. > > but in reality not every airport _has_ lightning. Mybe it would be > appropriate to stick to the information on airport lightning that is present > in the airport database, Right, our database does have lighitngn information, and the airport generator honors it. If you fly around SFO with the new lighitng you'll see an ALSF-II approach, an SSALS, and SSALR, and a couple REIL's. Also you'll see some runways with centerlines, some without, and some runways have touchdown zone lighting. Our world (once I finishe with the other lighting schemes, and once it's regenerated) will be as close to reality as our database allows. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org --__--__-- Message: 3 Date: Fri, 18 Oct 2002 13:24:16 - To: <[EMAIL PROTECTED]> Subject: Re: [Flightgear-devel] Wright flyer wing warping From: "Jim Wilson" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Very interesting, but from the photos there seems to be much more movement than that. Are you sure you are scaled correctly? Also remember that Orville claims the leading edges stayed parallel (although I suppose at 0.8mm it'd be hard to tell). Best, Jim Marcel Wittebrood <[EMAIL PROTECTED]> said: > Sorry, I made a mistake, > =20 > I contour plotted the beam bending moment in the last mail and wrote = > some nonsense to talk the large deflection value straight.:-)) > =20 > This picture is probably correct=20 > =20 > Only 6.011 mm at the back spar tip, 0.8 mm at the front spar tip. So for = > 80 N force input you get about atan((6.011-0.8) /1180) =3D 0.25 deg
re: [Flightgear-devel] breakage
John Check writes: > Latest cvs build falls down with: > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o pt_lights.o `test -f > 'pt_lights.cxx' || echo './'`pt_lights.cxx > pt_lights.cxx: In function `ssgTimedSelector* gen_rabbit_lights(const >point_list&, const point_list&, const int_list&, const int_list&, const >std::string&, float*)': > pt_lights.cxx:304: `cout' undeclared (first use this function) > pt_lights.cxx:304: (Each undeclared identifier is reported only once for each >function it appears in.) > make[2]: *** [pt_lights.o] Error 1 > > > commenting out the cout's in pt_lights.cxx gets me past it. I had the same problem last night, but didn't have a chance to commit my changes. It's fixed in CVS now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
John Check writes: > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > -I/usr/X11R6/include -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 > -D_REENTRANT -c -o main.o `test -f 'main.cxx' || echo './'`main.cxx > main.cxx:152: `void (*glPointParameterfEXT)(unsigned int, float)' redeclared > as >different kind of symbol > /usr/X11R6/include/GL/gl.h:2519: previous declaration of `void >glPointParameterfEXT(unsigned int, float)' > main.cxx:153: `void (*glPointParameterfvEXT)(unsigned int, const GLfloat*)' >redeclared as different kind of symbol > /usr/X11R6/include/GL/gl.h:2520: previous declaration of `void >glPointParameterfvEXT(unsigned int, const GLfloat*)' I didn't get this one. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel font crash
On Fri, Oct 18, 2002 at 04:05:52PM -0400, David Megginson wrote: > Andy Ross writes: > > > The attached one-liner fixes the problem, but someone with more > > knowlege should probably think of a better solution. We shouldn't be > > initializing static state from within a member initializer. Maybe > > there's a need for a "panel subsystem" as separate from the individual > > FGPanel objects? > > It's a hard call. The J3Cub shows that it's possible to have a true > 3D panel, using 3D models rather than a projected 2D panel. We'll > still need the 2D panel for some applications, but I'd like to start > deemphasizing it when we can. > The 3D panel is almost unusable for me (with a K7 550 and an original Radeon) - the performance hit is just too great, and it still occasionally overloads my system and locks up (a driver problem, admittedly, but combined with the performance hit it's a serious problem). It'd be very nice if all the aircraft had a 2d panel that could be switched to without having to fiddle with properties, even if the panel was just the c172/310 default . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08975/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] breakage
On Fri, Oct 18, 2002 at 11:16:25PM -0400, John Check wrote: > On Friday 18 October 2002 11:02 pm, John Check wrote: > > Latest cvs build falls down with: > > > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > > -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o pt_lights.o `test -f > > 'pt_lights.cxx' || echo './'`pt_lights.cxx > > pt_lights.cxx: In function `ssgTimedSelector* gen_rabbit_lights(const > >point_list&, const point_list&, const int_list&, const int_list&, const > >std::string&, float*)': > > pt_lights.cxx:304: `cout' undeclared (first use this function) > > pt_lights.cxx:304: (Each undeclared identifier is reported only once for > > each function it appears in.) > > make[2]: *** [pt_lights.o] Error 1 > > > > > > commenting out the cout's in pt_lights.cxx gets me past it. > > > > Plib Simgear and FG from CVS > > > > > Okay now it dies with: > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > -I/usr/X11R6/include -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 > -D_REENTRANT -c -o main.o `test -f 'main.cxx' || echo './'`main.cxx > main.cxx:152: `void (*glPointParameterfEXT)(unsigned int, float)' redeclared > as >different kind of symbol > /usr/X11R6/include/GL/gl.h:2519: previous declaration of `void >glPointParameterfEXT(unsigned int, float)' > main.cxx:153: `void (*glPointParameterfvEXT)(unsigned int, const GLfloat*)' >redeclared as different kind of symbol > /usr/X11R6/include/GL/gl.h:2520: previous declaration of `void >glPointParameterfvEXT(unsigned int, const GLfloat*)' > Are you using Mesa 4, or Mesa 3? I've had some problems building Simgear and FlightGear recently, due to (apparently) some changes between Mesa 3.4 and Mesa 4.0 (which I'm using through the DRI cvs tree now). I'm not sure if this is a bug with Mesa 4.0 or with FlightGear - I'm investigating it at the moment . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08976/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] breakage
On Sat, Oct 19, 2002 at 08:53:54PM +1000, Simon Fowler wrote: > On Fri, Oct 18, 2002 at 11:16:25PM -0400, John Check wrote: > > On Friday 18 October 2002 11:02 pm, John Check wrote: > > > Latest cvs build falls down with: > > > > > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > > > -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o pt_lights.o `test -f > > > 'pt_lights.cxx' || echo './'`pt_lights.cxx > > > pt_lights.cxx: In function `ssgTimedSelector* gen_rabbit_lights(const > > >point_list&, const point_list&, const int_list&, const int_list&, const > > >std::string&, float*)': > > > pt_lights.cxx:304: `cout' undeclared (first use this function) > > > pt_lights.cxx:304: (Each undeclared identifier is reported only once for > > > each function it appears in.) > > > make[2]: *** [pt_lights.o] Error 1 > > > > > > > > > commenting out the cout's in pt_lights.cxx gets me past it. > > > > > > Plib Simgear and FG from CVS > > > > > > > > > Okay now it dies with: > > > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > > -I/usr/X11R6/include -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 > > -D_REENTRANT -c -o main.o `test -f 'main.cxx' || echo './'`main.cxx > > main.cxx:152: `void (*glPointParameterfEXT)(unsigned int, float)' redeclared > > as > >different kind of symbol > > /usr/X11R6/include/GL/gl.h:2519: previous declaration of `void > >glPointParameterfEXT(unsigned int, float)' > > main.cxx:153: `void (*glPointParameterfvEXT)(unsigned int, const GLfloat*)' > >redeclared as different kind of symbol > > /usr/X11R6/include/GL/gl.h:2520: previous declaration of `void > >glPointParameterfvEXT(unsigned int, const GLfloat*)' > > > Are you using Mesa 4, or Mesa 3? I've had some problems building > Simgear and FlightGear recently, due to (apparently) some changes > between Mesa 3.4 and Mesa 4.0 (which I'm using through the DRI cvs > tree now). > Actually, I just got the same error with (according to GL/gl.h) Mesa 3.4, so that's not it. Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08977/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] breakage
On Sat, Oct 19, 2002 at 09:55:46PM +1000, Simon Fowler wrote: > On Sat, Oct 19, 2002 at 08:53:54PM +1000, Simon Fowler wrote: > > On Fri, Oct 18, 2002 at 11:16:25PM -0400, John Check wrote: > > > Okay now it dies with: > > > > > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > > > -I/usr/X11R6/include -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 > > > -D_REENTRANT -c -o main.o `test -f 'main.cxx' || echo './'`main.cxx > > > main.cxx:152: `void (*glPointParameterfEXT)(unsigned int, float)' redeclared > > > as > > >different kind of symbol > > > /usr/X11R6/include/GL/gl.h:2519: previous declaration of `void > > >glPointParameterfEXT(unsigned int, float)' > > > main.cxx:153: `void (*glPointParameterfvEXT)(unsigned int, const GLfloat*)' > > >redeclared as different kind of symbol > > > /usr/X11R6/include/GL/gl.h:2520: previous declaration of `void > > >glPointParameterfvEXT(unsigned int, const GLfloat*)' > > > > > Are you using Mesa 4, or Mesa 3? I've had some problems building > > Simgear and FlightGear recently, due to (apparently) some changes > > between Mesa 3.4 and Mesa 4.0 (which I'm using through the DRI cvs > > tree now). > > > Actually, I just got the same error with (according to GL/gl.h) Mesa > 3.4, so that's not it. > And it went away again, when I stopped defining GL_GLEXT_LEGACY . . . In Mesa 3.4's gl.h glPointParameterfvEXT is wrapped in a #ifdef GL_GLEXT_LEGACY (as is glActiveTextureARB in Mesa 4.0, which is why I was playing around with it). I got the error above when GL_GLEXT_LEGACY was defined, and it went away without it. Anyone with more knowledge of OpenGL got any clues? Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08978/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] breakage
Simon Fowler wrote: Actually, I just got the same error with (according to GL/gl.h) Mesa 3.4, so that's not it. And it went away again, when I stopped defining GL_GLEXT_LEGACY . . In Mesa 3.4's gl.h glPointParameterfvEXT is wrapped in a #ifdef GL_GLEXT_LEGACY (as is glActiveTextureARB in Mesa 4.0, which is why I was playing around with it). I got the error above when GL_GLEXT_LEGACY was defined, and it went away without it. Anyone with more knowledge of OpenGL got any clues? Well, I know it started as glPointParameterfvSGIS when SGI invented it, then it became glPointParameterfvEXT because it was an extension if nVidea and now it looks like the OpenGL ARB has adopted this feature and called it glPointParameterfvARB ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Wright flyer wing warping (Jim Wilson
On Sat, 19 Oct 2002 11:18:34 +0200, "Marcel Wittebrood" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Dear Jim, > > I checked myself several times but cannot find a mistake at the > moment. Somebody else with a FEM package could check my calculations. ..is not going to happen unless someone tells me where I can find it. I have FElt, http://felt.sourceforge.net/ > I fiddled a bit around with the constraints but these do not make much > difference. > > I also got your model running. It looks very nice indeed. The model is > also behaving much more friendly then the java script program from the > Internet as was already mentioned before. > > kind regards, > > Marcel Wittebrood ADSE > -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
John Check wrote: > Latest cvs build falls down with: > > pt_lights.cxx:304: `cout' undeclared (first use this function) You're using gcc 3.2 I assume? It's a namespace issue. The C++ standard library naming is stricter now. You need to use std::cout, or insert a "using namespace std;" above the usage. > main.cxx:153: >void (*glPointParameterfvEXT)(unsigned int, const GLfloat*) > /usr/X11R6/include/GL/gl.h:2520: >glPointParameterfvEXT(unsigned int, const GLfloat*)' OK, this one looks kinda wrong. Our code is defining its own copy of the glPointParameter function pointers, when they've already been declared as regular functions in gl.h. What's the purpose here? All of the declared extensions are supposed to be defined in the ARB glext.h header, I believe. User-level code shouldn't have to play this kind of game anymore. It's worth pointing out that I don't see this issue. I have the NVidia drivers installed, which might have differeing header behavior? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
Andy Ross writes: > John Check wrote:> > > main.cxx:153: > >void (*glPointParameterfvEXT)(unsigned int, const GLfloat*) > > /usr/X11R6/include/GL/gl.h:2520: > >glPointParameterfvEXT(unsigned int, const GLfloat*)' > > OK, this one looks kinda wrong. Our code is defining its own copy of > the glPointParameter function pointers, when they've already been > declared as regular functions in gl.h. What's the purpose here? All > of the declared extensions are supposed to be defined in the ARB > glext.h header, I believe. User-level code shouldn't have to play > this kind of game anymore. This is true in the non-windows world, but since the distributed M$oft OpenGL is version 1.1 this is a major pain to do easily in a cross platform way. FWIW making this transparent is what the extgl package in the Clouds3D directory is trying to do. Perhaps it is time to bring up cross platform OpenGL extension handling on the PLIB list. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
diff -u -w -r1.31 main.cxx
--- main.cxx17 Oct 2002 04:34:32 - 1.31
+++ main.cxx19 Oct 2002 18:38:22 -
@@ -141,16 +141,16 @@
typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC)(GLenum pname,
const GLfloat *params);
- PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT = 0;
- PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT = 0;
+ PFNGLPOINTPARAMETERFEXTPROC gl_PointParameterfEXT = 0;
+ PFNGLPOINTPARAMETERFVEXTPROC g_lPointParameterfvEXT = 0;
#elif linux
#include
typedef void (* OpenGLFuncExt)(GLenum pname, GLfloat param);
typedef void (* OpenGLFuncExtv)(GLenum pname, const GLfloat *params);
- OpenGLFuncExt glPointParameterfEXT = 0;
- OpenGLFuncExtv glPointParameterfvEXT = 0;
+ OpenGLFuncExt gl_PointParameterfEXT = 0;
+ OpenGLFuncExtv gl_PointParameterfvEXT = 0;
#endif
float default_attenuation[3] = {1.0, 0.0, 0.0};
@@ -743,8 +743,8 @@
glEnable(GL_POINT_SMOOTH);
float quadratic[3] = {1.0, 0.001, 0.001};
// makes the points fade as they move away
-glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
-glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0);
+gl_PointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
+gl_PointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0);
glPointSize(4.0);
}
@@ -774,7 +774,7 @@
#ifdef FG_EXPERIMENTAL_LIGHTING
if (glutExtensionSupported("GL_EXT_point_parameters")) {
-glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT,
+gl_PointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT,
default_attenuation);
}
@@ -1578,14 +1578,14 @@
#ifdef FG_EXPERIMENTAL_LIGHTING
// get the address of our OpenGL extensions
# ifdef WIN32
-glPointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
+gl_PointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
wglGetProcAddress("glPointParameterfEXT");
-glPointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
+gl_PointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
wglGetProcAddress("glPointParameterfvEXT");
# elif linux
-glPointParameterfEXT = (OpenGLFuncExt)
+gl_PointParameterfEXT = (OpenGLFuncExt)
glXGetProcAddressARB((GLubyte *)"glPointParameterfEXT");
-glPointParameterfvEXT = (OpenGLFuncExtv)
+gl_PointParameterfvEXT = (OpenGLFuncExtv)
glXGetProcAddressARB((GLubyte *)"glPointParameterfvEXT");
# endif
#endif
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
[Er, oops. The last one had the patch but not the text. Apologies!]
OK, looking more carefully, I think I see how this is supposed to
work. Because not all OpenGL implementations export the
PointParameter functions, Curt is using function pointers and the
GetProcAddress stuff.
This is fine; the only bug is that the names of the function pointers
are identical to the names of the functions. This is attractive,
because you can use the same syntax for both.
But it doesn't work across all implementations. In some, the
definition of the functions are as "regular" functions, not pointers.
So while the invocation syntax is the same, the assignment syntax is
not. You can't redeclare a regular function as a function pointer --
they're not compatible types.
The following patch just renames the symbol used to avoid the
collision. It seems to work for me.
Andy
diff -u -w -r1.31 main.cxx
--- main.cxx17 Oct 2002 04:34:32 - 1.31
+++ main.cxx19 Oct 2002 18:38:22 -
@@ -141,16 +141,16 @@
typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC)(GLenum pname,
const GLfloat *params);
- PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT = 0;
- PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT = 0;
+ PFNGLPOINTPARAMETERFEXTPROC gl_PointParameterfEXT = 0;
+ PFNGLPOINTPARAMETERFVEXTPROC g_lPointParameterfvEXT = 0;
#elif linux
#include
typedef void (* OpenGLFuncExt)(GLenum pname, GLfloat param);
typedef void (* OpenGLFuncExtv)(GLenum pname, const GLfloat *params);
- OpenGLFuncExt glPointParameterfEXT = 0;
- OpenGLFuncExtv glPointParameterfvEXT = 0;
+ OpenGLFuncExt gl_PointParameterfEXT = 0;
+ OpenGLFuncExtv gl_PointParameterfvEXT = 0;
#endif
float default_attenuation[3] = {1.0, 0.0, 0.0};
@@ -743,8 +743,8 @@
glEnable(GL_POINT_SMOOTH);
float quadratic[3] = {1.0, 0.001, 0.001};
// makes the points fade as they move away
-glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
-glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0);
+gl_PointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
+gl_PointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0);
glPointSize(4.0);
}
@@ -774,7 +774,7 @@
#ifdef FG_EXPERIMENTAL_LIGHTING
if (glutExtensionSupported("GL_EXT_point_parameters")) {
-glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT,
+gl_PointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT,
default_attenuation);
}
@@ -1578,14 +1578,14 @@
#ifdef FG_EXPERIMENTAL_LIGHTING
// get the address of our OpenGL extensions
# ifdef WIN32
-glPointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
+gl_PointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
wglGetProcAddress("glPointParameterfEXT");
-glPointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
+gl_PointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
wglGetProcAddress("glPointParameterfvEXT");
# elif linux
-glPointParameterfEXT = (OpenGLFuncExt)
+gl_PointParameterfEXT = (OpenGLFuncExt)
glXGetProcAddressARB((GLubyte *)"glPointParameterfEXT");
-glPointParameterfvEXT = (OpenGLFuncExtv)
+gl_PointParameterfvEXT = (OpenGLFuncExtv)
glXGetProcAddressARB((GLubyte *)"glPointParameterfvEXT");
# endif
#endif
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
On Friday 18 October 2002 09:17 pm, David Megginson wrote: > John Check writes: > > The last time we had KSFO with lights in there it had some problems > > too. I think it's worth the tradeoff but if you think it's going > > to break anything I can hold off. > > I'd prefer to put in a complete rebuild from William Riley if he has > time to redo the base package. I have been busy lately (who hasn't?) but can find the time to do a base Scenery rebuild. What is the status of the lighting? Should I do a rebuild this weekend? I'll have to check the back messages as I haven't been following along as closely as I would like. :( I am in the office with the door locked and the phone being ignored so I will do some tinkering today (Saturday). Hehehe Regards, Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
William L. Riley writes: > > I have been busy lately (who hasn't?) but can find the time to do a base > Scenery rebuild. What is the status of the lighting? Should I do a rebuild > this weekend? I'll have to check the back messages as I haven't been > following along as closely as I would like. :( I am in the office with the > door locked and the phone being ignored so I will do some tinkering today > (Saturday). Hehehe It would be wise to wait a week or two before doing a complete rebuild of the scenery, in case Curt needs to change anything, but a rebuild of w130n30 (or at least the area around KSFO) would be very welcome this weekend. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Networked Sound / Networked Input
Hi having played around a little bit with flightgrear earlier this year, I got really hooked since 0.8.0 came out. Good work guys... :) A couple of questions have popped up in my mind about some things... (some are especially interesting for cockpit builders :-) Is it possible to have (or implement) Sound and also Input (mostly for analog joysticks -or pots- and keyboards) networked ? eg. if you have several machines networked, one could be used for engine and wind noise, another for gear, flap, touchdown-squeal,... that would allow placing speakers a different places and angles and it would also overcome the limitation of (i think) 3 simultaneous samples playing via plib. Networking Input could allow more than the 4 axes per gameport. And since most computers have soundcards and analog joystick ports anyway, this would allow them to be used. I know that I could add some more joystick ports to my machine but this often not that easy since the good old ISA slots disappear and ISA cards that contain only joystick ports are not easy to find nowadays. USB is not a good way of interfacing your home built stuff since it requires more circuitry than the plain ol'gameport. PS: anyone using OpenGC under unix ? After fixing some capitalization Issues, I got the 0.3 CVS version compiled (using cmake) 2 weeks ago. However it does not work w/ flightgear. Looking at the source I could see why: the fgfs stuff is just left out at some places. PPS: anyone heard of the A340 Glass Cockpit project: http://a340gc.iradis.org/ it uses something called Raw Distributed Data Protocol (RDDP) Happy flying, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
On Saturday 19 October 2002 1:33 pm, Andy Ross wrote: > John Check wrote: > > Latest cvs build falls down with: > > > > pt_lights.cxx:304: `cout' undeclared (first use this function) > > You're using gcc 3.2 I assume? It's a namespace issue. The C++ > standard library naming is stricter now. You need to use std::cout, > or insert a "using namespace std;" above the usage. > > > main.cxx:153: > >void (*glPointParameterfvEXT)(unsigned int, const GLfloat*) > > /usr/X11R6/include/GL/gl.h:2520: > >glPointParameterfvEXT(unsigned int, const GLfloat*)' > > OK, this one looks kinda wrong. Our code is defining its own copy of > the glPointParameter function pointers, when they've already been > declared as regular functions in gl.h. What's the purpose here? All > of the declared extensions are supposed to be defined in the ARB > glext.h header, I believe. User-level code shouldn't have to play > this kind of game anymore. > > It's worth pointing out that I don't see this issue. I have the > NVidia drivers installed, which might have differeing header behavior? > > Andy nvidia-glx-1.0.3123 here. This is Gentoo 1.4-r1 machine FWIW. I'll apply the patch from your later email. Your explaination is right in line with the error message. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
On Saturday 19 October 2002 03:30 pm, [EMAIL PROTECTED] wrote: > It would be wise to wait a week or two before doing a complete rebuild > of the scenery, in case Curt needs to change anything, but a rebuild > of w130n30 (or at least the area around KSFO) would be very welcome > this weekend. I am working on the base Scenery rebuild and hope to have something tonight (CST). Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LWCE
John Check wrote: [snip] So, my question is, is anybody planning on attending the show and/or willing to do some booth time? It's not necessarily the deciding factor in the long run, but I don't want to wait too long to register. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel John, I signed up for an exhibits only pass 9 days ago. Had been planning to do about half of one day, as in the last 2 years. Checked the bus schedule, and it looks practical to make it a full day. Could also make it a second day from appearances now, and if it would really help. Friday is not an option for me, however. Of possible relevance, does anyone have an idea for FlightGear might perform on a laptop with an ATI Mobility Radeon chip and 32MB DDR video memory? There is a small chance I might be able to carry said laptop with me on days I am there. Totally irrelevant, has anyone noticed an odd temperature on ATIS at KSFO, or is my system doing it uniquely? -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LWCE
On Saturday 19 October 2002 6:03 pm, William Earnest wrote: > John Check wrote: > [snip] > > > So, my question is, is anybody planning on attending the show > > and/or willing to do some booth time? It's not necessarily the > > deciding factor in the long run, but I don't want to wait too long > > to register. > > > > TTYL > > J > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > John, > > I signed up for an exhibits only pass 9 days ago. Had been planning to > do about half of one day, as in the last 2 years. Checked the bus > schedule, and it looks practical to make it a full day. Could also make > it a second day from appearances now, and if it would really help. > Friday is not an option for me, however. Duly noted. > > Of possible relevance, does anyone have an idea for FlightGear might > perform on a laptop with an ATI Mobility Radeon chip and 32MB DDR video > memory? There is a small chance I might be able to carry said laptop > with me on days I am there. > > Totally irrelevant, has anyone noticed an odd temperature on ATIS at > KSFO, or is my system doing it uniquely? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
On Saturday 19 October 2002 2:47 pm, Andy Ross wrote: > [Er, oops. The last one had the patch but not the text. Apologies!] > > OK, looking more carefully, I think I see how this is supposed to > work. Because not all OpenGL implementations export the > PointParameter functions, Curt is using function pointers and the > GetProcAddress stuff. > > This is fine; the only bug is that the names of the function pointers > are identical to the names of the functions. This is attractive, > because you can use the same syntax for both. > > But it doesn't work across all implementations. In some, the > definition of the functions are as "regular" functions, not pointers. > So while the invocation syntax is the same, the assignment syntax is > not. You can't redeclare a regular function as a function pointer -- > they're not compatible types. > > The following patch just renames the symbol used to avoid the > collision. It seems to work for me. > > Andy > > > diff -u -w -r1.31 main.cxx > --- main.cxx17 Oct 2002 04:34:32 - 1.31 > +++ main.cxx19 Oct 2002 18:38:22 - > @@ -141,16 +141,16 @@ > typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC)(GLenum pname, >const GLfloat > *params); > > - PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT = 0; > - PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT = 0; > + PFNGLPOINTPARAMETERFEXTPROC gl_PointParameterfEXT = 0; > + PFNGLPOINTPARAMETERFVEXTPROC g_lPointParameterfvEXT = 0; Is this last line correct? The rest of the patch uses gl_PointParameterfvEXT FWIW I couldn't get the patch to apply and I noticed while applying changes ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
The base scenery package was rebuilt tonight and is available for download. http://www.randdtechnologies.com/fgfs/newScenery/ The rebuild went very smoothly so there is probably some huge glaring error that I missed. ;) Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
On Saturday 19 October 2002 7:42 pm, William L. Riley wrote: > The base scenery package was rebuilt tonight and is available for download. > > http://www.randdtechnologies.com/fgfs/newScenery/ > > The rebuild went very smoothly so there is probably some huge glaring error > that I missed. ;) > > Wm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LWCE
On Sat, 19 Oct 2002 18:45:15 -0400, John Check <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Saturday 19 October 2002 6:03 pm, William Earnest wrote: > > Of possible relevance, does anyone have an idea for FlightGear > > might > > perform on a laptop with an ATI Mobility Radeon chip and 32MB DDR ..this chip is not a mach64 based chip? > > video memory? There is a small chance I might be able to carry said > > laptop with me on days I am there. > > -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
On Saturday 19 October 2002 7:42 pm, William L. Riley wrote: > The base scenery package was rebuilt tonight and is available for download. > > http://www.randdtechnologies.com/fgfs/newScenery/ > > The rebuild went very smoothly so there is probably some huge glaring error > that I missed. ;) > > Wm Looks good to me, but what do I know. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
John Check wrote: > Is this last line correct? Uh, no. :) Sorry. I don't compile on a windows box, so that part of the change was blind. Obviously, the actual names of the symbols used isn't important. You could just as easily use "GL" or "fg", or "fgfsgl" or whatnot so long as it's consistent and doesn't collide with the existing OpenGL names. But the patch should have applied cleanly -- it just would have failed during compilation. Or is that what you meant? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] breakage
On Saturday 19 October 2002 8:52 pm, Andy Ross wrote: > John Check wrote: > > Is this last line correct? > > Uh, no. :) > > Sorry. I don't compile on a windows box, so that part of the change > was blind. windows box? I don't like the way they look. Shutters are okay, but windowboxes.. not my thing. > > Obviously, the actual names of the symbols used isn't important. You > could just as easily use "GL" or "fg", or "fgfsgl" or whatnot so long > as it's consistent and doesn't collide with the existing OpenGL > names. Right. > > But the patch should have applied cleanly -- it just would have failed > during compilation. Or is that what you meant? > It wouldn't apply. I was getting 4 failed hunks. I should have saved the .rej file. It might have been because I saved the email and trimmed off the headers and the list sig. > Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
