[Flightgear-devel] [PATCH 3/9] remove pointless previousInstruction local in FGGroundNetwork::checkSpeedAdjustment

--- src/Airports/groundnetwork.cxx |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/Airports/groundnetwork.cxx b/src/Airports/groundnetwork.cxx index 34ee61c..787057c 100644 --- a/src/Airports/groundnetwork.cxx +++ b/src/Airports/groundnetwork.cxx @@ -893,7 +893,6 @@

[Flightgear-devel] [PATCH 6/9] remove pointless useInitialWayPoint/useCurrentWayPoint locals from FGAIFlightPlan::ctor

--- src/AIModel/AIFlightPlan.cxx | 13 - 1 files changed, 0 insertions(+), 13 deletions(-) diff --git a/src/AIModel/AIFlightPlan.cxx b/src/AIModel/AIFlightPlan.cxx index 21ad6f9..b94f033 100644 --- a/src/AIModel/AIFlightPlan.cxx +++ b/src/AIModel/AIFlightPlan.cxx @@ -164,25 +164,12

[Flightgear-devel] [PATCH 4/9] remove pointless elevation_feet local from FGGroundNetwork::render

--- src/Airports/groundnetwork.cxx |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/src/Airports/groundnetwork.cxx b/src/Airports/groundnetwork.cxx index 787057c..78e8812 100644 --- a/src/Airports/groundnetwork.cxx +++ b/src/Airports/groundnetwork.cxx @@ -1354,7 +1354,6

[Flightgear-devel] [PATCH 2/9] remove pointless minbearing local in FGGroundNetwork::checkSpeedAdjustment

--- src/Airports/groundnetwork.cxx |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/src/Airports/groundnetwork.cxx b/src/Airports/groundnetwork.cxx index 8e9b16f..34ee61c 100644 --- a/src/Airports/groundnetwork.cxx +++ b/src/Airports/groundnetwork.cxx @@ -915,7 +915,7

[Flightgear-devel] [PATCH 9/9] simplify FGRadioTransmission::getFrequency

--- src/Radio/radio.cxx | 14 +++--- 1 files changed, 3 insertions(+), 11 deletions(-) diff --git a/src/Radio/radio.cxx b/src/Radio/radio.cxx index 169cd32..a22274a 100644 --- a/src/Radio/radio.cxx +++ b/src/Radio/radio.cxx @@ -77,19 +77,11 @@

[Flightgear-devel] [PATCH 8/9] remove unused percent_RPM local from FGPiston::doEnginePower

--- src/FDM/JSBSim/models/propulsion/FGPiston.cpp |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/src/FDM/JSBSim/models/propulsion/FGPiston.cpp b/src/FDM/JSBSim/models/propulsion/FGPiston.cpp index 0f47018..dbd494c 100644 ---

[Flightgear-devel] [PATCH 7/9] remove unused locals from Rotorpart::calculateAlpha

--- src/FDM/YASim/Rotorpart.cpp |9 ++--- 1 files changed, 2 insertions(+), 7 deletions(-) diff --git a/src/FDM/YASim/Rotorpart.cpp b/src/FDM/YASim/Rotorpart.cpp index bd54f41..b88087a 100644 --- a/src/FDM/YASim/Rotorpart.cpp +++ b/src/FDM/YASim/Rotorpart.cpp @@ -377,11 +377,8 @@ float

[Flightgear-devel] [PATCH 1/9] remove pointless remainingTimeEnroute local in FGAISchedule::update()

--- src/Traffic/Schedule.cxx |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/src/Traffic/Schedule.cxx b/src/Traffic/Schedule.cxx index 789631b..05e4eda 100644 --- a/src/Traffic/Schedule.cxx +++ b/src/Traffic/Schedule.cxx @@ -196,7 +196,6 @@ bool

[Flightgear-devel] Cleanup unused locals

These patches clean up some set-but-unused locals which cause warnings on current GCC. There should be no change in semantics. Tested against c5eba72c758b92b9120c38ae101f4a4ab2044ff8 ('next' at time of writing) -- Chris

[Flightgear-devel] [PATCH 5/9] remove pointless elevation_feet local from FGStartupController::render

--- src/ATC/trafficcontrol.cxx |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/src/ATC/trafficcontrol.cxx b/src/ATC/trafficcontrol.cxx index 8e29f04..eb8ca7e 100644 --- a/src/ATC/trafficcontrol.cxx +++ b/src/ATC/trafficcontrol.cxx @@ -1328,8 +1328,6 @@ void

[Flightgear-devel] [PATCH] TrafficMgr: remove ~5M of unnecessary heap churn during startup

--- src/Traffic/TrafficMgr.cxx |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/src/Traffic/TrafficMgr.cxx b/src/Traffic/TrafficMgr.cxx index 44e8567..d4f20b3 100644 --- a/src/Traffic/TrafficMgr.cxx +++ b/src/Traffic/TrafficMgr.cxx @@ -674,9 +674,7 @@ void

[Flightgear-devel] [PATCH] SchedFlight: make comparison inlinable

Reduces the perf impact of FGAISchedule::findAvailableFlight() --- src/Traffic/SchedFlight.cxx |5 - src/Traffic/SchedFlight.hxx |5 - 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/src/Traffic/SchedFlight.cxx b/src/Traffic/SchedFlight.cxx index 5339a29..1b8586f

Re: [Flightgear-devel] [PATCH] TrafficMgr: remove ~5M of unnecessary

Martin, Is it acceptable to send merge requests with a git URL for a server elsewhere, or must it be on gitorious? -- Chris On Fri, Feb 17, 2012 at 11:23 PM, Martin Spott martin.sp...@mgras.net wrote: Hi Chris, Chris Forbes wrote: --- src/Traffic/TrafficMgr.cxx |    4 +--- 1 files changed

Re: [Flightgear-devel] Project Rembrandt - next steps

I doubt you're going to have an acceptable experience using a deferred renderer on a go7400, regardless of driver bugs. There's not a lot of fillrate there. On 7/03/2012 4:42 AM, Arnt Karlsen a...@c2i.net wrote: On Sat, 03 Mar 2012 21:17:30 +0100, Torsten wrote in message

Re: [Flightgear-devel] More Rembrandt Feedback

It's possible to have two layers of shadow map to separate static and dynamic things, but at a significant cost (you need the extra buffer, and the memory bandwidth to sample it, ...). Probably not a win on the kind of hardware that needs a speedup here. On Wed, Apr 4, 2012 at 7:45 AM, Vivian

Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000

Presumably you could just ask osg or the gl to discard the top mip level(s) rather than altering the source art to work around apple's driver bugs? -- For Developers, A Lot Can Happen In A Second. Boundary is the first to

Re: [Flightgear-devel] [Rembrandt] the plan

Ignoring the horrible artifacts for a moment, I think we need at least one more mip level on the instrument faces for the 172. Even at that low resolution they are very blurry. On Mon, Apr 16, 2012 at 9:24 PM, Martin Spott martin.sp...@mgras.net wrote: Frederic Bouvier wrote: This shader error

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.

Re: [Flightgear-devel] An empassioned plea

What do people think about dynamically scaling the eye candy to meet a target framerate? -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in

Re: [Flightgear-devel] An empassioned plea

Assuming shaders ON, you can scale the fragment workload continuously by using dynamic resolution rendering. Pick your resolution per-frame, pay a constantish cost to copy it to the display buffer (which you're paying anyway if you need to tonemap down from an hdr buffer)

Re: [Flightgear-devel] Terrain Haze v1.3

Presumably all these effects could actually be done as one screenspace pass? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT

Re: [Flightgear-devel] Terrain Haze v1.3

It would be interesting to use skeletal animation to get rid of some of the batch spam with complex multipart models. It wouldn't even necessarily require reworking the model data -- we could initially do the merge and bone attachment when a model is loaded. What are the animation cases? So far I

Re: [Flightgear-devel] Terrain Haze v1.3

You'll have to elaborate on how 'spin' is special. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond.

Re: [Flightgear-devel] Terrain Haze v1.3

Only a win if 1) your draw order wrt depth is chaotic and unfixable, and 2) you are fillrate bound ... -- Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and

Re: [Flightgear-devel] Random buildings improvements - phase 2

I would be happy to set up an automated are we fast yet-style system for FG. It would be nice to have perhaps 10 minutes worth of (representative) test that the machine can just run against every commit. What hardware do people think is actually a sensible baseline? The guy with the

[Flightgear-devel] [PATCH] simgear: update .gitignore to include all current build results

simgear build off /next was leaving a bunch of untracked and unignored files lying around. most of these are new binaries, but some are intermediate files generated during the build. updates .gitignore to ignore all of them. --- .gitignore | 16 1 file changed, 16

[Flightgear-devel] [PATCH] fg: update gitignore

Update .gitignore to ignore another build result --- .gitignore |1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 8a18462..d8d0fd4 100644 --- a/.gitignore +++ b/.gitignore @@ -15,3 +15,4 @@ CTestTestfile.cmake .kdev4 *.kdev4 *.pyc

[Flightgear-devel] [PATCH V2] fg: update gitignore

Update .gitignore to ignore another build result V2: Ignore the install_manifest too. --- .gitignore |2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitignore b/.gitignore index 8a18462..1524d4c 100644 --- a/.gitignore +++ b/.gitignore @@ -15,3 +15,5 @@ CTestTestfile.cmake .kdev4

[Flightgear-devel] [PATCH] nasal: parse: fix typo in comment

--- simgear/nasal/parse.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/simgear/nasal/parse.c b/simgear/nasal/parse.c index 2e66d8f..10339c8 100644 --- a/simgear/nasal/parse.c +++ b/simgear/nasal/parse.c @@ -311,7 +311,7 @@ static struct Token* parsePrecedence(struct

Re: [Flightgear-devel] Nasal CG: (Was: Sea color)

I have been working on a 4-color incremental mark/sweep collector with the intention of merging it into the Nasal interpreter. The work so far can be found at http://github.com/chrisforbes/incgc; There's still quite a lot to do, but the path is clear. -- Chris On Sat, May 19, 2012 at 9:51 PM,

Re: [Flightgear-devel] A plan for a 3.0 release?

Fragment discard isn't anywhere near as free or beneficial as you think it is. It's pretty crippling on a lot of older hardware. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's

Re: [Flightgear-devel] DDS usage in effects files

If DDS is not politically acceptable, there should be an alternative way of providing premipped textures. Mipmap generation is a *significant* portion of the load time, particularly on the nicer aircraft with large textures. Even something as simple as a bunch of PNGs concatenated from small to

Re: [Flightgear-devel] Functions to textures?

Somewhat inversely, I'm also wondering if a simple texture1D() lookup might not be faster than evaluating the light function e / pow((1.0 + a * exp(-b * (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet. That depends a lot on the GPU, and how coherent the texture coordinates are across a

Re: [Flightgear-devel] Patch for metar.exe for windows

Geoff, your patch is asking for the quirky old win95-era winsock1.1. Is this intentional? WSACancelBlockingCall and friends don't exist in modern winsock. -- Chris On Sat, Jul 28, 2012 at 5:03 AM, Geoff McLane ubu...@geoffair.info wrote: On Fri, 2012-07-27 at 17:39 +0100, James Turner wrote:

Re: [Flightgear-devel] license

I still think we need another license for sceneries etc. ... not allowing any commmercial use. Why? Freedom Zero matters just as much for things other than code. -- Chris -- Live Security Virtual Conference Exclusive

Re: [Flightgear-devel] Compiling 2.8.0

Looks like its not bothering to link against libm (the system math library) On 5/09/2012 7:53 PM, zezinho lists.jjo...@free.fr wrote: hi, I am trying to package 2.8.0 in my Linux Mageia system, which already brings 2.6.0 in rpms. The 2.8 compilation fails with below error, any hints please?

Re: [Flightgear-devel] Removing landclass seams

Thorsten, A palette of 16 standard terrain textures can be stored in a single 2048x2048 texture sheet and referenced with a multi-texture coordinate, so we don't necessarily run out of texture units. A similar palette of overlay textures for all landclasses can be stored. You probably want to