On Wed, 2012-06-27 at 14:13 +0100, Alasdair wrote:
>
> OK, sorry for the noise. I was all those random buildings. With the
> maximum setting of 5.0, FG uses a massive 6.3 GB of memory on another
> machine. Setting it to 0, the memory usage drops to a more reasonable
> 1.6GB. I wonder if there co
On Wed, 2012-06-27 at 10:45 +0100, Alasdair wrote:
> After yesterday's git pulls, Flightgear will no longer run at KSFO,
> having
> exhausted my 4G of memory and a good load of swap space as well.
> Indeed, until I increased the amount of swap, it just died with an
> unceremonious
> "Killed" messa
On Fri, 2012-05-04 at 20:40 +0200, flightg...@sablonier.ch wrote:
> >
> > Selectively disabling features is probably not going to work reasonable
> > as long as the features in question are required to play nice in order
> > to get disabled, there's no such infrastructure as a "kill-switch" to
> >
>
> Selectively disabling features is probably not going to work reasonable
> as long as the features in question are required to play nice in order
> to get disabled, there's no such infrastructure as a "kill-switch" to
> prevent the use/loading of *any* shaders (or whichever additional
> feature
Alex Perry wrote:
> It would probably make things a lot simpler for the average user if
> FGFS included a wizard that automatically identified which
> combinations of features would be usable on a specific installation.
> Using that result as constraining logic in the menus would allow
> unusable
Vic:
I was kidding.
B.
--
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. Discussions
will include endp
>>> Bj?rn Kesten said,
I don't want no friggin' wizard to tell me what I can or can't do... ;) <<<
Is this a wind-up, or what.
How can a simple request for developers to optimise their coding on new
improvements end up with statements like this?
I was hoping this thread had served it's purpose
> It would probably make things a lot simpler for the average user if
> FGFS included a wizard that automatically identified which
> combinations of features would be usable on a specific installation.
> Using that result as constraining logic in the menus would allow
> unusable features to be kept
As an aside: When working on the codebase, I maintain a local script
that launches FGFS by disabling whatever features prevent the
simulation from being flyable on my development machine. When I am
unable to turn off features that prevent the simulator from running,
and disabling them in source i
>>> Bj?rn Kesten said,
"Can we just settle for a general "do as much performance optimization as
feasible" approach?" <<<
This is pretty much what I was asking for in the first place. It still applies.
I didn't intend to start a war about who could afford what computer etc, I just
wanted devs t
Can we just settle for a general "do as much performance optimization
as feasible" approach?
Btw:
Is the multithreading feature being actively worked on?
It would at least help to bring modern multi-core CPUs to bear.
-
On Mon, Apr 23, 2012 at 3:16 AM, Vic Marriott wrote:
> Things like food and shelter are higher up the finances queue than another
> computer set-up.
>
When I take a look at my family (of 4) finances, I see that for what we
spend on food each month (not including going out to eat which doesn't
ha
On Mon, 23 Apr 2012, Vic Marriott wrote:
Personally, I'd build the best white-box machine I could afford and
throw Linux on it. <<<
>
> Hi Gene,
>
> Once again the point is being missed.
>
> Things like food and shelter are higher up the finances queue than
> another computer set-up. T
On 22 Apr 2012, at 15:06, Vic Marriott wrote:
> James, I think you have an advantage in that you run Linux on your Mac, so
> you can utilise the best of both worlds.
Actually I don't - it's OS-X all the way for me, in terms of running FG. I have
Linux VMs to check builds, but there's no OpenGL
>>> Personally, I'd build the best white-box machine I could afford and throw
>>> Linux on it. <<<
Hi Gene,
Once again the point is being missed.
Things like food and shelter are higher up the finances queue than another
computer set-up. Those of you who can afford such luxuries might like to
On Sun, 22 Apr 2012, Vic Marriott wrote:
a Mac Pro can get periodic upgrades just like any other PC or Linux box.
<<<
>
> As I hinted before Gene, those of us on limited budgets can't really
> justify the spend for a Mac Pro.
>
Maybe not, but you could buy a used one and tweak it if yo
>>> a Mac Pro can get periodic upgrades just like any other PC or Linux box. <<<
As I hinted before Gene, those of us on limited budgets can't really justify
the spend for a Mac Pro.
Erik, You are forgiven :0)
James, I think you have an advantage in that you run Linux on your Mac, so you
can u
On Fri, 20 Apr 2012, James Turner wrote:
>
> Speaking as a fellow Mac user, you are unfortunately in the worst
> possible place in terms of bang-for-buck to use FlightGear - while your
> Mac has plenty of horse-power in the general case, it wasn't that fast
> at 3D when new, and you've no way t
On 19 Apr 2012, at 09:50, Vic Marriott wrote:
> I have discussed this with Tat, and he has managed somehow (I don't even
> understand what most developers are talking about) to make each new release
> work on my machine.
>
> I have a 3 year old iMac running OS X 10.6. I don't consider this to
On Thu, 2012-04-19 at 09:50 +0100, Vic Marriott wrote:
>
> Sorry for causing such a volatile reaction. I was only asking for
> those who know how to to optimise as much as possible.
I probably overreacted a bit, I'm sorry for that.
Erik
>>> Erik said,
"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." <<<
I don't want to appear unappreciative, but for the last 3 releases I have been
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)
--
> What do people think about dynamically scaling the eye candy to meet a
> target framerate?
Define 'the eye candy' and you'll spot the problem.
In general, the performance-driving factors are (not an exhaustive list)
1) visibility range, i.e. number of terrain vertices in the scene
2) cloud vis
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 Ultra-Fine
On Wed, 2012-04-18 at 15:33 +0200, EViLSLT - Rob wrote:
> 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)
>
> H
> 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
> (mor
On Sun, 15 Apr 2012 18:44:26 +0200
Gijs de Rooy 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 se
ance
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"
To: "FlightGear developers discussions"
Sent: Wednesday, April 18, 2012 1:12:36 PM
Subject: Re: [Flightge
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
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 advanc
> 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.
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 m
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.
htt
> >>> 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
> Pat wrote:
>
> Would having a dialog to set options for various PC capabilities help?
What's wrong with View > Rendering Options?
--
For Developers, A Lot Can Happen In A Secon
On Fri, 13 Apr 2012 10:56:41 +0200
Erik Hofman 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.
>
> Erik
>
Would having a dialog to set options for various PC capabilities help?
-Pat
---
On Fri, 2012-04-13 at 09:25 +0100, Vic Marriott wrote:
> Hi,
>
> More and more, the FG forums are showing that the most recent improvements,
> added to the existing code, are too memory consuming for operation on
> anything less than a high powered, up-to-date, well equipped computer.
>
> Thoug
Hi,
More and more, the FG forums are showing that the most recent improvements,
added to the existing code, are too memory consuming for operation on anything
less than a high powered, up-to-date, well equipped computer.
Though I, and probably most other FG users, am delighted that improvements
38 matches
Mail list logo
