Closed zmerp closed 3 years ago
Thanks! An initial concern: as illustrated in the linked reference, don't we also need an xrInitializeLoaderKHR
call?
As I'm not qualified to review JNI esoterica myself, I'd like success reports from manual testing on android at minimum.
Yes, in the work I'm doing on bevy I'm also sending the same Java pointers to the loader using the extension. It is easy enough to do with the function pointers and it doesn't require extra modifications to openxrs. I could also contribute it directly to openxrs (inside the entry creation call), but I should definitely have something running first (which I'm deferring because I currently don't have the software + hardware ready).
I added Entry::initialize_android_loader()
and updated the vulkan example for android support.
This PR is now ready for review, with some caveats:
khr_vulkan_enable
support, the vulkan example now has much more boilerplate.I'm going to add here commits related to the implementation of the khr_vulkan_enable
wrapper, for the sake of testing. I'll rebase later.
The Oculus Go is probably compatible with OpenXR and this crate (I'm waiting for some last reports). The problem is that it supports only Vulkan 1.0 so the example doesn't run without heavy modifications, so I'm not listing it as compatible (but it will be compatible on bevy).
It might not be too bad to refactor the example to use the multiview extension explicitly assuming the Go implements it, but I'm just as happy to keep things more concise/modern.
I'm ok with keeping the example on Vulkan 1.1 (without Oculus Go support). Another argument is that the cargo-apk metadata was a mashup of old and new entries for the sake of the Oculus Go support, when the user would probably decide to maintain separate Cargo.toml files for different headsets.
I fixed the examples README with the crates.io link for cargo-apk. I think now it's all ready for merging.
This is inspired from @blaind's work: https://github.com/blaind/bevy_openxr/blob/main/crates/bevy_openxr/src/platform/oculus_android/mod.rs
While @blaind work is known to be working, I didn't provide any testing for this code. If you want, I'm ok for waiting to have a working example before merging.