Re: [Flightgear-devel] Release candidates
Stuart Sent: 30 August 2013 23:30 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Release candidates On Fri, Aug 30, 2013 at 11:41 AM, Stuart Buchanan wrote: Great work James. I should have some time to test over the weekend. Did a quick test on a Windows 7 laptop, and generally looked good. In fact better than good, as under Windows I get x2 the framerate due to a bug in the NVidea Linux driver which meant I could run Rembrandt at a decent frame-rate (until I switched on random buildings whereupon the frame-rate nose-dived)! A couple of things I noticed from a quick flight with the Zero: 1) Windows launcher appears to have Rembrandt enabled by default, but set via the Advanced properties, rather than having a checkbox on the launcher. Makes it quite difficult for a new user to disable it. I would have expected Rembrandt to be switched off by default and with a checkbox on the Rendering Options section of the launcher to enable it. Caveat: It's possible that I've lost a config file somewhere on my Windows system, so if someone else could verify this is the case, that would be great. 2) There appears to be some invalid scenery around lat:37.228, lon:-121.9703. Scenery triangles are white and the UFO can't determine the material type. I'll investigate this further - might be an error in the landclass or something we've got wrong in materials.xml. I've checked RC1 - FGRun here - AFAIKS it just picks up whatever you had last set in Advanced/Properties - I had Rembrandt disabled and that's what I got. Vivian -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scripted Installation - An update and a summary of where things stand.
Lets review where things stand with the script: Current commit on team clone: download_and_compile.shAug 31 2013 #58ae270 Version 1.9.12 (Pat) http://www.gitorious.org/fg/fg-download-and-compile-fgmeta/raw/58ae27079531e69ec48c6df06538559680bd9433:download_and_compile.sh Contains a fix to a bug found and reported by Arnt. Additional testing is needed before this can be merged to the main fgmeta. A detailed list of the changes in the script version 1.9.12 can be found here: http://www.gitorious.org/fg/fg-download-and-compile-fgmeta/commit/58ae27079531e69ec48c6df06538559680bd9433 Francesco approved an early version of 1.9.12. There have been additional small changes made. -Pat For Arnt and others interested in where things are going, the following summarizes a lot of stuff that's already been said here and elsewhere. The current official script in fgmeta is 1.9.11 It builds 2.8.0 as stable and will build next. It would need small modifications to build 1.9.10 or 1.9.12 Arnt has requested details on any new design for the directory structure. I've given one below, but I'm open to suggestions if you'd prefer something different. Here are the design goals: 1. download_and_compile.sh continues to work exactly as it has in the past. It will continue to use the same directory structure unless the user decides to take an action that causes a new directory structure to be adopted for subsequent builds. 2. Minimize the impact on git and svn servers by removing the need to download multiple copies of sources and data. 3. Facilitate testing the script with different versions and options. To meet these goals there are several features being added to the script. Some of these are partially in place, some will require additional changes. Changes through script version 1.9.12: === === == === === 1. Terminal Window Titles 2. Additional versions of OSG supported 3. Support for any branch, including the soon to be released flightgear 2.12.0. 2.10.0 is considered stable at this point in time. 4. Use manually placed fgdata copies in the parent of the build directory. Copies of fgdata git repositories can be placed in directories named fgdata_2.8.0, fgdata_2.10.0, fgdata_2.12.0 and fgdata_2.99.9. If download_and_compile.sh is run from a sub-directory of the directory containing the fgdata* directories, instead of downloading a separate copy of fgdata, the script will simply create s symbolic link to the correct fgdata git copy. Note that initially all the copies' versions do not have to match the directory name. Any recent version of fgdata will do. When it runs, the script will update the version you are building to be the correct version of fgdata. This approach to keeping multiple fgdata versions means you never have to download fgdata more than once. 1. You can blow away a build and not have to redownload fgdata 2. You can have multiple variant builds of a single version all using the same fgdata_*/fgdata version 3. You can build different versions of flightgear and still not have to download another fgdata == Future Changes: == 1. Change the directory structure for sources to allow a single copy of the sources to be used for multiple versions and variants without having to download the sources repeatedly. Similarly to the placement of the fgdata_* copies, create new directories for sources: fgsrc which will contain sources for anything native to flightgear othersrc which will contain sources for plib and as many versions of OSG as you need. Builds will be done in a subdirectory, one per variant It will look something like: download_and_compile.sh fgdata_2.10.0 fgdata fgdata 2.12.0 fgdata fgdata 2.99.9 fgdata fgsrc flightgear simgear openrti fgcom (unless we abandon the separate fgcom) fgrun etc. othersrc OpenSceneGraph-3.0.1 OpenSceneGraph-3.1.9 plib-1.8.5 variant-2.12.0-openrti build install compilation_log.txt variant-2.10.0-noopenrti build install compilation_log.txt variant-master-openrti variant-master-noopenrti variant-next-noopenrti variant-next-noopenrti and so forth. Note that with 1.9.12 and later its possible to build the master branch. Usage: cd variant-master-openrti ../download_and_compile.sh [options] [component names] 2. Change the way
Re: [Flightgear-devel] Release candidates
On Fri, Aug 30, 2013 at 11:41 AM, Stuart Buchanan wrote: 1) Windows launcher appears to have Rembrandt enabled by default, but set via the Advanced properties, rather than having a checkbox on the launcher. Makes it quite difficult for a new user to disable it. I would have expected Rembrandt to be switched off by default and with a checkbox on the Rendering Options section of the launcher to enable it. Caveat: It's possible that I've lost a config file somewhere on my Windows system, so if someone else could verify this is the case, that would be great. On Sat, Aug 31, 2013 at 10:04 AM, Vivian Meazza wrote: I've checked RC1 - FGRun here - AFAIKS it just picks up whatever you had last set in Advanced/Properties - I had Rembrandt disabled and that's what I got. Ah good - I suspected that might be the case but couldn't work out where the config was being stored. 2) There appears to be some invalid scenery around lat:37.228, lon:-121.9703. Scenery triangles are white and the UFO can't determine the material type. I'll investigate this further - might be an error in the landclass or something we've got wrong in materials.xml. This looks just like a straight terrain build error. The problem appears to be in bucket 958408. Here's the screenshot, just using the terrain in data/Scenery: http://www.nanjika.co.uk/flightgear/fgfs-screen-057.png Here's the equivalent using current terrasync data, which matches what the mapserver is showing as the data: http://www.nanjika.co.uk/flightgear/fgfs-screen-058.png According to the UFO, the forested terrain for terrasync between the river and the road is one of Landmass, SomeSort, Island, Default, which is slightly suspicious. However, it isn't just that terrain that is missing, as the lake and the town are also not rendered which makes me think this is just a build error. I vaguelly recall that the scenery delivered with the base package is a special case and not simply a copy off the standard world scenery build. Can anyone comment if this is so, or whether we should over-write the base scenery with terrasync as a fix? -Stuart -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
