Add optional argument such that MSDF font pxrange is scaled by scribble_font_scale()

[caroparo]

I have a zh msdf font A that is generated with { size: 64, pxrange: 16 } that I scribble_font_scale() by 0.5, to merge with another en alphabet+numbers font B that is { size: 32, pxrange: 16 } using scribble_super_glyph_copy.

It works, but then thick borders tend to cause issues easily, so I decided to regenerate the zh font A with { size: 64, pxrange: 32 } to match the size/pxrange ratio of the en font B. However, this causes scribble_super_glyph_copy() to fail due to the unscaled pxrange mismatch. I then tried to modify scribble code so __msdf_pxrange is also scaled in scribble_font_scale() and the end results seem okay.

I wonder whether this is an overlooked corner case issue in scribble, or would it cause other issues if I scale __msdf_pxrange like described?

[JujuAdams]

It's been a while since I dived into MSDFs ... let me check what my original thinking was.

Edit: Ok - this is not a bug and is, as it stands, intentional.

The font scale set by scribble_font_scale() is communicated all the way down through into the MSDF renderer shader as you'd expect. However, by default and at the request of previous users, the border scale is not proportional to the scaling factor for the font. This was to create a more pleasing appearance when combining text using the same font but using different scales e.g. 1[scale,0.5]st[/scale].

You can change this behaviour by swapping #define PROPORTIONAL_BORDER_SCALE in __shd_scribble_msdf to true. Be warned that this will allow other scaling operations to change border thicknesses (but not .transform()).

Now, this is obviously not great for your use and is indeed a missing feature. This should be implemented as an optional argument to scribble_font_scale() which would then control if the MSDF pxrange is scaled alongside the font scale.

Final twist in this story: I'm looking to work on Scribble 9 over Christmas and this will throw away all MSDF features in preference for GameMaker's native SDF functionality - whilst the end result isn't quite as nice, the ease-of-use benefits are substantial. The feature that we've settled on here won't be implemented for a hypothetical v8.8 but I will bear it in mind for v9.0.