Next bunch of fixes

[TheSHEEEP]

You are a working machine!

[Eugene]

Next pull request is PR #435, https://bitbucket.org/sinbad/ogre/pull- ... aa/commits

◦[D3D11] Enable usage of monitor-less videoadapter for rendering, when results are displayed by another (discrete and integrated for example)
◦[D3D11] Enable "16" and "16 [Quality]" FSAA options on NVidia cards that can do 16xCSAA and 16xQ CSAA but can not 16xMSAA
◦[D3D11] Wrong FSAA options are shown if rendering device is changed but not yet applied
◦[D3D11] Enable enumeration of possible FSAA values over RDP/Simulator

[dark_sylinc]

I reviewed the patch, and was fine, thus I merged it.

However I would like to know about my comment on videomode being null.
Basically I just want to know if it's infrequent enough so that the warning only appears in rare cases (i.e. not many false positives), which could help us identify initialization problems if, in some rare machine, videomode turned out to be null and forcing 32bpp failed too.

[Eugene]

I reviewed the patch, and was fine, thus I merged it.

However I would like to know about my comment on videomode being null.
Basically I just want to know if it's infrequent enough so that the warning only appears in rare cases (i.e. not many false positives), which could help us identify initialization problems if, in some rare machine, videomode turned out to be null and forcing 32bpp failed too.

When monitor is attached to integrated GPU and rendering is performed using discrete GPU - then videoMode == NULL (all video modes are enumerated by iGPU but asked from dGPU). In RDP and/or Simulator scenario matching videomode often could not be found due to the size mismatch. On the other hand, we need video mode only to determine color depth, that is always 32bit in Ogre D3D11 RS, and initial version of Direct3D11 did not support 16bit color depth either, while 32bpp support is mandatory. So, it is probably safe fallback that does not need additional diagnostic.