Optimized 16 color for pindmd3 #119
Comments
|
Specifically, it appears that "RenderColoredGray4(ColoredFrame frame)" currently just upscales to 24-bit color, instead of using a palette with a smaller stream of data, which is likely adding the latency. Someone with access to a pindmd3 and knows its api could probably implement an indexed 16 color renderer instead. |
|
The problem is that PinDMD3's firmware doesn't support that. It's either 2-bit palette-based or full 24 bit... |
|
Well yes there is, but AFAIK there is no way to set the 16 colors of the palette individually. I think we talked about this and your answer was a firmware upgrade (which would be good too!). |
|
VPM sends out frames up to 60fps. The lag goes away if colorizations are not used. Pin2DMD does not have this issue either in 16 indexed color mode. So I do think we need this feature added to solve the issue correctly. |
|
Sure. The point is that it doesn't have the lag issue, so it rules out issues with the coloring system. Reviewing VPM recordings in the colorization tool, I regularly see frame changes at ~16ms. There are a lot of slower ones too, of course. Freezy's code also will ignore and not send dupe frames. The particular sequence that triggered this request is AFM's video mode. |
|
Yep sounds good. |
|
Cheers! |
|
Development cobwebs are the worst to dust off. :) |
|
I'm very happy to hear this Russell. |
|
Cheers! Got an example command how to flush? EDIT: Also, does the new firmware return a different version? If so, what's the string? I'm currently matching the regex |
|
@russdx any update? Will push out a new version soon and it would be great to have that in! I'm a bit hesitant to flush the firmware without instructions... So just to be clear, the new frame format is:
Which makes 2098 bytes per frame. So what's the |
|
We appreciate you taking the time to work on the update. :) |
|
bump - not meaning you should jump on it. Just a reminder in case you've forgotten about it. |
|
One week plus two weeks should be 21 days. Any news ? You should never give a estimated time for something. Then people will start to nag a few days sooner ;) |
|
And I'll keep reminding you <3 |
|
I can provide a build that implements your "specs" if that helps. Just need to patch the test image, because currently it's rgb24 which doesn't help much in that case. |
|
Just my semi regular poke ... I understand you are busy. Just in case you forgot I guess. |
|
Bump |
|
Any updates on this? I just ordered a pindmd3 so just curious. Thank you! |
|
Russ is this needed for existing PinDMDV3 owners too for the upcoming firemware or is this for new boards only with protection? |
|
I own a pindmdv3 and actually was going to get another for a second build. Should I grab the zip file from this thread and apply the update to my current Pindmdv3. Not feeling confident to go ahead and do that since it hasn't been tested and it was mentioned the firmware needing to be generated for specific serial #s? There doesn't seem to be any new information on pindmd.com about a new firmware?? Not wanting to make my currrent pindmdv3 useless by doing the wrong thing?? So i am holding off. Thank you for any clarity you can give. |
|
Thank you. Where will announcements be made about any firmware upgrades? I am interested because i am getting some slowdown in video mode on colorizations from time to time. Thanks so much!! |
|
I suggest you ask this question in VPF. This is info that most PindmdX users would love to get some more info about and this isn't really the best place to discuss this. |
|
I think the very specific case this bug is about is the AFM video mode. I imagine lag in other aspects of the DMD are less noticeable to users. Users with Pin2DMD with an indexed color mode, and LCD users do not have issues. Users who use a fixed color palette with PindDMDv3 also do not have a problem, so this very clearly points to the 24 bit mode not keeping up. VPM produces frames at 60fps so it's pretty easy to see why this could be the case for ROM-generated action. |
|
Yes Freezy's code drops redundant frames before rendering. The AFM video mode is a lot of tiny sprites, so I suspect the real ROM updates it at more than 24fps. What I see in the colorization tool that captures frame rates is that WPC roms frequently make changes in 16ms intervals but it is usually only updating only one of the two planes in that cycle. |
|
Yeah I think the code which compares and only renders changed frames is in this module, so we could look to see if it's been less than 25ms (~40fps) and skip rendering if so. I think VPM keeps sending frames so this could be workable. There's some risk though, that we might never render the final frame of something if nothing new comes down the pipe right after we drop a frame (remember not all sources are VPM, even colorization sequences can cause us to playback "videos" with variable framerates internally). Fixing that would be messier... (issue last frame if nothing changed in over ~50 ms...). If that is necessary it's probably better to just wait for the fix than add a complex workaround. |
|
Unfortunately those long runs of still frames tend to be things like "YOU WERE DEFEATED!" following some heavy motion sequence. I only know because these are the same sorts of issues that trip you up when creating VNI colorizations (and bugs I had to fix in the coloring engine). :) |
|
I have an example of another dmd colorization that runs into problems as described above. FT colorization by Martin. The game sequence where you need to shoot down water skiers. It lags and falls behind so much, that by the end of it, the dmd is playing catch up to the game. Pindmdv3. |
|
So i played the Fish Tales colorization on a pindmdv3 and pin2dmd. The video game sequence does not slow down at all in pin2dmd and does in the pindmdv3 as stated above. Not sure if this helps, but it seems like any video game sequence is when the pindmdv3 with current firmware trips up., |
|
I would love to give this a try. Do you console in using the usb cable and something like putty? How do I access the pindmdv3 to run the command? |
|
@russdx . Greetings, I do need the firmware upgrade: KUID=0780CA98-023E0132-03D48D16 |
|
@russdx Just checking, are you still doing the thing where we send in our serial number in order to get Freezy installed on pindmd3? Haven't seen a post since April, just checking before I go dig up my serial. |
|
I am not. I learned that dropping the brightness of the illumination seems
to fix 99% of the problems. I have a new pindmd3, so I am good to go.
Blessings
…On Tue, Sep 20, 2022 at 10:57 PM RunningMan-01 ***@***.***> wrote:
@russdx <https://github.com/russdx> Just checking, are you still doing
the thing where we send in our serial number in order to get Freezy
installed on pindmd3? Haven't seen a post since April, just checking before
I go dig up my serial.
—
Reply to this email directly, view it on GitHub
<#119 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AY5KM75V2BKMKMJR2JCTRP3V7J2R5ANCNFSM4FI4L3GA>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Dr. Benedetto Mongiovi
6007 Tremayne Drive
Mount Dora, FL 32757
Cell Phone: 352-638-7286
|
|
@russdx Hi i have also a pindmdv3 since 2016 i have still version 1008, do you still make does bin files ? i have my kuid number |
|
@russdx that's great good news i buy you a beer for that KUID=05FCCAAE-020D5139-05A48D16 tnx |
|
That's great news i Buy you a beer for that
KUID=05FCCAAE-020D5139-05A48D16
Kind regards
Timmy
Van: "russdx" ***@***.***>
Aan: "freezy/dmd-extensions" ***@***.***>
Cc: "timmy" ***@***.***>, "Comment" ***@***.***>
Verzonden: Woensdag 15 februari 2023 19:18:51
Onderwerp: Re: [freezy/dmd-extensions] Optimized 16 color for pindmd3 (#119)
Hello
Yes still, building firmware for all :)
Will build another batch this Friday, send over your KUIDs
—
Reply to this email directly, [ #119 (comment) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/A55NK2KESSMX7XRT4SBBT3LWXUMYXANCNFSM4FI4L3GA | unsubscribe ] .
You are receiving this because you commented. Message ID: ***@***.***>
|
|
I'd really love to make use of all the amazing alt colors : ) |
Whew, that was quick. However, when I click the links they all seem to redirect to the http://pindmd.com/ homepage. |
|
@russdx ok i have sent you a mail from [email protected] |
|
Works like a champ. Thank you! |
|
Hello, any chance I could get a firmware build? Thanks! |
|
I would like to get updated firmware for my PINDMD3. KUID is 0EDBCAE4-023DE123-0F178D16 Thanks! |
|
Hi Russ, I need to get an updated firmware for my PinDMD3 please. Thanks. |
|
Hi Russ, I recently purchased a new pindmd v3.1 dmd. It will not reset itself after I play a table. I have to reset it manually after every table. Is there a way to make it reset automatically after the table is played. I bought it from Virtuapin in October 2024. |
|
Hi Mike,
I received this in error. Russ' email address is ***@***.***
Good luck
AL
…On Wed, Oct 23, 2024 at 12:54 PM Redwings12345 ***@***.***> wrote:
Hi Russ, I recently purchased a new pindmd v3.1 dmd. It will not reset
itself after I play a table. I have to reset it manually after every table.
Is there a way to make it reset automatically after the table is played. I
bought it from Virtuapin in October 2024.
thanks. Mike
—
Reply to this email directly, view it on GitHub
<#119 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU5DLPDVM3UG3ZC2C337VILZ47ID7AVCNFSM4FI4L3GKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENBTGI4DKMBTHAYQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Switched github accounts this is my new one. |
|
Hi Russ, I recently purchased a new pindmd v3.1 dmd. It will not reset itself after I play a table. I have to reset it manually after every table. Is there a way to make it reset automatically after the table is played. I bought it from Virtuapin in October 2024. |
Hello I am not quite sure why this is. It feels like a firmware or software issue? The hardware has not changed since we launched the pinDMD ZeDMD in 2023? so don’t think it’s a hardware issue? Paul says there are a few customers with this issue recently so looks like it started with a recent firmware or DLL release maybe? (Not pointing fingers!!) just saying the hardware has not changed since day one. |
|
Thanks Russ, I wish I knew what to do about it. |
I think its going to be a bit of trial and error to see what version number it stop working and if its an issue with the ESP32 firmware? or with the Freezy DLL? I have no experience with either system so can't help much there sadly. |
|
Thanks Russ |
|
As said in the mail: |
|
A reset happens when a program like VPX releases the COM port and a different one takes over. |
|
Hello @mkalkbrenner & @zesinger So we use the CP2102N USB serial chip, but don't have any of its various reset signals wired up to the ESP32 reset pin. This was not in the original requirements? Has something changed in recent versions which now require this? Can the firmware not be reset via software how come its done at a physical hardware level? This was working before (as not had any reports of this issues before) so I can only think something has changed to swap over to using the physical firmware resetting rather then software which I assumed it used before? |
|
Requirements? We never published requirements for custom PCBs. ZeDMD uses ESP32 dev-kit boards. But as you can check in the git history, the hardware reset was part of the first commit ever to libzedmd. So it has not been added recently. What has changed over time is when it gets called. And we added a additional reset to solve issues with some frontends. I remember that earlier versions of the ESP framework had issues with the software reset. But you could try to implement it. But that won't replace the hardware reset entirely. The hardware reset is also called under specific error or connection conditions. The only good way I see is to leverage dmdserver. This program holds a permanent connection to the DMDs and other programs like DMDext, VPX, frontends can connect to it. I assume adding a dmdserver as DMD device to dmdext is the simplest change. Or you fix the hardware. |
|
Fixing hardware is not an option, it is what it is and can’t be updated. There is only 100 of these made and won’t be any more. If there is a software fix that would be fantastic. Having to fire a physical ESP32 reset when switching tables does seem a little odd to me though. Resetting hardware should always be a last resort. Usually everything can be handled in software. The pinDMD initially did everything though software commands. I never had to physically reboot it… is this because of the virtual comport handle having to swap between different pc processes? Even then can’t one close it and another open it and just say hello to the DMD firmware? I don’t understand the need for the hardware reboot? |
|
ESP.restart() should be the soft reset. We had that in the code in an early version, but there was an issue. I think the hardware reset is needed to reset the USB converter itself. |
|
So you think there might be a chance it’ll work if(when) a newer version comes out? |
Yes, But an easier fix might be to go back a revision or 2 as it was working at some point, this seems to be a recent change? @mkalkbrenner is this a ESP32 firmware update or pc side DLL update? |
and others
There is still a small delay that makes mini games like the video mode in afm not playable with *.vni enabled. Possible to fix ?
http://vpuniverse.com/forums/topic/3461-sambuild31-beta-thread/?do=findComment&comment=39918
The text was updated successfully, but these errors were encountered: