RE: [Flightgear-devel] Next release of FlightGear
Fred wrote > Sent: 19 July 2004 10:20 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Next release of FlightGear > > Vivian Meazza wrote: > > > The Cygwin build of FGFS-cvs appears still to have a problem with the > > scenery path. > > > > I've downloaded 0.9.5 scenery via Terrasync into /FlightGear/scenery > > > > This works: > > > > --fg-scenery=/FlightGear/scenery > > > > as does this: > > > > --fg-scenery=/FlightGear/data/scenery > > > > this fails: > > > > --fg-scenery=/FlightGear/scenery;/FlightGear/data/scenery > > On unix systems ( cygwin is emulating one ) semi-colon (;) is used > to seperate commands on a same line. Usually, the colon (:) is > used to seperate path in the same line. So try : > > --fg-scenery=/FlightGear/scenery:/FlightGear/data/scenery > > instead > That's fixed it, thanks. V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Vivian Meazza wrote: > The Cygwin build of FGFS-cvs appears still to have a problem with the > scenery path. > > I've downloaded 0.9.5 scenery via Terrasync into /FlightGear/scenery > > This works: > > --fg-scenery=/FlightGear/scenery > > as does this: > > --fg-scenery=/FlightGear/data/scenery > > this fails: > > --fg-scenery=/FlightGear/scenery;/FlightGear/data/scenery On unix systems ( cygwin is emulating one ) semi-colon (;) is used to seperate commands on a same line. Usually, the colon (:) is used to seperate path in the same line. So try : --fg-scenery=/FlightGear/scenery:/FlightGear/data/scenery instead -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
Curt wrote > Sent: 16 July 2004 16:34 > To: FlightGear developers discussions > Subject: [Flightgear-devel] Next release of FlightGear > > I've started doing some of the pre-release work for FlightGear-0.9.5 > (which is the next release.) That means I'd like to do our "official" > next release in the next week or two. Please take a few minutes to > download the tar balls and test this pre1 release. Please! This is our > quality control so if no one tests the pre releases and reports > problems, they will end up in the final release. > > Regards, > > Curt. > The Cygwin build of FGFS-cvs appears still to have a problem with the scenery path. I've downloaded 0.9.5 scenery via Terrasync into /FlightGear/scenery This works: --fg-scenery=/FlightGear/scenery as does this: --fg-scenery=/FlightGear/data/scenery this fails: --fg-scenery=/FlightGear/scenery;/FlightGear/data/scenery This is the output: WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. Object Stabilizer01 not found Object Stabilizer03 not found Tile not found (Ok if initializing) Segmentation fault (core dumped) Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
[EMAIL PROTECTED] wrote: Erik Hofman wrote: IRIX and Solaris binaries also include it by default. I'm not sure about other distributions, but I would encourage them to include it with the distribution. I include it with the slackware package too. Is there likely to be a new release of fgrun before the release of 0.9.5 or should I use the cvs version? What is in cvs is the next release of fgrun. I was testing it yesterday when my hard drive crashed. It may be some time before my system and data are fully recovered. OK, no problem - I'll use the cvs version in my test packages. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
I wrote > Sent: 17 July 2004 15:22 > To: 'FlightGear developers discussions' > Subject: RE: [Flightgear-devel] Next release of FlightGear > > Erik Hofman wrote > > > Sent: 17 July 2004 14:51 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] Next release of FlightGear > > > > Vivian Meazza wrote: > > > > > Once the offending entries are removed from simgear/sound, simgear > > compiles > > > correctly, but Norman's pre-built libraries were still present. I'll > > remove > > > those and try again. > > > > Nono, that's not what I meant. > > Norman once build a separate library for alut and openal, but in the end > > put them together into on library called openal. > > > > So I guess we just should remove the entries from configure.ac now. > > > > Thanks for testing this. > > > > I'm a bit confused now! > > Norman's last version put all the stuff into openal > > Unless test1 and test2 do something useful they can be easily removed from > simgear/sound/makefile.am > > V. Both Simgear-cvs and FlightGear-cvs compile without error post Eric's latest changes. Well done! First time since the introduction of OpenAL. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote: > Frederic Bouvier wrote: > > > What about calling SDL_Quit in a function installed by 'atexit', remove > > fgOSExit and only rely on exit in all the program ? > > The problem is that plib has taken the liberty to call exit() whenever > they feel like it You don't have to look into plib to find a lot of exit. jsbsim has its share and some other modules that are not willing to include fg_os.hxx. So I think it is safer not to provide our specific exit function and rely on atexit callbacks. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier wrote: What about calling SDL_Quit in a function installed by 'atexit', remove fgOSExit and only rely on exit in all the program ? The problem is that plib has taken the liberty to call exit() whenever they feel like it Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Jonathan Polley wrote:
> Fred,
>
> It turns out that the problem should exist on every FlightGear
> system, not just the Mac. On exit(), fgExitCleanup() is called which
> deletes the globals class and then calls fgOSExit(). The only thing
> that fgOSExit() does is turn around and call exit(), which repeats the
> process. I changed fgExitCleanup() in main.cxx to be as follows:
>
> void fgExitCleanup() {
> delete globals;
> //fgOSExit(0);
> }
>
> This prevented the recursive call to exit(), but will not work if
> someone is using the fg_os_sld.cxx module, but it works for me.
I proposed two patches but there is a question that maybe Andy could
answer : what is the purpose of fgOSExit ? It comes to me because
this function, is called only once in FlightGear while exit is called
at many locations. fgOSExit is just calling exit for the glut version
and SDL_Quit() + exit in the sdl version.
What about calling SDL_Quit in a function installed by 'atexit', remove
fgOSExit and only rely on exit in all the program ?
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Boris Koenig wrote:
Erik Hofman wrote:
Well, if we turn all that off, people start to complain that
FlightGear looks like crap and will search for something else. At
least now they start asking questions ...
Then how about optionally offering to disable such things in the
("advanced") rendering options dialog ?
It should be there already...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote: This is the penalty for those who want eye-candy. If specular highlighting is supported it will be enabled an make FlightGear slower. I noticed some enhancements in the new rendering dialog, and would like to ask how feasible it would be to integrate even more performance-related options into that rendering dialog. (see my other posting) So, generally I am talking about the rendering options that one can already provide via command line. It might be really useful if you could change these while the game is running - just for every user to be able to achieve a reasonable frame rate, this is just because I also noticed some decrease in FPS with the latest CVS built - and would like to be able to find the best configuration directly within the game. We could even introduce some basic kind of "rendering profiles", using comboboxes users could define their profiles and switch the profiles on the fly. Just a thought, though ... By the way: I noticed that the feature request/bug report options at sourceforge were being used at some time, is this still being maintained or at least looked at regularly ? Because, otherwise I would really suggest to separately install some kind of feature/bug database at flightgear.org - just drop me a line if you need help doing that. :-) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Richard Harke wrote: On Saturday 17 July 2004 07:08 am, Innis Cunningham wrote: I had a GeForce 2 Titanium with a PIII Xeon at 550MHz getting about 15 fps over SF Video card crapped out (even has a red LED come on to tell you it has crapped out) so I bought a Geforce FX 5200 Frame rate dropped to 4 in same circumstances. Occasionally up to 6. I already had plans to upgrade so I didn't panic New system is P4 at 3.0 GHz with 1MB cache AGP runs at 8x So now my frame rate is back to 15, though it does jump into the high 20's sometimes. Same copy of the executable in all cases. (CVS from mid Feb) This is rather disappointing, to be honest. I think there IS a point to it, because I've made very similar and *weird* observations, running on a pretty decent system with a nvidia card, you would get about 15-20 (the latter rarely) FPS, while taking the same CVS stuff to an OLD system (< 1 GHZ, 1 GIG RAM, ATI RAGE128) gives usually even more than these 20 FPS, as I am currently trying to summarize which subsystems I need and which of these can be "disabled" I have also made the following attempt: - disabling pretty much all rendering stuff - => now having an empty FG window - show the framerate THEN On my (decent) main system I keep getting not more than 30 FPS, while I do get around 50+ FPS with my old ATI RAGE 128 in such a mode on the other system. So, yes - I do think there are indeed some performance issues related to the openGL stuff. And I agree it's pretty disappointing to see the game @ 15 FPS on a system which usually provides up tp 80+ FPS in other games/openGL stuff. And I really don't think that FlightGear is making THAT much use of the GPU ?! Either it's really about some specific GPU options not being enabled or made full use of or there are some other _real_ problems ? Hence, it might really be a good idea to temporarily offer disabling of more advanced rendering features or even texture-rendering in general, personally I wouldn't care that much - and I agree with Erik, that most of the texture stuff gets pointless when you are IMC. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote:
Innis Cunningham wrote:
It is quite possible that the new graphics card/system is not set up for
FG.I will have a play with it and see if I can improve the situation.I
think
anisotropic filtering is on.
The point I was trying to make is people trying FG for the first time
will
be dissuaded from using it because of the poor performance.
As you yourself said it is disappointing to spend money on upgrading
only to find that the sim runs at the same speed if not slower.
With the price of computer hardware getting cheaper all the time I
would think most people who are going to use FG would have reasonably
new hardware.
Well, if we turn all that off, people start to complain that FlightGear
looks like crap and will search for something else. At least now they
start asking questions ...
Then how about optionally offering to disable such things in the
("advanced") rendering options dialog ?
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Innis Cunningham wrote: It is quite possible that the new graphics card/system is not set up for FG.I will have a play with it and see if I can improve the situation.I think anisotropic filtering is on. The point I was trying to make is people trying FG for the first time will be dissuaded from using it because of the poor performance. As you yourself said it is disappointing to spend money on upgrading only to find that the sim runs at the same speed if not slower. With the price of computer hardware getting cheaper all the time I would think most people who are going to use FG would have reasonably new hardware. Well, if we turn all that off, people start to complain that FlightGear looks like crap and will search for something else. At least now they start asking questions ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Ampere K. Hardraade wrote: Please tell me that you don't play FlightGear in wireframe mode. =P Neh, my O2 does support filled triangles. Just kidding. Oh. ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
"Frederic Bouvier" writes Norman Vine wrote: > Frederic Bouvier writes: > > > > FG is not using the latest features new cards are offering and the 'old' > > features are pretty maxed out now. This is not an explanation for > > worst performance but just for lack of improvement. In the meantime, > > you probably switched to another setup/resolution that can eat computing > > power on your back. > > Implying that the underlying rendering library is the cause for 'lack of > improvement' is a little harsh given the *many* changes since the > last relese that have little to do with rendering :-) I was not speaking about the underlying library at this point. It could also be our use of it, or the use of it by the model loaders. Otherwise, how could you explain the variations in framerate whether the buildings and the bridges are in view or not. Just as an example, it is not possible to share a set of vertices and vertices attributes between 2 graphic primitives. Indexed arrays are there but are never used, and if they would, the same vertex used by 2 adjacents primitives would have to be pushed twice. I didn't experienced myself what could be the gain yet, but I don't see a potential loss. And all this static data could reside in card memory instead of being sent to the bus every frame. > Has anyone profiled FGFS recently ? That is certainly needed. I was very disappointed myself to see that switching from GF3 to GF5900 didn't improve my framerate. I got a small improvement when I upgraded my CPU. There is another point with graphic cards. On windows, their drivers can switch on several features that are not managed by the application. FSAA and anisotropic filtering come to mind. Unexperienced users can have them to their max ( just because these are default values ) with a significant impact on framerate. It is just weird that in Innis case, things are getting worse. FX5200 are not top end cards but ATI 9800pro are. Something in the setup of these machines must be wrong. It is quite possible that the new graphics card/system is not set up for FG.I will have a play with it and see if I can improve the situation.I think anisotropic filtering is on. The point I was trying to make is people trying FG for the first time will be dissuaded from using it because of the poor performance. As you yourself said it is disappointing to spend money on upgrading only to find that the sim runs at the same speed if not slower. With the price of computer hardware getting cheaper all the time I would think most people who are going to use FG would have reasonably new hardware. You asked what the alpha window was.It is a window that pops up if you are using a JSBSIM FDM. Just says ALPHA and then the rest of sim loads. Well on the version I downloaded yesterday this window did not flash by instead I got a window saying "bad comand or file name" but then the sim continued to load normally. I will look into these things and see if I can find anything out. -Fred Cheers Innis _ Looking to buy a new house? Try http://property.ninemsn.com.au/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
On Saturday 17 July 2004 07:08 am, Innis Cunningham wrote: >for speed to the old box. To my surprise the frame rates > were worse than the old box. > The following tests were done using windows 98SE > The old box was a 850meg duron with 256 meg ram and > a GF4-MX-440 64meg graphics card.On this box I could get 27fps > sitting at the end of 28R at KSFO looking at the terminal. > The new box a 2gig athalon with 512meg ram and a FX5200 > 128meg graphics card could only give 22fps under the same > conditions.Also my son who has a 2.8 gig rig running an ATI 9800pro > card could only get 15fps.It seems the more powerfull the computer > the slower FG seems to run. I had a GeForce 2 Titanium with a PIII Xeon at 550MHz getting about 15 fps over SF Video card crapped out (even has a red LED come on to tell you it has crapped out) so I bought a Geforce FX 5200 Frame rate dropped to 4 in same circumstances. Occasionally up to 6. I already had plans to upgrade so I didn't panic New system is P4 at 3.0 GHz with 1MB cache AGP runs at 8x So now my frame rate is back to 15, though it does jump into the high 20's sometimes. Same copy of the executable in all cases. (CVS from mid Feb) This is rather disappointing, to be honest. Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
> Erik Hofman wrote: > > IRIX and Solaris binaries also include it by default. > > I'm not sure about other distributions, but I would > > encourage them to include it with the distribution. > > I include it with the slackware package too. > > Is there likely to be a new release of fgrun before the > release of 0.9.5 or should I use the cvs version? What is in cvs is the next release of fgrun. I was testing it yesterday when my hard drive crashed. It may be some time before my system and data are fully recovered. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote: IRIX and Solaris binaries also include it by default. I'm not sure about other distributions, but I would encourage them to include it with the distribution. I include it with the slackware package too. Is there likely to be a new release of fgrun before the release of 0.9.5 or should I use the cvs version? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier wrote: Just a thought : Maybe it would be wise to have a TerraGear release that match released SimGear as well ? That would avoid question about compatibility issues that are only resolved in CVS. Yes, I'm planning to do that soon, time permitting ... 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Please tell me that you don't play FlightGear in wireframe mode. =P Just kidding. Regards, Ampere On July 17, 2004 04:54 pm, Erik Hofman wrote: > This is the penalty for those who want eye-candy. If specular > highlighting is supported it will be enabled an make FlightGear slower. > > Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Ampere K. Hardraade wrote: Scrubbing FlightGear because of framerates was excatly what a friend of mine did. I agree with Innis that someone should fix this problem. The following tests were done using windows 98SE The old box was a 850meg duron with 256 meg ram and a GF4-MX-440 64meg graphics card.On this box I could get 27fps sitting at the end of 28R at KSFO looking at the terminal. The new box a 2gig athalon with 512meg ram and a FX5200 128meg graphics card could only give 22fps under the same conditions.Also my son who has a 2.8 gig rig running an ATI 9800pro card could only get 15fps.It seems the more powerfull the computer the slower FG seems to run. Now I dont know why that is but if we want to get new people into FG we should see what the problem is. This is the penalty for those who want eye-candy. If specular highlighting is supported it will be enabled an make FlightGear slower. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Norman Vine wrote: Frederic Bouvier writes: fgrun is installed by fgsetup. It is launched when you double-click on the FG icon. Cool, Perhaps merntion of this should be made as a 'dependenciy' then on http://www.flightgear.org/Downloads/source.html IRIX and Solaris binaries also include it by default. I'm not sure about other distributions, but I would encourage them to include it with the distribution. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Fred,
It turns out that the problem should exist on every FlightGear
system, not just the Mac. On exit(), fgExitCleanup() is called which
deletes the globals class and then calls fgOSExit(). The only thing
that fgOSExit() does is turn around and call exit(), which repeats the
process. I changed fgExitCleanup() in main.cxx to be as follows:
void fgExitCleanup() {
delete globals;
//fgOSExit(0);
}
This prevented the recursive call to exit(), but will not work if
someone is using the fg_os_sld.cxx module, but it works for me.
Thanks,
Jonathan Polley
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Norman Vine wrote: > Frederic Bouvier writes: > > > > FG is not using the latest features new cards are offering and the 'old' > > features are pretty maxed out now. This is not an explanation for > > worst performance but just for lack of improvement. In the meantime, > > you probably switched to another setup/resolution that can eat computing > > power on your back. > > Implying that the underlying rendering library is the cause for 'lack of > improvement' is a little harsh given the *many* changes since the > last relese that have little to do with rendering :-) I was not speaking about the underlying library at this point. It could also be our use of it, or the use of it by the model loaders. Otherwise, how could you explain the variations in framerate whether the buildings and the bridges are in view or not. Just as an example, it is not possible to share a set of vertices and vertices attributes between 2 graphic primitives. Indexed arrays are there but are never used, and if they would, the same vertex used by 2 adjacents primitives would have to be pushed twice. I didn't experienced myself what could be the gain yet, but I don't see a potential loss. And all this static data could reside in card memory instead of being sent to the bus every frame. > Has anyone profiled FGFS recently ? That is certainly needed. I was very disappointed myself to see that switching from GF3 to GF5900 didn't improve my framerate. I got a small improvement when I upgraded my CPU. There is another point with graphic cards. On windows, their drivers can switch on several features that are not managed by the application. FSAA and anisotropic filtering come to mind. Unexperienced users can have them to their max ( just because these are default values ) with a significant impact on framerate. It is just weird that in Innis case, things are getting worse. FX5200 are not top end cards but ATI 9800pro are. Something in the setup of these machines must be wrong. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier wrote: Norman Vine wrote: Perhaps merntion of this should be made as a 'dependenciy' then on http://www.flightgear.org/Downloads/source.html Sorry Norman, but I don't understand. FlightGear does not depend on fgrun. It is just in the Win32 binary package since 0.9.3 and probably in several Linux packages as a bonus. runfgfs and runfgfs.bat are still generated by configure in the source package. Anyway, the website could mention flightgear related projects but I presume there was not so much lobbying for this from their authors. If I remember correctly there IS a specific section on the webpages, at least that's what I think. Wait ... Ya, while it cannot be found under "related projects" those other projects are mentioned on the "links" page: http://www.flightgear.org/links.html I'd also suggest to separately maintain such a listing, this could be also done via some kind of basic CMS - if there aren't any other volunteers I really wouldn't mind to ocassionally update such a section. I think it's really a good idea to have a central place for all FlightGear related software, that way you would also make things easier for new users who are just trying to start getting familiar with FlightGear - they would only have to look in one place. We could add a small description with relevant remarks and have some small table for all the 2nd party stuff that there is. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Norman Vine wrote: > Frederic Bouvier writes: > > > > Norman Vine wrote: > > > > > Frederic Bouvier writes: > > > >> > > > > > > Also I noticed that in the 9.4 base the runfgfs bat file has been > > > > removed. > > > > > > Was there a reason for this. > > > > > > > > It has been supercede by fgrun that is much user frendly. > > > > > > Until fgrun is distributed with FGFS I 'vote' for the batch file being > > > reinstalled in the distribution. > > > > fgrun is installed by fgsetup. It is launched when you double-click on > > the FG icon. > > Cool, > > Perhaps merntion of this should be made as a 'dependenciy' > then on http://www.flightgear.org/Downloads/source.html Sorry Norman, but I don't understand. FlightGear does not depend on fgrun. It is just in the Win32 binary package since 0.9.3 and probably in several Linux packages as a bonus. runfgfs and runfgfs.bat are still generated by configure in the source package. Anyway, the website could mention flightgear related projects but I presume there was not so much lobbying for this from their authors. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier writes: > > FG is not using the latest features new cards are offering and the 'old' > features are pretty maxed out now. This is not an explanation for > worst performance but just for lack of improvement. In the meantime, > you probably switched to another setup/resolution that can eat computing > power on your back. Implying that the underlying rendering library is the cause for 'lack of improvement' is a little harsh given the *many* changes since the last relese that have little to do with rendering :-) Has anyone profiled FGFS recently ? Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Frederic > Bouvier > Sent: Saturday, July 17, 2004 12:20 PM > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Next release of FlightGear > > > I was too quick to press the reply button. I now see your > motivations, so receive all my apologies. > > Frederic Bouvier wrote: > > Innis Cunningham wrote: > > > > > > > > Hi Curt > > > I downloaded the windows binaries last night for > > > 9.4 and the problem of the drop down menu's > > > locking the sim up still seem to exist.Even if you > > > go to exit FG and then select cancel the sim locks up. > > > > Hey Innis, > > > > you just downloaded the release that is 3 months old ! > > There is no *** 0.9.555 *** ( not 4 ) Win32 binary > > yet. > > > > FYI, the menu lockup has been corrected in the binary below > > and is ok for the upcoming release. > > ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/FlightGear-0.9.4a.exe > > > > -Fred > > > > > The reason that I downloaded the binaries was that I > > > have just built a new box,that I am going to put linux > > > on,but wanted to find out how the new box compaired > > > for speed to the old box. To my surprise the frame rates > > > were worse than the old box. > > > The following tests were done using windows 98SE > > > The old box was a 850meg duron with 256 meg ram and > > > a GF4-MX-440 64meg graphics card.On this box I could get 27fps > > > sitting at the end of 28R at KSFO looking at the terminal. > > > The new box a 2gig athalon with 512meg ram and a FX5200 > > > 128meg graphics card could only give 22fps under the same > > > conditions.Also my son who has a 2.8 gig rig running an ATI 9800pro > > > card could only get 15fps.It seems the more powerfull the computer > > > the slower FG seems to run. > > FG is not using the latest features new cards are offering and the 'old' > features are pretty maxed out now. This is not an explanation for > worst performance but just for lack of improvement. In the meantime, > you probably switched to another setup/resolution that can eat computing > power on your back. > > > > > Now I dont know why that is but if we want to get new people into > > > FG we should see what the problem is. > > > As my son says if he had downloaded the game(sorry sim)and seen these > > > kind of results he would have just scrubed it and moved on and I guess > > > there are a lot of other people who would do the same thing. > > > My son says that he gets frame rates of well over 100 on Quake and Doom > > > which seem to be much more graphics intensive than FG. > > > Original Quake is not pushing so much triangles and textures to the card > because their action is indoor and the scene is bound to few rooms. Doom is > even using sprites for the monsters instead of full 3d and lots of tricks > are done to maintain a high framerate. That's said, FG is not very good > at framerate because it is modeling a lot of things in background and > it's graphic engine is a bit outdated. > > > > Also I noticed that in the 9.4 base the runfgfs bat file has been > removed. > > > Was there a reason for this. > > It has been supercede by fgrun that is much user frendly. > > > > I guess I did not notice this before because I was running the 9.4 > > binaries > > > with the CVS version of the base package and my own bat files. > > > When I ran the 9.4 version I downloaded last night it seemed to flash up > > > a dos window saying bad command or file name about were I would expect > > > to see the Alpha window on my other version of 9.4.The sim would then > > > continue to load.But once loaded the runway had black lines at the end > of > > > each texture. > > What is the Alpha window ? If you don't see fgrun, you probably have a path > problem that is in conflict with you cvs version. > The black lines are brought to you by newer hardware. I have the same and > they > probably come from anisotropic or another kind of filtering. > > > > I have seen this before when running AC3D and FG 9.4 at the same time on > > > my old box.On that system the sim would, under those conditions, only > run > > at > > > about 1fps or less.But in that case I could get the sim to run correctly > > by > > > shutting > > > down AC3D(maybe a memory thing).But with the version I downloa
RE: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier writes: > > Norman Vine wrote: > > > Frederic Bouvier writes: > > >> > > > > > Also I noticed that in the 9.4 base the runfgfs bat file has been > > > removed. > > > > > Was there a reason for this. > > > > > > It has been supercede by fgrun that is much user frendly. > > > > Until fgrun is distributed with FGFS I 'vote' for the batch file being > > reinstalled in the distribution. > > fgrun is installed by fgsetup. It is launched when you double-click on > the FG icon. Cool, Perhaps merntion of this should be made as a 'dependenciy' then on http://www.flightgear.org/Downloads/source.html Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Scrubbing FlightGear because of framerates was excatly what a friend of mine did. I agree with Innis that someone should fix this problem. Regards, Ampere On July 17, 2004 10:08 am, Innis Cunningham wrote: > The following tests were done using windows 98SE > The old box was a 850meg duron with 256 meg ram and > a GF4-MX-440 64meg graphics card.On this box I could get 27fps > sitting at the end of 28R at KSFO looking at the terminal. > The new box a 2gig athalon with 512meg ram and a FX5200 > 128meg graphics card could only give 22fps under the same > conditions.Also my son who has a 2.8 gig rig running an ATI 9800pro > card could only get 15fps.It seems the more powerfull the computer > the slower FG seems to run. > Now I dont know why that is but if we want to get new people into > FG we should see what the problem is. > As my son says if he had downloaded the game(sorry sim)and seen these > kind of results he would have just scrubed it and moved on and I guess > there are a lot of other people who would do the same thing. > My son says that he gets frame rates of well over 100 on Quake and Doom > which seem to be much more graphics intensive than FG. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Norman Vine wrote: > Frederic Bouvier writes: > >> > > > > Also I noticed that in the 9.4 base the runfgfs bat file has been > > removed. > > > > Was there a reason for this. > > > > It has been supercede by fgrun that is much user frendly. > > Until fgrun is distributed with FGFS I 'vote' for the batch file being > reinstalled in the distribution. fgrun is installed by fgsetup. It is launched when you double-click on the FG icon. > This is esp. true since there have been quite a few changes in > the layout of the base package which we can't expect non-developers > to intuitively know about. Current fgrun is aware of these changes, thanks to Bernie. It will be in 0.9.5 win32 binary. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier writes: >> > > > Also I noticed that in the 9.4 base the runfgfs bat file has been > removed. > > > Was there a reason for this. > > It has been supercede by fgrun that is much user frendly. Until fgrun is distributed with FGFS I 'vote' for the batch file being reinstalled in the distribution. This is esp. true since there have been quite a few changes in the layout of the base package which we can't expect non-developers to intuitively know about. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
I was too quick to press the reply button. I now see your motivations, so receive all my apologies. Frederic Bouvier wrote: > Innis Cunningham wrote: > > > > > Hi Curt > > I downloaded the windows binaries last night for > > 9.4 and the problem of the drop down menu's > > locking the sim up still seem to exist.Even if you > > go to exit FG and then select cancel the sim locks up. > > Hey Innis, > > you just downloaded the release that is 3 months old ! > There is no *** 0.9.555 *** ( not 4 ) Win32 binary > yet. > > FYI, the menu lockup has been corrected in the binary below > and is ok for the upcoming release. > ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/FlightGear-0.9.4a.exe > > -Fred > > > The reason that I downloaded the binaries was that I > > have just built a new box,that I am going to put linux > > on,but wanted to find out how the new box compaired > > for speed to the old box. To my surprise the frame rates > > were worse than the old box. > > The following tests were done using windows 98SE > > The old box was a 850meg duron with 256 meg ram and > > a GF4-MX-440 64meg graphics card.On this box I could get 27fps > > sitting at the end of 28R at KSFO looking at the terminal. > > The new box a 2gig athalon with 512meg ram and a FX5200 > > 128meg graphics card could only give 22fps under the same > > conditions.Also my son who has a 2.8 gig rig running an ATI 9800pro > > card could only get 15fps.It seems the more powerfull the computer > > the slower FG seems to run. FG is not using the latest features new cards are offering and the 'old' features are pretty maxed out now. This is not an explanation for worst performance but just for lack of improvement. In the meantime, you probably switched to another setup/resolution that can eat computing power on your back. > > Now I dont know why that is but if we want to get new people into > > FG we should see what the problem is. > > As my son says if he had downloaded the game(sorry sim)and seen these > > kind of results he would have just scrubed it and moved on and I guess > > there are a lot of other people who would do the same thing. > > My son says that he gets frame rates of well over 100 on Quake and Doom > > which seem to be much more graphics intensive than FG. Original Quake is not pushing so much triangles and textures to the card because their action is indoor and the scene is bound to few rooms. Doom is even using sprites for the monsters instead of full 3d and lots of tricks are done to maintain a high framerate. That's said, FG is not very good at framerate because it is modeling a lot of things in background and it's graphic engine is a bit outdated. > > Also I noticed that in the 9.4 base the runfgfs bat file has been removed. > > Was there a reason for this. It has been supercede by fgrun that is much user frendly. > > I guess I did not notice this before because I was running the 9.4 > binaries > > with the CVS version of the base package and my own bat files. > > When I ran the 9.4 version I downloaded last night it seemed to flash up > > a dos window saying bad command or file name about were I would expect > > to see the Alpha window on my other version of 9.4.The sim would then > > continue to load.But once loaded the runway had black lines at the end of > > each texture. What is the Alpha window ? If you don't see fgrun, you probably have a path problem that is in conflict with you cvs version. The black lines are brought to you by newer hardware. I have the same and they probably come from anisotropic or another kind of filtering. > > I have seen this before when running AC3D and FG 9.4 at the same time on > > my old box.On that system the sim would, under those conditions, only run > at > > about 1fps or less.But in that case I could get the sim to run correctly > by > > shutting > > down AC3D(maybe a memory thing).But with the version I downloaded last > night > > I could not get the black lines to disappear at all. > > Is anyone else seeing this. > > >From the air the runway looks like a step ladder. > > Also on the new box the frame rates do not seem to change if I > > have full fog or no fog.On the old box the frame rates would half > > with no fog That last sentence make me feel that your performance problem is not related with the graphic card. If submitting less job to the card give the same result, that just mean that the bottleneck is not likely to be the graphic system, either software or harware. > > So with a new version coming out could these problems be looked at. Not likely on performance this time. You can still submit bug reports on the current version. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Innis Cunningham wrote: > > Hi Curt > I downloaded the windows binaries last night for > 9.4 and the problem of the drop down menu's > locking the sim up still seem to exist.Even if you > go to exit FG and then select cancel the sim locks up. Hey Innis, you just downloaded the release that is 3 months old ! There is no *** 0.9.555 *** ( not 4 ) Win32 binary yet. FYI, the menu lockup has been corrected in the binary below and is ok for the upcoming release. ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/FlightGear-0.9.4a.exe -Fred > The reason that I downloaded the binaries was that I > have just built a new box,that I am going to put linux > on,but wanted to find out how the new box compaired > for speed to the old box. To my surprise the frame rates > were worse than the old box. > The following tests were done using windows 98SE > The old box was a 850meg duron with 256 meg ram and > a GF4-MX-440 64meg graphics card.On this box I could get 27fps > sitting at the end of 28R at KSFO looking at the terminal. > The new box a 2gig athalon with 512meg ram and a FX5200 > 128meg graphics card could only give 22fps under the same > conditions.Also my son who has a 2.8 gig rig running an ATI 9800pro > card could only get 15fps.It seems the more powerfull the computer > the slower FG seems to run. > Now I dont know why that is but if we want to get new people into > FG we should see what the problem is. > As my son says if he had downloaded the game(sorry sim)and seen these > kind of results he would have just scrubed it and moved on and I guess > there are a lot of other people who would do the same thing. > My son says that he gets frame rates of well over 100 on Quake and Doom > which seem to be much more graphics intensive than FG. > Also I noticed that in the 9.4 base the runfgfs bat file has been removed. > Was there a reason for this. > I guess I did not notice this before because I was running the 9.4 binaries > with the CVS version of the base package and my own bat files. > When I ran the 9.4 version I downloaded last night it seemed to flash up > a dos window saying bad command or file name about were I would expect > to see the Alpha window on my other version of 9.4.The sim would then > continue to load.But once loaded the runway had black lines at the end of > each texture. > I have seen this before when running AC3D and FG 9.4 at the same time on > my old box.On that system the sim would, under those conditions, only run at > about 1fps or less.But in that case I could get the sim to run correctly by > shutting > down AC3D(maybe a memory thing).But with the version I downloaded last night > I could not get the black lines to disappear at all. > Is anyone else seeing this. > >From the air the runway looks like a step ladder. > Also on the new box the frame rates do not seem to change if I > have full fog or no fog.On the old box the frame rates would half > with no fog > So with a new version coming out could these problems be looked at. > - > >Curtis Olson > > Thanks in advance > Cheers > Innis > > _ > Play Love Hunt to win a $9000 holiday and find love! > http://mobilecentral.ninemsn.com.au/mclovehunt/lovehunt.aspx > > > ___ > 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] Next release of FlightGear
On Sat, 17 Jul 2004 09:34:24 +0200, Frederic wrote in message <[EMAIL PROTECTED]>: > I wrote: > > > Curtis L. Olson wrote: > > > > > I've started doing some of the pre-release work for > > > FlightGear-0.9.5(which is the next release.) That means I'd like > > > to do our "official" next release in the next week or two. Please > > > take a few minutes to download the tar balls and test this pre1 > > > release. Please! This is our quality control so if no one tests > > > the pre releases and reports problems, they will end up in the > > > final release. > > > > Just a thought : > > Maybe it would be wise to have a TerraGear release that match > > released SimGear as well ? That would avoid question about > > compatibility issues that are only resolved in CVS. > > And what about jumping in version numbers ( all 3 projects to 0.9.5 ) > to make clear what are the dependencies ? ..I say _not_ until F|S|TG-1, and only _if_ we make a _formal_ suite of it all. My opinion is we need a more valid reason than "just make the numbers look alike." -- ..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] Next release of FlightGear
Vivian Meazza wrote: I'm a bit confused now! There is really no need to be confused. Norman's last version put all the stuff into openal Good. That part is fixed in CVS no.w Unless test1 and test2 do something useful they can be easily removed from simgear/sound/makefile.am We sometimes include test programs into the source tree that don't get installed by default. They are just to test the particular subsystem, nothing more nothing less. But there is really no need to remove them from Makefile.am. The only thing they do is add a small bit of compile time, nothing noticeable compared to the compile time of the complete project. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote > Sent: 17 July 2004 14:51 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Next release of FlightGear > > Vivian Meazza wrote: > > > Once the offending entries are removed from simgear/sound, simgear > compiles > > correctly, but Norman's pre-built libraries were still present. I'll > remove > > those and try again. > > Nono, that's not what I meant. > Norman once build a separate library for alut and openal, but in the end > put them together into on library called openal. > > So I guess we just should remove the entries from configure.ac now. > > Thanks for testing this. > I'm a bit confused now! Norman's last version put all the stuff into openal Unless test1 and test2 do something useful they can be easily removed from simgear/sound/makefile.am V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
Hi Curt I downloaded the windows binaries last night for 9.4 and the problem of the drop down menu's locking the sim up still seem to exist.Even if you go to exit FG and then select cancel the sim locks up. The reason that I downloaded the binaries was that I have just built a new box,that I am going to put linux on,but wanted to find out how the new box compaired for speed to the old box. To my surprise the frame rates were worse than the old box. The following tests were done using windows 98SE The old box was a 850meg duron with 256 meg ram and a GF4-MX-440 64meg graphics card.On this box I could get 27fps sitting at the end of 28R at KSFO looking at the terminal. The new box a 2gig athalon with 512meg ram and a FX5200 128meg graphics card could only give 22fps under the same conditions.Also my son who has a 2.8 gig rig running an ATI 9800pro card could only get 15fps.It seems the more powerfull the computer the slower FG seems to run. Now I dont know why that is but if we want to get new people into FG we should see what the problem is. As my son says if he had downloaded the game(sorry sim)and seen these kind of results he would have just scrubed it and moved on and I guess there are a lot of other people who would do the same thing. My son says that he gets frame rates of well over 100 on Quake and Doom which seem to be much more graphics intensive than FG. Also I noticed that in the 9.4 base the runfgfs bat file has been removed. Was there a reason for this. I guess I did not notice this before because I was running the 9.4 binaries with the CVS version of the base package and my own bat files. When I ran the 9.4 version I downloaded last night it seemed to flash up a dos window saying bad command or file name about were I would expect to see the Alpha window on my other version of 9.4.The sim would then continue to load.But once loaded the runway had black lines at the end of each texture. I have seen this before when running AC3D and FG 9.4 at the same time on my old box.On that system the sim would, under those conditions, only run at about 1fps or less.But in that case I could get the sim to run correctly by shutting down AC3D(maybe a memory thing).But with the version I downloaded last night I could not get the black lines to disappear at all. Is anyone else seeing this. From the air the runway looks like a step ladder. Also on the new box the frame rates do not seem to change if I have full fog or no fog.On the old box the frame rates would half with no fog So with a new version coming out could these problems be looked at. - Curtis Olson Thanks in advance Cheers Innis _ Play Love Hunt to win a $9000 holiday and find love! http://mobilecentral.ninemsn.com.au/mclovehunt/lovehunt.aspx ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Vivian Meazza wrote: Once the offending entries are removed from simgear/sound, simgear compiles correctly, but Norman's pre-built libraries were still present. I'll remove those and try again. Nono, that's not what I meant. Norman once build a separate library for alut and openal, but in the end put them together into on library called openal. So I guess we just should remove the entries from configure.ac now. Thanks for testing this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Line 92 of globals.cxx seems ok. subsystem_mgr was allocated with a new operator in line 45. Could you put a breakpoint at line 92 to see if on your system, the destructor is not called twice ? -Fred Jonathan Polley wrote: > Since there is a new release coming, I decided to bring the Mac version > back up to date (I've been busy otherwise). When I exit FlightGear, I > get the following errors (and crash). > > > *** malloc[8626]: Deallocation of a pointer not malloced: 0x18bef000; > This could be a double free(), or free() called with the middle of an > allocated block; Try setting environment variable MallocHelp to see > tools to help debug > *** malloc[8626]: Deallocation of a pointer not malloced: 0x18d8d000; > This could be a double free(), or free() called with the middle of an > allocated block; Try setting environment variable MallocHelp to see > tools to help debug > *** malloc[8626]: Deallocation of a pointer not malloced: 0x141794c0; > This could be a double free(), or free() called with the middle of an > allocated block; Try setting environment variable MallocHelp to see > tools to help debug > > Using gdb gives me the following stack dump. Any ideas? > > Program received signal EXC_BAD_ACCESS, Could not access memory. > 0x0002bec8 in FGGlobals::~FGGlobals() (this=0x6b3e830, __in_chrg=3) at > globals.cxx:92 > 92 delete subsystem_mgr; > (gdb) backtrace > #0 0x0002bec8 in FGGlobals::~FGGlobals() (this=0x6b3e830, __in_chrg=3) > at globals.cxx:92 > #1 0xf178 in fgExitCleanup() () at main.cxx:1497 > #2 0x9002c7b8 in exit () > #3 0x00011224 in fgOSExit(int) (code=112624448) at fg_os.cxx:148 > #4 0x9002c7b8 in exit () > #5 0x0003d284 in fgExit(int) (status=0) at util.cxx:110 > #6 0x00026c20 in do_exit(SGPropertyNode const*) (arg=0x55d070) at > fg_commands.cxx:193 > #7 0x00235178 in FGBinding::fire() const (this=0x2) at input.cxx:122 > #8 0x00220de4 in action_callback(puObject*) (object=0x6b68340) at > /usr/include/gcc/darwin/3.3/c++/bits/stl_vector.h:511 > #9 0x00382d7c in puOneShot::doHit(int, int, int, int) (this=0x0, > button=0, updown=1000, x=2013490264, y=0) at puOneShot.cxx:32 > #10 0x0037d370 in puObject::checkHit(int, int, int, int) > (this=0x19969a10, button=0, updown=1, x=429300720, y=2) at > puObject.cxx:508 > #11 0x0037a46c in puGroup::checkHit(int, int, int, int) > (this=0x199697f0, button=0, updown=1, x=102, y=23) at puGroup.cxx:218 > #12 0x0037a46c in puGroup::checkHit(int, int, int, int) > (this=0x199683c0, button=0, updown=1, x=102, y=23) at puGroup.cxx:218 > #13 0x0035c8a8 in puMouse(int, int, int, int) (button=0, updown=1, > x=364, y=316) at pu.cxx:365 > #14 0x00235ed4 in FGInput::doMouseClick(int, int, int, int) > (this=0x18b85000, b=0, updown=1, x=364, y=316) at input.cxx:282 > #15 0x875270e8 in -[GLUTView _commonMouseUp:] () > #16 0x92e02cfc in -[NSWindow sendEvent:] () > #17 0x87542600 in -[GLUTWindow sendEvent:] () > #18 0x92df5324 in -[NSApplication sendEvent:] () > #19 0x87521cc4 in -[GLUTApplication > _runMainLoopUntilDate:autoreleasePool:] () > #20 0x87521df4 in -[GLUTApplication run] () > #21 0x8753bd28 in glutMainLoop () > #22 0x00010b54 in fgMainInit(int, char**) (argc=1, argv=0x4ff198) at > main.cxx:1779 > #23 0xa8fc in main (argc=1, argv=0x8756216c) at bootstrap.cxx:175 > > > Thanks, > > Jonathan Polley > > > ___ > 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] Next release of FlightGear
Erik Hofman wrote > Sent: 17 July 2004 10:27 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Next release of FlightGear > > Vivian Meazza wrote: > > > SimGear-0.3.6-pre1 will not compile under Cygwin. It fails in > > > > [openal-test1.exe]: cannot find -lalut. > > This is using Norman's prebuild libraries, isn't it? > Norman has integrated the alut library and the openal library so the > reference should then be removed in the configure.ac in both SimGear and > FlightGear. > Once the offending entries are removed from simgear/sound, simgear compiles correctly, but Norman's pre-built libraries were still present. I'll remove those and try again. V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Since there is a new release coming, I decided to bring the Mac version back up to date (I've been busy otherwise). When I exit FlightGear, I get the following errors (and crash). *** malloc[8626]: Deallocation of a pointer not malloced: 0x18bef000; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug *** malloc[8626]: Deallocation of a pointer not malloced: 0x18d8d000; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug *** malloc[8626]: Deallocation of a pointer not malloced: 0x141794c0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug Using gdb gives me the following stack dump. Any ideas? Program received signal EXC_BAD_ACCESS, Could not access memory. 0x0002bec8 in FGGlobals::~FGGlobals() (this=0x6b3e830, __in_chrg=3) at globals.cxx:92 92 delete subsystem_mgr; (gdb) backtrace #0 0x0002bec8 in FGGlobals::~FGGlobals() (this=0x6b3e830, __in_chrg=3) at globals.cxx:92 #1 0xf178 in fgExitCleanup() () at main.cxx:1497 #2 0x9002c7b8 in exit () #3 0x00011224 in fgOSExit(int) (code=112624448) at fg_os.cxx:148 #4 0x9002c7b8 in exit () #5 0x0003d284 in fgExit(int) (status=0) at util.cxx:110 #6 0x00026c20 in do_exit(SGPropertyNode const*) (arg=0x55d070) at fg_commands.cxx:193 #7 0x00235178 in FGBinding::fire() const (this=0x2) at input.cxx:122 #8 0x00220de4 in action_callback(puObject*) (object=0x6b68340) at /usr/include/gcc/darwin/3.3/c++/bits/stl_vector.h:511 #9 0x00382d7c in puOneShot::doHit(int, int, int, int) (this=0x0, button=0, updown=1000, x=2013490264, y=0) at puOneShot.cxx:32 #10 0x0037d370 in puObject::checkHit(int, int, int, int) (this=0x19969a10, button=0, updown=1, x=429300720, y=2) at puObject.cxx:508 #11 0x0037a46c in puGroup::checkHit(int, int, int, int) (this=0x199697f0, button=0, updown=1, x=102, y=23) at puGroup.cxx:218 #12 0x0037a46c in puGroup::checkHit(int, int, int, int) (this=0x199683c0, button=0, updown=1, x=102, y=23) at puGroup.cxx:218 #13 0x0035c8a8 in puMouse(int, int, int, int) (button=0, updown=1, x=364, y=316) at pu.cxx:365 #14 0x00235ed4 in FGInput::doMouseClick(int, int, int, int) (this=0x18b85000, b=0, updown=1, x=364, y=316) at input.cxx:282 #15 0x875270e8 in -[GLUTView _commonMouseUp:] () #16 0x92e02cfc in -[NSWindow sendEvent:] () #17 0x87542600 in -[GLUTWindow sendEvent:] () #18 0x92df5324 in -[NSApplication sendEvent:] () #19 0x87521cc4 in -[GLUTApplication _runMainLoopUntilDate:autoreleasePool:] () #20 0x87521df4 in -[GLUTApplication run] () #21 0x8753bd28 in glutMainLoop () #22 0x00010b54 in fgMainInit(int, char**) (argc=1, argv=0x4ff198) at main.cxx:1779 #23 0xa8fc in main (argc=1, argv=0x8756216c) at bootstrap.cxx:175 Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Ampere K. Hardraade wrote: I've got an error during compiliation: -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT -c -o viewer.o `test -f viewer.cxx || echo './'`viewer.cxx source='viewmgr.cxx' object='viewmgr.o' libtool=no \ depfile='.deps/viewmgr.Po' tmpdepfile='.deps/viewmgr.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/share/simgear/include -I/usr/X11R6/include -I/usr/local//include -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT -c -o viewmgr.o `test -f viewmgr.cxx || echo './'`viewmgr.cxx make[2]: *** No rule to make target `fg_os.cxx', needed by `fg_os.o'. Stop. make[2]: Leaving directory `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src' make: *** [all-recursive] Error 1 Same problem here - fg_os.cxx appears to be missing from the tarball - dropping the cvs version into place allows you to finish compiling it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier wrote: Erik Hofman wrote: Vivian Meazza wrote: SimGear-0.3.6-pre1 will not compile under Cygwin. It fails in [openal-test1.exe]: cannot find -lalut. This is using Norman's prebuild libraries, isn't it? Norman has integrated the alut library and the openal library so the reference should then be removed in the configure.ac in both SimGear and FlightGear. Is there a correct detection of libalut and libopenal in simgear configure.ac ? No, it's pre-defined for every platform right now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote: > Vivian Meazza wrote: > > > SimGear-0.3.6-pre1 will not compile under Cygwin. It fails in > > > > [openal-test1.exe]: cannot find -lalut. > > This is using Norman's prebuild libraries, isn't it? > Norman has integrated the alut library and the openal library so the > reference should then be removed in the configure.ac in both SimGear and > FlightGear. Is there a correct detection of libalut and libopenal in simgear configure.ac ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Vivian Meazza wrote: SimGear-0.3.6-pre1 will not compile under Cygwin. It fails in [openal-test1.exe]: cannot find -lalut. This is using Norman's prebuild libraries, isn't it? Norman has integrated the alut library and the openal library so the reference should then be removed in the configure.ac in both SimGear and FlightGear. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
Curt wrote > Sent: 16 July 2004 16:34 > To: FlightGear developers discussions > Subject: [Flightgear-devel] Next release of FlightGear > > I've started doing some of the pre-release work for FlightGear-0.9.5 > (which is the next release.) That means I'd like to do our "official" > next release in the next week or two. Please take a few minutes to > download the tar balls and test this pre1 release. Please! This is our > quality control so if no one tests the pre releases and reports > problems, they will end up in the final release. > SimGear-0.3.6-pre1 will not compile under Cygwin. It fails in [openal-test1.exe]: cannot find -lalut. And [openal-test2.exe]: cannot find -lalut. This is a known problem in cvs, and can be resolved by removing all reference to openal-test1 and openal-test2 in ~/simgear/sound/makefile.am If test1 and 2 are no longer required they should be removed, or this known bug should be fixed or recorded. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier wrote: Indeed, the package only contains fg_os_sdl.cxx. I think it reflects the packager's ( Curt ) own build option. And the package doesn't include Network/jpg-httpd.* . May I suggest to include all the files that are in conditional statement in Makefile.am to be include inconditionally in an EXTRA_DIST clause ? Yep. Thanks for the jpg-httpd.* reminder. This is now updated also. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Ampere K. Hardraade wrote: make[2]: *** No rule to make target `fg_os.cxx', needed by `fg_os.o'. Good catch. There was a mistake in the build system. This should be solved in the FlightGear-0.9.5-pre2. (In the mean time you could just copy the fg_os* files from CVS) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
I wrote: > Curtis L. Olson wrote: > > > I've started doing some of the pre-release work for FlightGear-0.9.5 > > (which is the next release.) That means I'd like to do our "official" > > next release in the next week or two. Please take a few minutes to > > download the tar balls and test this pre1 release. Please! This is our > > quality control so if no one tests the pre releases and reports > > problems, they will end up in the final release. > > Just a thought : > Maybe it would be wise to have a TerraGear release that match released > SimGear as well ? That would avoid question about compatibility issues > that are only resolved in CVS. And what about jumping in version numbers ( all 3 projects to 0.9.5 ) to make clear what are the dependencies ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Curtis L. Olson wrote: > I've started doing some of the pre-release work for FlightGear-0.9.5 > (which is the next release.) That means I'd like to do our "official" > next release in the next week or two. Please take a few minutes to > download the tar balls and test this pre1 release. Please! This is our > quality control so if no one tests the pre releases and reports > problems, they will end up in the final release. Just a thought : Maybe it would be wise to have a TerraGear release that match released SimGear as well ? That would avoid question about compatibility issues that are only resolved in CVS. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Indeed, the package only contains fg_os_sdl.cxx. I think it reflects the packager's ( Curt ) own build option. And the package doesn't include Network/jpg-httpd.* . May I suggest to include all the files that are in conditional statement in Makefile.am to be include inconditionally in an EXTRA_DIST clause ? Sorry I can't test that myself because I don't use automake for MSVC. -Fred Durk Talsma wrote: > Yep, I just got the same error. I had hoped that rerunning ./autgen.sh would > fix the problem but it appears not to. > > Cheers, > Durk > > > > On Saturday 17 July 2004 06:32, Ampere K. Hardraade wrote: > > I've got an error during compiliation: > > > > -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT > > -c -o viewer.o `test -f viewer.cxx || echo './'`viewer.cxx > > source='viewmgr.cxx' object='viewmgr.o' libtool=no \ > > depfile='.deps/viewmgr.Po' tmpdepfile='.deps/viewmgr.TPo' \ > > depmode=gcc3 /bin/sh ../../depcomp \ > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > > -I/usr/share/simgear/include -I/usr/X11R6/include -I/usr/local//include > > -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT > > -c -o viewmgr.o `test -f viewmgr.cxx || echo './'`viewmgr.cxx > > make[2]: *** No rule to make target `fg_os.cxx', needed by `fg_os.o'. > > Stop. make[2]: Leaving directory > > `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src/Main' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory > > `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src' > > make: *** [all-recursive] Error 1 > > > > > > Regards, > > Ampere > > > > On July 16, 2004 11:34 am, Curtis L. Olson wrote: > > > I've started doing some of the pre-release work for FlightGear-0.9.5 > > > (which is the next release.) That means I'd like to do our "official" > > > next release in the next week or two. Please take a few minutes to > > > download the tar balls and test this pre1 release. Please! This is our > > > quality control so if no one tests the pre releases and reports > > > problems, they will end up in the final release. > > > > > > Regards, > > > > > > Curt. > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Yep, I just got the same error. I had hoped that rerunning ./autgen.sh would fix the problem but it appears not to. Cheers, Durk On Saturday 17 July 2004 06:32, Ampere K. Hardraade wrote: > I've got an error during compiliation: > > -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT > -c -o viewer.o `test -f viewer.cxx || echo './'`viewer.cxx > source='viewmgr.cxx' object='viewmgr.o' libtool=no \ > depfile='.deps/viewmgr.Po' tmpdepfile='.deps/viewmgr.TPo' \ > depmode=gcc3 /bin/sh ../../depcomp \ > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > -I/usr/share/simgear/include -I/usr/X11R6/include -I/usr/local//include > -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT > -c -o viewmgr.o `test -f viewmgr.cxx || echo './'`viewmgr.cxx > make[2]: *** No rule to make target `fg_os.cxx', needed by `fg_os.o'. > Stop. make[2]: Leaving directory > `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src/Main' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src' > make: *** [all-recursive] Error 1 > > > Regards, > Ampere > > On July 16, 2004 11:34 am, Curtis L. Olson wrote: > > I've started doing some of the pre-release work for FlightGear-0.9.5 > > (which is the next release.) That means I'd like to do our "official" > > next release in the next week or two. Please take a few minutes to > > download the tar balls and test this pre1 release. Please! This is our > > quality control so if no one tests the pre releases and reports > > problems, they will end up in the final release. > > > > Regards, > > > > Curt. > > ___ > 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] Next release of FlightGear
On Friday 16 July 2004 17:34, Curtis L. Olson wrote: > I've started doing some of the pre-release work for FlightGear-0.9.5 > (which is the next release.) That means I'd like to do our "official" > next release in the next week or two. Please take a few minutes to > download the tar balls and test this pre1 release. Please! This is our > quality control so if no one tests the pre releases and reports > problems, they will end up in the final release. > There's one thing I can't really test right now with tearing apart my system, but seem to remember from previous update experience. AFAICT, the SimGear configure script currently doesn't check whether or not a working openal lib is installed. Maybe this is fixed already, if not, probably worth looking into. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Correction: Not only is fgfs missing, but so are metar, terrasync, and (est-epsilon?). Regards, Ampere On July 17, 2004 12:42 am, Ampere K. Hardraade wrote: > Oh, I forgot to mention, I installed simgear in /usr/share/simgear and > tried to do the same with FlightGear in /usr/share/FlightGear. > > I used the following commands when I was compiling FlightGear: > > ./configure --prefix=/usr/share/FlightGear > --with-simgear=/usr/share/simgear make (with the error showed up at the > end) > > make install works, but fgfs is missing in /usr/share/FlightGear/bin > > Regards, > Ampere > > On July 17, 2004 12:32 am, Ampere K. Hardraade wrote: > > I've got an error during compiliation: > > > > -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 > > -D_REENTRANT -c -o viewer.o `test -f viewer.cxx || echo './'`viewer.cxx > > source='viewmgr.cxx' object='viewmgr.o' libtool=no \ > > depfile='.deps/viewmgr.Po' tmpdepfile='.deps/viewmgr.TPo' \ > > depmode=gcc3 /bin/sh ../../depcomp \ > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > > -I/usr/share/simgear/include -I/usr/X11R6/include -I/usr/local//include > > -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 > > -D_REENTRANT -c -o viewmgr.o `test -f viewmgr.cxx || echo > > './'`viewmgr.cxx > > make[2]: *** No rule to make target `fg_os.cxx', needed by `fg_os.o'. > > Stop. make[2]: Leaving directory > > `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src/Main' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory > > `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src' > > make: *** [all-recursive] Error 1 > > > > > > Regards, > > Ampere > > > > On July 16, 2004 11:34 am, Curtis L. Olson wrote: > > > I've started doing some of the pre-release work for FlightGear-0.9.5 > > > (which is the next release.) That means I'd like to do our "official" > > > next release in the next week or two. Please take a few minutes to > > > download the tar balls and test this pre1 release. Please! This is > > > our quality control so if no one tests the pre releases and reports > > > problems, they will end up in the final release. > > > > > > Regards, > > > > > > Curt. > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Oh, I forgot to mention, I installed simgear in /usr/share/simgear and tried to do the same with FlightGear in /usr/share/FlightGear. I used the following commands when I was compiling FlightGear: ./configure --prefix=/usr/share/FlightGear --with-simgear=/usr/share/simgear make (with the error showed up at the end) make install works, but fgfs is missing in /usr/share/FlightGear/bin Regards, Ampere On July 17, 2004 12:32 am, Ampere K. Hardraade wrote: > I've got an error during compiliation: > > -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT > -c -o viewer.o `test -f viewer.cxx || echo './'`viewer.cxx > source='viewmgr.cxx' object='viewmgr.o' libtool=no \ > depfile='.deps/viewmgr.Po' tmpdepfile='.deps/viewmgr.TPo' \ > depmode=gcc3 /bin/sh ../../depcomp \ > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > -I/usr/share/simgear/include -I/usr/X11R6/include -I/usr/local//include > -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT > -c -o viewmgr.o `test -f viewmgr.cxx || echo './'`viewmgr.cxx > make[2]: *** No rule to make target `fg_os.cxx', needed by `fg_os.o'. > Stop. make[2]: Leaving directory > `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src/Main' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src' > make: *** [all-recursive] Error 1 > > > Regards, > Ampere > > On July 16, 2004 11:34 am, Curtis L. Olson wrote: > > I've started doing some of the pre-release work for FlightGear-0.9.5 > > (which is the next release.) That means I'd like to do our "official" > > next release in the next week or two. Please take a few minutes to > > download the tar balls and test this pre1 release. Please! This is our > > quality control so if no one tests the pre releases and reports > > problems, they will end up in the final release. > > > > Regards, > > > > Curt. > > ___ > 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] Next release of FlightGear
I've got an error during compiliation: -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT -c -o viewer.o `test -f viewer.cxx || echo './'`viewer.cxx source='viewmgr.cxx' object='viewmgr.o' libtool=no \ depfile='.deps/viewmgr.Po' tmpdepfile='.deps/viewmgr.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/share/simgear/include -I/usr/X11R6/include -I/usr/local//include -DPKGLIBDIR=\"/usr/share/FlightGear/share/FlightGear\" -g -O2 -D_REENTRANT -c -o viewmgr.o `test -f viewmgr.cxx || echo './'`viewmgr.cxx make[2]: *** No rule to make target `fg_os.cxx', needed by `fg_os.o'. Stop. make[2]: Leaving directory `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/share/FlightGear/source/FlightGear-0.9.5-pre1/src' make: *** [all-recursive] Error 1 Regards, Ampere On July 16, 2004 11:34 am, Curtis L. Olson wrote: > I've started doing some of the pre-release work for FlightGear-0.9.5 > (which is the next release.) That means I'd like to do our "official" > next release in the next week or two. Please take a few minutes to > download the tar balls and test this pre1 release. Please! This is our > quality control so if no one tests the pre releases and reports > problems, they will end up in the final release. > > Regards, > > Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Durk Talsma wrote: Curt and others, Just a quick question: Does this mean, we're entering a feature-freeze period now? Yes, I apologize for not being 100% clear ... I'm juggling way too many things this summer, but I'm still trying to get a release out. The reason I'm asking is that I have some upates for the traffic manager that I was planning to clean-up a bit and submit by the end of the weekend. This new code, while humble in size, is going to be a big step forward because it eliminates the dependency on predefined flightplans, and thus allows for much more flexibility in creating Traffic files. I seem to see a huge memory leak when leaving FG running for a long time. I suspect it is within the AI system somewhere, but I haven't really worked hard at verifying this. I am leaning towards having the AI system toggled off by default in the official release unless we can get to the bottom of this in the next couple days. I'm also in the process of creating some sample traffic patterns for the 737, going in and out of KSFO, based on the current United Airlines time table. I'd also like to see these included in the new version (and they depend on the new code), because it would liven up the dynamic scenery around KSFO quite a bit. As an aside, just after the release of 0.9.4, I reported two segfaults occurring randomly after prolonged FlightGear use (approx 8-10 hours of run time). One of those I managed to track down, but the other one never really got much attention. Would people downloading and testing the prereleases be willing to run FlightGear for extended periods of time (preferably from within gdb, so that we can try to find some evidence whether or not this bug is still there and find some evidence about it's nature? I haven't had a chance to do long runs of FG in the last couple weeks, but if there are segfaults floating around, we should attack them aggressively. 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
"Ampere K. Hardraade" wrote: > The file or > folder /site/ftp.flightgear.org/flightgear-ftp/Source/FlightGear-0.9.5-pre1.tar.gz ^^ > does not exist. Simply put a "de." in there, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Curt and others, Just a quick question: Does this mean, we're entering a feature-freeze period now? The reason I'm asking is that I have some upates for the traffic manager that I was planning to clean-up a bit and submit by the end of the weekend. This new code, while humble in size, is going to be a big step forward because it eliminates the dependency on predefined flightplans, and thus allows for much more flexibility in creating Traffic files. I'm also in the process of creating some sample traffic patterns for the 737, going in and out of KSFO, based on the current United Airlines time table. I'd also like to see these included in the new version (and they depend on the new code), because it would liven up the dynamic scenery around KSFO quite a bit. As an aside, just after the release of 0.9.4, I reported two segfaults occurring randomly after prolonged FlightGear use (approx 8-10 hours of run time). One of those I managed to track down, but the other one never really got much attention. Would people downloading and testing the prereleases be willing to run FlightGear for extended periods of time (preferably from within gdb, so that we can try to find some evidence whether or not this bug is still there and find some evidence about it's nature? Any thoughts? Cheers, Durk On Friday 16 July 2004 17:34, Curtis L. Olson wrote: > I've started doing some of the pre-release work for FlightGear-0.9.5 > (which is the next release.) That means I'd like to do our "official" > next release in the next week or two. Please take a few minutes to > download the tar balls and test this pre1 release. Please! This is our > quality control so if no one tests the pre releases and reports > problems, they will end up in the final release. > > Regards, > > Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Ampere K. Hardraade wrote: The file or folder /site/ftp.flightgear.org/flightgear-ftp/Source/FlightGear-0.9.5-pre1.tar.gz does not exist. Did anyone encounter this problem? Most likely sunsite hasn't sync'd it's mirror yet. You can always go direct to ftp://ftp.flightgear.org 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
The file or folder /site/ftp.flightgear.org/flightgear-ftp/Source/FlightGear-0.9.5-pre1.tar.gz does not exist. Did anyone encounter this problem? Regards, Ampere On July 16, 2004 11:34 am, Curtis L. Olson wrote: > I've started doing some of the pre-release work for FlightGear-0.9.5 > (which is the next release.) That means I'd like to do our "official" > next release in the next week or two. Please take a few minutes to > download the tar balls and test this pre1 release. Please! This is our > quality control so if no one tests the pre releases and reports > problems, they will end up in the final release. > > Regards, > > Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
