[Flightgear-devel] Failed to select the language for Flightgear
Failed to select the language Hi ! I'm confusing that when I use the FGrun,every time I select language from the Advanced Options(e.g. ,I input fr for French),the language of the FlightGear remains English.It remains the same Even when I use the command line to select the language(I input the command as fgfs --language=fr,the FG rans but the menu is still English). My operation system is Windows xp,and the version of the Flightgear is 2.6.0. Could you please tell me anything about the reason? -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed to select the language for Flightgear
On 18.04.2012 07:03, 刘先生 wrote: I'm confusing that when I use the FGrun,every time I select language from the Advanced Options(e.g. ,I input fr for French),the language of the FlightGear remains English.It remains the same Even when I use the command line to select the language(I input the command as fgfs --language=fr,the FG rans but the menu is still English). Could you please tell me anything about the reason? See http://code.google.com/p/flightgear-bugs/issues/detail?id=263 It's broken for a long time. Right now, only the language for the command-line help can be switched, not the language for the menu. cheers, Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terrain mesh
Hi I only wanted to throw in that x-plane is using an opensource terrain mesh... So maybe we could use/integrate some of that? We could also get compatibility with photoscenery etc. Cheers Michael -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed to select the language for Flightgear
Hi 刘先生, already replied to your forum topic an hour ago ;-) http://www.flightgear.org/forums/viewtopic.php?f=35t=16071 Thorsten wrote: Right now, only the language for the command-line help can be switched And even that appears broken now... Or is it just me and some fault in my home-built FG? Cheers, Gijs -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. Vic -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed to select the language for Flightgear
On 18.04.2012 10:34, Gijs de Rooy wrote: Right now, only the language for the command-line help can be switched And even that appears broken now... Or is it just me and some fault in my home-built FG? Indeed. It got broken when the evaluation of command-line options was restructured. I'm adding this to the bug report... cheers, Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
What *is* the baseline hardware fg ought to be aiming at? -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed to select the language for Flightgear
On 18 Apr 2012, at 10:00, ThorstenB wrote: Indeed. It got broken when the evaluation of command-line options was restructured. I'm adding this to the bug report... Whoops, my bad. Will take a look. James -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Random Buildings
Hi All, A while back I initiated a discussion about improving our random buildings, and got lots of very useful feedback and suggestions. The first part of this (masking of random object and vegetation placement to match the underlying terrain texture) has been in git for some time. I have finally got around to implementing the second part - generating (efficient) random buildings. Before and after screenshots: Before - http://www.nanjika.co.uk/flightgear/buildings-old.jpg After - http://www.nanjika.co.uk/flightgear/buildings.jpg At a functional level, there are three different size of buildings (small, medium, large), with slightly different constraints (small and medium buildings are never deeper than they are wide, small buildings may have pitched roofs). Various parameters can be set in the materials.xml file, such as the proportion of each building size, the texture file (which is shared across all buildings), and the range of sizes of each building. The actual buildings are then generated by FG itself directly as OSG primitives. Obviously, this would be pointless if frame-rates were hit to the same extent as they are with a similar number of normal models. The good news is that on my system there is _no_ fps drop from the random buildings. I get the same frame-rate whether or not the random buildings are generated or not. The same applies whether or not I'm running with Rembrandt. Of particular note - I get significantly better frame-rates with this rather than the urban shader. For those interested, the technical background is as follows: - a Quadtree is used to ensure very fast culling of the buildings - based on the work that Tim Moore did for the forests. - a single 1024x1024 texture is used for all the buildings, minimizing the number of state changes on the GPU - all the buildings at the leaf of the quadtree are part of the same geometry, so the GPU can churn through it very quickly without having to change state. There are still some bugs to be worked out before this can be pushed to git, but I'm hoping to get it checked in over the weekend. If someone is interested in spending some time creating a better default texture, please get in touch. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On 18 Apr 2012, at 10:25, Stuart Buchanan wrote: There are still some bugs to be worked out before this can be pushed to git, but I'm hoping to get it checked in over the weekend. Fantastic. And, the performance numbers confirm many discussions here - the batched geometry with no state changes is very efficient, it's nodes, transforms and state changes that are killing us. Could you make the density controllable? If the hit is really 'almost zero', I think about double the density in your screenshot would look even better. James -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Wed, 2012-04-18 at 09:46 +0100, Vic Marriott wrote: It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. Why does anybody always expect the most imressive results on their old Intel 486DX? Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Before and after screenshots: Before - http://www.nanjika.co.uk/flightgear/buildings-old.jpg After - http://www.nanjika.co.uk/flightgear/buildings.jpg Wow, this looks pretty good! Why are there buildings on the street though - isn't that a different landclass? Does this have to an US-style rectangular street grid, or can we come up with an algorithm to draw more European-style street patterns (I think an adaption of the Markov chains I've been using for the undulatus cloud patterns might do the trick)? And, the performance numbers confirm many discussions here - the batched geometry with no state changes is very efficient, it's nodes, transforms and state changes that are killing us. I don't know... might be lack of transparency and low vertex count as well. The buildings are more or less cubes, if there are 1000 visible it's ~8000 vertices, usually I see performance deteriorating when I go from ~400.000 vertices to 800.000 vertices, if you throw 10.000 more in or not is just lost in the variations in scenery vertex count. I thought a lot of the resource drain comes from models with an xml-wrapper. Well, I'm looking forward to this! Cheers, * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 18, 2012 at 10:30 AM, James Turner wrote: Could you make the density controllable? If the hit is really 'almost zero', I think about double the density in your screenshot would look even better. Yes, the density is controllable in the same way as the random vegetation density (i.e. requires a scenery reload to take effect). However, one of the issues I'm hitting right now is that I have to avoid overlapping buildings by binning buildings that are too close to other buildings. As density increases you get more overlapping, and spend more time binning points, so scenery loading starts taking longer. One of the things I'm looking at before checking this in is making that process more efficient, as well as dealing with non-random objects. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
However, one of the issues I'm hitting right now is that I have to avoid overlapping buildings by binning buildings that are too close to other buildings. As density increases you get more overlapping, and spend more time binning points, so scenery loading starts taking longer. Create a grid with a (density-dependent) cell size up-front and roll a dice for every cell once if there's a building in or not - this avoids dealing with overlap issues. You might even save some random number generation... * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Wed, Apr 18, 2012 at 10:45 AM, Renk Thorsten wrote: Wow, this looks pretty good! Why are there buildings on the street though - isn't that a different landclass? That's a bug in the placement algorithm - the buildings shouldn't extend past the edges of the city landclass. I'm planning to fix that before checking it into git. Does this have to an US-style rectangular street grid, or can we come up with an algorithm to draw more European-style street patterns (I think an adaption of the Markov chains I've been using for the undulatus cloud patterns might do the trick)? The current city textures are US-style rectangular street grids. Placement and rotation of the buildings uses the terrain-masking, where a second texture is used as a mask for placement and rotation. If you have a more European city texture, it would take ~1hr to create a suitable mask (the difficult bit is mentally converting the rotation in degrees into a 0-256 colour value!). Note also that changes I made to the materials.xml loading a couple of months ago so that any condition tags on the material definition are evaluation at tile loading time, and the directory structure would make it very easy to apply such a texture/mask to just European cities. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
What *is* the baseline hardware fg ought to be aiming at? I guess in practice every developer works such that stuff runs well on his own system. What else can we do? I'm not buying a second computer just to test how it would run on a Mac. Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Actually, as Stuart or Mathias have demonstrated here, that's not always true. We seem to be getting more random buildings for less framerate impact for instance. Same was true with the clouds or with the geodinfo() which suddenly was a factor 50 faster. There are sometimes clever ways of doing a task much faster, and one has to spot them. More often, there are clever ways to do a task a bit faster. Taking a week to streamline shader code, I have typically gained 10-20% improvement in the past, at the expense of making the code difficult to understand. Not much, but I notice it, especially summing up several such effects. I didn't get the impression we usually make things as efficient as they could be. Many slow-changing quantities are determined per frame, or when it's clear that they're not needed for instance. An example is ridge lift which is updated per frame at agl altitudes of 20.000 ft when its value is ~1e-5 and it's clear that there can't be any real lift. Many distance calculations in Nasal scripts in the visible scene use spherical geometry while they could be in local Cartesian geometry which is about a factor 5 faster to compute. The problem with making things efficient is that you have to understand well what you're doing. If you approximate an expression by something that works faster with the same accuracy in most cases, you need to take care of the case when it doesn't work. It's a weakness of the modular structure of the Flightgear project that there's hardly anyone with the 'big picture' who knows enough to realize where computations are repeated and how we could streamline the whole. So, I think we can agree that spending performance on improvements, optionally implemented, is reasonable and desirable, burning performance in inefficient code is not desirable, but how to translate this into practical consequences isn't as easy to see. People are trying as a rule. Cheers, * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Wow, this is beyond awesome! And even better than the buggy shader! I'd take a look at the texture(s) used and see what I can do. B. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Vic wrote: It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. The point is that those have halfway decent hardware can use the new features, and those who haven't can't. If we want to make the effort - well that's free. If we could find a way of doing shadows etc. which could run on older hardware then we would. Perhaps as development continues we will be able to optimise the system to find more framerate. By the way - just how old is the hardware you are using? The hardware needed to run this stuff can be picked up on eBay for peanuts. Vivian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Wed, 2012-04-18 at 10:33 +, Renk Thorsten wrote: What *is* the baseline hardware fg ought to be aiming at? I guess in practice every developer works such that stuff runs well on his own system. What else can we do? I'm not buying a second computer just to test how it would run on a Mac. Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Actually, as Stuart or Mathias have demonstrated here, that's not always true. We seem to be getting more random buildings for less framerate impact for instance. Same was true with the clouds or with the geodinfo() which suddenly was a factor 50 faster. There could sometimes be room for improvement but that is only because of slightly less optimal use of resources in the current implementation. But in general the argument sticks. Don't get me wrong; every improvement is great (and welcome) but it is silly to expect (or almost demand) Rembrandt to run on older hardware. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Hi All! The new rembrandt project is really cool, it seems to be the eyecandy that's currently missing. I check for new and watch the youtube updates quite regularly, mostly clips of fred etc. (wish there we some more hehe) However,I'm not that happy with performance (FPS) with or without rembrandt and in my humble opinion my hardware is not outdated, My machine: Core i7 920 2.8 ghz 24 Gbyte ram ocz vertex 2 and sandforce SSD storage 4x 1 tbyte SATA ATI 5870 Asus Xonar d2x soundcard I often choose to fly in areas with very little or non exciting scenery, basically because when i do my frames per second either fluctuate too heavily, and gameplay stutters which is quite annoying and setting max fps to the lowest stable number isn't really a preferred option as the lowest value is simply to low for smooth simulation/gameplay. Or simply because i find performance too low (e.g. 20 - 30 fps), e.g. KSFO, EHAM the more 'advanced' scenery. When i do fly in those areas i basically disable all the eyecandy you want on, random vegetation, buildings (has been improved indeed) and 3d clouds, things that make the world look more real just to have that bit of extra performance to keep things running as smooth as possible. Though as many of the people that have this comment in regards of the frames per second performance, my programming skills and knowledge of the internal workings of FG, OSG, SimGear are lacking quite a bit, and investigation and testing of this would go dramatically slow and bad if this was up to me. Though i do have a question in relation to this: Is there a benchmarking tool/setup for flightgear? For example a preconfigured/prerecorded flight with fixed variables (weather, time, fov, etc), fixed nr of frames. Basically everything fixed except rendering options and that it measures how long it takes to render/run and calculate the average FPS? People would be able to compare this value, and one would not be comparing apples with pears. Everybody ran the same benchmark/flight. It would be very helpful in determining if some change brought improvement or made performance worse by a proper measuring instead of staring at the FPS counter in the bottom of the screen during gameplay and 'estimating' if things improved or not. And a more simple second question, what do the developers accept as proper performance (value) in regards of frames per second. Perhaps i demand/expect too much, but 20 - 30 fps i find rather disappointing, flight is far from smooth at such numbers, but others might find that (more then) ideal. (rembrandt though not really the focus of my email cuts my performance generally in 2, 8 - 15 fps at EHAM when lucky). This was my penny Kindest Regards and happy flying Rob - EViLSLT - Original Message - From: Erik Hofman e...@ehofman.com To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Wednesday, April 18, 2012 1:12:36 PM Subject: Re: [Flightgear-devel] An empassioned plea On Wed, 2012-04-18 at 10:33 +, Renk Thorsten wrote: What *is* the baseline hardware fg ought to be aiming at? I guess in practice every developer works such that stuff runs well on his own system. What else can we do? I'm not buying a second computer just to test how it would run on a Mac. Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Actually, as Stuart or Mathias have demonstrated here, that's not always true. We seem to be getting more random buildings for less framerate impact for instance. Same was true with the clouds or with the geodinfo() which suddenly was a factor 50 faster. There could sometimes be room for improvement but that is only because of slightly less optimal use of resources in the current implementation. But in general the argument sticks. Don't get me wrong; every improvement is great (and welcome) but it is silly to expect (or almost demand) Rembrandt to run on older hardware. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] Random Buildings
Hi, On Wednesday, April 18, 2012 10:25:55 Stuart Buchanan wrote: For those interested, the technical background is as follows: - a Quadtree is used to ensure very fast culling of the buildings - based on the work that Tim Moore did for the forests. - a single 1024x1024 texture is used for all the buildings, minimizing the number of state changes on the GPU - all the buildings at the leaf of the quadtree are part of the same geometry, so the GPU can churn through it very quickly without having to change state. That sounds like we are heading in the right direction. Thanks! Let me be somehow picky: You are talking about having the houses in the same geometry, that's already fine. The next thing to care for is that they are also in a minimum amount of osg::PrimitiveSet instances. That's about minimizing the amount of draw calls that happen underneath. The best thing would be to have one single *DrawElements instance doing the whole geometry in a single draw call. Greetings Mathias -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
2012/4/18 Mathias Fröhlich wrote: Let me be somehow picky: You are talking about having the houses in the same geometry, that's already fine. The next thing to care for is that they are also in a minimum amount of osg::PrimitiveSet instances. That's about minimizing the amount of draw calls that happen underneath. The best thing would be to have one single *DrawElements instance doing the whole geometry in a single draw call. I think I've already got that covered. I'm using a single osg::PrimitiveSet, and a single list of QUADS/vertices/normals/colors/textureCoords at the leaf of each Quadtree. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Hi, On Wednesday, April 18, 2012 17:21:56 Stuart Buchanan wrote: I think I've already got that covered. I'm using a single osg::PrimitiveSet, and a single list of QUADS/vertices/normals/colors/textureCoords at the leaf of each Quadtree. Great! Thanks! Mathias -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Sun, 15 Apr 2012 18:44:26 +0200 Gijs de Rooy gijsr...@hotmail.com wrote: Pat wrote: Would having a dialog to set options for various PC capabilities help? What's wrong with View Rendering Options? For a novice user, would they know that performance could be affected by view rendering settings? which ones would they set, and at what levels? The idea would be to have sets of option settings pre-configured to fit common hardware limitations at various levels. While doing this I would not want to make it a default, just give the user the option. Then again, maybe I'll just get a better graphics card. I've done that once already, just for flightgear but it didn't increase my framerate much. -Pat Core2 8400 4Gig Nvidia 420 P.S. I've got an old 386 laptop with 80 meg of memory and a 2 gig hard drive somewhere around here. Perfect for running flightgear on the go! -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
