Support for VIVE/eMR/etc. still in the works.
- gilesgoat
- Sheepie Whore

- Posts: 27258
- Joined: Wed Sep 03, 2003 7:54 am 0
- Location: Monfalcone, Italy
- Contact:
Support for VIVE/eMR/etc. still in the works.
So while "jumping jobs" between things I can tell you that MAVOL1 with support for VIVE/MR/Oculus ( obviously ) and experimental Looking Glass ( if you have a powerful enough GPU ) EXISTS and MAVOL1 is done.
But Jeff wants to have it all together with Polybius so that's still in work, this is not just "added support" as in "you touched a few sources there and there" this is "a complete migration into a totally NEW system/framework" that in essence meant I had to literally go ONE BY ONE through ALL the sources and do "significant cleanup" to *ALL* of them.
The concept is ( or should be ) that "even more/better than before" I do have now a "core game logic" that is "fully disconnected" from "machine dependencies" and a set of "modular bits" that are machine and non-machine independent that should speed up further games development/porting.
I could go for too long explaining details of what I've been doing that anyway for you should be almost "irrelevant" but let's say "the final product" has :
- better graphic support
- better controller support
- code easier to maintain
Now Polybius really to date I'd say "it's the most complex thing LS maybe has ever done" it's TONS of code/shaders/things, the idea at the time was that Polybius
also had to be "the new thing to go on" it's "even a bit too more complicated", took me almost 2 weeks to sort of the "neon modules" alone, there are really many just to go on and check things and replace this with that and sort of dependencies and crap like that.
Also this thing is 'quite a bit of a bastard' in terms of 'testing and checking' because 'you can not do it a bit at the time', I mean you can't see something works until ALL is complete and there's no other way to test it.
Now I may get to the point "something could start to run" but I have 100 and something VS/PS shaders to sort out as well.
Useless I say in doing this I found "mini and less mini" bugs there and there I think I finally fixed.
So while MAVOL1 in in FQA again, I will try to "not to think about it" while working on this can't wait mysef to see something appearing on screen again.
But yes it's in the work, it always been, it's not forgotten.
But Jeff wants to have it all together with Polybius so that's still in work, this is not just "added support" as in "you touched a few sources there and there" this is "a complete migration into a totally NEW system/framework" that in essence meant I had to literally go ONE BY ONE through ALL the sources and do "significant cleanup" to *ALL* of them.
The concept is ( or should be ) that "even more/better than before" I do have now a "core game logic" that is "fully disconnected" from "machine dependencies" and a set of "modular bits" that are machine and non-machine independent that should speed up further games development/porting.
I could go for too long explaining details of what I've been doing that anyway for you should be almost "irrelevant" but let's say "the final product" has :
- better graphic support
- better controller support
- code easier to maintain
Now Polybius really to date I'd say "it's the most complex thing LS maybe has ever done" it's TONS of code/shaders/things, the idea at the time was that Polybius
also had to be "the new thing to go on" it's "even a bit too more complicated", took me almost 2 weeks to sort of the "neon modules" alone, there are really many just to go on and check things and replace this with that and sort of dependencies and crap like that.
Also this thing is 'quite a bit of a bastard' in terms of 'testing and checking' because 'you can not do it a bit at the time', I mean you can't see something works until ALL is complete and there's no other way to test it.
Now I may get to the point "something could start to run" but I have 100 and something VS/PS shaders to sort out as well.
Useless I say in doing this I found "mini and less mini" bugs there and there I think I finally fixed.
So while MAVOL1 in in FQA again, I will try to "not to think about it" while working on this can't wait mysef to see something appearing on screen again.
But yes it's in the work, it always been, it's not forgotten.
Giles the billy goat
"Baa"
"Baa"
- gilesgoat
- Sheepie Whore

- Posts: 27258
- Joined: Wed Sep 03, 2003 7:54 am 0
- Location: Monfalcone, Italy
- Contact:
Re: Support for VIVE/eMR/etc. still in the works.
It's finally starting to almost be ready for another "Beta" on STEAM.
I can easily say this been "one of the most complex recent works I've done" ( and time consuming ) and I dare to say "definitely" the LAST OpenGL thing I am going to make (*).
This been not just "a port", well it did start like that it turned out ALMOST in "a complete re-make of Polybius".
The intent was to put all this "into a new framework/perspective" "cleaning up all the old shit" and stuff like that.
Turned out to be "a much more massive work than initially expected", there was lot of old stuff/etc. in it.
There has NOT been ONE source I did not have to re-touch/re-look/re-learn how it was working/etc.
You always start with something that works ... then you extend a bit .. then you make it better .. then you find out you needed something else ..
.. then you end up at some point "you started with a small car, it ends with wings/etc. looks like an airplane, kinda flies like an airplane but it never been an airplane in the first place but has to work now like an airplane and a car and something else".
Quite a number of "doh" moments, a number of "why on Earth I ever did that ?" or "look at that shit of code over there" or "this code says it does X but in reality does Y and the comment never been changed" and stuff like that.
Overall this experience says :
- OpenGL is really "semi crap", done its time, done it well for what it was but now "something else" is needed
- OpenVR "does things good enough" but NOT as good as they could be, I can see why there's some "frown" about "one size fits many" thing.
- After 2 .. 3 projects you should start re-looking ALL your code ( and do it all anew )
- NEVER be afraid to trash things and start all over again
- the only 2 things that "kill" you and all this are time & money ( that you don't have enough to keep working on improvements )
- development NEVER ends, the code is NEVER as good as it could be, the stuff is NEVER as well done as it should be, bugs NEVER stop
- keep on truckin', you'll die anyway, there's no point to worry, it's only worrying what you could have done and you have not done for the fear of death
There are already "plans in place" for "a totally new - more psychedelic - thing/framework/system"
Anyway it's coming along,"soon out in beta" should be working OK with Vive and the rest.
Also VIVE/etc. .. sorry to say "after much watching" I am still thinking "the two best systems" are Oculus and PSVR, Oculus is still the "overall best looking feeling", and PSRV the "overall simpler to grab once set up", Oculus Quest is "the top so far" best of both worlds.
I can easily say this been "one of the most complex recent works I've done" ( and time consuming ) and I dare to say "definitely" the LAST OpenGL thing I am going to make (*).
This been not just "a port", well it did start like that it turned out ALMOST in "a complete re-make of Polybius".
The intent was to put all this "into a new framework/perspective" "cleaning up all the old shit" and stuff like that.
Turned out to be "a much more massive work than initially expected", there was lot of old stuff/etc. in it.
There has NOT been ONE source I did not have to re-touch/re-look/re-learn how it was working/etc.
You always start with something that works ... then you extend a bit .. then you make it better .. then you find out you needed something else ..
.. then you end up at some point "you started with a small car, it ends with wings/etc. looks like an airplane, kinda flies like an airplane but it never been an airplane in the first place but has to work now like an airplane and a car and something else".
Quite a number of "doh" moments, a number of "why on Earth I ever did that ?" or "look at that shit of code over there" or "this code says it does X but in reality does Y and the comment never been changed" and stuff like that.
Overall this experience says :
- OpenGL is really "semi crap", done its time, done it well for what it was but now "something else" is needed
- OpenVR "does things good enough" but NOT as good as they could be, I can see why there's some "frown" about "one size fits many" thing.
- After 2 .. 3 projects you should start re-looking ALL your code ( and do it all anew )
- NEVER be afraid to trash things and start all over again
- the only 2 things that "kill" you and all this are time & money ( that you don't have enough to keep working on improvements )
- development NEVER ends, the code is NEVER as good as it could be, the stuff is NEVER as well done as it should be, bugs NEVER stop
- keep on truckin', you'll die anyway, there's no point to worry, it's only worrying what you could have done and you have not done for the fear of death
There are already "plans in place" for "a totally new - more psychedelic - thing/framework/system"
Anyway it's coming along,"soon out in beta" should be working OK with Vive and the rest.
Also VIVE/etc. .. sorry to say "after much watching" I am still thinking "the two best systems" are Oculus and PSVR, Oculus is still the "overall best looking feeling", and PSRV the "overall simpler to grab once set up", Oculus Quest is "the top so far" best of both worlds.
Giles the billy goat
"Baa"
"Baa"
- The Gardner
- Baaa!

- Posts: 117
- Joined: Mon Aug 17, 2009 6:34 am 0
Re: Support for VIVE/eMR/etc. still in the works.
I don't really know much about this, but isn't OpenGL still the primary cross-platform, low-level, 3D acceleration API? Is there another one, aside from DirectX? Or are you planning to go with something higher level like Unity or Unreal? I suppose those must include something for custom shaders these days.OpenGL is really "semi crap", done its time, done it well for what it was but now "something else" is needed
- gilesgoat
- Sheepie Whore

- Posts: 27258
- Joined: Wed Sep 03, 2003 7:54 am 0
- Location: Monfalcone, Italy
- Contact:
Re: Support for VIVE/eMR/etc. still in the works.
No I am planning to go "even more low level", the thing that seems "most are going for" is VULKAN nowadays.The Gardner wrote:I don't really know much about this, but isn't OpenGL still the primary cross-platform, low-level, 3D acceleration API? Is there another one, aside from DirectX? Or are you planning to go with something higher level like Unity or Unreal? I suppose those must include something for custom shaders these days.OpenGL is really "semi crap", done its time, done it well for what it was but now "something else" is needed
The thing is the double thing will *sigh* always remaing, MS will keep going in the direction of DX12 and such, the rest of the world seems it's VULKAN.
Vulkan seems also to be "the new API supported by Oculus that will ditch OpenGL/ES".
Giles the billy goat
"Baa"
"Baa"
- gilesgoat
- Sheepie Whore

- Posts: 27258
- Joined: Wed Sep 03, 2003 7:54 am 0
- Location: Monfalcone, Italy
- Contact:
Re: Support for VIVE/eMR/etc. still in the works.
<RANT MODE>
.. I am getting to the following conclusions ..
1. OpenGL is CRAP
2. OpenVR is semi-crap ( well, see '3' )
3. vr::VRCompositor()->WaitGetPoses() WHAT THE FUCK MAN ! WHAT THE FUCK !!
4. VSYNCH ( does not exits ), see HACKs/whatever and notes in the sources dating back to too long ago
5. Tried the latest version of OpenVR still issues
So '3' 'eats ms like it wants at random' and NOBODY seems to really know why/what would be the best thing to do.
</RANT MODE>
So with lot of measure, this and that .. hell knows what is going inside that WaitGetPoses() (*) also I "don't get" those "yes you should render in 11.1 ms" but because such WaitGetPoses() consumes SO much time by its own plus time there and there you should maybe render in 6 ms or even less because we loose so much time somewhere else ..
I am starting to learn that "if you see a DEMO CODE that shows a STATIC SCENE, BEWARE, BEWARE A LOT about it !!"
Yes .. with a static scene works very well .. now "make those cubes move" that I am going to have a laugh ...
After MUCH battling with QueryPerformanceCounter(×tamp_e); and various this and that and " a glFlush() someone placed in a place nobody knows why but heck do not touch it or it's even worse", documentation that says literally "DO OR this way OR that way" and to code DOES NOT do like that but if you do like the doc says ( which involves calling a thing first instead that after ) goes even worse ...
(*) it called 'wait' because 'more correctly' ( found after MUCH forum searchings ) someone explains "it actually waits to synch and get you can not avoid to call it at all", pity this is not written in the documentation.
So after much this and that I got into "something that more or less works" ..
Do I do the way they tell me to do ? YES .
Does it work very well ? NO .
Do I understand why ! NO and nobody else seems to know !
Anyway "you get what you get" ..
It's frustrating ...
.. I am getting to the following conclusions ..
1. OpenGL is CRAP
2. OpenVR is semi-crap ( well, see '3' )
3. vr::VRCompositor()->WaitGetPoses() WHAT THE FUCK MAN ! WHAT THE FUCK !!
4. VSYNCH ( does not exits ), see HACKs/whatever and notes in the sources dating back to too long ago
5. Tried the latest version of OpenVR still issues
So '3' 'eats ms like it wants at random' and NOBODY seems to really know why/what would be the best thing to do.
</RANT MODE>
So with lot of measure, this and that .. hell knows what is going inside that WaitGetPoses() (*) also I "don't get" those "yes you should render in 11.1 ms" but because such WaitGetPoses() consumes SO much time by its own plus time there and there you should maybe render in 6 ms or even less because we loose so much time somewhere else ..
I am starting to learn that "if you see a DEMO CODE that shows a STATIC SCENE, BEWARE, BEWARE A LOT about it !!"
Yes .. with a static scene works very well .. now "make those cubes move" that I am going to have a laugh ...
After MUCH battling with QueryPerformanceCounter(×tamp_e); and various this and that and " a glFlush() someone placed in a place nobody knows why but heck do not touch it or it's even worse", documentation that says literally "DO OR this way OR that way" and to code DOES NOT do like that but if you do like the doc says ( which involves calling a thing first instead that after ) goes even worse ...
(*) it called 'wait' because 'more correctly' ( found after MUCH forum searchings ) someone explains "it actually waits to synch and get you can not avoid to call it at all", pity this is not written in the documentation.
So after much this and that I got into "something that more or less works" ..
Do I do the way they tell me to do ? YES .
Does it work very well ? NO .
Do I understand why ! NO and nobody else seems to know !
Anyway "you get what you get" ..
It's frustrating ...
Giles the billy goat
"Baa"
"Baa"
- p-saurus
- Baaaaa!

- Posts: 1282
- Joined: Wed Apr 24, 2002 8:56 pm 0
- Yahoo Messenger: p_saurus
- Location: Tucson, Arizona
- Contact:
Re: Support for VIVE/eMR/etc. still in the works.
I liked Polybius in 2D, but now that the beta is out and I can play it on my WMR headset, I'm obsessed. This is the second "killer app" (the other one being Moss) that has made me happy I bought the headset.
I know it's been a crazy amount of work to get it working. Thank you!
I know it's been a crazy amount of work to get it working. Thank you!
- gilesgoat
- Sheepie Whore

- Posts: 27258
- Joined: Wed Sep 03, 2003 7:54 am 0
- Location: Monfalcone, Italy
- Contact:
Re: Support for VIVE/eMR/etc. still in the works.
I am still chasing the story of that 'little glitch' because overall I am "enough satisfied" of this "beta" ( it's not perfect yet I know ).p-saurus wrote:I liked Polybius in 2D, but now that the beta is out and I can play it on my WMR headset, I'm obsessed. This is the second "killer app" (the other one being Moss) that has made me happy I bought the headset.
I know it's been a crazy amount of work to get it working. Thank you!
This is definitely "the biggest OpenGL work I've done so far", it uses almost "everything" ( the only thing not used are compute shaders ), from ps/vs/gs/instancing/msaa/various degrees of this and that, attempted optimisations/buffering mechanisms/etc. makes you realise how different OpenGL are from DX.
I have to say "I think DX are better" or at least they give the impression they are , I had to go through some "weird hoops and loops" to have our stuff working the way it works because of what it does ( and because the fact in its first iteration it was done on DX rather than GL ) .
I can't wait to start moving on something "much more evolved", Vulkan, because I am tired to jump through loops for "doing things the way they should not really be done but that's all the API gives you".
With VR we got the stage where "enough is never enough", only the max you can get is the "enough" to stop you.
You think you go 90 Hz, this is like you are playing a "standard game" at 180Hz because you have to render everything twice, the GPU is really the limit, enough is never enough for proper VR.
I like Moss as well, BUT had to be said got VERY UNsatisfied of the ending
I mean it's all good, all good, all ok, all vaffanculo ( some puzzles are bastard ), all ok .. you get to the end and .. .. and .. erm .. erm .. but .. erm .. they could have spent "5 more mins" in doing something a bit better IMHO.
Said that the rest of the game is very good in VR !
Anyway glad you are enjoying it and worries not "the work never stop", we are always thriving for "perfection" here and the code is NEVER perfect
".. our work is NEVER OVER .. " - Daft Punk
Giles the billy goat
"Baa"
"Baa"
Re: Support for VIVE/eMR/etc. still in the works.
I cant get polybius to run on my index! It was working fine before but now will only launch in 'theatre mode' I tried the beta also and tried regular mode and oculus mode but when i hit the vr mode in the launch & resolution box steam vr theatre closes and goes back to home!
I get the error 'cannot initialise oculus rift, going NON-vr mode'
I get the error 'cannot initialise oculus rift, going NON-vr mode'
- p-saurus
- Baaaaa!

- Posts: 1282
- Joined: Wed Apr 24, 2002 8:56 pm 0
- Yahoo Messenger: p_saurus
- Location: Tucson, Arizona
- Contact:
Re: Support for VIVE/eMR/etc. still in the works.
Have you tried opting out of the Beta? I couldn't get it to run on my Windows MR headset until I opted out of the Beta and downloaded the other version.Nixie wrote:I cant get polybius to run on my index! It was working fine before but now will only launch in 'theatre mode' I tried the beta also and tried regular mode and oculus mode but when i hit the vr mode in the launch & resolution box steam vr theatre closes and goes back to home!
I get the error 'cannot initialise oculus rift, going NON-vr mode'
Re: Support for VIVE/eMR/etc. still in the works.
Yeah I tried the beta after it stopepd working normally. I've since tried both over and over but get the same issue 
