Forum Discussion
Why is DirectToRift always (?) a separate executable?
Due to the lack of Linux support, I'm not yet familiar with the 0.4.x SDK. So stupid question: Does the DirectToRift feature really require to have multiple executables? At least that is how it looks judging from current demos. It's a bit weird to split something that is more or less a binary setting into two executables, where the setting is hard-coded in each. Especially since Unity-based demos in fact have the possibility to adjust settings within the launcher before entering fullscreen mode. Is there a difference how the executables are linked statically? And if so, how is this supposed to work when using the Rift within non-native environments like the JVM?
11 Replies
- Well, since the direct to rift is a fraction of the size of the normal executable, I assume it is just calling into it, perhaps with some wrapping code.
- I find this a little bit strange, too. It counteracts the easy-to-use-principle of the device. It should basically be this:
- Oculus switched on --> Display on Oculus, mirror undistored left view on monitor
- Else --> Display on monitor only
spyro "spyro" wrote:
I find this a little bit strange, too. It counteracts the easy-to-use-principle of the device. It should basically be this:
- Oculus switched on --> Display on Oculus, mirror undistored left view on monitor
- Else --> Display on monitor only
spyro
I generally agree, except mirroring may hurt performance, so not everyone will want that.
Can we even detect whether the Rift is switched on though? If so, how?- So, will upcoming games need there own special EXE, too? So you will never able to switch from VR to a normal display and back without restarting the whole game?
spyro "spyro" wrote:
So you will never able to switch from VR to a normal display and back without restarting the whole game?
I personally find this an important requirement, that users should be able to seamlessly go in and out of VR mode.- The DirectToRift stuff is, as far as I am aware, simply a wrapper that forces Unity games hook into the Oculus service at startup.
You can support Direct HMD mode in the same binary if you're writing directly against the SDK, and I expect engines with better Rift integration (and maybe even future Unity versions) to not require it either. - Looks like legacy support for games that don't yet support DirectToRift.
- Glad to read that, thanks. :)
- What *_DirectToRift.exe basically does is this:
1. Try to detect Rift
2. Start the non-DirectToRift exe using detected values for screen width, height and adapter in suspended state
3. Inject a DLL (OculusPlugin.dll) into the non-DirectToRift exe's process using CreateRemoteThread()
4. Resume execution of the non-DirectToRift exe - A lot of people are experiencing that the Oculus is not working due to their screen setup. Because of this they can make it work by running the alternative executable file.
ex
So the alternative file is very useful for a lot of people... In the final version I would expect the alternative file being removed as most of the challenges users and developers has faced is solved.
