I have now integrated 0.5.0.1 RC4 into Dolphin. The important thing to do is make sure that #OVR_DLL_BUILD is defined.
Unfortunately, 0.5.0.1 RC4 seems to be a regression, at least for my particular setup. There are little tracking hiccups that exist that didn't in 0.4.4, features like "Synchronous Timewarp" start fine, but eventually start juddering. When I switch back to 0.4.4, this goes away. I'm also getting a bit of tracking jump on the desk demo (a little hiccup every 15 seconds), and it used to be pretty smooth. Pulsating judder in direct mode is still apparent on most games in Dolphin, unless I change the threading method to a deterministic one. Judder for 2 seconds, smooth for 2 seconds, judder for 2 seconds, smooth for 2 seconds. The Direct Mode judder happened in both 0.4.4 and 0.5.0.1. Here's the most interesting data point I have on the regressions:
------------
Background info: In Dolphin VR, games typically run at 60fps. To get the games running at 75fps, we have two options. One uses timewarp and injects a frame every 4 frames, which gets the frame rate to 75fps. The code looks like this whenever we inject a frame:
ovrFrameTiming frameTime = ovrHmd_BeginFrame(hmd, ++g_ovr_frameindex);
ovr_WaitTillTime(frameTime.NextFrameSeconds - g_ActiveConfig.fTimeWarpTweak);
ovrHmd_EndFrame(hmd, g_eye_poses, &g_eye_texture[0].Texture);
.fTimeWarpTweak can be set on the fly in the GUI by the user.
This test is done in extended mode by the way.
0.4.4 - In a sample game such as Mario Kart Wii, .fTimeWarpTweak can be set to somewhere around 0.0050 to 0.0015 and left there for 30 minutes of gameplay with no issue. Game feels glassy smooth, no noticeable judder.
0.5.0.1 - The game starts okay with this setting. There are no issues until about 3 minutes into the race, where it starts to judder severely. Moving fTimeWarpTweak to a higher range around .0090 to .0060 fixes the issue. This is good again for another 3-5 minutes, until it must be moved up an equivalent amount again. Repeat until .fTimeWarpTweak is set somewhere around ~0.0300 (IIRC) then it must be reset back to between 0.0050 and 0.0015 again. It keeps going like this is a circle.
I also noticed that our other way of generating extra frames (a type of reprojection) also starts fine but gets out of sync in some games now. I feel like something similar is happening, but I don't have a way to adjust the time until the frame is presented.
---------------
If you guys are interested, I think it would be of a lot of benefit for your team to populate Dolphin VR at some point and try to work out some of the judder issues. We have so many different kinds of timings and modes, some glassy smooth, and some juddery. We have both OpenGL and Direct3D, different threading methods (single core, dual core, dual core determinism, gpu determinism), synchronous timewarp, reprojection, direct mode, extended mode, etc. It could provide you with a ton of data points of how different timings and configurations effect the SDK. It's all open source and is fairly easy to get running. I'd totally be willing to help with this too, if you guys are interested. I feel like if the judder in all of Dolphin's modes were fixed, it'd be pretty likely that it'd work in almost any engine.
Display Driver Install: This seems to have gone perfectly for both RC2 and RC4, and still works great with the 0.4.4 games I tried. Good work there!
OpenGL 2D texture crawling bug is still there. I've been building my own modified versions of the SDK to fix this issue. The explanation and the code for the fix can be found here:
viewtopic.php?f=34&t=16910Here's my specs so you don't have to search for them:
OS: Win7 64-bit
GPU: AMD HD7970
Video Drivers: Omega Drivers
CPU: i7-3570K @4.3GHz
Monitor(s): 1x 1080p HDTV + 1x1280x1024 monitor
Connection(s): DK2 plugged in via HD7970 GPU HDMI port, HDTV plugged in via HD7970 GPU HDMI port, monitor plugged in via Intel HD4000 port (lower GPU power usage this way).
Other: N/A
