[Added] DrawString scale parameter

[Matt]

Would be nice to be able to get different font sizes without either defining whole new fonts or changing the screen size just to draw a particular string.

[m8f]

Another way to draw scaled strings is to use Screen.DrawText with the proper parameters.
Matt, you most probably know about this already, I'm posting the code just to show that this way is not nice either.

Code: Select all • Expand view

  ui void drawTextCenter(string text, int color, double scale, double relativeY,
                         Font font, int xAdjustment = 0)
  {
    int width    = int(scale * Screen.GetWidth());
    int height   = int(scale * (Screen.GetHeight() - font.GetHeight()));
    int position = width - font.StringWidth(text);

    double x = position * 0.5 + xAdjustment;
    double y = height   * relativeY;

    Screen.DrawText(font, color, x, y, text,
                    DTA_KeepRatio,     true,
                    DTA_VirtualWidth,  width,
                    DTA_VirtualHeight, height);
  }

[Matt]

I did not and might need to spend a couple days studying that code snippet since about 90% of it is code I haven't even touched since ZScript started!

[Nash]

m8f - what are "xAdjustment" and "relativeY" supposed to mean?

[Matt]

Can we reopen this feature suggestion? I've been trying to get m8f's suggested alternative to work for 2 hours and it's a horrible mess. I'm sure many other modders would have an even worse time with it. [Okay, the single biggest problem was that I was trying to create a function and call that function in 2 different places, so I couldn't see immediately that I'd defined one of the function's parameters differently than what I had assumed. It got a lot better though I am still relying on a function and a function call elsewhere rather than a single, easily debugged inline parameter.]

Also HUDfonts don't work with this, and scale is inversed so that bigger numbers mean smaller display output.

And the scale will throw off the position of the text.

And it doesn't clamp to the HUD size, so there needs to be an additional 2-3 lines to deal with that.

I'm just slowly hammering away at this one glitch and oversight at a time until I get something that can work like my feature suggestion. It might take me a day or two.

It really shouldn't be this painful to scale a font in comparison to an image.

[Graf Zahl]

Can we reopen this feature suggestion?

Why? All this boils down to is "I cannot deal with how the function needs to be called and need an easier interface."

I think stuff like this is far better suited for some external utility library.

[Matt]

We're talking about something approaching 30 lines of code in the VM to deal with something that is dealt natively with a similar function elsewhere, that's why.

I mean, unless you want a bunch of randos coding horrible gruesome hacks involve giant hundred-line if blocks and DrawImage, because I've half a mind to start doing that at this point...


EDIT: Right after going to bed at around 2 it finally occurred to me to stop trying to mess with Screen.DrawText and go back to depending on SetSize. If having to recalculate all the positioning so that it doesn't run with the scale is totally unavoidable, this is the simplest solution from the user point of view. Number of additional lines is closer to 4-8 depending on what other changes are required.

[m8f]

m8f - what are "xAdjustment" and "relativeY" supposed to mean?

Sorry for giving this snippet out of context - it was just to illustrate the use of Screen.DrawText().
This function is used, among other things, to draw scalable crosshair for Target Spy mod. There, relativeY means vertical position on the screen relative to the screen size. This parameter should be in range [0.0, 1.0], 0.0 for the top of the screen, and 1.0 for the bottom. xAdjustment is used to move text to the left or to the right, so it is properly centered. It is read from user settings, and is set by the user if they find the selected crosshair symbol to be off-center.

[Major Cooke]

---

Personally I just do something like this.

Code: Select all • Expand view

void DrawStringScaled(HUDFont font, String string, Vector2 pos, int flags = 0, int translation = Font.CR_UNTRANSLATED, double Alpha = 1., int wrapwidth = -1, int linespacing = 4, double scaling = 1.0)
{
   if (scaling == 0.0)
      return;
      
   scaling = abs(scaling);
   
   Vector2 OldScale = BaseSize, TempScale = BaseSize;
   Vector2 ScaledPos = pos;
   
   bool sized = (scaling != 1.0);
   if (sized)
   {
      TempScale /= scaling;
      ScaledPos /= scaling;
   }
   
   if (sized) SetSize(0, TempScale.X, TempScale.Y);
   DrawString(font, string, ScaledPos, flags, translation, Alpha, wrapwidth, linespacing);
   if (sized) SetSize(0, OldScale.X, OldScale.Y);
}


BaseSize is a constant (in D4D's case, (1024, 768)) you'll have to set up but other than that, it works out of the box. It's set up where scaling works as a multiplier so 2 is twice as big and so on.

[Player701]

It's set up where scaling works as a multiplier so 2 is twice as big and so on.

Bigger, yes, but making strings smaller using your code doesn't work for me. Although I don't need this so badly, it might come in useful later on.

The method with Screen.DrawText looks fine as long as the HUD scale is not relevant, but unfortunately, most of the time it is. And while BaseStatusBar functions (DrawString, DrawImage and so on) abstract the HUD scale away, Screen.DrawText does not. Being a programmer myself, I don't like breaking the abstraction unless really necessary, so I kind of wonder why DrawString shouldn't have a scale parameter when DrawImage and co. already have it.

[Matt]

I don't like breaking the abstraction unless really necessary, so I kind of wonder why DrawString shouldn't have a scale parameter when DrawImage and co. already have it.

^^^this. But from the discussion so far I take it this would be a much more complicated thing to add than it might look.

I've been noticing another problem, though: when I try to scale things with SetSize, it seems to "snap" between a few thresholds of sizes, instead of progressing smoothly at all points. Is there any way around that?

[phantombeta]

Bumping/revisiting this. The lack of a scale parameter forces us to use Screen.DrawText instead of BaseStatusbar.DrawString, which is a pain in the ass. We have to manually handle shadows, spacing, the HUD scaling settings, and much more, just so we can have scaled text in our HUDs. There's really no reason for DrawString to not have a scale parameter.

[Major Cooke]

I have to agree here. The longer I look at this stuff, the more I feel like something official should be done.

[Player701]

I'm really sorry for bumping this, but why was this closed as "Not needed"? As far as I'm aware, there is still no robust solution to this problem. In the context of a HUD, using Screen::DrawText is not an option (the reasons are explained in phantombeta's post above).

Upd: Unless I'm missing something here, I can provide a PR to implement this feature. However, If there really exists a non-hacky way to achieve HUD string scaling in the current GZDoom version, I'd appreciate if someone could tell me about it.

[Player701]

Sorry for double-posting, but I decided to take the initiative and went ahead with my PR. It just got merged, so this can be reclassified as "added". I hope this message will help other people who are interested in this feature, and they can finally stop using questionable hacks.