[Flightgear-devel] Multithreading pattern and frame rate
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 and the log window is showing no more activity. I have done two tests, directly after eachother. Same conditions, same METAR. Compared to a version of one week ago, there seems to be a different pattern in CPU usage. The older GIT version had one thread 75% busy and two more threads of about 30% busy and a frame rate of a little over 40 FPS. In the version of today, I have one thread 85% busy and one other thread about 20% busy and the frame rate is about 20 FPS. When I take off and during flight, I have one thread 100% busy all the time, where in the previous versions there were only brief moments that one of the threads was running at 100%. I know there has been done some work on caching and loading of 3D elements... perhaps it is related... Has anyone else noticed a difference? m -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multithreading pattern and frame rate
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, compile it, run it, and see if you still see the same performance difference? FPS is not a good performance metric. If you have vsync turned on in your driver, a very tiny change in the time of an operation can make a big fps difference. Also, everyone has different hardware... It's more useful to look at the OSG statistics (choose Cycle On-Screen Statistics twice) and report the times reported for each traversal. Or include a screenshot of them. Did you update anything else, like OSG? Tim On Sat, Nov 20, 2010 at 11:33 AM, fiers...@zonnet.nl wrote: 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 and the log window is showing no more activity. I have done two tests, directly after eachother. Same conditions, same METAR. Compared to a version of one week ago, there seems to be a different pattern in CPU usage. The older GIT version had one thread 75% busy and two more threads of about 30% busy and a frame rate of a little over 40 FPS. In the version of today, I have one thread 85% busy and one other thread about 20% busy and the frame rate is about 20 FPS. When I take off and during flight, I have one thread 100% busy all the time, where in the previous versions there were only brief moments that one of the threads was running at 100%. I know there has been done some work on caching and loading of 3D elements... perhaps it is related... Has anyone else noticed a difference? m -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Further properties heads-up - property objects.
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:
simgear::PropertyObjectint frameRate(/sim/rendering/fps);
int theFrameRate = frameRate; // maps to getIntValue
frameRate = 1234; // maps to setIntValue
if (frameRate == 789) {
...
}
and so on. (The std::string variant tries to convert nicely to char*
too, where possible)
To the extent possible by C++, once you've declared a property object, you
should be able to treat it exactly like a plain int/double/bool/string, but of
course the actual storage is the property. (if you find areas where this falls
down, of course let me know, or fix them)
The goal of the PropertyObject is that it's hard to use inefficiently - it
lazily does the the property lookup, but caches the result.
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 the cases where people
want to read a property that might not exist)
Suggestions are most welcome - for example there's no read-only version at the
moment, but there could be.
Apart from being a nicely short syntax, there is another goal - tied properties
are a menace, for thread-safety, for un-tie-ing cleanly on subsystem shutdown,
and for not firing change listeners. My hope here is to create something that
has semantics that work in a multi-threaed or multi-process world - but which
is as painless to use in code as a tied value. I think I've succeeded, but time
will tell.
(One other thing I will be adding, probably to SGPropertyNode itself, is a
nicer listener syntax, since I'm aware of various pieces of code that use tied
setters as a value-changed notification - SGPropertyChangeListener is a rather
cumbersome solution for this)
I'm not going to start converting tied properties to use propertyObjects next
week, or next month, but certainly next year. The hope is that by that time,
this code is mature, efficient and so on - so please try it, use it and fix it!
Regards,
James
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multithreading pattern and frame rate
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 on any visibility configured manually (command-line etc). FG would always load the same number of tiles at start-up - no matter what the weather/configuration was. This was a bug, since the tile manager didn't bother about visibility changes - and METAR/manually configured visibility was only set _after_ the initial scenery was already scheduled. This has changed yesterday: now, once visibility increases considerably (METAR is received, weather configured) this, as expected, causes an immediate update and loading of all required scenery. So, even if you have configured the same conditions/METAR, this may not be a fair comparison. It's possible that METAR specifies 10nm visibility, but an older FG build would still render only 5nm at start-up (meaning only a quarter of the actually required scenery tiles). With older FG builds, you should wait for METAR to be received, then fly (or reposition) your plane several miles away from the initial location. This location change triggers the scenery scheduler which only then takes the correct visibility into account. I doubt though that this could cause such a severe drop of framerate. And which plane are you using for this comparison? cheers, Thorsten -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further properties heads-up - property objects.
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 the cases where people want to read a property that might not exist) ... I'm not going to start converting tied properties to use propertyObjects next week, or next month, but certainly next year. The hope is that by that time, this code is mature, efficient and so on - so please try it, use it and fix it! Regards, James This concerns me a bit. JSBSim grabs a copy of the relevant simgear code to support properties once every couple of years. When JSBSim is built within FlightGear, we of course just use what's there in the FlightGear tree. But, when JSBSim is incorporated into other products, they use what we have in our codebase. I'm concerned that at some point the property system will evolve to the point where serious conflicts arise, and backwards compatibility is broken. We (JSBSim) depend on the property system. I'm wondering if the property code should just be left well enough alone... Jon -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further properties heads-up - property objects.
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 JSBSim needs to be prepared to stay in sync (eg, update from the Simgear code monthly or quarterly), or you need to decide that you want your own code, and fork it 'properly' - at which point we'd make a bridge in the FG side between JSBSim properties and SimGear ones - which is fine. My guess is the latter is going to work better for you, though it's more effort upfront. However, all that being said: 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 of source tiles total. If you'd rather not use the new property features, that's fine - it'll just mean more boilerplate code to use the existing APIs when tie() does finally cease to exist. (And you can carry on shipping a version of props.hxx/.cxx with JSBSim-standalone, that *does* include tie(), to avoid breaking existing users who might have tie in their code) As far as I'm concerned, all of 2) is my problem - if I remove tie(), then I have to fix all the previous users, including JSBSim. You don't need to do anything, and I don't expect any JSBSim breakage. I think you *ought* to do something about 1), since you're following a pattern that is going to cause pain for someone, sooner or later, but that's just my opinion - it's your code! Regards, James [1] - especially, since the property code was designed, multi-core machines have become rather common! -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further properties heads-up - property objects.
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 of source tiles total. If you'd rather not use the new property features, that's fine - it'll just mean more boilerplate code to use the existing APIs when tie() does finally cease to exist. (And you can carry on shipping a version of props.hxx/.cxx with JSBSim-standalone, that *does* include tie(), to avoid breaking existing users who might have tie in their code) Anders point out my checking was flawed - since tie() gets renamed to Tie() - doh. Since I assume changing every JSBSIm use of Tie() is a non-starter, we'll have to devise something special on the FG side, to keep tie() 'apparently' working for JSBSim - not ideal, but probably doable. Anyway, something for the future! Regards, James -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery tile management heads up...
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. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery tile management and further property heads up...
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 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? From memory it was a few months ago that there was some talk of a release before 25th December, but that talk has died down, and that date is not very far away now, is there any planning underway to make a stable 2.1 release? cheers S. On Sat, 2010-11-20 at 21:41 +, Heiko Schulz wrote: 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. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery tile management heads up...
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 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 process in the background. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery tile management heads up...
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 process in the background. 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 -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery tile management heads up...
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, then this is normal. So far, we were burning CPU time at 100fps while the splash screen was active. This is now explicitly limited to 2 fps to give more CPU time to the loader threads. This results in a considerable loading speed-up for single core CPUs. And rendering a splash screen at 100fps didn't really help too much anyway - except for the dramatic fps rate display. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery tile management heads up...
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 writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS-Release was Scenery tile management and further property heads up...
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? From memory it was a few months ago that there was some talk of a release before 25th December, but that talk has died down, and that date is not very far away now, is there any planning underway to make a stable 2.1 release? 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 shader is broken... (GIT from today) I propose, that we list up some targets like -stable Route-Manager -fixed shaders etc before we really decide to release a candiate. With the Hudson-Builder we have now the wounderful opportunity to have releases now nightly! Cheers HHS -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Error-message: The property xyz is initially undefined...
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 -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS-Release was Scenery tile management and further property heads up...
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 shader is broken... (GIT from today) * Route manager works here with current GIT, certainly doesn't crash. I have flown many TGA events with route manager, seems to be quite stable. * not sure what issues the water shader has with the sun, except for a slight misalignment: http://imagebin.ca/view/SeUwOd.html * don't know which is the landcover shader and which is the landmass shader, but both seem to work fine here: http://imagebin.ca/view/aCUqSb-i.html For me, FGFS is in no worse shape than some previous releases ;) By the way, I have just noticed that somebody has put some work into Budapest (LHBP) scenery. Big thanks! -- Cheers, Csaba/Jester -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS-Release was Scenery tile management and further property heads up...
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 water shader has with the sun, except for a slight misalignment: http://imagebin.ca/view/SeUwOd.html slight? Very noticeable! * don't know which is the landcover shader and which is the landmass shader, but both seem to work fine here: http://imagebin.ca/view/aCUqSb-i.html Some shadertypes seems to be immun against fog, which make the whole scenery looks a bit akward: www.hoerbird.net/fgfs-screen-064.png Even more on detailed sceneries like LOWI... Noticed by several people now already... For me, FGFS is in no worse shape than some previous releases ;) Let's decide the users... HHS -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS-Release was Scenery tile management and further property heads up...
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 the sun, except for a slight misalignment: http://imagebin.ca/view/SeUwOd.html slight? Very noticeable! 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, but noticeably, misaligned :) Some shadertypes seems to be immun against fog, which make the whole scenery looks a bit akward: www.hoerbird.net/fgfs-screen-064.png Even more on detailed sceneries like LOWI... Noticed by several people now already... Ahha, I see. That is quite ugly indeed. For me, FGFS is in no worse shape than some previous releases ;) Let's decide the users... For these features, I count myself as an user. Even if some new features don't work perfectly, as long as they are not regressions, I would like to have them. -- Csaba/Jester -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS-Release was Scenery tile management and further property heads up...
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, but noticeably, misaligned :) I prefer fixing instead of releasing. And I'm not yet convinced that it really depends on the shaders. Maybe the new shader makes it really visible. Ahha, I see. That is quite ugly indeed. Let's decide the users... For these features, I count myself as an user. Even if some new features don't work perfectly, as long as they are not regressions, I would like to have them. Myself as well, but I try to follow our philosophy: make things right! HHS -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery tile management heads up...
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 -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS-Release was Scenery tile management and further property heads up...
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 to ensure we have a consistent and stable product to release. I'm not sure which changes provoked your initial email. The tile manager change is big, but it addresses longstanding, severe bugs. My property tree hash work was also in response to bugs, and I think we've established that it is not in fact a major change. James' work isn't changing anything yet, as far as I know. Part of that work is first finding a suitable point in time and code to take a snapshot of the code, that includes simgear, flightgear and fgdata. Then I think it would be wise to test that snapshot and fix any of the problems that may be uncovered. But before we can start any of that, we have to make a decision to make a release and set a tentative release date. We are going to make a release branch soon. Tim S. On Sun, 2010-11-21 at 02:25 +0100, Csaba Halász wrote: 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 the sun, except for a slight misalignment: http://imagebin.ca/view/SeUwOd.html slight? Very noticeable! 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, but noticeably, misaligned :) Some shadertypes seems to be immun against fog, which make the whole scenery looks a bit akward: www.hoerbird.net/fgfs-screen-064.png Even more on detailed sceneries like LOWI... Noticed by several people now already... Ahha, I see. That is quite ugly indeed. For me, FGFS is in no worse shape than some previous releases ;) Let's decide the users... For these features, I count myself as an user. Even if some new features don't work perfectly, as long as they are not regressions, I would like to have them. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
