WPC DMD animations too slow ("Remove the built-in rom delay")

[PastorL69]

Hi,

This is probably already known, but figured I might as well report it.

Since PC's now no longer use tech from the early 2000's I feel like the rom delay can be removed.
Having real pins it's obvious to me that the dmd animations aren't as fluent as they usually are. Especially noticeable with the WPC games. (I also confirmed this by comparing the frame timings of a real pin dump with a vpin dump)

Some time ago @mkalkbrenner made a seperate build for us Serum authors to test some things, showing that it is indeed possible to get the rom running at the exact rate real pins do.

Maybe it's worth looking into now since tech will definitely not be the reason holding it back.

:)

[toxieainc]

I wouldn't know what that 'rom delay' should be actually.
Do you have any additional info what exactly you know by that?

Otherwise, what is that special build of @mkalkbrenner ??

[PastorL69]

I will wait for a comment from @mkalkbrenner. He can probably explain it better than me if he still remembers what he modified.

[mkalkbrenner]

Maybe some things get mixed here.

I added a frame dumper to libdmdutil that ignores most of the "transitional" frames as colorizers always delete such frames manually.
For WPC there's a pattern how these frames occur on real machines and in pinmame.

In general, we're a bit slower in pinmame as we record three (or four?) refreshes of the DMD to calculate the brightness of each pixel of a "frame", before pinmame sends that frame. That might already be an issue for in-game video modes or animations. But colorizing DMD replacements for real pinball machines have the same issue if they require the brightness level per pixel for their masks.

Furthermore, I'm not sure if I remember correctly what I found in the code. I assume there was something that synchronizes the refresh rate of the DMD data with the DMD rendering on the screen or clients like VPX. That might slow down animations compared to real pinball machines. And for the use-case of pinmame to act as a CPU replacement for real machines, it would be ideal to optionally turn that off. But again, I'm not sure because I had no time to take a closer look.

[vbousquet]

Note that I'm rewriting the DMD shading atm so things will change a bit in the coming days. For the time being DMD handling depends a lot on how the driver is written. The general scheme is the following:

• PinMame runs at a fixed 60Hz pace (so every 16.7ms do an update then stall), leading to little latency,
• DMD driver update the DMD output at the same fixed 60Hz, they do so by accumulating a few frames and deriving the shades from them. The latency here (low pass filter response delay) should be fairly slow as DMD usually have fairly high refresh rate to be able to create these PWM shades (at least 120Hz, with up to 900Hz) and the low pass filter are pretty basic (usually a simple average, sometime biased)
• Then the client (colorization plugin, display driver, VPX, whatever) process these datas, adding their own latency. If rendering on a computer, this can be from 1 to 3 frames at the refresh rate of the display (for example 1 to 3 times 16.67ms for a 60Hz display)

In the end, the latency will vary quite a lot, and I would expect something around 50-100ms. It doesn't sound that much to me but I guess it depends on your perception.

[PastorL69]

Funny you mention that 16.7ms. Here a dump of a real pin:

dump of a vpin with pinmame:

16.7ms seems about right :)

It is a pretty big non issue overall, just thought I'd mention it. Seeing that @vbousquet is working on rewriting some of these things I'll just wait for a newer release and test.

On second thought, I am starting to doubt it this "rom delay" that popped back in my head from some time ago was for Stern SAM games instead of WPC.
Are you guys aware if Stern SAM DMD emulation is slowed down by any chance? I remember that at the time when I was colorizing Iron Man, AC/DC and Tron that the animations do not have the same speed to them compared to real pins. I remember this being noticeable when I used the seperate build by Markus.

[vbousquet]

This is actually pretty interesting. How did you get these dumps ? Could you explain the numbers at the top of each frame ? Do you have this type of dumps for other hardware also ?

Right now, I have been rewriting a bunch of this (it all started as a little fix since I'm integrating DMD/Alpha/B2S to VPX, but in the end, it happened to be somewhat larger. So far, GTS3, Data East 128x32, Sega/Stern Whitestar and WPC are mostly done, Alvin G is in progress but with wrong timings I will fix in the coming days), and this lead to adjust/fix timings here and there. Being able to validate timings is a key point here. For the time being, I just read the schematics and adjust to it, then have a look to a video of the real pin and check that I get the same speed & brightness levels. But having access to raw captures would be awesome.

I also discovered that some colorization is made from shaded frame (processed by PinMame), not raw frames (the raw ones from the hardware) which will be a fairly annoying issue to maintain backward compatibility.

[mkalkbrenner]

I "reduced" some more smoothings for PPUC real pin usage. I think I experienced with removing them entirely but it was a kind of endless story. So a rewrite sounds great.

[mkalkbrenner]

Maybe setting WPC_DISPLAYSMOOTH to 1 gave @PastorL69 that boost?

[vbousquet]

All these constants are only used for the 'legacy' binary to physic output smoothing (each driver having its own model of how the physic device reacts to the binary output). I tried to push these forward with the new physic output included in latest PinMame mode by:

• splitting the binary (a.k.a. pulsed) output which is the high frequency binary state output of the controller,
• adding a clean and common accross drivers model of physic devices (bulbs, LEDs, VFDs, with the will of adding stepper motor, solenoids,...)
  So in latest PinMame, these value are computed on demand, therefore at the pace of the consumer, with a common model. The bulb model is the most advanced regarding this and it has very good results IMHO (can be used to drive LEDs replacement of incandescent bulbs with a fairly high level of quality).

The DMD is not processed here, and I'm doing the same process at the moment: first reviewing the emulation (done for most systems), then moving to a common model (in progress), then changing the update from emulator driven from consumer driven (to be done).

[PastorL69]

The yellow numbers are the time in ms of a frame. This dump was obtained via AlphaDMD
Software used to view the dump is SortingCDump

I only have access to WPC and Stern SAM. I could also get a dump from my real Tron if you'd be interested in that.

sttng_l7.txt
Here is a dump of the real STTNG pin.

[toxieainc]

On second thought, I am starting to doubt it this "rom delay" that popped back in my head from some time ago was for Stern SAM games instead of WPC. Are you guys aware if Stern SAM DMD emulation is slowed down by any chance? I remember that at the time when I was colorizing Iron Man, AC/DC and Tron that the animations do not have the same speed to them compared to real pins. I remember this being noticeable when I used the seperate build by Markus.

This one can well be. SAM emulation is not perfect yet timing wise. Especially IJ and CSI even need a special hack to not lock up on game start.
In general, SAM timing improved over the years, BUT the 64bit version of PinMAME (or the Arm CPU compiles) is still having more issues. So maybe you used the 64bit version?

[PastorL69]

On second thought, I am starting to doubt it this "rom delay" that popped back in my head from some time ago was for Stern SAM games instead of WPC. Are you guys aware if Stern SAM DMD emulation is slowed down by any chance? I remember that at the time when I was colorizing Iron Man, AC/DC and Tron that the animations do not have the same speed to them compared to real pins. I remember this being noticeable when I used the seperate build by Markus.

This one can well be. SAM emulation is not perfect yet timing wise. Especially IJ and CSI even need a special hack to not lock up on game start. In general, SAM timing improved over the years, BUT the 64bit version of PinMAME (or the Arm CPU compiles) is still having more issues. So maybe you used the 64bit version?

Yes, good chance.
In that case you can close this issue if you want, since it's not really an issue. Just wanted to notify you all of these findings.