SteamVR on SteamOS?

[Herbivorous Cyborg]

Does/will this game support SteamVR on Linux/SteamOS? SteamVR for Linux is currently in beta and I would love to see this game support it. Once it leaves beta I will be permanently eliminating Windows.

[inwerp]

It does or it will :)
Atm my brother Dmitry is very busy on his new job/moving to another state and since we bought just one Vive HMD, ii can't really test it myself(steamVR won't work with oculus for sure). :(
If it does not work, try --steam_openvr=1 launch option.
Polynomial was developed on linux, so it won't take much time to patch it for VR support as well. We simply missed steamVR Linux beta release because of family and job stuff.

[dmytryl]

There's atually a severe technical issue with the SteamVR for Linux beta. It lacks any practical OpenGL interoperability (i.e. it is extremely slow at getting OpenG-originating information to the display). Polynomial 2 is an OpenGL game (development started before Vulcan).

We simply have to wait until NVidia provides a function which lets you mark OpenGL memory as readable by Vulcan. They do already have a function that works in the other direction.

[chrix]

Khronos is working for an OpenGL extension for that from what I heard.

[chrix]

The EXT_memory_object extension is now released and implemented in drivers and SteamVR is making use of it fully transparently, see http://steamcommunity.com/gid/103582791435040972/announcements/detail/3011070884003755867

[dmytryl]

BRB recompiling edit: i have some other stuff in the works which is not ready so may take a bit of time to backport stuff.

[chrix]

Thanks, I'm always up for testing alphas and betas on Archlinux and my RX 480.

[dmytryl]

I uploaded a new build, beta branch "linux_vr_alpha" . I can't test it myself right now but it "should" work.

[chrix]

It works mostly.

Some of the shaders use an OpenGL compatibility profile, that's not really supported on mesa, but it looks right with the MESA_GL_VERSION_OVERRIDE=4.5COMPAT MESA_GLSL_VERSION_OVERRIDE=450 variables to use a fake compatibility profile.

Next was the game window opening in fullscreen on the vive display (extended mode). Maybe you can set it to windowed by default in VR mode, especially since the window doesn't really show anything but some text by default.

It looks like motion controllers need to be enabled in the controller settings. There's only "First Test" available, which makes the Vive controllers appear and you can wave them around, but none of the buttons do anything.

Mouse and Keyboard controls in the game window work and so it can be seen that rendering seems to fully work too. I hope you don't have ancient header files and run into https://github.com/ValveSoftware/SteamVR-for-Linux/issues/35

[dmytryl]

Thanks for testing! I'll make some changes, yeah I think I should indeed default to windowed for VR mirror. Compatibility profile: Yeah, parts of the engine are rather old, especially the GUI subsystem...

I currently have my Vive disassembled because I'm working on a hardware modification (that I will share in due course if it works), so I can't test it properly.

re: controllers, I actually updated OpenVR api version to 1.0.9 in that beta, I don't know if that may have broken something.

[dmytryl]

Indeed, I have just the bug described in your github thread, and that's with the latest version of the api, 1.0.9 . I checked in the headers , https://github.com/ValveSoftware/openvr/blob/master/headers/openvr_capi.h#L1336 , there's no #pragma pack around it, but there is in C++ api , https://github.com/ValveSoftware/openvr/blob/master/headers/openvr.h#L890

I accidentally locked myself out from my github account for the day by trying to guess my password, I'll submit an issue sometime later.

I'll make a new build shortly. This bug is rather worrying because there is a lot of other structures lacking pack pragmas, and some pieces having pack pragma with alignment 8 (so it's not clear it's safe to just pack everything at 4). The reason I have to use C api is that under Windows, C++ API works only with Microsoft Visual C++ (they neglected to add call specifications that would make it cross compiler compatible).

[Not Root]

Originally posted by dmytryl:

Indeed, I have just the bug described in your github thread, and that's with the latest version of the api, 1.0.9 . I checked in the headers , https://github.com/ValveSoftware/openvr/blob/master/headers/openvr_capi.h#L1336 , there's no #pragma pack around it, but there is in C++ api , https://github.com/ValveSoftware/openvr/blob/master/headers/openvr.h#L890

Ah, got just a tiny taste of my personal hell, did you? :)

This is what I've tried to do to get around it, and I'm not even sure if it works: https://github.com/roothorick/WineOpenVR/blob/master/src/repacked_structs.h

[dmytryl]

Originally posted by roothorick:

Originally posted by dmytryl:

Indeed, I have just the bug described in your github thread, and that's with the latest version of the api, 1.0.9 . I checked in the headers , https://github.com/ValveSoftware/openvr/blob/master/headers/openvr_capi.h#L1336 , there's no #pragma pack around it, but there is in C++ api , https://github.com/ValveSoftware/openvr/blob/master/headers/openvr.h#L890

Ah, got just a tiny taste of my personal hell, did you? :)

This is what I've tried to do to get around it, and I'm not even sure if it works: https://github.com/roothorick/WineOpenVR/blob/master/src/repacked_structs.h

I ended up using the struct from C++ api...

re: your code, interesting, why in the world would they pack it at 4 under Linux when default is 8? Or does it pack at 4 by default under 32 bits and they made it 4 under 64 bits as well?

By the way, out of curiosity, how do you deal with visual studio's calling conventions in C++ api? It's kind of funny how this "open" API entirely lacks either specifications or an open source implementation, but since headers are on github every user thinks it's open source.

[Not Root]

Originally posted by dmytryl:

re: your code, interesting, why in the world would they pack it at 4 under Linux when default is 8? Or does it pack at 4 by default under 32 bits and they made it 4 under 64 bits as well?

From what I can tell, packing was not originally specified for these, they found their mistake later, and explicitly specified the old packing so they wouldn't have similar unpleasant surprises in the future. Look at the blame on openvr.h, you can find where they added those pragmas which hints at what happened. I really don't understand why -- they're already not caring at all about ABI, doing their versioning thing, just change the packing, bump the ABI versions and call it a day. Well, in any case, we're stuck with it.

You want more fun? There's a handful of overlay-related structs that don't have explicit packing :) Here we go again!

By the way, out of curiosity, how do you deal with visual studio's calling conventions in C++ api? It's kind of funny how this "open" API entirely lacks either specifications or an open source implementation, but since it's on github every user thinks it's open source.

Yeah, that was fun. Ultimately, GCC actually did most of the work. Surprisingly enough, it can cleanly mix the two if you set the right attributes (ms_abi / sysv_abi / thiscall etc).

It doesn't QUITE get it right though; it puts the this-pointer and the return value pointer (for returning a struct/class/etc) in the wrong order/registers/etc, requiring the hairy "ERP hack" explained in WOVR's README.

[EndeavourAccuracy]

Thanks for looking into Linux support.
Bought just now as a thank you. ;)

[dmytryl]

Originally posted by roothorick:

Originally posted by dmytryl:

re: your code, interesting, why in the world would they pack it at 4 under Linux when default is 8? Or does it pack at 4 by default under 32 bits and they made it 4 under 64 bits as well?

From what I can tell, packing was not originally specified for these, they found their mistake later, and explicitly specified the old packing so they wouldn't have similar unpleasant surprises in the future. Look at the blame on openvr.h, you can find where they added those pragmas which hints at what happened. I really don't understand why -- they're already not caring at all about ABI, doing their versioning thing, just change the packing, bump the ABI versions and call it a day. Well, in any case, we're stuck with it.

You want more fun? There's a handful of overlay-related structs that don't have explicit packing :) Here we go again!

Well if they don't then hopefully they're same for C and C++ at least... heh

By the way, out of curiosity, how do you deal with visual studio's calling conventions in C++ api? It's kind of funny how this "open" API entirely lacks either specifications or an open source implementation, but since it's on github every user thinks it's open source.

Yeah, that was fun. Ultimately, GCC actually did most of the work. Surprisingly enough, it can cleanly mix the two if you set the right attributes (ms_abi / sysv_abi / thiscall etc).

It doesn't QUITE get it right though; it puts the this-pointer and the return value pointer (for returning a struct/class/etc) in the wrong order/registers/etc, requiring the hairy "ERP hack" explained in WOVR's README.

Interesting. I had to do something like that to get leaderboards etc working back in the day. I didn't need returns until they actually added a C API (which I ended up using), presumably for unity bindings , so I didn't look into returns. Returns are also the reason I can't just use the OpenVR C++ headers on Windows.

Looking at your readme - here's another gotcha, not sure if you're aware of it or if OpenVR has overloads - MSVC re-orders overloaded members in backwards order in the vtable. I.e. all overloads had to be put in opposite order. Luckily overloads I had to deal with were all together. I don't know what MSVC does if there's something in-between overloads.

@EndeavourAccuracy Thanks / you're welcome!