How come OVR-API is still so bad designed after years of iteration?

Without sounding too apologetic for the development team, I'd say because there is a lot of stuff that needs to get done and the team simply needed to launch a version 1. It's easy to want to compare the functionality found in other platform SDKs like iOS or Android and compare them to OVR v1.x. But that would be forgetting that those other SDKs have had 5+ years to mature. They were also a complete mess in their initial releases and missing a lot of functionality we take for granted now.

The OVR and Platform SDKs have a long way to go, but they will get there. I definitely agree it would be nice to see more transparency on upcoming changes (e.g. a roadmap plan such as what Unity has), improved documentation and examples, and a more dedicated developer relations team to answer questions.

Nevertheless, we are very early in VR development and competitive forces (HTC) have pushed all platforms out now, whether they are fully ready or not.

OpenVR is HTCs API for the Vive. It is not 5+ years old, and I think it is very fair to compare them :wink: They have a long way to go, but OVR-API is resting while rearranging their backpack the third time in a row...

Having seen the OpenVR-API and using OVR-API a lot, I see many things are better designed in the OpenVR-API. Latest iterations of OVR-API have seen FrameIndex handling and SwapChain generating changed - but without any real progress.

You can bash on the API all you want, but unless you actually say what progress is from your perspective, it's not very helpful.  Personally I think the API is much cleaner than it was when I started working on it.

It seems they want to make tiny things more convenient (f.e. FrameIndex managed by API), but this is more than useless for most.

The change to FrameIndex was about more than convenience.  Allowing the texture to be fully managed by the API, instead of requiring them to manually increment a value gives one less thing a developer can fuck up.  It's about minimizing pointless potential bugs.  

And for a little bit more convenience at parts already working, 80% of all old demos and tools were not yet adapted to the API changes and 1.3 runtime is not backwards compatible again!

Since 1.3 is the first actual production runtime, your use of the word again is a little specious.  You also seem to be complaining in both directions.  Oculus isn't improving the API enough.  Oculus also isn't maintaining compatibility enough?  Which is it?  Regardless, there's already an existing open source project that re-implements older versions of the API in terms of the 1.3 API, in order to allow prior demos to run, so unless you're talking about pre-0.6 stuff, which means really old demos, I don't see what the problem is.   If you really want to play something that old, contribute to the compatibility DLL project to support even older API versions.  

The problem is they are constantly destroying compatibility without having ANY progress feature wise.

So, did you or anybody else really "fuck up" by the attempt to increment the frameindex? NO!
And did you have problems with the new solution for the FrameIndex, and did I have to find the woraround to fix this again? YES!
https://forums.oculus.com/community/discussion/comment/377315/#Comment_377315
(And if the problem did not really bother you, maybe stop commenting on simply everything!)

So - they FUed everything again and messed with the frameindex just another way, now if you did not commit an initial Swapchain! So now they can change everything again, third time... [at least spec-wise you would have to call commit only at RuntimeXY...]!

Also I brought two examples of possible improvements:
-Capability to disable Timewarp
-Capability to provide Eye-Dependant QuadLayers

Lame from you, first removing this suggestion examples from my quote, and then blaming me this way: "You can bash on the API all you want, but unless you actually say what progress is from your perspective, it's not very helpful."

It is some strange talking from you, putting me in a OVR basher position here, suggesting people the wrong things I have or haven't saied! Also you never seem to have tried the compatibility DLLs. They are just 0.8 and only work with a very little set of 0.8 Software. Also why would you have to break complete compatibility for applications managing their frame-index the old way? Simply export the old method with frameindex managed by the application - if it worked before, it would still work now!

Now I am in a developer-hell again - this time more than ever! Not only constantly changing between incompatible Runtime versions, but also between the old DK2 and the CV1 because I can not even use the CV1 with 0.8 and 1.3 is not backwards compatible.
But I got it, there is a company with a fruit, and for some special people everything this company does it just great - and for some, Oculus VR has become the same now...

In general, breaking backwards compatibility is bad. It's especially bad when the changes aren't really justified and migration isn't explained (no idea really if that's the case here, just saying in general).

But the 0.8 runtime was a beta and was never intended for use with the consumer hardware. The fact that it changed and compatibility wasn't maintained shouldn't be that surprising. That's often the case with beta SDKs.

Why exactly do you need to support 0.8 runtime anyway? Nothing you submit to Oculus for publishing would pass validation without using the 1.3.x runtime.

thewhiteambit said:

The problem is they are constantly destroying compatibility without having ANY progress feature wise.

You can't break compatibility between a dev kit and a consumer product.  That's what dev kits are for, working out the kinks and dealing with developers who are prepared to cope with changes prior to the consumer release.  

So, did you or anybody else really "fuck up" by the attempt to increment the frameindex? NO!
And did you have problems with the new solution for the FrameIndex, and did I have to find the woraround to fix this again? YES!
https://forums.oculus.com/community/discussion/comment/377315/#Comment_377315

Yeah, I don't actually have to do that.  My minimal example works fine if I call ovr_CommitTextureSwapChain just once per frame, right before the submit, and at no other time.  

Also I brought two examples of possible improvements:
-Capability to disable Timewarp
-Capability to provide Eye-Dependant QuadLayers

Yeah, those aren't API changes....  those are feature requests.  No one besides you seems to have a problem with timewarp, so maybe you should consider whether you're doing something wrong, as opposed to asking Oculus implement a feature that only you will use.  As for eye dependent quad layers, well, there's nothing stopping you from compositing in quads to each eye independently.  

It is some strange talking from you, putting me in a OVR basher position here, suggesting people the wrong things I have or haven't saied! Also you never seem to have tried the compatibility DLLs. They are just 0.8 and only work with a very little set of 0.8 Software.

So fix it.  It's open source.  No, I haven't really used it, although I considered creating it at one point, but I'm too busy working on my actual work projects to do something like that.  

Now I am in a developer-hell again - this time more than ever! Not only constantly changing between incompatible Runtime versions, but also between the old DK2 and the CV1 because I can not even use the CV1 with 0.8 and 1.3 is not backwards compatible.

Port all your code to 1.3 and stop looking back.  0.8 was a pre-release dev kit and it's over now.  

Well, I think Oculus has been pretty clear from the last year or two that the beta development SDK/Runtimes would not have long term support. This is not surprising, based on previous SDKs we've released, and we even messaged developers via our blog.

We did, however, commit to supporting the first public 1.0 SDK (actually ended up being 1.3) for the long term. This new SDK should be working with DK2 for at least through the end of the year, and there is no reason I can see that developers should be using old pre-1.0 SDKs at this point in time. If you think the 0.8 works better, then you're probably coding something wrong.

In addition, there have been lots of critical features now available in the 1.3 SDK. If you think there haven't been any improvements, then you haven't looked at it long enough. Most importantly asynchronous timewarp is a huge win for maintaining performance, and was not available on pre-1.0 SDKs. There's also tighter integration with Nvidia/AMD drivers resulting in better reliability and lower latency, among other things. It's honestly a big improvement.

Sorry Cyber "If you think the 0.8 works better, then you're probably coding something wrong"
I DID NOT WRITE THAT - BUT I HAVE TO USE 0.8 AGAINST MY WILL, BECAUSE OCULUS VR DEVELOPMENT IS FU!

I see, nobody at Oculus even trys to get the point! A developer rage seems to start about the stupid way of Oculus VR decisions and it would not be the first company I have seen falling with that attitude!

jherico: We have all our Software working on 0.6 - 1.4! This is becoming way to stupid to even discuss - specially with you always giving stupid comments. You even dares to give me the Help for a Workaround back, I once provided to you about calling ovr_CommitTextureSwapChain first - and let it look as if it was yours!

jherico seems to know you can fix it in "OpenSource-Project", but if the Demo you need to run uses static librarys - like most of them do - you can do nothing about it! The pure existence of an OpenSource project like this is proof of OculusVR doing wrong! And feature-wise there has been no improvement since 0.6 - just other ways to call the same functionality.

BTW, I am not having trouble with timewarp, your assumptions that I have because I want to be able to disable it are really stupid. I and many others need the OPTION (you seem to have a problem with that word, have a look at the meaning!) to disable it were it is just WRONG. There are threads about other people needing it to!

Sorry for the strong words, but users like jherico bring up bad behavior in me. So I am the only one having "problems" with timewarp?
https://forums.oculus.com/developer/discussion/comment/379798#Comment_379798
https://forums.oculus.com/developer/discussion/comment/353769#Comment_353769
https://forums.oculus.com/developer/discussion/33622/how-to-turn-off-atw
https://forums.oculus.com/developer/discussion/comment/367014#Comment_367014

Really, you comment on everything here as if you have no live and do not even remember the threads? People like you make me sick - you do not understand the problem people have in first place, but that does not stop you from giving your stupid comments on everything, does it? Your assumptions I want to disable timewarp because "I have a problem with it" is as stupid as all your other false assumptions!

jherico, maybe you can just stop giving your comments on things you do not even understand, please? You already destroyed enough other threads and stopped people from discussing the topic, f.e. the original timewarp discussion above (367014). You seem to think people are to stupid to understand, but the only person not understanding is you!

With all due respect, if you are using static libraries that are linked against 0.8, isn't the problem with the static libraries that have not updated to use the new sdk version? Is it possible to get those libraries updated somehow in order to get your demos to run again?