[Airac] - Airac 1909
martes, 27 de agosto de 2019
sábado, 31 de diciembre de 2016
Nuevas texturas para mejorar la VC del Ifly
Hola.
Aquí tienen una buena mejora para la cabina virtual del Ifly, le da mejor calidad de texturas al VC. HAY QUE TENER INSTALADO EL FEATURE PACK PARA ESTAS TEXTURAS.
http://paulo-design.net/VCupgradeV2.zip
Y después el 2.1: http://paulo-design.net/VCupgradeV2.1.zip
Dentro tienen esto:
El contenido del cockpit textures va dentro de cada textura, es decir, si queremos poner estas texturas nuevas para la VC la tienen que meter en texture.aireuropa o en cualquiera que quieran.
Barely used para texturas de avión nuevo y worn para texturas de usado.
Dentro de customize igual, y en MCP, copian ese gauge en la carpeta Gauges, haciendo copia de seguridad del archivo antes de copiarlo por si acaso.
Aquí tienen unas cuantas fotos para que vean como quedaría el cockpit.
Este es el gareshield con las texturas de usado, las de worn.
Espero que les guste, yo ya lo probé y está muy bien, le da un nuevo look al VC del Ifly, al VC de las texturas de Air Europa que tengo instaladas les puse las texturas de usado.
Felices vuelos.
Aquí tienen una buena mejora para la cabina virtual del Ifly, le da mejor calidad de texturas al VC. HAY QUE TENER INSTALADO EL FEATURE PACK PARA ESTAS TEXTURAS.
http://paulo-design.net/VCupgradeV2.zip
Y después el 2.1: http://paulo-design.net/VCupgradeV2.1.zip
Dentro tienen esto:
El contenido del cockpit textures va dentro de cada textura, es decir, si queremos poner estas texturas nuevas para la VC la tienen que meter en texture.aireuropa o en cualquiera que quieran.
Barely used para texturas de avión nuevo y worn para texturas de usado.
Dentro de customize igual, y en MCP, copian ese gauge en la carpeta Gauges, haciendo copia de seguridad del archivo antes de copiarlo por si acaso.
Aquí tienen unas cuantas fotos para que vean como quedaría el cockpit.
Este es el gareshield con las texturas de usado, las de worn.
Espero que les guste, yo ya lo probé y está muy bien, le da un nuevo look al VC del Ifly, al VC de las texturas de Air Europa que tengo instaladas les puse las texturas de usado.
Felices vuelos.
viernes, 30 de diciembre de 2016
All Weather Operations at Aerodromes
All Weather Operations at Aerodromes
All Weather Operations at Aerodromes
European Guidance Material on All Weather Operations at Aerodromes (4th edition)
History
1. The principles of the Low Visibility Procedures and the basis for All-Weather Operations in Europe have been defined in the ICAO Manual of All-Weather Operations (Doc No. 9365, 2nd Edition, 1991) and previously in ECAC.CEAC Doc No. 17.
2. When the requirement to implement the ICAO Global Strategy for introduction and application of non-visual aids to approach and landing was set up, the European Air Navigation Planning Group (EANPG) established the All Weather Operations Group (AWOG) which was tasked to deal with the related matters and manage the transition in the EUR region.
1. The principles of the Low Visibility Procedures and the basis for All-Weather Operations in Europe have been defined in the ICAO Manual of All-Weather Operations (Doc No. 9365, 2nd Edition, 1991) and previously in ECAC.CEAC Doc No. 17.
2. When the requirement to implement the ICAO Global Strategy for introduction and application of non-visual aids to approach and landing was set up, the European Air Navigation Planning Group (EANPG) established the All Weather Operations Group (AWOG) which was tasked to deal with the related matters and manage the transition in the EUR region.
3. ...
Purpose:
The purpose of this Guidance Material is to assist EUR States in the development of procedures to be applied in Reduced Aerodrome Visibility Conditions (RAVC) and the implementation of Low Visibility Procedures (LVP) in a harmonised way.
With due account taken to provisions enacted by the appropriate authorities, this Guidance Material may also be used by aerodrome operators, and those responsible for providing other facilities and equipment, to assess the suitability of an aerodrome for All Weather Operations (AWO), to determine the steps to be taken to prepare an aerodrome for AWO, and to maintain these operations safely. Similarly, this Guidance Material may also be used by providers of ANS & Apron Management Services to ensure that the relevant procedures required for such operations comply with requirements established by the appropriate authorities. This document will provide guidance on the interpretation and application of these requirements to achieve these aims and objectives.
With due account taken to provisions enacted by the appropriate authorities, this Guidance Material may also be used by aerodrome operators, and those responsible for providing other facilities and equipment, to assess the suitability of an aerodrome for All Weather Operations (AWO), to determine the steps to be taken to prepare an aerodrome for AWO, and to maintain these operations safely. Similarly, this Guidance Material may also be used by providers of ANS & Apron Management Services to ensure that the relevant procedures required for such operations comply with requirements established by the appropriate authorities. This document will provide guidance on the interpretation and application of these requirements to achieve these aims and objectives.
Structure of this guidance material:
Chapter 2: Regulatory framework: identifies the supporting regulatory framework which must also be considered in the development of All Weather Operations.
Chapter 3: Introduction to All Weather Operations: provides an introduction to the concepts and procedures that are used in conjunction with All Weather Operations.
Chapter 4: Provisions to support All Weather Operations: this section details the requirements relating to the need for (but not operation of) any equipment, facilities, services, and procedures that have to be in place before AWO can take place in accordance with the applicable ICAO frameworks.
Chapter 5: Preparing a local All Weather Operations Plan: A description of an organisation to establish and maintain the All Weather Operations Plan.
Chapter 6: Reduced Aerodrome Visibility Procedures: Describes the procedures to support operations in Reduced Aerodrome Visibility Conditions.
Chapter 7: Low Visibility Procedures: Describes the LVP required when specific types of departure and approach and landing operations take place.
Chapter 8: Optimised Operations
Chapter 9: GBAS
Chapter 10: Safety Management of All Weather Operations
Appendix A: Samples of AIP Entries
Appendix B: Equipment Failure Tables
Appendix C: Examples of AWO Checklists
Nvidia configuration guide (Inspector + 2xx.xx drivers) version 2.0 + explanations of all settings
Last update 14JAN16
[Link updated]
Time to update this post, it's been a year since it was last done!
New settings screenshots using the current 1.9.5.9 version of Inspector including a new 4xS setting and a discussion of the new frame rate limiter feature have been added!
===========DX10 WARNING - AA does NOT work in FSX's DX10 preview mode, it never has. You should not run in DX10 mode basically ever - it is slower and buggy.
Step 1 - Get the latest Nvidia Inspector version here: http://www.guru3d.co...r-download.html SURE YOU EXTRACT ALL THE FILES! The program needs more than just the exe, there's a file called CustomSettingNames_en-EN.xml that defines the names of all the different settings - if you're seeing cryptic feature names and hex values, you didn't put that file in the same folder as the exe.)
Here are three possible ways to set it for FSX and FS9 - one uses the 4xS mode, one uses 8xS and the other uses 8xSQ. I added the 4xS version because it was my own personal experience with the NGX that running a ton of texture resolution intensive addons like the NGX, REX, Orbx sceneries etc all at once massively increased the load on the video card and caused stuttering, particularly in spot view. The work required of the GPU to perform supersample AA is affected by the resolution of the textures and with everything using 4096 textures, I found this a better solution on my particular card (GTX 570). It's definitely possible that the next generation of cards will not be affected in this way even when using a ton of 4096 textures. The 4xS option is probably best for people with older video cards in a general sense as well. 8xSQ reduces shimmering a bit more than 8xS does, but it comes at a performance cost and may look a bit more blurred due to the higher level of supersample AA used.
To make these settings - run Nvidia Inspector and click the icon to the right of the driver version (it looks like a wrench and screw driver in an X shape) - that will bring up the profile editor. Click in the Profiles dropdown box and type "MS" - this should make the FS9 and FSX profiles visible - click (you can't use the arrow+enter keys for some reason) the one you want and that will make it active for editing. The settings are the same for both FS9 and FSX - I'm only showing FSX here.
Now - go through and change the settings that are in bold in the screenshots below - anything that is greyed out should be left at the default, which is inherited from the main global profile.Inside FSX, uncheck AA and set filtering to Trilinear. These in-game settings actually do not matter, but I've seen NickN bring up a good point that if they're set this way it acts as a way to warn you if something isn't working right in the driver - for example, say you update your drivers and suddenly see blurry textures - that would tell you that the forced AF mode is no longer working because your profile got wiped or the driver is bugged etc. That's good advice that makes sense to me.
4xS version:
8xS version:
8xSQ version:
Now...In the interest of furthering everyone's understanding of GPU technology and settings, here's the explanation of what Nvidia Inspector itself is and explanation for what you're doing with each of these settings:
Nvidia Inspector:There's been some confusion over what Inspector (and any similar program like the old nHancer we used before the 2xx.xx drivers) actually does. Inspector is a front-end for editing the Nvidia driver's application profiles. Application profiles determine the video card image quality settings get applied when you run a particular game. The profiles are stored in a binary file that's usually edited using the Nvidia Control Panel's "Manage 3D settings" page, Program Settings tab. That's all Inspector is, an alternate way of editing that file - it does not make the video card do things it and the driver are not already capable of doing. It's not a "hack" or anything like that. What it does do however is allow access to some AA modes that Nvidia considers experimental because they don't always work with every possible game out there. The 8xS mode that works best for FS is one of these modes that isn't normally accessible in the Nvidia Control Panel.The other big reason to use a tool like Inspector is that Nvidia predefines the way certain programs act with respect to the card's options. For some reason they set the FS profiles to "Enhance only", which does not allow you to totally override what FS tries to do on its own as far as AA and AF settings. Inspector lets you clear those "flags" so that you can set whatever you want in the application profile and FS will get exactly those settings applied to it without any modification. Most modern games do not require this - they have settings in the game itself for all these options and you just leave the application profile set to "Use the 3D application setting" for everything.
Antialiasing Section
Antialiasing - Behavior Flags:
By setting this to none, we are disabling Nvidia's predefined flags for FS that force it into "Enhance" mode that I mentioned above - you can see what the default is before you change it to None.
Antialiasing - Mode:
By setting this to override, we're telling the card to ignore anything FS itself is telling it to do and apply strictly what we have specified.
Antialiasing - Setting:
This is the full scene antialiasing (FSAA) mode. FSAA is what provides the main AA effect on all the terrain, buildings, the edges of the planes etc. These particular "combined" modes that work best in FSX are a combination of a multisample FSAA algorithm and a low-level supersampling FSAA algorithm. Multisampling and supersampling are two different ways of doing FSAA. Multisampling AA works by looking at the edges of polygons and the surrounding color pixels. It adjusts those colors at the pixel level to smooth the jagged lines. It's very fast to the point of being "free" in terms of performance on modern video cards, but it has a couple of drawbacks, most importantly that it doesn't AA inside polygons or on alpha-test textures. Supersampling AA works in an entirely different way - it actually renders the scene internally at a higher resolution than the monitor is displaying and uses that image to create the AA "map". Supersampling is very hard on performance at higher settings - for example to run at true 4x4 supersampling AA on a 1920x1200 monitor requires the video card to actually render every frame internally at 7680x4800. That's a huge amount of data and even the top of the line cards today will choke on it. That's why the combined mode is there - it gets you close to the image quality that pure supersampling offers, but without the massive performance hit. 8xS is a 4x multisampling AA combined with a 1x2 supersampling AA (this means only the vertical component of the screen is rendered at twice the resolution internally.) 8xSQ is a 2x multisampling AA combined with a 2x2 supersampling AA. It has a bigger hit on performance because it's using true 2x supersampling in both dimensions of the image. I would not use this unless you have a late model video card.
Antialiasing - Transparency: (there are two settings - Multisampling and Supersampling)
Transparency AA on Nvidia cards can be one of two types - multisampling or supersampling, just like FSAA. Transparency AA singles out objects like trees and power poles that can't normally be antialiased by FSAA methods. FSAA works on the edges of polygons, but objects like trees in FSX are actually a larger invisible box - the shape of the leaves/needles on the trees are a texture that is placed onto that invisible polygon. (These are also called "alpha test textures" technically) TSAA modes are able to AA those textures, the driver figures out where they are and performs something akin to what FSAA does, but ONLY on the objects that use transparency textures. Supersample TSAA is higher quality than multisample TSAA, just as it is with the full scene versions.You have to choose one or the other, you can't have both multisampling and supersample TSAA active at the same time. I'm not sure why the author of Inspector has it as two separate settings. It's totally normal though for the Transparency Multisampling setting in Inspector to be disabled when you have a supersample mode selected.I've actually had the TSAA setting slightly wrong here in the past. The card actually cannot do a higher level of TSAA than what the base FSAA level is set to - in this two examples above, it's limited to 4X with 8xS FSAA because that's the base FSAA mode in 8xS. (8xS is not true "8X" anything, so 4X is the max TSAA that will work with it) 8xSQ is limited to 2x TSAA because 2x multisampling is the base AA level in it.It is a combination of this setting and the supersampling component of the FSAA setting that massively reduce the shimmering in the trees, power lines and another other similar objects in the sim.
Texture Filtering section
Anisotropic filtering mode:
All we're doing here is putting the driver into the mode that lets us set this manually instead of letting FS set it itself.
Anisotropic filtering setting:
This is setting the actual level of anisotropic filtering (AF). AF is an effect that blends texture mipmaps into the distance while correcting for angle and perspective. A texture in a 3D game engine contains bunch of different resolutions called "mipmaps" - this cuts down on memory usage and processing work for the card because distant textures that shouldn't have much detail to them anyway can be drawn with the lower resolution mipmaps. Close up they'll be the full high resolution mipmap. AF blends the transition points between these mipmaps in an extremely smooth and convincing way. It should never be set to anything other than 16x in any game on a modern GPU. This operation is "free" like multisample AA is on cards today.Here are examples of the same scene in FSX that demonstrate the huge difference AF makes:
Trilinear filtering (not AF):
16x AF:
The difference there should be immediately apparent.
Texture filtering - Negative LOD Bias:
This setting prevents the FS engine from moving the mipmap transition points further into the distance. It does this in an attempt to sharpen the textures, but that creates massive texture aliasing (aka texture "crawl"). Anisotropic filtering does not need negatively biased mipmap transition points, in fact it's designed to work without them and not create aliasing. This setting should basically always be on in any game when you're using AF.
Texture filtering - Quality:
The Nvidia driver has various optimizations it does to the texture filtering process to speed it up. At the "High Performance" setting, all these optimizations are active and you trade image quality slightly for performance. At the other end, "High Quality", all of those optimizations are disabled and a slight amount of performance is traded for the best possible image quality. This is very very slight, I see no noticeable difference in performance between the settings, but High Quality does cut down on the texture shimmering slightly vs. the others.Common section:
Frame rate limiter: (requires Nvidia driver 290.xx or higher)
FSX performs differently when the sim's internal target framerate limiter slider is set to unlimited instead of an actual framerate. For a lot of people with high end systems it produces a smoother experience. The problem with doing this however is that the sim can wildly fluctuate and you can actually get stuttering from the sim pumping out far more frames than the monitor can handle. Externally limiting the framerate solves this problem. Up until very recently simmers had to use one of two dedicated frame rate limiting utilities to do this - no longer! This setting is an Nvidia created and approved framerate limiter that is built right into the driver itself. 30FPS is a good starting point - if you have a very powerful machine, you may be able to raise it up to 40 or so. I suspect within another year or so we might actually be able to lock this to 60 realistically.
Power management mode:
This stops the card from underclocking itself when it feels the load isn't enough to warrant the maximum clock speed. It just makes sense to me to have it going full speed while I'm flying. There's probably no harm in leaving this at Adaptive, but I'd rather be safe knowing all the card's power is instantly available.
That's the gist of it all - hopefully this gives you all a better understanding of what we're actually doing when we set up our video cards for FS.
New settings screenshots using the current 1.9.5.9 version of Inspector including a new 4xS setting and a discussion of the new frame rate limiter feature have been added!
===========DX10 WARNING - AA does NOT work in FSX's DX10 preview mode, it never has. You should not run in DX10 mode basically ever - it is slower and buggy.
Step 1 - Get the latest Nvidia Inspector version here: http://www.guru3d.co...r-download.html SURE YOU EXTRACT ALL THE FILES! The program needs more than just the exe, there's a file called CustomSettingNames_en-EN.xml that defines the names of all the different settings - if you're seeing cryptic feature names and hex values, you didn't put that file in the same folder as the exe.)
Here are three possible ways to set it for FSX and FS9 - one uses the 4xS mode, one uses 8xS and the other uses 8xSQ. I added the 4xS version because it was my own personal experience with the NGX that running a ton of texture resolution intensive addons like the NGX, REX, Orbx sceneries etc all at once massively increased the load on the video card and caused stuttering, particularly in spot view. The work required of the GPU to perform supersample AA is affected by the resolution of the textures and with everything using 4096 textures, I found this a better solution on my particular card (GTX 570). It's definitely possible that the next generation of cards will not be affected in this way even when using a ton of 4096 textures. The 4xS option is probably best for people with older video cards in a general sense as well. 8xSQ reduces shimmering a bit more than 8xS does, but it comes at a performance cost and may look a bit more blurred due to the higher level of supersample AA used.
To make these settings - run Nvidia Inspector and click the icon to the right of the driver version (it looks like a wrench and screw driver in an X shape) - that will bring up the profile editor. Click in the Profiles dropdown box and type "MS" - this should make the FS9 and FSX profiles visible - click (you can't use the arrow+enter keys for some reason) the one you want and that will make it active for editing. The settings are the same for both FS9 and FSX - I'm only showing FSX here.
Now - go through and change the settings that are in bold in the screenshots below - anything that is greyed out should be left at the default, which is inherited from the main global profile.Inside FSX, uncheck AA and set filtering to Trilinear. These in-game settings actually do not matter, but I've seen NickN bring up a good point that if they're set this way it acts as a way to warn you if something isn't working right in the driver - for example, say you update your drivers and suddenly see blurry textures - that would tell you that the forced AF mode is no longer working because your profile got wiped or the driver is bugged etc. That's good advice that makes sense to me.
4xS version:
8xS version:
8xSQ version:
Now...In the interest of furthering everyone's understanding of GPU technology and settings, here's the explanation of what Nvidia Inspector itself is and explanation for what you're doing with each of these settings:
Nvidia Inspector:There's been some confusion over what Inspector (and any similar program like the old nHancer we used before the 2xx.xx drivers) actually does. Inspector is a front-end for editing the Nvidia driver's application profiles. Application profiles determine the video card image quality settings get applied when you run a particular game. The profiles are stored in a binary file that's usually edited using the Nvidia Control Panel's "Manage 3D settings" page, Program Settings tab. That's all Inspector is, an alternate way of editing that file - it does not make the video card do things it and the driver are not already capable of doing. It's not a "hack" or anything like that. What it does do however is allow access to some AA modes that Nvidia considers experimental because they don't always work with every possible game out there. The 8xS mode that works best for FS is one of these modes that isn't normally accessible in the Nvidia Control Panel.The other big reason to use a tool like Inspector is that Nvidia predefines the way certain programs act with respect to the card's options. For some reason they set the FS profiles to "Enhance only", which does not allow you to totally override what FS tries to do on its own as far as AA and AF settings. Inspector lets you clear those "flags" so that you can set whatever you want in the application profile and FS will get exactly those settings applied to it without any modification. Most modern games do not require this - they have settings in the game itself for all these options and you just leave the application profile set to "Use the 3D application setting" for everything.
Antialiasing Section
Antialiasing - Behavior Flags:
By setting this to none, we are disabling Nvidia's predefined flags for FS that force it into "Enhance" mode that I mentioned above - you can see what the default is before you change it to None.
Antialiasing - Mode:
By setting this to override, we're telling the card to ignore anything FS itself is telling it to do and apply strictly what we have specified.
Antialiasing - Setting:
This is the full scene antialiasing (FSAA) mode. FSAA is what provides the main AA effect on all the terrain, buildings, the edges of the planes etc. These particular "combined" modes that work best in FSX are a combination of a multisample FSAA algorithm and a low-level supersampling FSAA algorithm. Multisampling and supersampling are two different ways of doing FSAA. Multisampling AA works by looking at the edges of polygons and the surrounding color pixels. It adjusts those colors at the pixel level to smooth the jagged lines. It's very fast to the point of being "free" in terms of performance on modern video cards, but it has a couple of drawbacks, most importantly that it doesn't AA inside polygons or on alpha-test textures. Supersampling AA works in an entirely different way - it actually renders the scene internally at a higher resolution than the monitor is displaying and uses that image to create the AA "map". Supersampling is very hard on performance at higher settings - for example to run at true 4x4 supersampling AA on a 1920x1200 monitor requires the video card to actually render every frame internally at 7680x4800. That's a huge amount of data and even the top of the line cards today will choke on it. That's why the combined mode is there - it gets you close to the image quality that pure supersampling offers, but without the massive performance hit. 8xS is a 4x multisampling AA combined with a 1x2 supersampling AA (this means only the vertical component of the screen is rendered at twice the resolution internally.) 8xSQ is a 2x multisampling AA combined with a 2x2 supersampling AA. It has a bigger hit on performance because it's using true 2x supersampling in both dimensions of the image. I would not use this unless you have a late model video card.
Antialiasing - Transparency: (there are two settings - Multisampling and Supersampling)
Transparency AA on Nvidia cards can be one of two types - multisampling or supersampling, just like FSAA. Transparency AA singles out objects like trees and power poles that can't normally be antialiased by FSAA methods. FSAA works on the edges of polygons, but objects like trees in FSX are actually a larger invisible box - the shape of the leaves/needles on the trees are a texture that is placed onto that invisible polygon. (These are also called "alpha test textures" technically) TSAA modes are able to AA those textures, the driver figures out where they are and performs something akin to what FSAA does, but ONLY on the objects that use transparency textures. Supersample TSAA is higher quality than multisample TSAA, just as it is with the full scene versions.You have to choose one or the other, you can't have both multisampling and supersample TSAA active at the same time. I'm not sure why the author of Inspector has it as two separate settings. It's totally normal though for the Transparency Multisampling setting in Inspector to be disabled when you have a supersample mode selected.I've actually had the TSAA setting slightly wrong here in the past. The card actually cannot do a higher level of TSAA than what the base FSAA level is set to - in this two examples above, it's limited to 4X with 8xS FSAA because that's the base FSAA mode in 8xS. (8xS is not true "8X" anything, so 4X is the max TSAA that will work with it) 8xSQ is limited to 2x TSAA because 2x multisampling is the base AA level in it.It is a combination of this setting and the supersampling component of the FSAA setting that massively reduce the shimmering in the trees, power lines and another other similar objects in the sim.
Texture Filtering section
Anisotropic filtering mode:
All we're doing here is putting the driver into the mode that lets us set this manually instead of letting FS set it itself.
Anisotropic filtering setting:
This is setting the actual level of anisotropic filtering (AF). AF is an effect that blends texture mipmaps into the distance while correcting for angle and perspective. A texture in a 3D game engine contains bunch of different resolutions called "mipmaps" - this cuts down on memory usage and processing work for the card because distant textures that shouldn't have much detail to them anyway can be drawn with the lower resolution mipmaps. Close up they'll be the full high resolution mipmap. AF blends the transition points between these mipmaps in an extremely smooth and convincing way. It should never be set to anything other than 16x in any game on a modern GPU. This operation is "free" like multisample AA is on cards today.Here are examples of the same scene in FSX that demonstrate the huge difference AF makes:
Trilinear filtering (not AF):
16x AF:
The difference there should be immediately apparent.
Texture filtering - Negative LOD Bias:
This setting prevents the FS engine from moving the mipmap transition points further into the distance. It does this in an attempt to sharpen the textures, but that creates massive texture aliasing (aka texture "crawl"). Anisotropic filtering does not need negatively biased mipmap transition points, in fact it's designed to work without them and not create aliasing. This setting should basically always be on in any game when you're using AF.
Texture filtering - Quality:
The Nvidia driver has various optimizations it does to the texture filtering process to speed it up. At the "High Performance" setting, all these optimizations are active and you trade image quality slightly for performance. At the other end, "High Quality", all of those optimizations are disabled and a slight amount of performance is traded for the best possible image quality. This is very very slight, I see no noticeable difference in performance between the settings, but High Quality does cut down on the texture shimmering slightly vs. the others.Common section:
Frame rate limiter: (requires Nvidia driver 290.xx or higher)
FSX performs differently when the sim's internal target framerate limiter slider is set to unlimited instead of an actual framerate. For a lot of people with high end systems it produces a smoother experience. The problem with doing this however is that the sim can wildly fluctuate and you can actually get stuttering from the sim pumping out far more frames than the monitor can handle. Externally limiting the framerate solves this problem. Up until very recently simmers had to use one of two dedicated frame rate limiting utilities to do this - no longer! This setting is an Nvidia created and approved framerate limiter that is built right into the driver itself. 30FPS is a good starting point - if you have a very powerful machine, you may be able to raise it up to 40 or so. I suspect within another year or so we might actually be able to lock this to 60 realistically.
Power management mode:
This stops the card from underclocking itself when it feels the load isn't enough to warrant the maximum clock speed. It just makes sense to me to have it going full speed while I'm flying. There's probably no harm in leaving this at Adaptive, but I'd rather be safe knowing all the card's power is instantly available.
That's the gist of it all - hopefully this gives you all a better understanding of what we're actually doing when we set up our video cards for FS.
GE View: Google earth viewer for FSX and P3D
Note: I was not quite sure where to post this, so I asked Jim Young, Forums Director, who suggested that I post it here.
For an occasional and interesting diversion from usual Flight Sim VFR flights, take a look at GE View, a new FSX and P3D application written by Robbie McElrath. GE View produces an additional view of the external world using Google earth’s satellite imagery, displayed in a separate browser window as you fly. It can be freely downloaded from the link attached below.
Screen shots below show side-by-side comparisons. For purposes of the comparison, the main cockpit panel has been closed in the FS window on the left. In the bottom picture, note the 3D views of buildings in Sion, Switzerland, that can be seen thanks to low altitude aerial stereo imagery now available in Google earth over many cities across the world.
Screen shots below show side-by-side comparisons. For purposes of the comparison, the main cockpit panel has been closed in the FS window on the left. In the bottom picture, note the 3D views of buildings in Sion, Switzerland, that can be seen thanks to low altitude aerial stereo imagery now available in Google earth over many cities across the world.
In my opinion, the Google earth view is often spectacular in mountainous areas, but cities that have the low altitude stereo imagery are impressive as well.
GE View consists of two files, HttpX.dll that accesses pertinent A:Vars from Flight Sim and makes them readable to a web application, and earth.html, the web app that opens Google earth and uses the A:Vars to control Google earth’s camera view. Those files, plus an installation guide, are attached to this posting.
GE View consists of two files, HttpX.dll that accesses pertinent A:Vars from Flight Sim and makes them readable to a web application, and earth.html, the web app that opens Google earth and uses the A:Vars to control Google earth’s camera view. Those files, plus an installation guide, are attached to this posting.
In the works:
Oculus VR view: Robbie has completed a beta version of GE View that uses the Oculus Rift Virtual Reality headset (Development Kit 2 headset). It’s very cool to move your head around and see the Google earth 3D world around you as Flight Sim flies. Further work will await commercial release of the Oculus Rift VR headset and/or advancements in how the Google earth browser plug-in is implemented.
Oculus VR view: Robbie has completed a beta version of GE View that uses the Oculus Rift Virtual Reality headset (Development Kit 2 headset). It’s very cool to move your head around and see the Google earth 3D world around you as Flight Sim flies. Further work will await commercial release of the Oculus Rift VR headset and/or advancements in how the Google earth browser plug-in is implemented.
On the horizon:
Enhanced HttpX.dll: Expansion of functionality to read all types of Flight Sim variables and capability to write to L:Vars and fire events from html. This would facilitate development of a MFD on a tablet, for example. For a related product, please also check out http://websimconnect.webs.com/. Many will find that interesting as well. HttpX.dll does not use any websimconnect code, but I believe the underlying idea of joining Flight Sim with a web application is the same.
Enhanced HttpX.dll: Expansion of functionality to read all types of Flight Sim variables and capability to write to L:Vars and fire events from html. This would facilitate development of a MFD on a tablet, for example. For a related product, please also check out http://websimconnect.webs.com/. Many will find that interesting as well. HttpX.dll does not use any websimconnect code, but I believe the underlying idea of joining Flight Sim with a web application is the same.
Admittedly, none of these are mainstream Flight Simulator applications, just additional interesting things that can be done. But if you’ve never been to the Alps, let GE View give you an aerial tour!
GE View link: https://drive.google...uNXM&authuser=0
Regards,
Bob McElrath
FS9: If anyone wants GE View for FS9, please respond and an FS9 http.dll will be posted (FS9 requires a different http.dll than FSX / P3D).
Security Note: HttpX opens a TCP port (54321) on the machine running Flight Simulator. While every effort was made to ensure there are no vulnerabilities, as best practice you should restrict access to this port to your local machine or local network (for those behind home routers, most will allow external access only to whitelisted ports by default anyway). As such, use this software at your own risk.
How to properly setup multiple monitors with SoftTH.
Introduction
A few weeks ago, quite by accident I stumbled upon SoftTH. I always wanted to "triplehead" my system but I didn't want to spend a lot of money on an extra videocard to run them in SLI. Around the same time, a friend also gave me two old 19" Samsung monitors so this was the perfect time to try out triplehead through software. I bought a cheap used Geforce 7900 GS and got going with SoftTH.
SoftTH automagically creates a config file for you to use. It simply adds up the resolutions of your monitors and uses that as the total resolution for your game. And although this works and looks good, with just a little extra effort you can actually make it look a lot better!
Problem with the default approach
The problem with the standard approach is that it does not take into account the physical size of your monitors, nor does it take into account that your monitors have bezels. Let me try to explain that with a few images.
First, let's assume you have three monitors. Your primary monitor (the one in the middle) is 1920 pixels wide while the monitors on the left and right are both 1024 pixels wide (I've chosen such a big difference between the size of the monitors on purpose because it perfectly illustrates the problems you will encounter). What most people do (and what SoftTH does by default), is simply add up these three values. So the total width of your game's viewport would become 1920 + 1024 + 1024 = 3968 pixels.
This view is then split up and sent to your monitors as follows:
This works but there are a few problems with this approach. Suppose your three monitors look like this:
Even though your primary monitor has almost twice as much pixels horizontally than the monitors on the left and right (1920px vs 1024px), those monitors are almost the same width physically as your primary monitor. So how does it look when we superimpose the three parts of the main view on top of these monitors?
So even though the monitors on the left and right monitor are almost as wide as your primary monitor, they spread out 1024 pixels of the original image over this width while the center monitor spreads out 1920 pixels. This means that the image left and right will be stretched horizontally (quite a bit actually). Also, since the outer monitors are less high, the image is squashed vertically.
This is caused because the monitors have a different dot pitch (the primary monitor packs a lot more pixels per inch than the outer two monitors).
Another problem is that we don't take the bezels of each monitor into account. Let's use a simple image to illustrate this problem:
And for argument's sake, this time let's use three equally sized monitors and spread the image over these three monitors:
Looks weird, doesn't it? The red lines no longer look attached, and the green shapes look awefully distorted. That's what happens if you simply split the original image in three and render them as if the three screens had no bezels.
How we really want the image rendered, is like this:
Yes, parts of the image are now obscured by the bezels but that's exactly how it would be in real life, if we were looking through three windows.
So how do we do that? Well, that's not as hard as it looks.
The solution
So we actually have two problems. The first is that we might be using monitors that don't have the same dot pitch (dpi), And we want to take the monitors' bezels into account. If we get rid of these two problems, we end up with a perfect render.
Let's assume again we have three monitors. The primary (center) monitor has a resolution of 1920x1200 while the resolution of the outer monitors is 1024x768.
First of all, we need to consider all three screens as a single screen with the same dot pitch. Because we want the primary (center) monitor to have a pixel perfect image, we want to use the primary monitor's dot pitch for all three monitors. We can usually find the dot pitch of a monitor in its manual, but unfortunately this is usually rounded to the nearest (standard) dpi value and thus not very accurate. We actually will have to measure it ourselves.
In below example I measure in inches. But you can measure in centimeters instead if you like, it doesn't matter for the calculations.
So step 1 would be to measure the width of the primary monitor. Mind you, we need the width of the screen - not the monitor:
Let's say we measure 20 inch (or 51cm) while the screen has a horizontal resolution of 1920px. This means that the screen's dpi is 1920/20 = 96dpi.
In step 2, we need to measure the entire width of the viewport - so all three monitors including the bezels. Mind you, we musn't include the outer bezels:
Say we measured 54.5 inch. That means that if this was one big 54.5 inch wide monitor with 96 dpi, it would have 54.5 x 96 = 5232 pixels horizontally.
In step 3, we need to know the physical width (and height) of the outer monitors. Again, we need the actual screen width, not the entire monitor's width:
Suppose we measure 16 inch. This means that if this was a 96 dpi monitor, it would have a horizontal resolution of 16 x 96 = 1536 pixels. This is the monitor's virtual width.
We do the same thing for the height. Say we measure 12 inch. That means if this was a 96 dpi monitor, it would have a vertical resolution of 12 x 96 = 1152 pixels. This is the monitor's virtual height.
Since in this example both outer monitors are the same, we don't need to measure the second outer monitor (if you use different outer monitors, you will need to measure that monitor as well).
In step 4, we need to figure out the (virtual) width of the two bezels in pixels:
We can either measure them and multiply the measured width by the dpi (96), or if we are using identical outer monitors, we can calculate the width. Either way, we have to make sure that the total (virtual) width in pixels of all three monitors plus the width of the bezels (in pixels) equals the total width found in step 1.
So in this case, 1920 px + 1536 px + 1536 px + virtual width left bezel + virtual width right bezel must equal 5232 px. If you measured the bezels, this probably means you will have to add/substract a few pixels to the measured width to make sure it adds up to the right value.
Since we use identical outer monitors in this example, we can simply calculate the width of a bezel:
Bezel width = ( 5232 - (1920 + 1536 + 1536) ) / 2 = 120 px
Now we have everything we need to manually create a SoftTH config file (config.SoftTHconfig), and we put it all together in step 5:
A) Horizontal resolution primary monitor: 1920 px
B) Vertical resolution primary monitor: 1200 px
C) Width viewport: 5232 px (step 2)
D) Height viewport: 1200 px (vertical resolution primary monitor)
E) Virtual width left outer monitor: 1536 px (step 3)
F) Virtual height left outer monitor: 1152 px (step 3)
G) Virtual width right outer monitor: 1536 px (step 3)
H) Virtual height right outer monitor: 1152 px (step 3)
I) Virtual width bezel #1: 120 px (step 4)
J) Virtual width bezel #2 120 px (step 4)
So this is how we use these values in config.SoftTHconfig:
In section main:
In section head_1 (assuming that head_1 is your left monitor):
in section head_primary:
In section head_2 (assuming that head_2 is your right monitor):
And there you have it. A perfect render over three monitors.
Now I have made a few assumptions here. First of all, I made the assumption all three monitors are lined up at the top. If they are not, then you will need to measure the distance between the top of the primary monitor, and the top of the outer monitors and offset the vertical values in the config file by the calculated virtual pixel distance.
The other assumption I have made, is that your center monitor is the largest of the three.
But no matter what your setup is, you should be able to use above theory to create the perfect setup. And don't think for one second it isn't worth it. You will not be disappointed. The result is absolutely amazing and feels/looks much more natural and realistic.
Enjoy!
A few weeks ago, quite by accident I stumbled upon SoftTH. I always wanted to "triplehead" my system but I didn't want to spend a lot of money on an extra videocard to run them in SLI. Around the same time, a friend also gave me two old 19" Samsung monitors so this was the perfect time to try out triplehead through software. I bought a cheap used Geforce 7900 GS and got going with SoftTH.
SoftTH automagically creates a config file for you to use. It simply adds up the resolutions of your monitors and uses that as the total resolution for your game. And although this works and looks good, with just a little extra effort you can actually make it look a lot better!
Problem with the default approach
The problem with the standard approach is that it does not take into account the physical size of your monitors, nor does it take into account that your monitors have bezels. Let me try to explain that with a few images.
First, let's assume you have three monitors. Your primary monitor (the one in the middle) is 1920 pixels wide while the monitors on the left and right are both 1024 pixels wide (I've chosen such a big difference between the size of the monitors on purpose because it perfectly illustrates the problems you will encounter). What most people do (and what SoftTH does by default), is simply add up these three values. So the total width of your game's viewport would become 1920 + 1024 + 1024 = 3968 pixels.
This view is then split up and sent to your monitors as follows:
This works but there are a few problems with this approach. Suppose your three monitors look like this:
Even though your primary monitor has almost twice as much pixels horizontally than the monitors on the left and right (1920px vs 1024px), those monitors are almost the same width physically as your primary monitor. So how does it look when we superimpose the three parts of the main view on top of these monitors?
So even though the monitors on the left and right monitor are almost as wide as your primary monitor, they spread out 1024 pixels of the original image over this width while the center monitor spreads out 1920 pixels. This means that the image left and right will be stretched horizontally (quite a bit actually). Also, since the outer monitors are less high, the image is squashed vertically.
This is caused because the monitors have a different dot pitch (the primary monitor packs a lot more pixels per inch than the outer two monitors).
Another problem is that we don't take the bezels of each monitor into account. Let's use a simple image to illustrate this problem:
And for argument's sake, this time let's use three equally sized monitors and spread the image over these three monitors:
Looks weird, doesn't it? The red lines no longer look attached, and the green shapes look awefully distorted. That's what happens if you simply split the original image in three and render them as if the three screens had no bezels.
How we really want the image rendered, is like this:
Yes, parts of the image are now obscured by the bezels but that's exactly how it would be in real life, if we were looking through three windows.
So how do we do that? Well, that's not as hard as it looks.
The solution
So we actually have two problems. The first is that we might be using monitors that don't have the same dot pitch (dpi), And we want to take the monitors' bezels into account. If we get rid of these two problems, we end up with a perfect render.
Let's assume again we have three monitors. The primary (center) monitor has a resolution of 1920x1200 while the resolution of the outer monitors is 1024x768.
First of all, we need to consider all three screens as a single screen with the same dot pitch. Because we want the primary (center) monitor to have a pixel perfect image, we want to use the primary monitor's dot pitch for all three monitors. We can usually find the dot pitch of a monitor in its manual, but unfortunately this is usually rounded to the nearest (standard) dpi value and thus not very accurate. We actually will have to measure it ourselves.
In below example I measure in inches. But you can measure in centimeters instead if you like, it doesn't matter for the calculations.
So step 1 would be to measure the width of the primary monitor. Mind you, we need the width of the screen - not the monitor:
Let's say we measure 20 inch (or 51cm) while the screen has a horizontal resolution of 1920px. This means that the screen's dpi is 1920/20 = 96dpi.
In step 2, we need to measure the entire width of the viewport - so all three monitors including the bezels. Mind you, we musn't include the outer bezels:
Say we measured 54.5 inch. That means that if this was one big 54.5 inch wide monitor with 96 dpi, it would have 54.5 x 96 = 5232 pixels horizontally.
In step 3, we need to know the physical width (and height) of the outer monitors. Again, we need the actual screen width, not the entire monitor's width:
Suppose we measure 16 inch. This means that if this was a 96 dpi monitor, it would have a horizontal resolution of 16 x 96 = 1536 pixels. This is the monitor's virtual width.
We do the same thing for the height. Say we measure 12 inch. That means if this was a 96 dpi monitor, it would have a vertical resolution of 12 x 96 = 1152 pixels. This is the monitor's virtual height.
Since in this example both outer monitors are the same, we don't need to measure the second outer monitor (if you use different outer monitors, you will need to measure that monitor as well).
In step 4, we need to figure out the (virtual) width of the two bezels in pixels:
We can either measure them and multiply the measured width by the dpi (96), or if we are using identical outer monitors, we can calculate the width. Either way, we have to make sure that the total (virtual) width in pixels of all three monitors plus the width of the bezels (in pixels) equals the total width found in step 1.
So in this case, 1920 px + 1536 px + 1536 px + virtual width left bezel + virtual width right bezel must equal 5232 px. If you measured the bezels, this probably means you will have to add/substract a few pixels to the measured width to make sure it adds up to the right value.
Since we use identical outer monitors in this example, we can simply calculate the width of a bezel:
Bezel width = ( 5232 - (1920 + 1536 + 1536) ) / 2 = 120 px
Now we have everything we need to manually create a SoftTH config file (config.SoftTHconfig), and we put it all together in step 5:
A) Horizontal resolution primary monitor: 1920 px
B) Vertical resolution primary monitor: 1200 px
C) Width viewport: 5232 px (step 2)
D) Height viewport: 1200 px (vertical resolution primary monitor)
E) Virtual width left outer monitor: 1536 px (step 3)
F) Virtual height left outer monitor: 1152 px (step 3)
G) Virtual width right outer monitor: 1536 px (step 3)
H) Virtual height right outer monitor: 1152 px (step 3)
I) Virtual width bezel #1: 120 px (step 4)
J) Virtual width bezel #2 120 px (step 4)
So this is how we use these values in config.SoftTHconfig:
In section main:
[main] ; Use value C and D: renderResolution=5232x1200
In section head_1 (assuming that head_1 is your left monitor):
[head_1] devID=1 ; use values 0 (zero), 0 (zero), E and F: sourceRect=0,0,1536,1152 transportResolution=1536x1152
in section head_primary:
[head_primary] ; The primary (center) monitor doesn't start at 1536 (virtual width of left monitor), but 1536 + 120 (width of bezel #1) = 1656 ; Use values E + I, 0 (zero), A and B: sourceRect=1656,0,1920,1200 ; Use values A and B: screenMode=1920x1200
In section head_2 (assuming that head_2 is your right monitor):
[head_2] devID=2 ; The right monitor starts at 1536 (width left monitor) + 120 (width bezel #1) + 1920 (width center monitor) + 120 (width bezel #2) = 3696 ; use values E + I + A + J, 0 (zero), E and F: sourceRect=3696,0,1536,1152 transportResolution=1536x1152
And there you have it. A perfect render over three monitors.
Now I have made a few assumptions here. First of all, I made the assumption all three monitors are lined up at the top. If they are not, then you will need to measure the distance between the top of the primary monitor, and the top of the outer monitors and offset the vertical values in the config file by the calculated virtual pixel distance.
The other assumption I have made, is that your center monitor is the largest of the three.
But no matter what your setup is, you should be able to use above theory to create the perfect setup. And don't think for one second it isn't worth it. You will not be disappointed. The result is absolutely amazing and feels/looks much more natural and realistic.
Enjoy!
FS2004- FTX GLOBAL 2.0
FS2004- FTX GLOBAL 2.0
Texturas global para seu FS2004 (O original tem apenas texturas para o solo, mas nós adicionamos varias outras)
Melhorias:
Melhorias:
- Solo
- Céu
- Estrelas
- Nuvens
- Água
- Sol
- Lua
- Alguns sons
- Arvores
- Alguns Efeitos
- Brilho (Apenas em PC's mais potentes)
- Entre outros.
Foi notada um pequeno ganho de FPS após a instalação desse
O arquivo contem apenas 1.7GB, enquanto o original contem 3.7GB, isso porque fizemos um auto-instalador, deixando assim BEM mais fácil a instalação.
O arquivo contem apenas 1.7GB, enquanto o original contem 3.7GB, isso porque fizemos um auto-instalador, deixando assim BEM mais fácil a instalação.
IMPORTANTE!
Não é possível efetuar a desinstalação desse programa, por tanto crie um ponto de restauração em seu Windows.clique aqui e veja como fazer
IMPORTANTE!
Caso após a instalação o FS2004 não abra, siga os passos a seguir:
Vá até a pasta rais do FS2004 (C:\Program Files\Microsoft Games\Flight Simulator 9)
Procure, a apague os seguintes arquivos: enbseries.ini e d3d9.dll
Suscribirse a:
Entradas (Atom)