Add data exchange through a global shared state block

[vbousquet]

This commits allows to share previously unshared data without overloading too much the API by adding a single data block for pulsed state, device state, modulated segments, multiple DMDs, raw DMD frames (for correct rendering and allow coloring) and video.

This commit contains the skeleton and base implementation to set up the ground for more testing on client side (VPX) when support will be more advanced there. It also gives a ground to implement in LibPinMame.

The aims of these changes are for VPX but could be useful for other client as well:

• allow VPX to perform correct DMD rendering (needs unprocessed DMD frames),
• allow VPX's plugin to perform coloring (needs unprocessed DMD frames),
• allow VPX to include a backglass renderer with support for fading lamps & flashers (could be done with existing interface but at the price of lots of data exchange and likely some API bloat),
• allow VPX to support modulated segments,
• allow VPX to add support for video output (MrGame machines, ...).

[Edit: multiple force-push to fix stupid build bugs (missing min/max, ...)]

[toxieainc]

Hi! In principle this looks good, but as i don't have time to dig into details at the moment, is this somehow future-proof, e.g. could hypothetically newer platforms like SPIKE, etc be supported, too, without breaking backwards compatibility?
(e.g. if somebody would run an older VPX version with a then even newer VPM version)

[vbousquet]

It is supposed to be as future proof as possible (and especially for Spike) but it's difficult to be fully sure and in some situation, this needs client to be updated:

• the client must agree with the server on the data format, so the first field is a version id : if it does not match then no further processing should be done. This means that when PinMame will change its state block format, then it will change this version id and all client will have to be updated (copy/paste the declaration, recompile, adjust code),
• all fields come with their data size (or struct size) to allow processing (or skipping) of future fields by today implementation,
• instead of DMD, it supports generic 'display' which can be a DMD / LED matrix / RGB display. Regarding Spike, I would say that the main difference would be the video which would benefit from this display data span (exchange the LCD as an RGB array), but I can't tell if the performance will be good enough (Spike has an HD screen so datacopy are somewhat expensive),
• output are modeled as 'devices' with a data stride of the device state included. This should allow to support devices that could need more state information without breaking anything (it would be nice to model at least solenoids and stepper motors).

What I had in mind was to propose this change (eventually keeping it in a separated branch), then move VPX forward (multiple display for DMD & Backglass, and a skeleton for plugin are already comited but this needs far more love to really give some useful feature). It will likely lead to identify some defect in the proposed design/data format that will need some updates here.

[toxieainc]

Sounds good. I mainly wonder about this, as i guess that there will be a longer transition phase for VPX to a potential VP11, similar (most likely even longer) to what happened with VP9 and VPX.
So people will run both versions, BUT will need a current VPM, too. But that may also be possible to be solved by still doing updates to VPX then.

[toxieainc]

@vbousquet How should we progress with this one?

[vbousquet]

@vbousquet How should we progress with this one?

I have converted this PR to a draft since I think it is not good enough for merging. I will continue to push the integration on other parts to validate the design before converting it back to a normal PR. Indeed, the last weeks have shown that implementing all the uses may show API change needs and I think it would be better to merge it only after these have stabilized.

For the time being, DMD data exchange is quite nice. Next to be tackled would be alphanumeric displays, then displays (sRGB screens which still needs real use case with a VPX bridge to be validated), then lamps, then GPIO (solenoids / motors / ...). Until then, the API change risk is too high.

If you prefer, this can be closed for now.

[toxieainc]

As you wish, whatever is easier for you. Maybe some (incl. me ;)) want to follow your progress.

[freezy]

Subscribed ;)