[Flightgear-devel] Submodels and MP objects
Hello everybody, I have noticed since quite a while that collision detection of submodels with MP Objects doesn't work anymore. It works fine with normal AI Objects (Aircraft, Ship and groundvehicles). MP Objects seem to be ignored. Has anybody else noticed this? Greetings -- Detlef Faber http://www.sol2500.net/flightgear -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Selectable ignore for MP chat
On Sun, 11 Oct 2009, Rob Shearman, Jr. wrote: Oh, it has a select all then? :) :) :) That option is available in the View-Rendering Options dialog! Uncheck Show chat messages. :) (It might hide slightly more than you asked for, though) Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Submodels and MP objects
Detlef Faber Hello everybody, I have noticed since quite a while that collision detection of submodels with MP Objects doesn't work anymore. It works fine with normal AI Objects (Aircraft, Ship and groundvehicles). MP Objects seem to be ignored. Has anybody else noticed this? Greetings I hadn't noticed it, but it might be a bug introduced when I added ground vehicles. I'll check it out. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
DurkTalsma wrote: FWIW, I would like to build a minimum base package this time, which only consists of one aircraft, no AI, and a minimal set of shared models. AI and other aircraft can be released as a separate ADDON packages, or via CVS. Likewise, shared models are now maintained via terrasync/SVN, so that is also taken care of. I'm very, very, concerned with this approach, and see a number of significant issues: 1) We're effectively telling new users that they need to be able to install new packages and customize their FG installation to do any reasonable level of virtual flying. With 1.9.1 they could quite happily fly in MP around KSFO and have a pretty good user experience without installing anything else. Frankly, I doubt that our install tools and instructions are user-friendly enough to support this approach. We're requiring a much higher level of computer know-how from our user-base, so this will have significant implications for our documentation and the level of basic help that will be required on the Forums. 2) Only including a single aircraft implies that the simulator is only really designed for that aircraft, and any other aircraft may represent a compromise in quality or capabilities. This will be particular apparent when people do the inevitable comparison with MSFS and X-Plane, which include a wider selection of aircraft with the initial install. 3) New users often want to fly a military jet or commercial jet ASAP, despite this being an un-realistic goal. If we increase the barrier to entry for these people to even get into the cockpit of something that they want to fly, we'll see a lot more people giving up on FG before they get hooked. 4) Adequately documenting how to install the various ADDON packages in a way that can be understood by users, and getting them to RTFM. Martin and I have put quite a bit of effort into providing instructions for Aircraft and Scenery in The Manual, and yet people still have problems. Having to provide additional instructions for AI aircraft as well is going to be a pain. 5) Deciding which single aircraft to include, and ensuring that it is a shining example of what FG can do. Ideally, we should have decided on the aircraft months ago, and encouraged a concentrated effort to make it as complete as possible. If we are really concerned about the size of the base package, I suggest that rather than restrict it to a minimum, we offer two different but complete install images: 1) FG-Lite with a single aircraft, no AI aircraft and a big warning that they won't be able to see more than one or two aircraft in MP! 2) FG-Deluxe with a wider selection of aircraft and a full set of AI aircraft. Much closer to what we provided in 1.9.1 Of course, this requires a lot more effort from our packagers, and may also cause some confusion amongst new users, but if we want to grow the FG community making things more difficult for the user is not the way forward. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGMS v1.0.0
Hi, As promised I've put my current sources of the development branch of fgms into cvs, see http://fgms.sourceforge.net/cvsresources.php for details. So the curious can have a look and test-compile it. Do not expect to much from it. The testclient (mpdummy) sends an authentication request to the server and the server receives and handles it (but does not yet send a reply). Enjoy, and don't forget to give me comments, suggestions, flames, whatever. Cheers, Oliver -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
On Mon, 12 Oct 2009 08:13:51 + (GMT), Stuart wrote in message 305052.62106...@web26005.mail.ukl.yahoo.com: DurkTalsma wrote: FWIW, I would like to build a minimum base package this time, which only consists of one aircraft, no AI, and a minimal set of shared models. AI and other aircraft can be released as a separate ADDON packages, or via CVS. Likewise, shared models are now maintained via terrasync/SVN, so that is also taken care of. I'm very, very, concerned with this approach, and see a number of significant issues: 1) We're effectively telling new users that they need to be able to install new packages and customize their FG installation to do any reasonable level of virtual flying. With 1.9.1 they could quite happily fly in MP around KSFO and have a pretty good user experience without installing anything else. Frankly, I doubt that our install tools and instructions are user-friendly enough to support this approach. We're requiring a much higher level of computer know-how from our user-base, so this will have significant implications for our documentation and the level of basic help that will be required on the Forums. 2) Only including a single aircraft implies that the simulator is only really designed for that aircraft, and any other aircraft may represent a compromise in quality or capabilities. This will be particular apparent when people do the inevitable comparison with MSFS and X-Plane, which include a wider selection of aircraft with the initial install. 3) New users often want to fly a military jet or commercial jet ASAP, despite this being an un-realistic goal. If we increase the barrier to entry for these people to even get into the cockpit of something that they want to fly, we'll see a lot more people giving up on FG before they get hooked. 4) Adequately documenting how to install the various ADDON packages in a way that can be understood by users, and getting them to RTFM. Martin and I have put quite a bit of effort into providing instructions for Aircraft and Scenery in The Manual, and yet people still have problems. Having to provide additional instructions for AI aircraft as well is going to be a pain. 5) Deciding which single aircraft to include, and ensuring that it is a shining example of what FG can do. Ideally, we should have decided on the aircraft months ago, and encouraged a concentrated effort to make it as complete as possible. If we are really concerned about the size of the base package, I suggest that rather than restrict it to a minimum, we offer two different but complete install images: 1) FG-Lite with a single aircraft, no AI aircraft and a big warning that they won't be able to see more than one or two aircraft in MP! 2) FG-Deluxe ...I'd call that FG-Standard... with a wider selection of aircraft and a full set of AI aircraft. Much closer to what we provided in 1.9.1 ...and reserve FG-Deluxe for all the bells 'n whistles etc... Of course, this requires a lot more effort from our packagers, and may also cause some confusion amongst new users, but if we want to grow the FG community making things more difficult for the user is not the way forward. -Stuart -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sunday 11 Oct 2009, Alan Teeder wrote: -Original Message- From: leee [mailto:l...@spatial.plus.com] ie if u stick in a new value to the FDM then it will react.. That sucks in my oioiion.. I how have to create my own craqo to make the model. that sucks to me.. pete You really need to chill a bit. Just moaning about things isn't the best way to go about getting stuff fixed. Anyway, in short, this 'problem' such as it is, is largely due to the rates at which the autopilots are run within FG. In real life, autopilot controllers, and the sensors that feed them the data they need to work with, run at much higher frequencies than are possible within the FG framework. Ideally, you want to be able to run the autopilots at several to many kHz but in FG, although you can specify very high rates in the autopilot config, you are effectively limited by the frame rate, so not only do they run much more slowly than is desirable but they also run at varying rates as the frame rate changes. Lee First, thanks for the quick into to Flightgear´s autopilot. I think that your premise that autopilots need to run at very high frame rates is not realistic. I guess it depends upon what you're trying to do. If you just need an autopilot for a light aircraft or an airliner, where you want fairly slow and gentle responses, you can get away with relatively low rates. Apart from frame-rate induced instabilities, I found the rates that I could get, on my relatively old kit, acceptable for the larger aircraft I did. For the faster and more maneuverable military jets though, I found that I really needed guaranteed higher rates to both ensure a crisp response and avoid instabilities. For example, I could tune an altitude-hold cascade that would work fine at speeds up to 400kt say, but which would become unstable above that. The reason was that the rate of deviation increases with aircraft speed as the control surfaces generate more force for a given deflection, so for a given deflection of the control surfaces by the controller, it sees a greater response result in its next sample. Eventually, it can't help but over-correct and go into oscillation. Running the controller at a higher rate though, would mean that it would see a smaller deviation because the aircraft would have moved less in the shorter time period. Now admittedly, I the autopilots I were working on were more like FBW/FMS systems. For example, I was using a three-stage cascade for elevator control and the final elevator driver stage had to be able to maintain pitch between take-off and landing speeds, up to top speed, a typically range of 130-1200 kts. To maintain control at take-of and landing speeds, the elevators need a lot of authority, and to be quite honest, pretty brutal, but you can't apply that brutefulness at top speed. One way to ameliorate this was to use reciprocal filters to reduce the controller gains as the speed increases, but once again, a higher guaranteed sample rate would be better. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. You can think of the different autopilot controllers and filters as analogue logic building blocks. You're pretty much building an analogue computer when you set up a complex autopilot. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. As I've mentioned, you can simulate the control surface actuators in the aircraft FDM config, both in JSBSim and YASim. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. Alan There's the rub really, as the response of the aircraft is quite slow. LeeE -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
-Original Message- For the faster and more maneuverable military jets though, I found that I really needed guaranteed higher rates to both ensure a crisp response and avoid instabilities. For example, I could tune an altitude-hold cascade that would work fine at speeds up to 400kt say, but which would become unstable above that. The reason was that the rate of deviation increases with aircraft speed as the control surfaces generate more force for a given deflection, so for a given deflection of the control surfaces by the controller, it sees a greater response result in its next sample. Eventually, it can't help but over-correct and go into oscillation. Running the controller at a higher rate though, would mean that it would see a smaller deviation because the aircraft would have moved less in the shorter time period. Did you try scheduling your autoplilot´s height-error to pitch demand gain with 1/V (speed inverse) ? Alan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] October $250 Flight Gear Developers
Hi Heiko, On Tuesday 06 October 2009 08:16:11 am Heiko Schulz wrote: That's one the best article I found about ProFlightSim: http://ezinearticles.com/?Flight-Pro-Sim-is-the-Best-Simulatorid=2813712 Interesting, I actually decided to leave a comment behind, in response to this article, explaining that Flight Pro Sim is actually a repackaged version of FlightGear and that, while this is legal, we were actually hoping that our communication with the Flight Pro Sim team would be more open and less secretive on their part. I also stated being quite flattered by their praise regarding the accurate position of sun, moon, stars, and planets (since that was originally my code, except for the stars), :-). I think it turned out to be a relatively positive comment, and I'm really surprised that it still isn't posted there yet. All comments are moderated In actual fact, the above comment is quite the way I feel about this; I have no problem with somebody repackaging, re-branding and selling FlightGear, as long as the GPL is honored. Mainly, as long as the GPL is honored, I'm not too concerned about somebody making huge loads of cash behind our backs. Just to put it in perspective. I'm sometimes amazed at FlightGear's popularity. Yet the commercial re-branded versions are still extremely obscure. So, the majority will much sooner be drawn toward us than toward a competitor, and if a few copies are sold, the people buying them are completely free to distribute their copy, and eventually may find out about FlightGear itself. So, if the number of sales of a slightly improved FlightGear remains limited, I wouldn't have too many problems with that. Simply because the nature of the license and our popularity would correct the situation rather quickly. Basically, I'm assuming that you would have to live on another planet to get interested in Flight Simulation, buy Flight Pro Sim, and not eventually stumble upon one web page or another referring to FlightGear, or making the connection between FlightGear and Flight Pro Sim. IF, on the other hand, the GPL license would not be honored than it wouldn't matter with license we choose because the perpetrator wouldn't care anyhow. So, in essence, I believe that in our current situation the GPL is still our best option, guaranteeing our basic freedom. My impression is that the person/people behind the Flight Pro Sim product are reasonably genuine in what they are doing, but that they have chosen a business model that is rather unfortunate; not only for us, but also something that would hurt themselves in the long run. This might not not necessarily be deliberate, but might be something borne out of inexperience. Since it isn't clear from their website that their product is an adaptation of FlightGear, imagine the disappointment of a buyer who as just found out. Now, in contrast, consider that I would be interested in a product called FlightGear Pro, from a reseller who clearly mentions up front that this program is a commercial adaptation of FlightGear, but with the added bonus of having a nice shell around it connecting all the loose bells and whistles in addition to having a knowledgeable help desk. Now somebody knowingly buying a program like that would never be disappointed due to the link between the free open source FlightGear program, and the commercially repackaged FlightGear-pro. And, likewise, I don't think that any of us developers would have a problem with a commercial distribution that is adding so many bells and whistles and service to the program Cheers, Durk -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hi,
I got an error with the Sunday CVS - FG crashed while exiting .
gdb reports SIGSEGV error at file soundmgr_openal.cxx, line 159.
Error was fixed by changing lines 157-159 from:
buffer_map_iterator buffers_current = _buffers.begin();
buffer_map_iterator buffers_end = _buffers.end();
for ( ; buffers_current != buffers_end; ++buffers_current ) {
to :
buffer_map_iterator buffers_current;
while(_buffers.size()){
buffers_current = _buffers.begin();
With respect,
Alex
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Stuart Buchanan wrote: Scott Hamilton wrote: On Tue, 2009-10-06 at 22:06 -0400, William Harrison wrote: Maybe it's just me, but has anyone noticed a dramatic performance decrease with 3d clouds after this patch? yep, from 30fps to 2fps... I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. The code falls back to a 2D cloud layer if a 3D cloud isn't defined for a specific cloud type (st, ac etc.). IIRC previously we didn't define a 3D stratus layer, so we'd get a 2D layer instead. The updated 3D clouds include stratus layers (which look rather nice IMO), but require quite a larger number of sprites - something like 40 per cloud. I've seen a small perf hit from the new stratus layers, but nothing like what you have reported. I suspect what you are seeing if the difference between a 2D and 3D cloud. What performance change are you seeing with, say, cumulus clouds, which haven't changed much? BTW - I've updated Docs/Readme.3Dclouds with information on the new format, if anyone is interested in enhancing the clouds. -Stuart What I have seen (airplane-ufo, altitude - 2000ft, cloud layer 0 = 4000ft, overcast, cloud layer 1 = 19500ft, cirrus): 1. 3D clouds OFF from command line: FPS=70, memory usage 360M, layer 0 - visible. 2. 3D clouds ON from command line: memory usage from 800M up to 1.2G - pitch =0 deg : FPS=10-12 - pitch =90 deg : FPS=70 - pitch =-90 deg : FPS=70 3. 3D clouds ON from command line, than switch OFF from menu : FPS = 60-70, memory usage 700-800M 4. 3D clouds ON from command line, start at lat,lon = 0, 0 (no scenery loaded) : NO clouds in layer 0, both 3D and 2D. If switch 3D clouds OFF from menu then 2D clouds appears. With respect, Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG crashes when changing visibility
Hi, I was noticed that FG hangs and than crashes if pressing z key. If visibility value is not controlled by user, it can be occasionally **increased to a huge value (1000 km). In this case TileLoader is trying to load hundreds of tiles. At the beginning I was expected a number of tiles to be limited by the size of TileCache (100), but I was mistaken. Size of TileCache is growing in routine FGTileMgr::schedule_needed( ... ) to make space for all tiles. On my PC when /environment/visibility-m 500-1000km memory usage grows from 300M up to 3G an this leads to crash. Can somebody limit the value in property /environment/visibility-m or the value of variable vis in FGTileMgr::schedule_needed( ... ). The maximum value of 100km will be acceptable IMHO. With respect, Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hi Erik (sorry Erik ;)) Bit of background : I used to use Vivian setup when I first starting building my own exe a while back (OpenAL SDK 1.1 + freealut 1.0.1) and sound worked. I switched to Fredb's third party libs a few months back, sound worked. Now, I can build a working exe with my old/Vivian's setup, but get no working sound (and no errors) but I do have the crash on exit. I believe it's because we're trying to release the alcDevice and alcContext a second time by calling AlutExit., after doing it manually in the stop method of the soundmanager. Anyone has sound on Vista64, with VC9, with latest CVS and OpenAL SDK 1.1 + freealut 1.0.1 ? Before anyone mentions hardware problems, I only have a generic software device since Vista never had support for hardware 3d positional audio in hardware through DirectSound, it was dropped before release. There never was generic hardware positional audio support in Vista. So only the Generic Software device available to OpenAL, thus cannot be that my default device is a malfunctioning hw wrapper (we pass null to the device selection code, so we get the default one, whatever it is) And OpenAL works fine here, many other apps using the exact same dll, so I'm at a bit of a loss at the moment to root that one out. Will look further into it as time permits, but would love to hear if anyone has to this setup working under Vista64, especially as it use to work (yes, I've gotten rid of AL part of the 3rd party stuff to avoid it being referenced, to make sure the SDK is used. I've triple checked everything) Cheers, and thanks again Erik for working on the sound system. Nic On Sun, Oct 11, 2009 at 10:04 AM, Geoff McLane ubu...@geoffair.info wrote: On Sun, 2009-10-11 at 15:49 +0200, Erik Hofman wrote: Geoff McLane wrote: I hope this makes it into CVS sometime soon... Was his soon enough? ;-) Erik So slick and quick... thanks... Geoff. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Alex Buzin wrote:
Hi,
I got an error with the Sunday CVS - FG crashed while exiting .
gdb reports SIGSEGV error at file soundmgr_openal.cxx, line 159.
Error was fixed by changing lines 157-159 from:
buffer_map_iterator buffers_current = _buffers.begin();
buffer_map_iterator buffers_end = _buffers.end();
for ( ; buffers_current != buffers_end; ++buffers_current ) {
to :
buffer_map_iterator buffers_current;
while(_buffers.size()){
buffers_current = _buffers.begin();
Good catch, and odd it didn't provide a problem for me.
It's committed.
Erik
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Nicolas Quijano wrote: Now, I can build a working exe with my old/Vivian's setup, but get no working sound (and no errors) but I do have the crash on exit. I believe it's because we're trying to release the alcDevice and alcContext a second time by calling AlutExit., after doing it manually in the stop method of the soundmanager. I think this is fixed by a patch I just committed. Since alut is initialized without a Context it shouldn't try to destroy it either. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG crashes when changing visibility
Hi Alex, a 100 cliks is way too low, visual horizon at 3 feet is much higher than 100 km, and users with the horsepower might want to set it to what it is in real life : the visual horizon at 3 feet to sea level is over 350 km, close to 360. http://radarproblems.com/calculators/horizon.htm If we don't have it exposed in preferences.xml, having a user accessible and settable limit for visibility would do the trick rather than an arbitrary value that will not cater to all cases. Cheers, Nic On Mon, Oct 12, 2009 at 1:18 PM, Alex Buzin buzin6...@hotmail.com wrote: Hi, I was noticed that FG hangs and than crashes if pressing z key. If visibility value is not controlled by user, it can be occasionally **increased to a huge value (1000 km). In this case TileLoader is trying to load hundreds of tiles. At the beginning I was expected a number of tiles to be limited by the size of TileCache (100), but I was mistaken. Size of TileCache is growing in routine FGTileMgr::schedule_needed( ... ) to make space for all tiles. On my PC when /environment/visibility-m 500-1000km memory usage grows from 300M up to 3G an this leads to crash. Can somebody limit the value in property /environment/visibility-m or the value of variable vis in FGTileMgr::schedule_needed( ... ). The maximum value of 100km will be acceptable IMHO. With respect, Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
On Wed, 2009-10-07 at 22:03 +1100, Scott Hamilton wrote: On a final note, I did a 'make distclean' and ./configure for both SimGear and FlightGear and now the change in frame rate is acceptable, it goes from 30 fps to around 22 - 24 fps once 3D clouds are turned on. S. On Wed, 2009-10-07 at 09:18 +, Stuart Buchanan wrote: Scott Hamilton wrote: On Tue, 2009-10-06 at 22:06 -0400, William Harrison wrote: Maybe it's just me, but has anyone noticed a dramatic performance decrease with 3d clouds after this patch? yep, from 30fps to 2fps... OK, I hope this reproducer scenario helps; 1. don't turn on 3D clouds from command line, don't specify any weather (manual metar), default; scattered at 4000ft and cirrus at 19500 25-31fps 2. go into rendering options, turn on 3D clouds 2-3fps 3. change 19500 from cirrus to clear 2-6fps 4. change 4000 from scattered to few remains 2-6 fps 5. change 4000 from few to clear 20-24fps 6. turn OFF 3D clouds (so there is no 3D or 2D clouds) 23-26fps I last built fgfs 2009-10-03 19:23 (Sydney time) I've now done a cvs update and 'make clean' on SimGear and FlightGear and updated data/Shaders/ 1. same as a above. The cmd line is; bin/fgfs --enable-sound --enable-hud --aircraft=A380 --airport=YSSY --runway=34L --timeofday=afternoon 28-32fps 2. go into rendering options, turn ON 3D clouds 7 fps 3. change 19500 from cirrus to clear remains 7fps 4. change 4000 from scattered to few 10-11fps 5. change 4000 from few to clear 23-27fps 6. turn OFF 3D clouds remains 23-27fps Operating System: openSuSE 11.1 (kernel2.6.27.29-0.1-default ) Model: nVidia Quadro FX 580 I'm assuming shaders need some OpenGL help; # glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_ARB_create_context, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_multisample_coverage GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro FX 580/PCI/SSE2 OpenGL version string: 3.0.0 NVIDIA 180.44 I hope something here helps, as they do look good, but I can't get off the ground to see them :) cheers S. I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. The code falls back to a 2D cloud layer if a 3D cloud isn't defined for a specific cloud type (st, ac etc.). IIRC previously we didn't define a 3D stratus layer, so we'd get a 2D layer instead. The updated 3D clouds include stratus layers (which look rather nice IMO), but require quite a larger number of sprites - something like 40 per cloud. I've seen a small perf hit from the new stratus layers, but nothing like what you have reported. I suspect what you are seeing if the difference between a 2D and 3D cloud. What performance change are you seeing with, say, cumulus clouds, which haven't changed much? BTW - I've updated Docs/Readme.3Dclouds with information on the new format, if anyone is interested in enhancing the
[Flightgear-devel] Pauses in flightgear
I am having some strange pause problems in flightgear fgrun+fgfs-osg-win32-cvs-20090817 with corresponding data. My CPU is not flat out at 100% while this is happening it seems to be something else causing the problem! Here is a video I have made showing the problem. Video Test Of me landing at Switzeland HD http://www.veoh.com/browse/videos/category/entertainment/watch/v19210020c5NpGfhr Aerotro Online FlightGear Simulator Tracker Page. http://mpserver04.flightgear.org http://www.flightgear.org-- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
