Hi All
I rebuilt from GIT this morning. I am sitting on the runway at a quiet
airport, doing absolutely nothing. No AI traffic, no other multiplayers
around. Global weather. I have no other applications running, except
fgrun. And I am waiting until terrasync has updated all it wants to
update
Lots of variables. It sounds like you're using up-to-date scenery, so there
could have been a change there. New code has also been checked in that deals
with paging in the scenery, though I doubt that's causing the problems you
are seeing.
Can you check out of git the source code from a week ago,
Moving us along the road to supporting better thread- and process- separation
of the simulator elements, I've added a first attempt at at 'propertyObject'.
This is a template wrapper for SGPropertyNode*, with conversion operators
to/from the related primitive type.
I.e:
From: fiers...@zo... - 2010-11-20 10:33
I have done two tests, directly after eachother. Same conditions, same METAR.
One thing to note here is that, prior to yesterday's update, the size
of the scenery area loaded/rendered at start-up did _not_ depend on
the visibility (weather/METAR), neither
It has another interesting feature, suggested by ThorstenB - if you try
to read an invalid path, it doesn't silently succeed - it throws an
exception! This is to avoid lurking typos in property paths, which has
been an issue. (I will be adding a 'weak' variant, that takes a default
value, for
On 20 Nov 2010, at 14:53, Jon S. Berndt wrote:
I'm wondering if the property code should just be left well enough alone...
There's two answers to this:
1) it's not really tenable to have pieces of the API frozen in perpetuity -
whether next year or in ten years, things evolve. [1] Either
On 20 Nov 2010, at 18:00, James Turner wrote:
2) I'm only proposing one non-backwards compatible change - the removal of
tie/untie, and probably not in the next twelve months - certainly not the
next six. I just checked and the JSBSim code makes extremely limited use of
tie(), in a couple
Hi,
Getting the splash screen down faster on startup and
re-position is a huge win here - excellent.
James
But needs more time to get a stable and usuable fps...about 30seconds here with
latest GIT from today.
If I may, I'd like to temporarily put a product managers hat on.
Two useful, but rather significant changes have occurred recently in
the code-base and we are nearing the end of November, a traditional time
for a product release.
These two code changes seem like they are forward
On Sat, Nov 20, 2010 at 10:41 PM, Heiko Schulz aeitsch...@yahoo.de wrote:
But needs more time to get a stable and usuable fps...about 30seconds here
with latest GIT from today.
Right, the splash screen is down early now, while FG is still busy
loading more distant scenery areas. Loading in the
Hi,
Right, the splash screen is down early now, while FG is
still busy
loading more distant scenery areas. Loading in the
background may
affect fps - however this is the same effect as experienced
during a
flight whenever a scenery area is crossed - since this
triggers the
same loading
On Sat, Nov 20, 2010 at 11:48 PM, Heiko Schulz wrote:
Not yet completly tested, but I notice the first 30 seconds of startup fps of
1-2.
Imagine the same fps when loading new tiles would make FGFS pretty unusuable
for me
If you refer to the fps _before_ the splash screen is dropped,
Hi,
If you refer to the fps _before_ the splash screen is
dropped, then
this is normal.
I refer on the first 30 sec after the splash_screen is dropped, and aircraft
and scenery etc. appears
HHS
--
Beautiful is
Hi,
These two code changes seem like they are
forward thinking, intended
for increasing performance in the future, so since we
haven't had a
product release for almost twelve months, should there be
some thought
about a branch for a code freeze to make a stable code
release as 2.1?
Hi,
with the 737-300 and the latest GIT I get an error-message and FGFS aborts:
The property /engines/emgine/reverser-pos-norm is initially undefined
How to solve this?
Kind regards
HHS
still in work: http://www.hoerbird.net/galerie.html
But already done: http://www.hoerbird.net/reisen.html
On Sun, Nov 21, 2010 at 1:05 AM, Heiko Schulz aeitsch...@yahoo.de wrote:
I would say we are far away from a stable release. Because it isn't stable
yet.
The Route-manager crashes FGFS again, there are issues with the water-shader
and the sun, the landcover-shaders looks milky, the landmass
Well...
* Route manager works here with current GIT, certainly
doesn't crash.
-Inserting an airport crashes FGFS
-choosing a rwy crashes FGFS
I have flown many TGA events with route manager, seems to
be quite
stable.
Let me correct: was stable a month ago.
* not sure what issues the
On Sun, Nov 21, 2010 at 2:09 AM, Heiko Schulz aeitsch...@yahoo.de wrote:
Well...
* Route manager works here with current GIT, certainly
doesn't crash.
-Inserting an airport crashes FGFS
-choosing a rwy crashes FGFS
Not here, it doesn't.
* not sure what issues the water shader has with
Not here, it doesn't.
Is your system the leadership?
It does here crashing, win 32 GIT from today (Hudson-builder), datas from today.
Noticeable, but the previous release didn't even have such
an effect
did it? And it is simply too awesome to not release just
because it is
slightly,
Hi,
But I must admit- when the fps are stable, and tiles are loaded- perfomance is
so much better! Wow!
With all shaders enabled!
www.hoerbird.net/fgfs-screen-069.png
www.hoerbird.net/fgfs-screen-070.png
www.hoerbird.net/fgfs-screen-071.png
Thanks for this improvement!
Cheers
HHS
On Sun, Nov 21, 2010 at 2:58 AM, Scott Hamilton
scott.hamil...@popplanet.biz wrote:
The important point here is that it has been nearly twelve months
since the last major release, the codebase appears to be looking
forward, and in the past it has required quite a bit of planning and
work
21 matches
Mail list logo
