freezy

There's a little bit of doc [here](https://github.com/freezy/dmd-extensions/tree/master/PinMameDevice#dmddevicedll), but it doesn't cover each function. The `Render_` functions receive a pointer to a pixel array representing pixels from top left to bottom...

Per SE, there aren't any games supported by PinMAME that originally support color. So what you're getting is the gradient of whatever color the game's DMD is using. BUT, since...

If you integrate your display with dmdext then it'll not only work with PinMAME (which is what DmdDevice.dll is for), but also with all the other pinball simulators like Future...

Cool! As mentioned above, you'll need to either write a driver for dmdext or implement the coloring yourself either in your own driver or in your firmware. I wouldn't recommend...

By dmdext driver I mean a new output device for dmdext that connects to your display. [Here](https://github.com/freezy/dmd-extensions/blob/master/LibDmd/Output/PinDmd3/PinDmd3.cs) is an example of such a driver for the PinDMD3.

> Would it be possible to code this driver in plain C? Nope.

Try rendering the virtual DMD at the same time - if the artifact is only on your display and not on the virtual, then it's a problem with your output...

I'm sorry, I'm stupid. Yes, it's definitely on the output's side then. How are you sending the data? If it's through a serial interface, there might be a speed issue...

The secret is just being *periodically* stupid. ;) Transmission seems fine then. Not sure what else it could be, it's not a pattern I recognize for what it's worth.

Well, you're subscribed to a stream, so you shouldn't have to deal with this. You basically get each frame already computed, ready to send, and the data you're getting isn't...