20,741
edits
(Created page with "{{Stub}} == Ideas == {{FGCquote |1= The only thing I want to do is detect the video card and based on the GL renderer name turn on ALS (or not), turn on water shader (or not)...") |
|||
| Line 17: | Line 17: | ||
}} | }} | ||
== Approach == | |||
{{FGCquote | |||
|1= that's basically a form of feature-scaling: [[Feature Scaling]] | |||
Like you say, we could expose most of the GL* info at the property tree level, and then use Nasal/propertylist rules to dynamically toggle features on/off during startup, i.e. sort of a better customiable initialization sequence. | |||
The easiest way to implement something like this would be supporting "data overlays", i.e. in the form of fgfsrc/preferences.xml files that are stored in $FG_ROOT/Profiles and automatically overlaid over default startup options once a certain GL vendor/make and GPU model are detected, e.g. by having: | |||
* $FG_ROOT/GraphicsProfiles/NVIDIA | |||
* $FG_ROOT/GraphicsProfiles/AMD-ATI | |||
* $FG_ROOT/GraphicsProfiles/INTEL | |||
* $FG_ROOT/Graphics Profiles/MATROX | |||
* $FG_ROOT/GraphicsProfiles/Other | |||
Each vendor-specific sub-folder could then contain graphics related xml overlays that will be loaded on top of the default startup options (i.e. those not customized/overriden by the user) - what that means is that the current hard-coded default settings in fg_init.cxx would need to be dynamically loaded during startup using the APIs from props_io.cxx. | |||
The corresponding startup profiles could be either conventional PropertyList XML files, or support embedded Nasal/property-rule blocks to provide support for regex-matching etc. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=275306#p275306 | |||
| title = <nowiki>Re: Review of FG on reddit: xpost</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Feb 7th, 2016 | |||
| added = Feb 7th, 2016 | |||
| script_version = 0.25 | |||
}} | |||
}} | |||
== Objective == | == Objective == | ||