Open MikedaSpike opened 1 year ago
Is that issue related to PinDMDv3? Could someone reproduce the issue with ZeDMD or PIN2DMD?
I can confirm that it's happening with my pindmd3 too.
@mkalkbrenner I confirm that on my ZeDMD with v3.3.0 there is a delay too, this is not the case with the virtual DMD. EDIT: I'm not 100% sure, but it seems to happen only when there is a background displayed. I can't see how it could be linked to Serum as there is no delay on the virtual DMD.
@zesinger @mkalkbrenner do you want me to investigate further, or are you handling this?
Let us have a look @freezy , not sure we'll solve it soon, but first we should look on our side
Same with my PinDMD3, pretty sure all was good with an earlier version of Freezy though, if you need to to confirm, just say the word.
I have led some tests (x86 only):
Just for notice : same issue with 2.2.1
I don't see this delay with the current development build of DMDext: https://youtu.be/B6D00oB4Co8?feature=shared&t=190
@freezy Maybe it is time for a new release?
I tested with dmdext-2.2.2-SNAPSHOT-r1-x64-Release on my real DMD, but it is still running slow DmdDevice.log
tested with v2.2.2 and v2.2.2-zedmd RC1 on my PinDMDv3, and still the same. Looks like it is even slower now.
I cannot use the new color alphanumeric DMDs with my PinDMD3 either because of this.
Is there a firmware update for the PinDMD3 (call it 3.1) to convert it to a ZeDMD ?
I can not answer for the PinDMD owners, but PinDMD3.1 is based on an ESP32 microcontroller when PinDMD3 is not, so I guess it is not possible. Anyway an ESP32 is 8€/8$ (and a shield is 20 if you don't want to wire it yourself), so you could easily create one.
Wishful thinking. Hopefully someone will come up with a solution, and I'm willing to modify the hardware. There's a lot of us out here.
Why rewriting firmware? Isn't it something wrong in the driver ? All is working, for now just the 2 colorizations of alphanumeric is very slow. Not sure if this is caused if the hardware of pindmdv3 is not processing the translation of the alphanumeric to images frames correctly, or that the libserum causes the issue. Strange part is that It is showing fine on the virtual dmd when this is enabled as well.
libserum can't cause the issue if it doesn't for all the devices (virtual DMD included), libserum just takes an uncolored frame and returns its colorized equivalent (basically receives a memory buffer and returns another one), so it is hardware independent.
Sorry David, didn't want to make you angry. So, if libserum sends to correct frames (memory buffers) to dmddevice.dll, is something not in sync for the pindmdv3 hardware ? With other words, something that freezy can fix (but don't want to grab the time of him as VPE is already taking a lot of time).
You really didn't make me angry, just to make clear what it does, so you understand it can't come from there. Some parts of dmdext are done by the device creators (all the code in this sub-directory https://github.com/freezy/dmd-extensions/tree/master/LibDmd/Output ), they are basically device drivers to communicate with the devices. If there are problems with only some specific devices, it is likely that the problem comes from here.
I ordered an esp32 and put zeDmD firmware on it. Connected it to de Pindmdv3 and all is working now (thanks to @zesinger as well ) . If it is just me, this issue can be closed
testing the colorized version of diner (https://vpuniverse.com/files/file/15442-diner-williams-1990-dmd-64-colors-serum-format/?tab=reviews&sort=newest#review-13700) and noticed that on the real DMD the frames are very slowly showed. it even ques everything and shows . This makes the DMD run behind the real frames.
To compare I made a video. Top is a virtual DMD and lower is my realDmDv3 https://youtu.be/XdpYBEWACQs
Also added the log file of this run DmdDevice.log
I tested this with 32 bit and 64 bit, and both shows the same result)
also when quitting Visual Pinball, the last frame is still on the DMD