Graphics card profiles: Difference between revisions

Jump to navigation Jump to search
(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 ==

Navigation menu