A number of changes were made to the API since the 0.6 release.
The most significant change is the addition of the Direct Driver Mode and the removal of Extended Mode.
Direct Driver Mode uses features of NVIDIA Gameworks VR or AMD LiquidVR to render directly to the HMD. If the installed GPU does not support NVIDIA Gameworks VR or AMD LiquidVR, it uses Oculus Direct Mode.
The removal of the legacy Extended Mode means that users can no longer manage the Oculus Rift as an extended monitor, which will affect some games. Additionally, Standalone Mode (which uses the Oculus Rift as the only display device) is no longer supported.
This release represents significant changes to the runtime. Changes include:
The runtime now supports Direct Driver Mode. Direct Driver Mode requires the latest GPU drivers:
This release represents a major revision of the API. Changes to the API include:
The following are known issues:
Prior to Oculus SDK 0.7, the Oculus compositor treated all eye texture formats as sRGB color textures, even when marked otherwise. As a result, when applications provided sRGB-correct textures (e.g. DXGI_FORMAT_R8G8B8A8_UNORM_SRGB and GL_SRGB8_ALPHA8), the results would look wrong. The compositor now requires all provided textures to be labelled with correct sRGB format. If an application uses an eye texture format such as DXGI_FORMAT_R8G8B8A8_UNORM, this will cause the results in the HMD display to look too bright even though the mirror texture visible on the desktop window might look normal.
There are a few ways to address this, but we will describe two of them. The first ensures that the application and Oculus compositor correctly manage sRGB. The second is for existing applications that want to make the fewest rendering changes.
The recommended method requires you to render in an sRGB-correct fashion, and then set the texture format accordingly. For D3D11, most applications use DXGI_FORMAT_R8G8B8A8_UNORM_SRGB instead of DXGI_FORMAT_R8G8B8A8_UNORM. For OpenGL, the correct format is GL_SRGB8_ALPHA8, but you have to make sure that the application calls glEnable(GL_FRAMEBUFFER_SRGB).
In some cases, making an existing application sRGB-correct might not be straightforward. There are some implications, including sRGB-correct diffuse texture sampling, linear-space and energy-conserving shading, and GPU-accelerated gamma read/write technology that are available in any modern GPU. We expect some applications that are gamma-correct do not rely on GPU read/write conversions and have opted to handle the conversions via shader math such as applying pow(2.2) and its inverse. This approach requires some finesse which is explained in the second method.
Although not recommended, the least resistance method allows the application to keep its rendering as-is while only modifying the calls to ovr_CreateSwapTextureSetD3D11() for D3D11 rendering or modifying the GL context state for OpenGL rendering.
Since each render API requires different approaches, a detailed explanation is provided in the function declarations of both ovr_CreateSwapTextureSetD3D11() and ovr_CreateSwapTextureSetGL() in OVR_CAPI_D3D.h and OVR_CAPI_GL.h respectively. For this purpose and other potential uses, we introduced a ovrSwapTextureSetD3D11_Typeless flag for D3D11 that allows the application to create DXGI-specific typeless textures that can have a ShaderResourceView that does not have to be the same as the RenderTargetView. Keep in mind that this also applies as a mirror texture creation flag. For OpenGL, the application can simply drop the glEnable(GL_FRAMEBUFFER_SRGB) while still creating a swap texture set with the format GL_SRGB8_ALPHA8.
For more information, refer to the "Swap Texture Set Initialization" section and the code samples provided in the SDK.