|0.0.0||Apr 25, 2022|
26 downloads per month
Used in ovr_overlay
Contains (ELF lib, 2.5MB) openvr/bin/androidarm64/libopenvr_api.so, (ELF lib, 1.5MB) openvr/bin/linux32/libopenvr_api.so, (Windows DLL, 1MB) openvr/bin/win64/openvr_api.dll, (ELF lib, 350KB) openvr/bin/linux64/libopenvr_api.so, (ELF lib, 315KB) openvr/bin/linuxarm64/libopenvr_api.so, (static library, 6KB) openvr/lib/win64/openvr_api.lib
New applications should probably seek to use
OpenXR instead of
there are still some things that you can't do in
OpenXR that you can do in
namely, creating overlays.
This binding allows you to create an OpenVR overlay with rust, but doesnt necessarily provide bindings to the rest of the OpenVR API. If you find missing functionality (and you will find missing functionality), submit a PR!
Why not build bindings on the C API?
The C API is straight up broken in the official repository. The latest release
doesn't even compile, and hasn't for over two years.
Whats more, the C bindings don't have the same safety features as the C++ API,
eschewing the use of
const, etc. Furthermore, the C API is autogenerated from
the C++ one, and isn't documented like the C++ one is.
Why not use the existing
That crate hasn't been updated in over 2 years. And I don't blame them, time is better spent getting first class support for OpenXR in Rust, as OpenVR is on its way out.
Unfortunately, that crate is missing all of the overlay functionality, and since I'm really just focused on overlays right now, I need an alternative.
We make no SemVer guarantees until we reach version 0.1.0 or greater. Until then, everything and anything may change in a breaking way.
We vendor the
OpenVR library as a git submodule. So either clone with
git submodule update --init after cloning.
You will also need
libclang installed, as its required by the
crates to generate the bindings.
All code in this repository is dual-licensed under either:
- MIT License (LICENSE-MIT or http://opensource.org/licenses/MIT)
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
at your option. This means you can select the license you prefer! This dual-licensing approach is the de-facto standard in the Rust ecosystem and there are very good reasons to include both.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.