Scale HUD/VGUI Based on Screen Res?

We all have problems with HUD/VGUI when using it in different screen resolutions (at least I do). That’s why I think we need an easy way to scale HUD/VGUI (Derma) based on screen resolution. Basically, by making some functions like these:
[lua]-- Scales clientside screen positions based on Screen Res in comparison to the X/Y coordinates in the 3rd and 4th arguments

– Scales clientside sizes based on Screen Res in comparison to the Width/Hight in the 3rd and 4th arguments
Basically, you’d configure your HUD/VGUI in whatever screen resolution you feel comfortable using. Then, wherever you have something that involved coordinates/sizes, you’d put this in by entering the screen res you constructed it in and the positions/sizes you originally used.
The function would then spit out some new values based on the current ScrW() and ScrH() in a table format so you could do something like this:
local translatePos = ScaleClientSidePos(1024,860,115,200)
local translateSize = ScaleClientSidePos(1024,860,400,800)
draw.RoundedBox( 3, translatePos.x, translatePos.y, translateSize.w, translateSize.h, Color(255,255,255,255) )
What equation(s) would be used to get such functions to work?


Thanks man, I’ll try this!

Are you seriously saying you can’t just multiply all your dimensions by a scale variable? All your scale needs to be is ScrH() / your current height. So it’ll be 1 on your current res, >1 on larger resolutions, <1 on smaller resolutions.

I’m just saying it would be convenient to have a function that does that for you on the fly.

Wow, this that overly complicated.

I added functions to the surface library for this.

[lua]function surface.ScreenScale( size )
return size * ( ScrH() / 480.0 )

surface.SScale = surface.ScreenScale[/lua]

Oh I just forgot, ScreenScale() also exists. which is based on 640x480

I wrote these after discovering G.ScreenScale was incorrect.


See above post.


I also added them to the surface library, considering I didn’t want to overwrite the global function, despite it’s incorrectness, considering it may have been used in a situation where the calculations were planned for it’s inaccuracy to work.


Also, you and everyone else who creates poorly coded HUD/VGUI do, not all of us; then again, all of my work is styled after HL2 for a native feel.

HUD/VGUI is not my strong-point, so that’s why I’d find it useful. But I’m not sure that your code is doing exactly what I had described.


You are only scaling screen hight from the looks of it, and all that will get it is a screen size correct? Wouldn’t it be great if we could get positions and object sizes based upon that?

This seems to be what I was looking for.

andrewmcwatters’ code works exactly the same as mine, except I do it in an unnecessarily complicated way. Use his code.

This; you should also know by scaling the height in such a manner of it being relative to a static width of 480px, you are scaling the width. This is what G.ScreenScale does wrong.


Steve, could you update the code for us? Having a third-party fix is hacky. You fixed the fall damage I had complained about a while back, which was another fix I mentioned. I’m not sure if you have direct access to the code or not, but it’s worth a shot.

Oh, I couldn’t tell. How is it working by only using ScrH() though?



[lua]function ScreenScale( size )
return size * ( ScrW() / 640.0 )

is incorrect.


[lua]function surface.ScreenScale( size )
return size * ( ScrH() / 480.0 )

surface.SScale = surface.ScreenScale[/lua]

however is.

It’s the same logic that Valve uses to render the HUD. Don’t ask me.


Say you scale it over (1280x)720. ScrH() / 720.

1280x720: 720 / 720 = 1
1920x1080: 1080 / 720 = 1.5
640x480: 480 / 720 = 0.66666

So it scales. You use ScrH() over ScrW() because things will look too big in widescreen aspect ratios, or if you scale it using widescreen, it will look too small in 4:3.

Considering the general standard is widescreen nowadays, why not default to that? Or, just add in an exceptional to detect what’s larger.

That’s is totally nothing like what I said. I said that you should always scale by ScrH() as it works best for all aspect ratios.

Ah, I see.

So that means if I multiply by that output, it will change all sizes and positions to that screen’s scale?