StatusBarCore::DrawString doesn't scale correctly

[arookas]

The scale parameter of the ZScript function StatusBarCore::DrawString doesn't work correctly:

• Spaces are not scaled when rendering, but are scaled when measuring for alignment. Most right- or center- aligned text will not align correctly.
• The horizontal shifting to the draws makes all glyphs render to the left (as well as each be less wide). This can be mostly worked around by setting the left offset of each glyph's image to -1.

In my specific scenario, all scale factors are integral (1x, 2x, 3x, or 4x only) so it would be nice if text rendered consistently for the larger scales as it does for 1x.
Included is an example with a test statusbar and test room for a clearer background:

[Player701]

I was the one who originally authored the PR to implement the scaling feature for DrawString, so I've looked into this and applied some fixes. Your example now looks like this to me:



The overlapping of texts is because the strings on the left are now longer (the shifting issue has been fixed). Please tell me if this looks OK, and I'll submit a PR with the fixes then.

[arookas]

It looks to be improved, but it's unfortunately hard to tell with the filter enabled on the text.

The lengths appear to be correct, but the right-aligned scaled text overlaps the red line by one pixel. There is an offset font and non-offset font in the files, the former having an offset X of -1 on each glyph's texture. In theory, this offset should offset the text rendering over to the right by one pixel (multiplied by the draw scale) and should not affect the width of the glyphs. On the unscaled text, you can see the offset font and non-offset font start on the same column despite this. On the right-aligned scaled text, this is likely the cause of the overlap, but it's strange that the offset isn't scaled with the scale parameter.

Unrelated to this, when making this demo I noticed DI_ITEM_* flags do not actually change where the text renders and it is always anchored on the top-left (as you can see with the yellow squares).

[Player701]

The lengths appear to be correct, but the right-aligned scaled text overlaps the red line by one pixel.

Fixed this, see screenshot below. Filters off.

On the unscaled text, you can see the offset font and non-offset font start on the same column despite this.

If offsets do not work with unscaled text, then this is definitely an unrelated issue. I will see what I can do though.

Unrelated to this, when making this demo I noticed DI_ITEM_* flags do not actually change where the text renders and it is always anchored on the top-left (as you can see with the yellow squares).

There is no code in the current implementation that checks for these flags, so this is probably an unimplemented feature.

[arookas]

That looks fixed to me. Thanks!

If offsets do not work with unscaled text, then this is definitely an unrelated issue. I will see what I can do though.

Fortunately, if this fix were implemented I would no longer need the offset. This and the anchor flags could be saved for a separate feature request.

[Player701]

PR here, calling in the dev team to comment and/or suggest other fixes if necessary.

[Accensus]

Requesting reopening this. I don't know if it is a regression or not, but running the example on 4.8.2 produces the same results as in the OP's screenshot. Went as far back as 4.8.0 and it's broken in all 3 versions.

[Player701]

Just for the record: I haven't done any more PRs affecting the relevant code since that last one, so if it's indeed broken again, it must be something unrelated. Better start a new thread though (and link back to this one).

[Rachael]

I reopened this one - it can always be closed again if that's the best choice of action.

[Player701]

All right, then.

[Accensus]

Seems that this commit reverts it. Possibly by accident from the looks of it.

[Accensus]

This can be closed now. It was fixed in https://github.com/ZDoom/gzdoom/commit/ ... f8b1f3d5a5.