Fixed hud text scale being ignored with the custom font disabled

[c8dhjp4tyv-bit]

Type of change

• Bug fix
• New feature

Description

With Custom Font disabled, the hud's Text Scale setting (and any per-element scale passed to HudRenderer#text) has no effect: every hud element keeps rendering at the default size while its background, spacing and click box grow, so the text ends up floating in an oversized box. See the screenshots in #6570.

HudRenderer#text sets the vanilla renderer's scale for measuring but not for drawing:

public double text(String text, double x, double y, Color color, boolean shadow, double scale) {
    if (scale == -1) scale = hud.getTextScale();

    if (!hud.hasCustomFont()) {
        return VanillaTextRenderer.INSTANCE.render(text, x, y, color, shadow); // scale never applied
    }

while textWidth/textHeight right below it do apply it:

VanillaTextRenderer.INSTANCE.scale = (scale == -1 ? hud.getTextScale() : scale) * 2;
return VanillaTextRenderer.INSTANCE.getWidth(text, shadow);

So the element is laid out at the requested scale but drawn at whatever HudRenderer#begin left behind — VanillaTextRenderer.INSTANCE.begin(graphics), i.e. a fixed 1 * 2.

This was lost in the 26.1 update (#6266). Before it, text() had the INSTANCE.scale = scale * 2; line, and begin() set scaleIndividually = true so that the old batched renderer applied the scale per render() call instead of once for the whole batch. The rewritten VanillaTextRenderer always scales per call through graphics.pose(), so restoring the assignment is all that is needed:

Matrix3x2fStack matrices = graphics.pose();
matrices.pushMatrix();
matrices.scale((float) scale, (float) scale);
graphics.text(mc.font, text, (int) (x / scale), (int) (y / scale), color.getPacked());

scaleIndividually has been dead since that rewrite — the only remaining reference resets it to false — but it is public and addons shadow it, so it is left alone here; removing it is a separate call for you to make.

This does not touch the custom font path, and it does not affect text drawn outside the hud (modules use TextRenderer#begin(graphics, scale), which sets the scale itself).

Related issues

#6570 (the hud scaling case reported in this comment)

How Has This Been Tested?

./gradlew compileJava passes.

Isolating the arithmetic of both paths with vanilla font metrics (Font#lineHeight 9, 6px glyphs) shows the layout/draw mismatch and that it disappears with the fix — textWidth()/textHeight() are what the element lays itself out with, drawn is what actually ends up on screen:

scale  | textWidth()/Height()   | drawn BEFORE fix       | drawn AFTER fix
1.0    |     72.0 x 18.0        |     72.0 x 18.0        |     72.0 x 18.0
1.5    |    108.0 x 27.0        |     72.0 x 18.0        |    108.0 x 27.0
2.0    |    144.0 x 36.0        |     72.0 x 18.0        |    144.0 x 36.0
3.0    |    216.0 x 54.0        |     72.0 x 18.0        |    216.0 x 54.0

At the default scale of 1 nothing changes, which is why the bug only shows up once Text Scale is moved.

In-game with Custom Font off: changing Text Scale now resizes hud text as it does with the custom font enabled, and text fills its background again instead of sitting in an oversized box.

Checklist:

• My code follows the style guidelines of this project.
• I have added comments to my code in more complex areas.
• I have tested the code in both development and production environments.