Re: [Flightgear-devel] FlightGear Build Problem
Hi, If you get blue screens while compiling I suspect a hardware or driver problem. On Windows 7 you can type into the Start Panel reliability and start the reliability monitor (In German Zuverlässigkeitsanzeige). If you dig through the reports you may get an information what component or driver is causing this issue. You may test the RAM of your computer with memtest. Download iso Image from http://www.memtest.org/ , boot it and run a test. You may boot you Win7 in Safe mode (without all the fancy drivers). If your computer crashes in safe mode while compiling, you have an HW issue, otherwise I suspect a SW issue. (Press F8 before Win7 Splash screen) Greetings Olaf Flebbe Sometimes I get the blue screen and have to restart. I tried the same procedures building FlightGear only and have the same problems. Do you have any idea what's going on? I'm using Windows 7 64-bt but building for 32-bit. If you could provide any recommendations that would be great. My ultimate goal is to build FlightGear 2.4.0 nearly the same as the binary that is provided on the FlightGear website. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata version in master branch
Hi everybody, since one or two weeks I have the following problem: When I start fgfs it tells me that it needs version 2.7.0 of fgdata and quits immediately. I am using SimGear/Flightgear next branch, and fgdata master branch. After maually changing the version-file in fgdata from 2.5.0 to 2.7.0 everything is okay. It would be nice if someone could change the version number to 2.7.0 in the master branch. cheers, Robert -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata version in master branch
Hi Robert, De: Robert Hi everybody, since one or two weeks I have the following problem: When I start fgfs it tells me that it needs version 2.7.0 of fgdata and quits immediately. I am using SimGear/Flightgear next branch, and fgdata master branch. After maually changing the version-file in fgdata from 2.5.0 to 2.7.0 everything is okay. It would be nice if someone could change the version number to 2.7.0 in the master branch. Already done for awhile. See yourself : https://gitorious.org/fg/fgdata/blobs/master/version https://gitorious.org/fg/fgdata/commit/49283115c5042d42c68939b2942eeda7760df5fc Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Build Problem
On Sun, 5 Feb 2012 00:29:56 -0500, Tim wrote in message CAGFQzCQ91bL4U5TE2n5tEohRMv2eFF3A8fgAaGf3kZ40Ja_m=w...@mail.gmail.com: Hi. I'm trying to BuildFlight gear and have many issues. To begin the process I went to the GIT repository for the FlightGear project and eventually found my way to FlightGear/flightgear/release2.4.0/doc-mini/. Then, I followed the instructions for 32-bit as stated in README.MSVC. When I open the MSVC solution file Visual C++ 2008 Express loads 14 different projects, which aren't mentioned in the instructions. However, continuing with the instructions I changed 'Debug' to 'Release' and clicked Build-Build Solution. The build starts with SimGear and stops when a message stating 'Microsoft c/c++ Optimization Compiler has stopped working.' Then I turned off the optimization under properties and the problem continues to occur. Sometimes I get the blue screen and have to restart. I tried the same procedures building FlightGear only and have the same problems. Do you have any idea what's going on? .._no_, I'm a GNU/Linux guy. ;o) ..the guys who _might_ know, will probably want to see your build logs on your build log website. ..and do heed Olav's advice, hardware with problems developing, will kill data even on GNU/Linux with the badram patch applied, that patch still needs an accurate and fresh map to navigate around on bad ram sticks. I'm using Windows 7 64-bt but building for 32-bit. ..if you want to run FG on your 64bit Wintendo 7, my _guess_ is you want to build a 64bit FlightGear. One way to prove me wrong, is show me your 32bit build runs faster and better than e.g. FG's official 64bit release. ;o) If you could provide any recommendations that would be great. My ultimate goal is to build FlightGear 2.4.0 nearly the same as the binary that is provided on the FlightGear website. ..why, we have FG-2.6.0 out in a coupla weeks now. ..to e.g. verify the build process and all the built binary file checksums? Now _that_ would be useful in e.g. copyright law enforcement. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shader performance
I haven't really seen any guidelines about efficient shader coding, but I've come across a few statements here and in the forum now and then, which I so far assumed to be true. I've now spent the last few days benchmarking my lightfield/terrain haze framework to see if I can't squeeze a bit more performance out. Since the results somewhat contradicted things I have assumed to be true before, I thought I might share my observations. 1) vertex shader is fast and efficient, fragment and geometry shaders are comparatively slow and cost performance I don't know who stated that here, but I intuitively assumed that this must be right. You can imagine that I was surprised that when I trivialized the fragment part of my code, the performance didn't change at all, but when I trivialized the vertex part, the performance doubled. So it seems like the whole performance drain of my code is caused by an overworked vertex shader. I then transferred the haze color computations to the fragment shader, which improved overall performance in my benchmarks by 20-40%. It seems the optimal results appear for a shared workload between vertex and fragment shader. Since for instance 3d clouds run almost exclusively via vertex shader, this may not be an otherwise irrelevant observation. 2) vertex count doesn't matter I've read that in the forum as advice to model-builders quite often. For all I can test, that's wrong. In order to get the same framerate in default scenery and custom Italy CORINE scenery, I have to set the visibility range ~a factor 10 different. That's consistent with a hundred times higher vertex count in the CORINE scenery, or with a factor 10 higher linear resolution of landcover and elevation data, which seems about right. So the vertex count more or less directly sets my framerate. This is also relevant for models, because having a cluster of ~ 5 AI planes (which happened to be stuck into each other) in my view or not caused a 25% change in framerate, so the vertex count of models matters compared with the vertex count of scenery and is not some insignificant correction. 3) shifting constant-per-frame computations out of the shader doesn't improve performance significantly. I suggested that here as an idea to improve performance of the cloud shaders. I was now able to construct a test case for the idea. The computation in question involved getting a per-frame constant from other constants, i.e. to compute sqrt(2 * hazeAlt * EarthRadius) where hazeAlt is the altitude up to which the haze extends which is passed as a uniform. Computing two of such square root expressions inside the vertex shader or not computing it makes the difference between 21 and 22 fps in a high vertex count benchmark test, i.e. 5%. Which is not that much in itself, but if we would find, track and eliminate all these occasions, the sum of such small improvements might well go into the 20-30%. I don't know how much of all that is specific for my system (NVIDIA GeForce 8600M GT) and how much is general, but my conclusion is that these things should be tested systematically, and I very much invite others to test the before/after version of the haze shader code. (I know that Vivian and Emilian are still working on separating the fog and light function out, but that's going to take, and if anyone could help me to get the correct xml conditionals so that the whole framework can be switched on and off along with the skydome shader, so that the whole thing can be committed and tested easily, that'd be terrific. I tried, but I keep messing the effect file up...) Cheers, * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata version in master branch
My fault. Sorry for the noise. 2012/2/5 Frederic Bouvier fredfgf...@free.fr Hi Robert, De: Robert Hi everybody, since one or two weeks I have the following problem: When I start fgfs it tells me that it needs version 2.7.0 of fgdata and quits immediately. I am using SimGear/Flightgear next branch, and fgdata master branch. After maually changing the version-file in fgdata from 2.5.0 to 2.7.0 everything is okay. It would be nice if someone could change the version number to 2.7.0 in the master branch. Already done for awhile. See yourself : https://gitorious.org/fg/fgdata/blobs/master/version https://gitorious.org/fg/fgdata/commit/49283115c5042d42c68939b2942eeda7760df5fc Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
On Sun, Feb 5, 2012 at 7:50 AM, thorsten.i.r...@jyu.fi wrote: I haven't really seen any guidelines about efficient shader coding, but I've come across a few statements here and in the forum now and then, which I so far assumed to be true. I've now spent the last few days benchmarking my lightfield/terrain haze framework to see if I can't squeeze a bit more performance out. Since the results somewhat contradicted things I have assumed to be true before, I thought I might share my observations. 1) vertex shader is fast and efficient, fragment and geometry shaders are comparatively slow and cost performance I don't know who stated that here, but I intuitively assumed that this must be right. You can imagine that I was surprised that when I trivialized the fragment part of my code, the performance didn't change at all, but when I trivialized the vertex part, the performance doubled. So it seems like the whole performance drain of my code is caused by an overworked vertex shader. I then transferred the haze color computations to the fragment shader, which improved overall performance in my benchmarks by 20-40%. It seems the optimal results appear for a shared workload between vertex and fragment shader. Since for instance 3d clouds run almost exclusively via vertex shader, this may not be an otherwise irrelevant observation. 2) vertex count doesn't matter I've read that in the forum as advice to model-builders quite often. For all I can test, that's wrong. In order to get the same framerate in default scenery and custom Italy CORINE scenery, I have to set the visibility range ~a factor 10 different. That's consistent with a hundred times higher vertex count in the CORINE scenery, or with a factor 10 higher linear resolution of landcover and elevation data, which seems about right. So the vertex count more or less directly sets my framerate. This is also relevant for models, because having a cluster of ~ 5 AI planes (which happened to be stuck into each other) in my view or not caused a 25% change in framerate, so the vertex count of models matters compared with the vertex count of scenery and is not some insignificant correction. Thorsten, #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. I've worked in the gaming world long enough to know otherwise. Total scene resources matter. Sure, graphics cards are optimized to quickly render large, well-designed objects. You can build a beautiful model with hundreds of thousands of polygons and that's great. But when it's in a scene with gazillions of other objects, it's a hit. Animate it and the situation just gets worse. This is why game designers build objects with minimal vertices and create detail using good texture and shading tricks. People need to understand that their wonderful creations must live and play in the same sandbox as other wonderful creations. But I am not going to rant. I am not going to rant. I am not going to rant... ;) -Gary aka Buckaroo -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] smooth animations or: what is property-interpolate for?
Hi, i have recently added a new internal command: property-interpolate. This exposes the SGInterpolator subsystem to bindings in xml animation files. The SGInterpolator allows the interpolation of property values over time and has so far been used via Nasal in aircraft.door. For an example, start the Hansajet from git (fgfs --aircraft=Hansajet) and zoom to the gyrosyn heading indicator left of the HSI. Locate the black/white knob with VOR and ADF written on it. Click it (it swaps the assignment of the needle-driving sources) and notice that it does rotate smoothly to its new position (it's a 2-position toggle knob). Now, look at the overhead panel, either by paning the view up and right or by pressing shift-v on the keyboard. Locate the six rotary buttons GEN.1, GEN.2, ALT.1, ALT.2 and the two between the AC and DC instruments. Move them by clicking their left/right edges. Notice they move smoothly instead of jumping to the new position. Thats done completely without Nasal but from just a few lines in the animation files. Basically, you have to add two bindings to the pick animation: 1. property-assing the target value describing the state of the button (that's what you are used to do) 2. property-interpolate the position of the model to it's new state's value (that's the new binding to add) 3. Animate the model's rotation from the position property, not the state property (that's what you have to change) 4. done. (see the animations for the object SyncKnob and SyncKnobPick.[LR] in Aircraft/Hansajet/Models/Sperry-C-6d.xml as an example). The use of the property-interpolate may be: Change the value of /some/target/property to the constant value of 100.0 over 3 seconds. binding commandproperty-interpolate/command property/some/target/property/property value100.0/value time3/time /binding Change the value of /some/target/property to the value of /some/source/property over 0.5 seconds. binding commandproperty-interpolate/command property/some/target/property/property property/some/source/property/property time0.5/time /binding I hope you like it as much as I do - comments are welcome! Torsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
On Sun, Feb 5, 2012 at 12:50 PM, Thorsten Renk wrote: I haven't really seen any guidelines about efficient shader coding, but I've come across a few statements here and in the forum now and then, which I so far assumed to be true. I've now spent the last few days benchmarking my lightfield/terrain haze framework to see if I can't squeeze a bit more performance out. Since the results somewhat contradicted things I have assumed to be true before, I thought I might share my observations. Very interesting, and food for thought :) 1) vertex shader is fast and efficient, fragment and geometry shaders are comparatively slow and cost performance snip Since for instance 3d clouds run almost exclusively via vertex shader, this may not be an otherwise irrelevant observation. That's very interesting. Do you have any suggestions for what information we could push onto the fragment shader? 2) vertex count doesn't matter I've read that in the forum as advice to model-builders quite often. For all I can test, that's wrong. In order to get the same framerate in default scenery and custom Italy CORINE scenery, I have to set the visibility range ~a factor 10 different. That's consistent with a hundred times higher vertex count in the CORINE scenery, or with a factor 10 higher linear resolution of landcover and elevation data, which seems about right. So the vertex count more or less directly sets my framerate. I think there are far too many variables in your examples to be able to draw a conclusion that vertex count is the over-riding factor. My understanding from Matthias' comments on the 3D cloud code is that provided the GPU isn't having to reload a different state set, then it should be very efficient indeed in handling larger numbers of vertices. So, in the 3D clouds case, asking the GPU to render a whole set of quads at once to create a cloud is more efficient than rendering each sprite one at a time. (On a related note, while the Impostor's haven't been a success, the other improvements should mean that you can use more sprites per cloud than before for the same perf cost) In your examples, the increase in vertex count will be accompanied by an increase in object count, and (in the AI case) an increase in textures. In each of these cases, the GPU will be loading and unloading state, which is inefficient. A more interesting example would be to compare the impact of a model with 1k vertices, with one with 10k vertices, with the same object count, texture etc. 3) shifting constant-per-frame computations out of the shader doesn't improve performance significantly. I suggested that here as an idea to improve performance of the cloud shaders. I was now able to construct a test case for the idea. The computation in question involved getting a per-frame constant from other constants, i.e. to compute sqrt(2 * hazeAlt * EarthRadius) where hazeAlt is the altitude up to which the haze extends which is passed as a uniform. Computing two of such square root expressions inside the vertex shader or not computing it makes the difference between 21 and 22 fps in a high vertex count benchmark test, i.e. 5%. Which is not that much in itself, but if we would find, track and eliminate all these occasions, the sum of such small improvements might well go into the 20-30%. Makes a lot of sense. I'm happy to add extra Uniforms to the 3D cloud shaders. What do you need calculated in the C++ code? -Stuart -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Random object/vegetation terrain masking
Hi All, I've just committed to simgear/next and fgdata/master code to allow the placement and rotation of random objects and vegetation to be masked based on a bitmap. So we can now control the placement and rotation of random objects precisely to match the underlying terrain texture. So, for farmland, the farm buildings etc. will appear at the ends of roads rather than in the middle of fields*, and in urban areas random buildings will align with the streets** (which works well with the urban shader IMO). As an extra bonus, I've also added a property (/sim/rendering/vegetation-density) that controls the density of the random vegetation. So you can control how uninviting the forests are based on the abilities of your graphics card :) I've committed changes to materials.xml and materials-dds.xml to make use of this, but there's plenty of room for someone to spend time improving the masking if they wish. The masks are very easy to create: - the Red channel controls Rotation - the Blue channel controls Buildings - the Green channel controls vegetation. (You can also use values 255 on the B and G channel for probability placements) Comments welcome as always. -Stuart * This isn't compatible with the crop shader. I don't know if that is solvable or not. ** There's still a bit of work to be done on the urban masks, as some buildings are intruding onto the highways :) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Quote: #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. And that's a point of frustration to me! Because no one, not Tim Moore, not me, not anyone, did say this! The wiki article is btw by Tim Moore. But they said, that the bottleneck of GPU's is not the vertice count, but other things. That never meant that you have to use many vertices as you want. ... As many vertices as needed- not more or less! From http://www.flightgear.org/forums/viewtopic.php?f=4t=6030 No one wants to see edgy aircraft as we still have in the repo. But also not oversized models like the Vostok-1. The other big problem was until now, that we didn't had a proper LOD-System- that made it difficult as well. According to TorstenB that has been improved a lot now. And especially in FGFS not really Vertices is one of the big problems, but .xml's and nasal-scripts. It is interesting to see that other Sims like X-Plane and in the past MSFS uses models with far, far more polygons and vertices than we do, and still seems to have good perfomance. How can it be? And there had been an other problem in the past and now: -Many misleading statements about that issues and no tips and helps for those interested to make it right. -People who had more of less the knowledge but kept them for themselves, instead of helping others to make their work better. Or used this to simply showoff. But that's how FGFS-Project has ever been: a tank full of sharks- survival of the fittest. Cheers Heiko -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Dang, I shouldn't have ranted. This added nothing to Thorsten's discussion. My apologies to the list and to Thorsten. -Gary Thorsten, #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. I've worked in the gaming world long enough to know otherwise. Total scene resources matter. Sure, graphics cards are optimized to quickly render large, well-designed objects. You can build a beautiful model with hundreds of thousands of polygons and that's great. But when it's in a scene with gazillions of other objects, it's a hit. Animate it and the situation just gets worse. This is why game designers build objects with minimal vertices and create detail using good texture and shading tricks. People need to understand that their wonderful creations must live and play in the same sandbox as other wonderful creations. But I am not going to rant. I am not going to rant. I am not going to rant... ;) -Gary aka Buckaroo -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Build Problem
I ran a memory test and to my surprise had a bad memory module. I removed the module and replaced it and the optimization compiler error went away. My system is much more stable too. Special thanks to Arnt Karlsen and Olaf Flebbe! Tim On Sun, Feb 5, 2012 at 6:39 AM, Arnt Karlsen a...@c2i.net wrote: On Sun, 5 Feb 2012 00:29:56 -0500, Tim wrote in message CAGFQzCQ91bL4U5TE2n5tEohRMv2eFF3A8fgAaGf3kZ40Ja_m=w...@mail.gmail.com: Hi. I'm trying to BuildFlight gear and have many issues. To begin the process I went to the GIT repository for the FlightGear project and eventually found my way to FlightGear/flightgear/release2.4.0/doc-mini/. Then, I followed the instructions for 32-bit as stated in README.MSVC. When I open the MSVC solution file Visual C++ 2008 Express loads 14 different projects, which aren't mentioned in the instructions. However, continuing with the instructions I changed 'Debug' to 'Release' and clicked Build-Build Solution. The build starts with SimGear and stops when a message stating 'Microsoft c/c++ Optimization Compiler has stopped working.' Then I turned off the optimization under properties and the problem continues to occur. Sometimes I get the blue screen and have to restart. I tried the same procedures building FlightGear only and have the same problems. Do you have any idea what's going on? .._no_, I'm a GNU/Linux guy. ;o) ..the guys who _might_ know, will probably want to see your build logs on your build log website. ..and do heed Olav's advice, hardware with problems developing, will kill data even on GNU/Linux with the badram patch applied, that patch still needs an accurate and fresh map to navigate around on bad ram sticks. I'm using Windows 7 64-bt but building for 32-bit. ..if you want to run FG on your 64bit Wintendo 7, my _guess_ is you want to build a 64bit FlightGear. One way to prove me wrong, is show me your 32bit build runs faster and better than e.g. FG's official 64bit release. ;o) If you could provide any recommendations that would be great. My ultimate goal is to build FlightGear 2.4.0 nearly the same as the binary that is provided on the FlightGear website. ..why, we have FG-2.6.0 out in a coupla weeks now. ..to e.g. verify the build process and all the built binary file checksums? Now _that_ would be useful in e.g. copyright law enforcement. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
