Default dot color in virtual DMD is too dim

[coding-horror]

I have always thought the virtual DMD is way too dim, and I blamed my small 10" IPS DMD monitor.. but now I realize, the virtual DMD is simply too dim!

Compare the Pinball Arcade DMD with the Virtual DMD:

1. The dot sizes should be a bit tighter, closer together
2. The virtual DMD brightness needs to be amped way way up!

[freezy]

Hmm yeah you're right. The colors are trivial, need to see how to parameterize the dot size.

[coding-horror]

I think you should bump intensity a lot for default, definitely. It's way off out of the box.

[coding-horror]

I am trying to load this in Visual Studio 2017 and I am in dependency hell currently.. the main error in my build log is

The tag 'VirtualDmdControl' does not exist in XML namespace 'clr-namespace:LibDmd.Output.VirtualDmd;assembly=LibDmd'. Line 26 Position 10. App C:\Users\Jeff\Documents\GitHub\dmd-extensions\App\MainWindow.xaml

I can't even locate the correct code that maps the DMD dot to a color intensity before drawing. I'll keep looking..

[freezy]

I've also tried to load it in VS2017 once and it gave me shit. I'm still using VS2015. One thing you'll need to do is go to the PinMameDevice project and clear (or adapt) the post build event which copies the DLL to the VPM folder. Otherwise it should compile okay (note that there are C++ projects to build as well).

One obvious fix for the intensity is changing the default render color in RenderGraph.DefaultColor. What you also can do is play with the algorithm that interpolates the shades for a given color, which is ColorUtil.GetPalette().

[coding-horror]

I'll need to install VS2015 I can't build at all in VS2017 due to the above error.

[freezy]

Can you create an issue for VS2017 please? I'll need to fix this at some point.

On Aug 5, 2017 9:14 AM, "Jeff Atwood" notifications@github.com wrote:

I'll need to install VS2015 I can't build at all in VS2017 due to the above error.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/freezy/dmd-extensions/issues/59#issuecomment-320423400, or mute the thread https://github.com/notifications/unsubscribe-auth/AAETGu0aI9Vay-9v-bLSMn1fLDdrr0rqks5sVBZPgaJpZM4OtVHH .

[coding-horror]

Well, I am boned, you cannot download Visual Studio 2015 without a MSDN subscription :(

[freezy]

Ah those rats!

Will look into this later today.

On Aug 5, 2017 11:54 AM, "Jeff Atwood" notifications@github.com wrote:

Well, I am boned, you cannot download Visual Studio 2015 without a MSDN subscription :(

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/freezy/dmd-extensions/issues/59#issuecomment-320434404, or mute the thread https://github.com/notifications/unsubscribe-auth/AAETGvbQP0vIDqKlpHV2WF3zwduKIltWks5sVDvIgaJpZM4OtVHH .

[coding-horror]

I can build so I am finally experimenting! You said

One obvious fix for the intensity is changing the default render color in RenderGraph.DefaultColor. What you also can do is play with the algorithm that interpolates the shades for a given color, which is ColorUtil.GetPalette().

I also added a Console.WriteLine("test"); so I know my custom EXE is running, but under Pinball Arcade setting all these values to Colors.Red makes zero difference! Very odd. The virtual DMD looks exactly the same under my custom EXE as the default one.

[freezy]

Okay, this has two reasons.

1. Capturing Mode

The TPA grabber actually implements two modes. In the first mode it grabs the texture and returns it as Bitmap. This is the method defined by IBitmapSource.

The second mode grabs it as 4-bit grayscale byte array. That's the IGray4Source interface.

Since the virtual DMD implements the IBitmapDestination, the render graph chooses IBitmapSource as source mode over IGray4Source, because the source format is the same as the destination format and hence more performant. Given a bitmap is just a bunch of pixels, there is no coloring of any kind applied, the pixels are just as-is passed from the grabber to the virtual DMD. That's why the render graph's default color is ignored.

In order to fix that, force the TPA grabber to the second mode, the 4-bit grayscale mode. To do that, just remove IBitmapSource from the TPAGrabber's implemented interfaces.

2. Default Color

You'll notice that instead of Connecting Pinball Arcade DX11 to Dmd (Bitmap => Bitmap), it'll now print Connecting Pinball Arcade DX11 to Dmd (Gray4 => Rgb24). That means the coloring is done by dmdext. However, there's one thing I've missed when talking about changing RenderGraph.DefaultColor: There is already a command line parameter that does that.

The --color parameter has a separate default value (defined at DmdExt.Common.BaseOptions). That's the value the colorizer will take when converting the 4-bit byte array to a bitmap.

TLDR; Remove IBitmapSource from the TPAGrabber and use the --color parameter to fiddle with the right color.

[coding-horror]

That does seem to work, I tried --color ff0000 and I got this

The small dot size is still a problem though; how do I increase the dot size so they are closer / touching to increase the visibility to better match the real DMDs?

[coding-horror]

Putting these side by side to see the difference.. quite dimmer

[freezy]

That's the shader. If you change anything in that file you'll need to manually recompile it into Dmd.ps. However that's usually not necessary because pretty much everything can be parameterized. You can do that here.

[freezy]

The Effect.Max property should change the dot size.

[freezy]

And if you're good with shaders, feel free to add some glowing effect, that's still also on my list :)

[coding-horror]

I tried

Effect.Max = Effect.AspectRatio * 0.5;

But this results in an eventual

Unhandled Exception: System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at LibDmd.Common.ColorUtil.ColorizeFrame(Int32 width, Int32 height, Byte[] frame, Color[] palette, Byte[] colorizedFrame) in C:\Users\Jeff\Documents\GitHub\dmd-extensions\LibDmd\Common\ColorUtil.cs:line 252

Due to math issues, I suppose.. I changed it to

Effect.Max = Effect.AspectRatio * 0.47;

And that seems stable in a minute or so of playtime..

Certainly far, FAR closer to real DMD look with this, I strongly recommend that be the new default size.

[freezy]

Well, my physical DMD has much larger padding ;)

But I get it that it's more attractive the lighter it is. Maybe a parameter? --virtual-dotsize=large?

[coding-horror]

I think the difference is that those LEDs are SUPER SUPER bright so visually they generate a massive halo and look closer together in the real world.

I believe the Pinball Arcade visual representation is more correct, and should be copied as default.

[freezy]

Sure, let's go for it then and add only the parameter if people start complaining. ;)

[coding-horror]

A value of 0.5 is slightly better IMO, moving up to 0.6 is definitely too far though. 0.55 is ... aggressive. But closing this as complete for now!

[Rallyace]

Unfortunately the latest .dll looks way worse on my set-up. I think there needs to be a setting to change the dot size, as people using virtual DMD's scale them differently depending on screen size, resolution and also depending on the grill size on the backglass.

[freezy]

Can you post a screenshot so we can be sure we're talking about the same? Before/after would be ideal.

[freezy]

Option added to change size back to normal.

• With dmdext.exe, use --virtual-dotsize=0.8.
• With DmdDevice.dll. add dotsize = 0.8 under [virtualdmd] to DmdDevice.ini.