Currently we use quest-sys for Quest integration. The upstream project has moved to remove a lot of the functionality we use.
Additionally, there are some areas where Selene would benefit from full access to the Quest functionality. It would perhaps be wise to take the same approach as we did with the Stim bindings wrap the underlying project in a cmake project, exposing a C api for integration into Selene.
A key upshot of this would be that we can then use some of the updates in Quest that will directly benefit Selene, and perhaps allow us to add some improvements (e.g. RNG behaviour can be patched to make measurements on Windows shot-for-shot consistent with those on Macos and Linux).
Currently we use quest-sys for Quest integration. The upstream project has moved to remove a lot of the functionality we use.
Additionally, there are some areas where Selene would benefit from full access to the Quest functionality. It would perhaps be wise to take the same approach as we did with the Stim bindings wrap the underlying project in a cmake project, exposing a C api for integration into Selene.
A key upshot of this would be that we can then use some of the updates in Quest that will directly benefit Selene, and perhaps allow us to add some improvements (e.g. RNG behaviour can be patched to make measurements on Windows shot-for-shot consistent with those on Macos and Linux).