While testing libfmod’s Python bindings (pytest segfault · Issue #22 · tyrylu/pyfmodex · GitHub) across different platforms we came across a strange issue of seemingly different default cone orientations on Linux and Windows (using recently downloaded FMOD API libraries).
Here’s the workflow:
create and initialise a core system
create a sound
play and pause the sound to yield channel
request the cone orientation of the channel
On Windows (64bit), this results in [0.0, 1.0, 1.0]. However, on Linux (64bit) this results in [1.7410261011059725e-19, 1.4074957596177471e-14, 1601833.125], which, after some rounding, amounts to something like [0.0, 0.0, infinity].
Are we doing something wrong here, or does this point to a different implementation for cones across platforms?
I’m not overly familiar with Python bindings so naturally I cannot comment too heavily on the implementation. However on brief inspection, it looks like the setter passing the vector into FMOD for Set3DConeOrientation isn’t doing so byref like our API expects. Perhaps this is the cause of your test fail?
As Python isn’t one of our supported languages we cannot debug too heavily, if you do find issues please test them using our C++ examples. I wouldn’t expect there to be any Linux specific issues with usage of that API, it is very trivial internally simply setting and returning the value set.