Bitmap Font example for reference

[Brian Cox]

Hi all,

There was some discussion about bitmap fonts with MPF on another platform, and I wanted to share a working example for those that are figuring it out.

This biggest "gotcha" I found was that there's a specific file structure and location that has to be used or it doesn't work (or at least didn't for me):

...so, a folder called "bitmap_fonts" has to be at the top level of your game, and inside that are the font definitions and the images used. I've got six fonts in this example, basically different sizes and colors of the same font.

The font definition file (very stripped down) looks like this:

info face=font size= bold= italic= charset= unicode= stretchH= smooth= aa= padding=0,0,0,0 spacing=0,0 outline=0

common lineHeight=55 base=55 scaleW=40 scaleH=55 pages=1 packed=0

page id=0 file="bitmapFontBallySevenSegment4.png"

chars count=11

char id=48 x=0 y=0 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=49 x=0 y=55 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=50 x=0 y=110 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=51 x=0 y=165 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=52 x=0 y=220 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=53 x=0 y=275 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=54 x=0 y=330 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=55 x=0 y=385 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=56 x=0 y=440 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=57 x=0 y=495 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

char id=32 x=0 y=550 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 chnl=15

...and a typical corresponding image file is this:

Some things to note: 

• The file name of the image is defined in the .FNT file
• The ASCII code for each character is defined by a starting position (x, y for the upper left corner)
• ...and a width and height value.

At this point I'm able to use it in a config directly like so:

slides:

  slideBaseBackglass:

    widgets:

    - type: image

      image: imagebackglass

      z: 40

      # --------------------

      # BITMAP FONT TEST

      # --------------------

    - type: text

      text: (player1|score)

      z: 30

      x: left + 730

      y: bottom + 787

      anchor_x: right

      anchor_y: middle

      font_name: bitmapFontBallySevenSegment4

      bitmap_font: true

Hope this helps,

Brian Cox

 

[Dan - aka BorgDog]

Thanks Brian for the awesome example!

[Adrian DeGroot]

Thank you Brian! That worked first try in my Joust game!  It was a pleasant surprise to not see an error in the command prompt window!

[jabdoa]

I wrote some docs based on Brians example reference about. Should be up in a few minutes here: https://docs.missionpinball.org/en/dev/displays/widgets/index.html

Jan

[james cardona]

been playing with this for a few days and almost everything works as it should. Thanks to Brain and Jan for this!!

The only problem I have found is this: 

when using a bitmap font and I make the font slightly larger, for example placing a border around the font, the left side of the border gets clipped on the very first character of a string. I have intentionally increased the offsets for all of the characters so this would not happen and it works fine for all the other characters because of the offset, however, the first character of a string is still clipped, but only on the left side. I am not sure if this is an MC bug or a kivy bug, but I find nothing in MC that would do this in my very brief search. For now, I am using a "work around" of adding a leading space to all strings.

[Quinn Capen]

Are your xoffsets negative (can you post your font descriptor file)? It looks like the total width calculation for the character string only uses the width of each character (ignoring any offsets). If the first character in the string has a negative xoffset it will attempt to draw it at a negative coordinate which would be clipped likely leading to the behavior you are seeing. The xoffset refers to an adjustment of the destination coordinates not the source coordinates in the bitmap font atlas (how much the current position should be offset when copying the image from the texture to the screen). Are you trying to preserve the character spacing between the different versions of the font and therefore adjusting the offsets but not the character widths? 

Quinn

[james cardona]

I'm using bmfont program and it does indeed generate negative offsets. If I understand correctly, I should zero out the x offsets and add that value to the width?

--
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/xS07-MoSEa4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mpf-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mpf-users/cfd853e2-1fdb-4d27-a25f-1a707a7fd045n%40googlegroups.com.

[Quinn Capen]

No, don't make any changes. I'm just trying to fully understand the issue so I can fix it. Can you post your font descriptor file and font image file for me to play with?  I think I need to adjust the drawing routine for the first (and potentially last) character based on the xoffset value to avoid boundary clipping (adjust the starting position and extent).

Thanks,

Quinn

[Quinn Capen]

I was able to reproduce your issue using one of the fonts in the automated tests. The code definitely has a bug that starts drawing the first character in the wrong position (noticeable with first characters that have a negative xoffset value). It is also possible to clip the last character in certain situations as well. The bugfix will adjust the starting location to the beginning of the text label taking into account the initial xoffset value. This appears to fix the issue. I will post the fix in dev and then backport it to 0.54 so look for new builds soon.

Quinn

[Quinn Capen]

I created an issue for this bug: https://github.com/missionpinball/mpf-mc/issues/422

[Quinn Capen]

Bug has been fixed and released in mpf-mc dev (0.55.dev.9) and in 0.54.1

[james cardona]

Awesome! Tried it out and works great. One minor thing is I noticed the clipping on the right side of the last char in a string as well. 

To view this discussion on the web visit https://groups.google.com/d/msgid/mpf-users/47c6be24-a7c9-470e-b375-2087343433fbn%40googlegroups.com.

[Quinn Capen]

I see the method that calculates the overall size of the text does not quite match the actual drawing algorithm so with some font characters it can underestimate the actual text length and therefore chop off some pixels on the end. I will fix that as well and let you know when you can test it again.

Quinn

[Quinn Capen]

This should be fixed correctly now and has been released in mpf-mc dev (0.55.dev.10) and in 0.54.2. Let me know if you have any other issues with bitmap fonts.

Quinn

[james cardona]

looks awesome. Thank you Quinn!