load_library_redirect=0 disables nvapi wrapper

[DarkStarSword]

Haven't investigated far enough to determine if this is a bug, or if CryEngine directly loads nvapi from system32. Debug log file from Ryse attached (There is no nvapi_log.txt, since our wrapper did not get loaded): d3d11_log.txt

If this is a CryEngine special (which is one of the few engines where we actually need our nvapi wrapper), maybe we should consider setting the load_library_redirect to 1 by default - is there any known issues with doing so?

Also, I think you mentioned you wanted the default set to 2 in the 1.2 branch? At the moment that still defaults to 0 if it is not in the d3dx.ini:

G->load_library_redirect = GetIniInt(L"System", L"load_library_redirect", 0, NULL);

[bo3b]

Yes, CryEngine does go direct to system32 and bypasses us.

This one, along with other examples, I think demonstrates that wasn't a good idea to set default=0. I'll change it back to default=2, and we can do an exclusion for cases where we need it instead.

For the 1.2 branch, the default specified in the d3dx.ini file (=2) takes precedence over the GetIniInit level, so that would only happen if the d3dx.ini file was missing. Will be better to make them match, but as a general rule I never expect to ship sans d3dx.ini. It's been in there forever, but I'm not a fan of this dual level of 'default', it's just needlessly confusing.

Edit: actually three levels, because we also have the defaults specified in the globals.h. Yucko.

[DarkStarSword]

For the 1.2 branch, the default specified in the d3dx.ini file (=2) takes precedence over the GetIniInit level, so that would only happen if the d3dx.ini file was missing. Will be better to make them match, but as a general rule I never expect to ship sans d3dx.ini. It's been in there forever, but I'm not a fan of this dual level of 'default', it's just needlessly confusing.

I'm more thinking about the case where someone updates a fix to the new d3d11.dll, but keeps their existing d3dx.ini so it is missing any new options.

Edit: actually three levels, because we also have the defaults specified in the globals.h. Yucko.

Yeah. For the most part the defaults in globals will be trumped by the defaults in the ini parser (I don't recall if there are any exceptions off hand). It might be worth adding some sort of mechanism to warn us if we've specified a different default in several locations - something like a build time assertion, but I also don't want to litter the ini parser with any more boilerplate than we have to.

Edit: Maybe a test case where 3DMigoto compares the contents of globals before and after loading the template d3dx.ini and warns of any discrepancies? Or just the differences in globals after loading a blank d3dx.ini compared to the template?