Question - IDE [UNRESOLVED] Bug with the font glyphsheet generator

[Elevory]

I have created a font resource using Pixel Love and the glyphsheet that GameMaker has come up with is a garbled mess (see attached). Here's what's interesting:

• Four or five months ago, I imported the same font and GameMaker rendered an accurate glyphsheet (see attached). I have directly imported the old glyphsheet and corresponding .yy file into my project through the filesystem, and now the font looks correct in-game--that is, until I accidentally touch anything that causes GameMaker to generate a new glyphsheet. Frustrating!
• I had planned on replacing Pixel Love with Pixeljosh6, but GameMaker is having trouble with this one as well.
• Here's a screenshot of the font resource as it appears in the IDE. As you can see, it looks fine in the preview panel.

In addition to the attached glyphsheets, I have uploaded the contents of the garbled .yy file and the contents of the older, accurate .yy file. Please let me know if I need to provide anything else.

Anyone else run into bugs with the glyphsheet generator? Any suggested workarounds?

Thanks!

EDIT: I just tried a couple of things that didn't work:

• I read somewhere that GameMaker can have trouble parsing glyphs at small sizes, so I tried setting the font size from 6 to 24
• I changed my IDE skin and DPI settings back to default out of desperation

 

[rwkay]

Not sure why you think is garbled - GMS (1 and 2) will order the font on the texture as it sees fit and creates an atlas that we use to index the glyphs.

It is working as intended...

Russell

 

[Elevory]

Not sure why you think is garbled - GMS (1 and 2) will order the font on the texture as it sees fit and creates an atlas that we use to index the glyphs.

It is working as intended...

Russell

Check out the top row of characters in font_garbled.png. The top half is missing. I can upload screenshots of how this looks in-game, if you would like.

EDIT: Here's the same file set against a black background, for your convenience:

EDIT 2: In order to rule out the possibility of a coding error on my part, I started a new GameMaker project, imported the suspect font and drew it to the screen:

Not a bad technique if you're going for some quasi-Arabic effect Unfortunately, I need the font to produce English

 

[Elevory]

Bump. Would anyone be so kind as to see if they can reproduce the issue? Thanks.

 

[gnysek]

As long as we can't provide own PNGs and set which gylph is where, I see no hope to have ideal font rendering. GMS already saves gylph data with edge positions, but don't allow to user to update it, automatically exporting it each time you update font resource.

 

[Elevory]

As long as we can't provide own PNGs and set which gylph is where, I see no hope to have ideal font rendering. GMS already saves gylph data with edge positions, but don't allow to user to update it, automatically exporting it each time you update font resource.

This is a good point. The tragedy, in my case, is that a previous version of GameMaker processed this font perfectly. Now I have to tiptoe around the IDE to make sure the old glyph data isn't overwritten.

At this rate, I may need to prepare the font as a sprite, but that seems like a lot of work.

Were there any documented changes to font resources in the last few months? I don't recall seeing anything like that in the changelog.

 

[gnysek]

They changed how font is generated in 2.0.2

A font-generation issue which caused fuzzy and mis-aligned text in-game has been fixed

 

[Elevory]

Interesting! Thanks for pinpointing the version number. Looks like that release is from November of last year. A bit older than I would have guessed, but still likely to be the culprit.

 

[rwkay]

please file a bug about this and include the font that you are rendering from so we can replicate the issue.

We are upgrading the version of FreeType we use (in both the IDE and the runtime) so this may well be addressed with that update, but until we can replicate the bug you are seeing we cannot tell.

Russell

 

[Elevory]

You got it. Thank you for the support.

EDIT: Report submitted.

 

[Elevory]

Any word about whether you have been able to reproduce the bug? v2.1 appears to have the same problem with the fonts in question.

 

[yuigoto]

I don't know if it's related to this, but I have a small issue with the font generator now (I just filed a bug report on this). Some fonts, which used to render really nice and pixel-perfect, like Ubuntu, Ubuntu Mono and even Verdana, are being generated a bit "uglier" now.

On the screenshot below, to the left is an older build of a test project I didn't tamper with, to the right is a project I just updated and opened the font to see if the character range was right.

Both fonts are the same, in every aspect: Ubuntu Mono, 8px, bold, non-aliased. The screen to the right, though, was taken after I upgraded GMS2 to the latest version.

P.s.: I tried pixel love once, before and had the exact same problem. :/

 

[gnysek]

Try to change font size, close font resource, open and change font size back, then again close - it should regenerate images (normally it uses cached ones and updating GMS won't update them, even when clearing asset cache - as font is copied from locally generated image in project source).

 

[yuigoto]

Thanks, gnysek, but I already tried everything, even uninstalling/installing GMS2, and it didn't work. Fonts are still being generated with a different look than they used to.

The attached image shows how the font spritesheet was before updating and after updating on the same project:


I also put the generated JSON files here: https://gist.github.com/yuigoto/86c7a935ad75312392ca4c802c14a0de.

 

[Jobo]

I don't know what pixel love is, but if you're using third-party applications then please rule them out before submitting a bug. Also be aware that if you're using a variant of draw_text_transform then the 'sep' parameter sets the line height, which will change alignment etc. when drawing. I fixed a bug recently regarding this font texture output - it may be related. That fix should be in the next update.

Most of the time rendering issues occur with non-standard fonts is down to the font not providing the correct information, so also try different fonts. If you send a PM to me with a CLEAN reproducing project then I'll take a look at some point - might have been fixed.

 

[yuigoto]

I don't know what pixel love is, but if you're using third-party applications then please rule them out before submitting a bug. Also be aware that if you're using a variant of draw_text_transform then the 'sep' parameter sets the line height, which will change alignment etc. when drawing. I fixed a bug recently regarding this font texture output - it may be related. That fix should be in the next update.

Most of the time rendering issues occur with non-standard fonts is down to the font not providing the correct information, so also try different fonts. If you send a PM to me with a CLEAN reproducing project then I'll take a look at some point - might have been fixed.

Thanks for looking, Jobo.

Pixel Love is a true-type font-face (www.dafont.com/pixel-love.font).

On my problem about font rendering at least, no third-party applications were used when generating the fonts, GM just generated the fonts differently than it used to.

Just creating a font using the Ubuntu Mono (8px, bold, non-aliased) font in a blank project results in the font being created like the one in red background, while it used to generate like the one in blue before, not mattering if I'm using draw_text or draw_text_transform.

Even fonts, which have been fine-tuned/hinted for small sizes, like Georgia, Verdana or Arial, do render differently, like in the attached screenshot.

I'll test a bit more, and wait for the updates then. For now, I'll keep using aliased fonts or fonts with a strict pixelated look.