These casts are not allowed by strict C standard, and a complying
compiler must emit a warning in such a case.
In practice most platforms support these casts just fine as they've been
de-facto standard practice given dlsym, GetProcAddress,
SDL_GL_GetProcAddress functions.
So we introduce the possibility to disable such warning at the line
scope through the OSAL_WARNING_{PUSH,POP,NO_WARNING_XXX} macros.
Also to avoid overusing this extreme macro, we wrap the 3 mandated cases
such that they return a generic function pointer (eg. m64p_function)
which can then be casted to the effective function pointer type.
This patch makes saving the configuration the responsibility of the UI.
The mupen64plus-ui-console plugin currently saves configuration already,
by default.
By adding init and release methods to video capture backend interface
we can completely separate implementation details from usage.
We don't need to include (nor have) implementation header,
and therefore can use true C++ for opencv implementation
(no need for in-place ctor, explicit call to dtor, ...).
Also, backend selection is done by name and multiple instanciation (with
different parameters) can be done by selecting the right config section.
Default video capture backend may be overrided at compile-time by
defining DEFAULT_VIDEO_CAPTURE_BACKEND to appropriate value.
Video input has been renamed to Video Capture.
This may help fixing some edge-cases of crashes while loading
savetstates.
We isolate the savestate data extraction part from the state committing
part so that curr offset don't depends on external factors which could
lead to crashes.
All the reverse-engineering work comes from AntonioND [1].
A new video backend API has been added to grab video images.
By default, a dummy backend is provided.
However, an OpenCV based backend is also provided (if enabled at
compile-time with OPENCV=1 in Makefile).
Other implementation should be possible (GStreamer for instance ?) in
the future.
With the OpenCV backend, the video device selection can be done using
the Core parameter:
[Core]
GbCameraVideoDevice=<my_device>
Where <my_device> can be either an integer which represent the device
number (0 for default) or a string which specify the video device path.
Tested with 64DD Mario Talent Studio (Japan), a transfer pak plugged
in the first controller with a Japanese GameBoy camera. Also since the
core currently requires a cart ROM (even if should strictly be required)
I used Perfect Dark (Japan) to allow using the Transfer Pak. This is a
core/ui limitation not related to this PR.
[1] https://github.com/AntonioND/gbcam-rev-engineer
For now, the bio pak only report hard-coded BPM value.
In future work remote heart rate monitoring methods (rPPG) could be
implemented to provide an experience similar to the Bio Sensor pak using
a regular webcam. However it could be quite CPU intensive and may prove
challenging in multi-player context.
Another idea to create an "equivalent" Bio Sensor experience without the
original device, could be to derive the reported heart rate from the
BPM (or any relevant quantity) from a user specified audio clip.
