Added support for alternate vector renderers

[Goldfinch2]

Allows to override the default screen vector renderer to other devices. Added an implementation that supports the USB-DVG hardware, which is a digital vector generator you can connect to real X-Y monitors or oscilloscopes.

New settings in mame.ini:

alt_vector_driver (none | usb_dvg)
alt_vector_port (ex: /dev/ttyACM0 or \\.\COM1)
alt_vector_dual (0 | 1) <-- Display on alternate renderer only (0) or alternate render + screen (1)

[rb6502]

Before we dig into the code, a couple of style things. For other MAME things where there's a selectable backend, it's just the backend name with no "alt", so the setting would be just "vector_driver", and instead of "none" the default would be "screen" or "raster" or something. Also, by analogy to existing MAME settings, it'd be cleaner to have something like "hybrid" for the "vector_driver" setting to indicate both on-screen and hardware output.

[Goldfinch2]

Before we dig into the code, a couple of style things. For other MAME things where there's a selectable backend, it's just the backend name with no "alt", so the setting would be just "vector_driver", and instead of "none" the default would be "screen" or "raster" or something. Also, by analogy to existing MAME settings, it'd be cleaner to have something like "hybrid" for the "vector_driver" setting to indicate both on-screen and hardware output.

Ok. However, if we specify hybrid, it does not state exactly which driver we are using. Let's say in the future someone comes with a new alternate driver renderer, we wouldn't know which one to use. Also, "screen mirror" would be a better term instead of "hybrid" IMO.

So I suggest:

vector_driver set vector driver (screen | usb_dvg)
vector_port set vector serial port
vector_screen_mirror enable screen mirror

[Goldfinch2]

Do you think it will be merged someday?

[cuavas]

Sorry, haven’t gotten to this yet. I do like the idea of having alternate vector outputs, but I have a feeling the implementation here is going to need significant reworking before it can be merged.

[cuavas]

I’ve spent some time thinking about this, and unfortunately it’s one of those, “it’s not you, it’s me,” situations. This is the kind of thing that we should really be able to allow via Lua plugins, but we can’t right now due to limitations.

We need a better way of adding Lua bindings for specific device types. Adding bindings in src/frontend/mame for core device types and mixins is OK, but it won’t scale out. It would result in the frontend library depending on too many types of device, which is unwanted coupling. We also don’t want the devices to become dependent on the front-end library. This is going to require quite a bit of reworking to do in a way that isn’t gross.

There’s still the issue of the file I/O classes having too much baked into them and the assumption that it’s always possible to seek backwards on the input side. This makes dealing with things like sockets problematic (as well as the issues we’re having with text I/O). I’ve made some good progress on this, but we’re not where we need to be yet.

Sorry, but we’re just not at the point where support for things like this can be added in a clean and supportable way.