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.
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.
Previously, the RDRAM detection/initialization was wrong and a post
RDRAM initialization hack was triggered (just before initial PI DMA)
to force specified amount of RDRAM to be recognized.
With this PR, several aspects of the RDRAM have been implemented which
results in proper detection of RDRAM by the IPL3:
- support for up to 8 (IPL3 hardcoded limitation) RDRAM modules
- partial support for individual rdram address mapping,
ADDR_SELECT has not been implemented though
- support broadcast register writes
- simulating read failure when current calibration is not done yet
