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.
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.
Presumably this crash is due to a bug in either the Oculus SDK or DirectX itself as changing the order of releasing these objects should not have any effect.
