mpf+gmc+pin2dmd

[Samuel Chauviere]

Hi there,

Since slide_player has been rebuild with the GMC plugin, I can't get my slides to be displayed on my PIN2DMD on mpf 0.80 the way I used to do on mpf 0.57.

Is there any trick to get it done ?

Thanks.

Samuel

[Sector 8 Music]

I have the same issue but then with the set up for Tinsy+SmartMatrix setup.

Since Godot is handling the graphics side of things. It probably needs to be written for godot specific.

--
You received this message because you are subscribed to the Google Groups "MPF Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mpf-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mpf-users/b93cf729-8f1e-4d04-b1bf-1119576ae73en%40googlegroups.com.

[Laurent Maillard]

Hi there,

I would be very interested in a solution to this problem too...

I'm currently recreating some WPC's Vdo Game in MPF 0.80 (just for fun) and it workks pretty well... exept I can only use them on an LCd screen insted of a DMD display... too bad...

Looking forward to see GMC work with a pin2dmd  :) 

Greetings from France

Laurent

Le samedi 21 décembre 2024 à 17:29:25 UTC+1, Cloudjor a écrit :

I have the same issue but then with the set up for Tinsy+SmartMatrix setup.

Since Godot is handling the graphics side of things. It probably needs to be written for godot specific.

On Saturday, 21 December 2024, Samuel Chauviere <samuel.c...@gmail.com> wrote:

Hi there,

Since slide_player has been rebuild with the GMC plugin, I can't get my slides to be displayed on my PIN2DMD on mpf 0.80 the way I used to do on mpf 0.57.

Is there any trick to get it done ?

Thanks.

Samuel

--
You received this message because you are subscribed to the Google Groups "MPF Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mpf-users+...@googlegroups.com.

[Anthony van Winkle]

Hmm, this is an interesting conundrum. Let's explore it!

The main purpose of MPF 0.80 is to separate MPF from its dependency on MC, but 0.57 has long-term-support for all new features and bugfixes. If you're not using GMC or a robust media engine, functionally there's no difference between 0.57 and 0.80 so you'd be just fine using 0.57 for your DMD-based project.

However, there's no reason that 0.80 shouldn't support PIN2DMD. I've already implemented the functionality to read the pixel colors on screen and report those colors back (for the light show creator), so the only question is how to get that pixel data out of Godot and over to the DMD. I did a look through the MPF and MC code and it looks straightforward: MC generates the dmd frame as a byte array and sends a special dmd_frame event back to MPF, which then updates any subscribed DMD with the data.

So I can work on building out GMC to be configured to return this data for a specified DMD, unfortunately I don't have a DMD so I'll have no way of knowing whether it actually works or not :P If somebody has some computer skills and would be willing to help run test code and share debug logs, that'd be a big help!

[Samuel Chauviere]

Sure I'll be glad to help ! Thank you Anthony.

Samuel 

You received this message because you are subscribed to a topic in the Google Groups "MPF Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mpf-users/eTe_1PEFQq4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mpf-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mpf-users/a3611cc6-cc85-4a22-81ee-ab36712f2992n%40googlegroups.com.

[Laurent Maillard]

Same thing here, if I can help, let me know ;)

[Sector 8 Music]

I would love to help and test it out as well, been really looking forward to check my graphics on the DMD again.

In theory does this mean that if you manage to send the same Byte Array over from Godot to MPF as MC did to MPF, that in theory from that point in MPF everything could still work?

To view this discussion visit https://groups.google.com/d/msgid/mpf-users/a3611cc6-cc85-4a22-81ee-ab36712f2992n%40googlegroups.com.

[Anthony van Winkle]

I've made some progress and it's looking reasonable, I've got a byte array of DMD pixel data sent back to MPF with the same event command as MC used, so in theory from that point in MPF everything should work the same. There may be some nuances to how the data is structured, but that can only be verified through an actual test or by comparing the event sent by MC.

If somebody is able to run their game in verbose mode (with -v -V in the command) and share the MPF and MC logs, that may help to see what the existing events look like. Don't need much, just a few slides appearing.

The one possible hurdle I'm seeing now is that the pixel data is pulled directly from the graphics card video buffer, which means it only works when the GMC window is present and visible on the screen. So if the machine is running without a monitor (or even if there's another window in front of the GMC window), no pixel data is rendered. I'll look into another way to read the pixels, but looking at the MC code that also appears to be pulling from the GL buffer. 

Can somebody confirm whether the 0.57 DMDs work and show/update slides if the MC window is not visible?

[Laurent Maillard]

Hi Anthony,
First of all, thank you for your help in resolving this problem.

I can confirm that on my win11/MPF 0.57 machine, even without an LCD screen connected, the Pin2DMD displays the slides correctly.

I am attaching to you below the logs of the attract mode of my machine

Thank you

Laurent

[Laurent Maillard]

oups... wrong logs...

Here ar the ones with the -v -V

[Anthony van Winkle]

Thanks! Unfortunately it looks like even verbose mode isn't logging the DMD data, but we'll soldier onward. 

Fortunately I was able to find something new in Godot 4.3 that allows the renderer to continue processing even when the window is not in focus, so please make sure you're all on 4.3 before proceeding (if you have 4.2, you should be able to upgrade without any changes needed).

Here's a sample project I'm using to test the flows, please check it out and add your DMD hardware configuration and see if you can get it to run. It should open attract mode with a red/green/blue screen and every few seconds change the positions of the colors.

https://github.com/missionpinball/mpf-examples/tree/dev/gmc_dmd

Please hook it up to your DMD and see if anything happens!

[Johan Gill]

Hi Anthony.

Thanks, much appreciated. Can't wait to see what you come up with.

Merry Christmas!

/Gill

To view this discussion visit https://groups.google.com/d/msgid/mpf-users/cbef1eb9-8951-4ef8-832d-112b0e289aaen%40googlegroups.com.

[Laurent Maillard]

Ok Anthony,
I'm going to try that tomorrow morning because it's currently past midnight here in France and I'm not going to take my DMD apart at that time :p
I'll let you know as soon as it's done.

See you tomorrow !

Laurent

[Laurent Maillard]

I'm Back :)

This morning I dowloaded your gmc_dmd folder on github,
installed my pin2dmd on my desktop machine

and configured it as I did with MPF 0.57.

I tried to fire it up but unfortunately, nothing showned up on the pind2dmd...

not sure if I'm doing something wrong or if the system is not operationnel yet...

the pictures belows show what I got by now and I join the log too (whithout -v -V options).

Hope this will help you :)

[Sector 8 Music]

Hey Anthony,

I have set up the project you send and tested as well. I've added the requested log.
Just as Laurent I don't get an image on the screen. In the log I do notice that the Smartmatrix is being recognized by mpf.80. (also if its not connected, MPF won't even fire up, but that has always been like that.)

Here are my updated files as a reference. 
Also this was the old reference how I set up in the past. 
https://missionpinball.org/latest/hardware/smartmatrix/

So does the Display: in Yaml actually still do anything?
Just or the sake of the test i did change the screen name to dmd in the godot just in case to match it with the smartmatrix settings.

Thanks for looking into this!

Best regards.

Jordy de Lat

To view this discussion visit https://groups.google.com/d/msgid/mpf-users/dce2a8ae-66d4-48f4-a660-00d400632c36n%40googlegroups.com.

[Anthony van Winkle]

Okay, made some progress I think!

I've got the serial communication back to MPF working and the RGBDMD platform devices are accepting the commands, so that seems promising. I've updated the code on the repo with the latest: https://github.com/missionpinball/mpf-examples/tree/dev/gmc_dmd

You can see in the config.yaml the hardware configuration I setup, yours will of course vary but there is no requirement for window: or displays: sections. There is one important thing you need to configure and that's the name of the dmd (under the rgb_dmds: section). In the sample repo it's named fast_rgb_dmd, and in the godot scene dmd_window.tscn the main Window has a child node (of type MPFDMDDisplay) and the node name is also fast_rgb_dmd. It's necessary for you to make sure your DMD node name matches the rgb_dmd name in your config, because that's how MPF knows which DMD to update.

Let me know how it goes!

[Samuel Chauviere]

Congratulations Anthony, it seems to work well here, I just kept the name default for the pin2dmd in rgb_dmds' config section and in the godot scene dmd_window.tscn.

A small vid to share : https://drive.google.com/file/d/1lD_AaBx5qVryDCq-YDLoKJx0p1kvNaty/view?usp=drive_link

Thanks Anthony and Merry Christmas to all the MPF Community !

Samuel

You received this message because you are subscribed to a topic in the Google Groups "MPF Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mpf-users/eTe_1PEFQq4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mpf-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mpf-users/5aa9433f-7ba7-4b3d-bb38-b172534c2be9n%40googlegroups.com.

[Sector 8 Music]

Thank you Anthony!

Its also working on my end, I'm gonna update my game and see how it goes from there.
I have one little issue though, and I think handled this previously.
In the config_spec.yaml. You will see under rgb_dmd's the option: channel_order: single|lstr|rgb
back then I asked Jan if he could add the option to switch color channels around. Because funny story my RGB pannels aren't actually RGB but RBG.

So in Godot I came up with this solution in the mpf_dmd_display.gd

In my head it makes the most sense to change the channels after the image is captured. so in the _capture() function. Since you don't want this effect to happen on your other screens or your virtual window.

for y in range(resolution.y):
        for x in range(resolution.x):
            var color = tex.get_pixel(x, y)
            var new_color = Color(color.r, color.b, color.g, color.a)
            tex.set_pixel(x, y, new_color)

This pretty brute forcing it, maybe you have a cleaner solution to do this?

Let me know! if something like this can be implemented again :)

Best regards,
Jordy de Lat

To view this discussion visit https://groups.google.com/d/msgid/mpf-users/5aa9433f-7ba7-4b3d-bb38-b172534c2be9n%40googlegroups.com.

[Sector 8 Music]

So to follow up i did a quick implementation on my game. (sorry for the crappy quality, the contrast of the graphics is amazing in real life, the camera really does not do it any justice).
I'm very very happy, thank you! and merry christmas!

[Laurent Maillard]

hello everyone!
back from the Christmas holidays...

it actually works!

Well done Anthony!

now, in practice...

it's rather difficult to work with a 128x32 display on the PC...

Before, with 0.57, we had the possibility of working with a 1280x320 window on the PC and 128x32 on the pin2dmd

It was a super comfortable set up.

now it looks like we are limited to 128x32 everywhere... :)

Do you think there is a trick to continuing to work as before with godot??

Maybe by creating a second window in godot which copies the contents of the DMD and applying a scale to it?

In any case, Big THANK YOU to Anthony for his remarkable work for the community

Laurent

[Anthony van Winkle]

Thanks for all the great feedback and testing!

DMD SIZING

I've changed the implementation of the DMD "resolution" property, instead of cropping to these dimensions the screen will now be RESIZED to these dimensions. This means you can render your project and slides at 1280x320, or any resolution you want, and the rendered frame will be resized to the DMD dimensions (no interpolation) before sending to the hardware.

Of course without a working DMD I can't verify that this is working correctly, but I do see that the number of bytes being sent is correct for the pixel dimensions of the display so I feel optimistic that it's right.

PIXEL RGB SHIFTING

I've implemented two options for this: a software-based one (from Jordy's mockup) and a hardware-based one (using a GPU shader). I've tested them both and they seem to work as expected, and I've included both RBG and GRB as options.

Currently the GPU-based option is not hooked up and will fall back to the software option, because I'm still sorting out the best way to "publically" implement the GPU option. The GPU-based shifter will be more performant because it uses the GPU-accelerated shaders to do the calculation, not the CPU. However this is done at the lowest level in Godot, so the editor and any screens will also be impacted, which will look wrong everywhere except the DMD. I'm working out the best way to mitigate this and also make it easy to apply without messing with the core GMC scenes, but it's kinda hairy so I've got it on pause. For now, the software-based option should work for you all. It does the shifting after the resize, so it's only a few thousand operations and shouldn't be noticable on your development computers.

Good luck all! Love seeing your projects!

[Sector 8 Music]

Hey Anthony!

Thank you for the updates again!

DMD SIZING
This works mostly as expected, I keep my resolution down to 128x32. but my project settings are set up that I can resize my window and maintain the pixel art style. (see video)
Rescaling the screen capture of the viewport does work as you can see. However I do seem to have a small rounding issue when the screen capture is scaled back to the DMD dimensions, so things like UI could be off by a pixel if you are scaling up. (as you may notice in the video as well)
So i think if you are fine tuning the graphics on your DMD, its best to work native.

PIXEL RGB SHIFTING

That works nicely! Thanks for implementing the idea! 
I imagend that the GPU was better suited to do this, but I have no knowledge of shader language. 
But I agree with you, for now the software option will do just fine :)

Thanks again!

To view this discussion visit https://groups.google.com/d/msgid/mpf-users/2817a1e1-d879-4005-a04b-67b80ad7e04bn%40googlegroups.com.

[Anthony van Winkle]

That's great! Glad things are working well, and when folks start getting into the in-machine CPUs and need that GPU acceleration, I can revisit.

For the pixel shift, yeah that's going to happen (especially with the no interpolation, which is most performant). I don't expect most folks to be dynamically resizing the source window, and especially if the window is a clean multiple of the DMD resolution it should be consistent and true. 

So happy to see those DMDs alive in GMC!

[Sector 8 Music]

Definitely awesome to see this work! 

Sounds like a plan! And yes I completely agree about the resizing of the viewport.

Thank you again Anthony! 

To unsubscribe from this group and stop receiving emails from it, send an email to mpf-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mpf-users/83cdd036-2da0-4d77-bf1a-63f73b42edb7n%40googlegroups.com.

[Laurent Maillard]

Hi !

It took me a few hours this morning to figure out why the latest version of gmc-dmd wasn't working well for me...

I mean, it worked perfectly with Anthony's attract slide but as soon as I tried to put some of my pngs into the attraction slide, the DMD screen showed no images at all. (except for the little overlay in the top left corner of the screen)

after scratching my head I was able to realize that the "problem" was the way the resizing was handled.

Indeed, the pixelart style images displayed perfectly, but my pngs are not drawn like that... I spent hours drawing them in a Dot Matrix style, which means that my pngs are made up of a bunch of 10 x 10 colored circles (not squares) on a transparent background....

As soon as I used an offset of (-5,-5) to place my pngs, they were displayed on the DMD :-))

 I assume the resizing process samples the top left pixel of the squares, which in my case are... transparent!   :p)

so... do you think there is a way, during the resizing process, to shift the sample point?


Thanks in advance

And in any case, thank you Anthony for your work and all the time you spend for us !

Laurent

To view this discussion visit https://groups.google.com/d/msgid/mpf-users/83cdd036-2da0-4d77-bf1a-63f73b42edb7n%40googlegroups.com.

[Anthony van Winkle]

That's an interesting conundrum. There's nothing built in for how to manage the downsize resampling, but some other approaches may work.

If your final output is going to be for the DMD, there's no reason to (1) have your PNGs at a higher resolution than the DMD, nor to (2) have transparency baked in. These both increase the cost and computational complexity of rendering the PNGs, which then requires more cost and complexity to revert when rendering for DMD.

The ideal long-term solution is to redo your PNGs to be pixel-accurate to the final DMD, which could be done with a batch script or specific resizing parameters to yield the center color of the 10x10 square in a way that GMC can't. If you can't find a good batcher to interpolate from the center, cropping 5px of the top and left of the image and then resizing down to DMD resolution (with no interpolation) should yield the same effect as sampling the middles of each.

Alternatively, there is a shader I built for GMC called pixelate which will reduce the output to a specific number of rows and columns. I don't know exactly whether the pixel image is top-left, center, or average, but you could explore. This may be able to counteract your PNG setup, but again, adding computational complexity instead of addressing the root issue.

If you want to simulate the appearance of DMD dots on your monitor, there's another shader called dmd_dots which creates an overlay of circles with some configurable parameters to tweak the appearance. There's also a shader called virtual_dmd which combines the pixelate and dmd_dots into one. 

However the fundamental question is: do you want to simulate a DMD on an LCD, or do you want to render to an actual DMD? Your underlying slides and assets should be built for whatever the end target is, and if you want to have another experience (e.g. previewing the DMD on a monitor) that should be done after-and-on-top-of the target experience.

[Laurent Maillard]

Indeed, taking a step back, it makes sense.

If we can, on the lcd display, apply an overlay to simulate the points of a dmd, then we can render the pngs in pixel art style (without including transparency) and still have a realistic display on the pc to test the slides…
I think i will be able to quickly code a small script in python to transform my circles into squares. i.e. sampling the center of my circles and apply the colour to the 10x10 square around it.

Thanks for the lead anthony.

Here is yet another proof that it is always good to share with a community, it allows to open up avenues when we think we are at a dead end :)

Laurent