VFD display techniques

[james-wallace-ghub]

I've been back and forth with @cuavas over this, but I'd love to thrash it out once and for all, since I think that MFME2MAME is probably going to need a decent template for this.

Basically, the Bellfruit dotmatrix VFDs, and pretty much anything using the 1937 MCUs for VFD control (so that's pretty much every 14 and 16seg that isn't Bellfruit) have a modifiable duty control.

In the past, I used to use the 'animate' feature in the artwork, fiddling with the alpha values, but that doesn't really work.
This is my current approach, so 0 is the colour of the standard off element, and 31 is fully on, so you get an effect to change the colour. The problem is the component has a built in 'off' colour - an artifact from me and Haze forking it from the LED code I think, but obviously the off segments are there.

			<element name="vfd~i~" ref="vfd0" blend="add">
				<animate name="vfdduty0"/>
				<color state="0" red="0.14" green="0.14" blue="0.14" alpha="1.0"/>
				<color state="31" red="0.00" green="1.00" blue="1.00" alpha="1.0"/>
				<bounds x="~x~" y="320" width="17" height="30"/>
			</element>

I could take the off colour out, but that feels wrong too, so I don't know what the best action is. There are other tricks you can do to not have an off colour, just have a blank (j6sonic does that, where I made an SVG pattern out of the real VFD glass to show instead of the inbuilt graphics). I'd use that all the time if it wasn't that embedding a full on SVG in every layout will be a pest.

[johnparker007]

I did a workaround like James's above, but that doesn't require an SVG for the 'off image' - if this is acceptable, this is how it's already coded in the new MFME2MAME that's under development for the second more comprehensive pass at building all fruit machine layouts - example grabbed from one of the new WIP test layouts:

<element name="vfd_character">
    <led16segsc />
</element>

<repeat count="16">
    <param name="x" start="105" increment="17.00" />
    <param name="i" start="15" increment="-1" />
    <element ref="vfd_character">
        <animate name="vfdduty0" />
        <color state="31" red="0.00" green="1.00" blue="0.00" alpha="0.00" />
        <color state="0" red="0.00" green="1.00" blue="0.00" alpha="1.00" />
        <bounds x="~x~" y="305.00" width="17.00" height="30.00" />
    </element>
</repeat>
<repeat count="16">
    <param name="x" start="105" increment="17.00" />
    <param name="i" start="15" increment="-1" />
    <element name="vfd~i~" ref="vfd_character">
        <animate name="vfdduty0" />
        <color state="0" red="0.00" green="1.00" blue="0.00" alpha="0.00" />
        <color state="31" red="0.00" green="1.00" blue="0.00" alpha="1.00" />
        <bounds x="~x~" y="305.00" width="17.00" height="30.00" />
    </element>
</repeat>

However if not, I guess it'll just need the internal component itself redoing in some way in MAME source, to draw 2 quads/custom shader using the individual alpha channel as the duty channel to blend/some other way that's appropriate to how you guys want to achieve this in the MAME codebase style.

From my side, with the workaround above already implemented, they all render correctly at present, so if nothing changed it'd look good... though I appreciate it may be worth rewriting the component internally to something that is a better fit for MAME's internal artwork system style :)

[james-wallace-ghub]

The issue with the above is that you're doing the animation twice, you don't need to as far as I can tell, so something like:

`

    <repeat count="16">
        <param name="x" start="105" increment="17.00" />
        <param name="i" start="15" increment="-1" />
        <element name="vfd~i~" ref="vfd_character">
            <animate name="vfdduty0" />
            <color state="0" red="0.00" green="1.00" blue="0.00" alpha="0.00" />
            <color state="31" red="0.00" green="1.00" blue="0.00" alpha="1.00" />
            <bounds x="~x~" y="305.00" width="17.00" height="30.00" />
        </element>
    </repeat>

`

Would match what you're talking about.
However, this has the issue I'm talking about, which is that 0 will be a blank character (no value), and the off segments will appear to 'fade' in because they're built into the component. What you have is very similar to what I was originally doing, until that artefact became clear.

[johnparker007]

"and the off segments will appear to 'fade' in because they're built into the component"

Sorry, I don't think I made it clear how the workaround does its thing :) Right, so we intentionally draw it twice, that is the trick, then, when an character is 'off', its off segments are still drawn:

So, when vfdduty is at full brightness, it is drawn like so:

And I captured this as it had just faded out fully a message during the attract (note the off segments are still rendered correctly):

And tried to capture one, as it was somewhere near halfway through a fade (note the off segments are still rendered correctly):

If you check the code above again, you'll see the fact there are 2x draws (on purpose) is why this works, with normal and also inverted vfdduty -> alpha mapping.

Hope that makes sense now :)

Like I said, it still is a workaround though, but it does work perfectly well in terms of looking correct...

Edit: I have spotted on reviewing this, that the <param name="i" start="15" increment="-1" /> could be removed from the first pass, as it's not referenced, since it's just drawing the blank, so it could be a more concise workaround - so it could be:

Drawing the off segments, with the alpha inverse to the alpha of the populated segment that will be drawn next:

<repeat count="16">
    <param name="x" start="105" increment="17.00" />
    <element ref="vfd_character">
        <animate name="vfdduty0" />
        <color state="31" red="0.00" green="1.00" blue="0.00" alpha="0.00" />
        <color state="0" red="0.00" green="1.00" blue="0.00" alpha="1.00" />
        <bounds x="~x~" y="305.00" width="17.00" height="30.00" />
    </element>
</repeat>

Drawing the on segments, as these fade, the off segment drawn previous will be in sync so the off segments render correctly

<repeat count="16">
    <param name="x" start="105" increment="17.00" />
    <param name="i" start="15" increment="-1" />
    <element name="vfd~i~" ref="vfd_character">
        <animate name="vfdduty0" />
        <color state="0" red="0.00" green="1.00" blue="0.00" alpha="0.00" />
        <color state="31" red="0.00" green="1.00" blue="0.00" alpha="1.00" />
        <bounds x="~x~" y="305.00" width="17.00" height="30.00" />
    </element>
</repeat>

[james-wallace-ghub]

Oh, you've drawn it twice, mirroring it. I see it now, that's not a bad workaround then actually, I'll try it out myself tonight and see what works.

[james-wallace-ghub]

Just put a few of these in different techs, they look OK to me

[johnparker007]

Ah cool :) I think I tried it only on MPU4 to be honest, but if you think it's an acceptable workaround then that is good to hear - I don't need to change anything here as it's already set up to do that - though later I'll need to set which platforms support vfd duty for brightness effects.

…

On Mon, Dec 19, 2022 at 8:26 PM James Wallace ***@***.***> wrote: Just put a few of these in different techs, they look OK to me — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEGOYYOQNHIPBFVOJYAQV7TWODAGPANCNFSM6AAAAAAS3GGCU4> . You are receiving this because you commented.Message ID: ***@***.***>

[james-wallace-ghub]

As far as I can tell, everything other than Global Games' "Stealth" platform that uses the same hardware can do this fade. Maygay M1, MPU4, JPM's Alphas and (I think) some early BFMs. Basically anything that MFME labels as having the 1937 chip can support it. Games that don't use it will still set it to something, as the reset behaviour is to set it to 0.

In fact, I turned it off for Stealth because, although it uses the same charset (or looks like it does), the duty is never set to anything other than 0, so it's clearly slightly different hardware.

[johnparker007]

Good to know, so I'll just set it at platform level, and it sounds like most platforms will want their layouts to have the vfdduty support in. I just checked Rat Race (an MPU3) and that has fade effects during attract too...

…

On Wed, Dec 21, 2022 at 7:37 PM James Wallace ***@***.***> wrote: As far as I can tell, everything other than Global Games' "Stealth" platform that uses the same hardware can do this fade. Maygay M1, MPU4, JPM's Alphas and (I think) some early BFMs. Basically anything that MFME labels as having the 1937 chip can support it. Games that don't use it will still set it to something, as the reset behaviour is to set it to 0. In fact, I turned it off for Stealth because, although it uses the same charset (or looks like it does), the duty is never set to anything other than 0, so it's clearly slightly different hardware. — Reply to this email directly, view it on GitHub <#19 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEGOYYLANHKDOONQCCEOUETWONL75ANCNFSM6AAAAAAS3GGCU4> . You are receiving this because you commented.Message ID: ***@***.***>