I'm not sure if increasing the tree count could trigger the same
problem.
I've been flying with 8 times the default tree density for the last half
year (I edited materials.xml) - apart from the (expected) general overall
impact on framerate, I haven't seen any issues like second-long lags when
On 28.07.2011 00:30, Stuart Buchanan wrote:
The patch does the following:
1) Fixes the longstanding bug where the first set of tree definitions
in a tile were used for all forests within that tile.
2) Re-introduce a feature to fade in trees by distance
And, after doing a few circles at LOWI,
On 28.07.2011 00:30, Stuart Buchanan wrote:
On my machine I don't see any performance impact, despite the fact
that more trees are displayed. I'd appreciate it if those with more
graphics-constrained systems than my own would test this and let me
know if they think the frame-rate hit is
On Fri, Jul 29, 2011 at 6:21 PM, ThorstenB wrote:
On 28.07.2011 00:30, Stuart Buchanan wrote:
On my machine I don't see any performance impact, despite the fact
that more trees are displayed. I'd appreciate it if those with more
graphics-constrained systems than my own would test this and let
However, I don't think my change will have affected this.
While the number of trees displayed is increased, the total number
of trees in the scenery is unaffected, it's just that more of those
trees are visible at any given time.
I'm also not sure if the tree model is shared in this way.
On 27 Jul 2011, at 23:30, Stuart Buchanan wrote:
Within the patch is the code below. The (*j)- just looks ugly. Surely
there's a better way?
I'm sure those of you who write C++ more regularly than me will
immediately be able to tell me where I'm going wrong!
As noted elsewhere, you can't
TreeBin* treebin;
SGTreeBinList::iterator j;
bool found = false;
for (j = randomForest.begin(); (j != randomForest.end()) (!found);
j++) {
if (((*j)-texture == mat-get_tree_texture() )
((*j)-texture_varieties == mat-get_tree_varieties())
((*j)-range ==
On Thu, 28 Jul 2011, Stefan Seifert wrote:
On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote:
But there is one minor and very common issue with the code that should be
fixed. In the for loop
for (..; ..; j++)
should be
for (..; ..; ++j)
if you use j++ the compiler has to make a
On 2011-07-28 14.33, Gene Buckle wrote:
On Thu, 28 Jul 2011, Stefan Seifert wrote:
On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote:
But there is one minor and very common issue with the code that should be
fixed. In the for loop
for (..; ..; j++)
should be
for (..; ..; ++j)
if
On Thu, 28 Jul 2011, Jari Häkkinen wrote:
Are you sure about that? I just tried it with a little example and at least
gcc compiles both variants to the exact same assembly code. Tried it with and
without -O2.
That would freak me out. Doesn't ++j mean increment j, then test
whereas j++ means
On 2011-07-28 15.22, Gene Buckle wrote:
On Thu, 28 Jul 2011, Jari Häkkinen wrote:
Are you sure about that? I just tried it with a little example and
at least
gcc compiles both variants to the exact same assembly code. Tried it
with and
without -O2.
That would freak me out. Doesn't ++j
On Thursday 28 July 2011 06:22:10 Gene Buckle wrote:
On Thu, 28 Jul 2011, Jari Häkkinen wrote:
Are you sure about that? I just tried it with a little example and
at least gcc compiles both variants to the exact same assembly
code. Tried it with and without -O2.
That would freak me out.
On 2011-07-28 14.52, Jari Häkkinen wrote:
That would freak me out. Doesn't ++j mean increment j, then test
whereas j++ means test j, then increment?
No, for a for loop
for ( [1]; [2]; [3] )
where [3] is ++j will increment j before use. However, in an
if-statement the complete statement
On Thu, Jul 28, 2011 at 8:33 AM, Gene Buckle ge...@deltasoft.com wrote:
On Thu, 28 Jul 2011, Stefan Seifert wrote:
On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote:
But there is one minor and very common issue with the code that should be
fixed. In the for loop
for (..; ..; j++)
Hi All,
I've got a small patch to improve the FG forests, along with some
particularly bad C++ I need advice on.
The patch does the following:
1) Fixes the longstanding bug where the first set of tree definitions
in a tile were used for all forests within that tile. This meant that
if you have
On Wednesday, July 27, 2011 03:30:06 PM Stuart Buchanan wrote:
Hi All,
I've got a small patch to improve the FG forests, along with some
particularly bad C++ I need advice on.
The patch does the following:
1) Fixes the longstanding bug where the first set of tree definitions
in a tile
16 matches
Mail list logo
