Bug fix for #419
Viewport calculations need to take VR eye buffer size into
account. Noticable at the older 100px boundary. Skewing still
exists at newer 8px buffer, but is harder to notice.
Eventually causes pretty bad eye strain, though.
Easily reproduced by setting the buffer to something obscenely
large, such as 2048.
Fixes#338
Create the swap chain without MSAA, and the eye textures
with MSAA. The core issue was using the surface description
for the backbuffer for the DSV on the eye textures which did
not match.
This meethod follows both the oculus and openvr guidance on MSAA -
MSAA is configured on the eye render targets, but not on the swap
chain.
Was previously supplying (major,minor,build) when it is
actuall (product,major,minor).
For example, the 0.5.0 SDK has the following:
```
#define OVR_PRODUCT_VERSION 0
#define OVR_MAJOR_VERSION 5
#define OVR_MINOR_VERSION 0
#define OVR_PATCH_VERSION 1
#define OVR_BUILD_NUMBER 0
```
BREAKING: bgfx::getHMD() now returns a valid pointer
if the VR runtime was initialized. This is different
from existing behavior where getHMD returned NULL until
a bgfx::reset(... BGFX_RESET_HMD) was issued. Applications
must now check HMD::flags for the current state of the VR
runtime. The following code has the code change required:
`const bgfx::HMD* hmd = bgfx::getHMD()
if (NULL != hmd)`
becomes:
`const bgfx::HMD* hmd = bgfx::getHMD()
if (NULL != hmd && 0 != (hmd->flags & BGFX_HMD_RENDRERING))
{
// rendering logic
}`
See the updated examples for details.
This allows applications to create the appropriately
sized back buffer for the HMD device by using the new device
resolution fields HMD::deviceHeight and HMD::deviceWidth.
These values report the pixel resolution of the attached
HMD hardware.
This also allows applications to query the reported HMD
resolution immediately after bgfx::init. This prevents
the device from being cycled which generates rendring
artifacts on startup - namely flashing back to a black
screen and reseting the Health+Warning disaply.
This involves initialization the ovrHmd device on
initialization, but deferring rendering until
postReset has been called. This adds an addiional
memory overhead of 32k to builds defining BGFX_CONFIG_USE_OVR.
The overhead for current builds is ~1.9MB for calls to
ovr_Initialize, so the additional overhead is pretty
trivial (+1.8%)
(XB1) Drops GPU Busy % on spiral from 65% to 20%
(PC) Drops bgfx::d3d11::RendererContextD3D11::commitShaderConstants
CPU usage by 95% (11.21%->0.66%)
(PC) Overall decreases bgfx::d3d11::RenderContextD3D11::submit CPU
usage by another 34% (27.18%->17.90%)
(XB1) Drops GPU Busy % on spiral from 65% to 20%
(PC) Drops bgfx::d3d11::RendererContextD3D11::commitShaderConstants
CPU usage by 95% (11.21%->0.66%)
(PC) Overall decreases bgfx::d3d11::RenderContextD3D11::submit CPU
usage by another 34% (27.18%->17.90%)
When adding sRGB support for the backbuffer render target in D3D11,
the now explicitly specified RTV desc specifies a TEXTURE2D dimension.
For multisampled targets, this needs to be TEXTURE2DMS dimension.
This solves it by branching on the presence of MSAA in the reset flags but
could envisionably be obtained by looking at the desc of the backbuffer.
