Dumping DMD frame need an updated dmddevice.dll

[Kraken74]

Dumping ROMs in PinMame 998 works as expected, but in 1122, the dump files are much larger. What is happening is the frames are being repeated multiple times but but with shorter timestamps, so for example one frame of 1000ms from 998 corresponds to ~50 frames of 15-20ms in 1122 making the dump files larger and causing issues for the Serum color authors when playing back the dump files for testing as we are limited to the number of frames that can be loaded. Attached zip file are the first few seconds of the T2 dump files from 998 and 1122.

On the left is 998, you can see the first frame is blank, then the panels start moving in on both sides of the frame on frame 2 (see arrow). On the right is the same dump but from 1122 and the first blank frame is repeated over and over.

Thanks!

Terminator 2 Dumpfiles.zip

[vbousquet]

Just had a look and I think this is linked to PinMame but the solution is not in it.

As far as I understand, the frame dump code inside VPinMame is a legacy left over since it can't be triggered (it can only be activated when using VPinMame by pressing a key but VPinMame does not have any input access, so it will never be triggered). Therefore, the frame dumping is not done by VPinMame and can't be fixed there (note that the code could be improved to filter out same frame, but since it is not used...).

I imagine that you use a dmddevice plugin to perform the dump, likely Freezy's DMDExt. Since latest updates to DMD code, there is an update needed as stated here: #361
This update will also need to update what is dumped to:

• create dumps from the identify frame stream (and not the render one like it is now, leading to wrong GTS3 caprture for example),
• filter out identical frames (this can't be done on VPinMame side since 3 frame streams are provided: render, identify, raw and each of them may or may not change, with the render frame changeing very frequently due to PWM integration)

@freezy pinging you for visibility on these informations
@toxieainc I also did not touch the frame dumping code in PinMame but I think something should be done: either remove it as it is dead code, or open a path to allow use of it. What do you think ?

[Kraken74]

Just had a look and I think this is linked to PinMame but the solution is not in it.

As far as I understand, the frame dump code inside VPinMame is a legacy left over since it can't be triggered (it can only be activated when using VPinMame by pressing a key but VPinMame does not have any input access, so it will never be triggered). Therefore, the frame dumping is not done by VPinMame and can't be fixed there (note that the code could be improved to filter out same frame, but since it is not used...).

I imagine that you use a dmddevice plugin to perform the dump, likely Freezy's DMDExt. Since latest updates to DMD code, there is an update needed as stated here: #361 This update will also need to update what is dumped to:

* create dumps from the `identify` frame stream (and not the render one like it is now, leading to wrong GTS3 caprture for example),

* filter out identical frames (this can't be done on VPinMame side since 3 frame streams are provided: render, identify, raw and each of them may or may not change, with the render frame changeing very frequently due to PWM integration)

@freezy pinging you for visibility on these informations @toxieainc I also did not touch the frame dumping code in PinMame but I think something should be done: either remove it as it is dead code, or open a path to allow use of it. What do you think ?

Thanks for the info Vincent. You are correct that we are using the DMDEXT (latest beta). I assumed it was a PinMame issue as it went away after rolling back to 998, but I now see it's a bit more elaborate.

[Kraken74]

Bit more info, after changing the rawoutput parameter to true, it appears to be dumping as expected under Pinmame 1122. From what I was told, setting this to true makes DMDEXT dump the ROM instead of PinMame. Maybe this is the solution.

[vbousquet]

How did you perform the dump before ?
Also note, that GTS3 dump will be wrong until dmddevice.dll is updated

[Kraken74]

Same way, but with rawoutput = false, which works with 998 but creates the issues with 1122.

[vbousquet]

What do you mean by 'same way' ?

without rawoutput=true, it is not supposed to dumpframe at all (see https://github.com/freezy/dmd-extensions?tab=readme-ov-file#frame-dumping)

[vbousquet]

ok, my bad, didn't know that creating dmddump would trigger the dumping in PinMame. Will have alook later

[Kraken74]

Yeah, if vPinMAME\dmddump folder exists and Show DMD/Display Window is checked in the F1 menu, PinMame will dump.

[vbousquet]

This was very simple, so wrapped up a patch during a break. Should be good now (and also dump alphanumeric systems)