07-24-2014 10:07 PM
07-26-2014 10:44 AM
"renderingpipeline" wrote:"rupy" wrote:
the plastic case for DK1 was polled if it should be one for DK2. This setup is getting more and more complicated for developers and consumers. I vote for extended only and each developer fixing portrait mode on their own. Of course you can keep all your stuff but don't force people to install stuff. It should all fit in the games drivers. Config if you want but don't force it on developers, I have my own IPD settings. etc. etc.
Bottom line don't force us into your software chain; oculus is not the only platform we need to cater! I for one have to support VR (not only Oculus), normal screen and Android. Make my job easier!
I think Oculus is going in the right direction here, for costumers it's better if the Rift is not visible as a screen (how to configure this? 2D windows end up on that screen, the OS menu bar (OSX) could end up on that screen, etc etc., also: the games start on the correct screen automatically!). Tracking and distortion can get updated without having to touch the applications.
It's less complicated for the users, just a bit more complex for the developers, but this is fine.
07-26-2014 01:09 PM
"rupy" wrote:
Sure, If it was a standard and properly implemented yes. But there has to be a way to write your own platform and that it doesen't punish you by making your users have to go through loops to get your game running!
07-26-2014 02:50 PM
07-26-2014 09:22 PM
"rupy" wrote:
I vote for extended only and each developer fixing portrait mode on their own.I have my own IPD settings. etc. etc.
07-26-2014 10:58 PM
"deanbeeler" wrote:
It's not easy for Oculus as there would be no way to delegate access to the Rift. It's not easier for developers since they're left on their own to implement much of what will be routine as the hardware kinks are worked out, and it's not easier for users as their configurations are ignored for every single VR app they own.
07-26-2014 11:02 PM
07-26-2014 11:31 PM
"jherico" wrote:
However, it seems like this relatively straightforward functionality is orthogonal to the new (much more fragile and experimental) direct HMD code. The two things shouldn't be tied together in the same service.
07-28-2014 07:50 AM
"deanbeeler" wrote:
Are you attempting to use OpenGL on AMD hardware? With this release that's presently unsupported though it will be in the next update.
07-28-2014 08:25 AM
07-28-2014 08:58 AM
"Afuerg" wrote:
Wait, what???
I'm developing with OpenGL on AMD hardware, so I won't be able to do that until the next update?