Scale HUD/VGUI Based on Screen Res?

[Grea_eMonkey-legacy (Grea$eMonkey)]

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
ScaleClientSidePos(ScrW,ScrH,PosX,PosY)

– Scales clientside sizes based on Screen Res in comparison to the Width/Hight in the 3rd and 4th arguments
ScaleClientSideSize(ScrW,ScrH,LenW,LenH)
[/lua]
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:
[lua]
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) )
[/lua]
What equation(s) would be used to get such functions to work?

[Nevec-legacy (Nevec)]

Ignore.

[Grea_eMonkey-legacy (Grea$eMonkey)]

@Nevec

HL2 HUDs use this. Basically, their position and size is relative to 640x480 and the aspect ratio of 4:3.

[lua]
function ValveToScreenRect( x, y, w, h )

local base_w, screen_w = 640, ScrW( );
local base_h, screen_h = 480, ScrH( );

screen_w = screen_h * ( base_w / base_h );

local screen_scale_w = screen_w / base_w;
local screen_scale_h = screen_h / base_h;

x = screen_scale_w * x;
y = screen_scale_h * y;
w = screen_scale_w * w;
h = screen_scale_h * h;

return x, y, w, h;

end
[/lua]

Essentially that does what you need. I wrote this to get the position and size of the default chatbox. If you look up the params in the HUD definition files and test it, you’ll see that it works.

Thanks man, I’ll try this!

[SteveUK-legacy (SteveUK)]

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.

[Grea_eMonkey-legacy (Grea$eMonkey)]

@SteveUK

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.

[andrewmcwatters-legacy (andrewmcwatters)]

Wow, this that overly complicated.

I added functions to the surface library for this.

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

surface.SScale = surface.ScreenScale[/lua]

[SteveUK-legacy (SteveUK)]

@grea$emonkey

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

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

[andrewmcwatters-legacy (andrewmcwatters)]

I wrote these after discovering G.ScreenScale was incorrect.

[editline]12:33PM[/editline]

@SteveUK

Oh I just forgot, ScreenScale() also exists.

See above post.

[editline]12:34PM[/editline]

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.

[editline]12:36PM[/editline]

@grea$emonkey

We all have problems with HUD/VGUI when using it in different screen resolutions (at least I do).

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.

[Grea_eMonkey-legacy (Grea$eMonkey)]

@andrewmcwatters

I wrote these after discovering G.ScreenScale was incorrect.

[editline]12:33PM[/editline]

See above post.

[editline]12:34PM[/editline]

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.

[editline]12:36PM[/editline]

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.

[editline]04:45PM[/editline]

@andrewmcwatters

Wow, this that overly complicated.

I added functions to the surface library for this.

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

surface.SScale = surface.ScreenScale[/lua]

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?

@Nevec

HL2 HUDs use this. Basically, their position and size is relative to 640x480 and the aspect ratio of 4:3.

[lua]
function ValveToScreenRect( x, y, w, h )

local base_w, screen_w = 640, ScrW( );
local base_h, screen_h = 480, ScrH( );

screen_w = screen_h * ( base_w / base_h );

local screen_scale_w = screen_w / base_w;
local screen_scale_h = screen_h / base_h;

x = screen_scale_w * x;
y = screen_scale_h * y;
w = screen_scale_w * w;
h = screen_scale_h * h;

return x, y, w, h;

end
[/lua]

Essentially that does what you need. I wrote this to get the position and size of the default chatbox. If you look up the params in the HUD definition files and test it, you’ll see that it works.

This seems to be what I was looking for.

[Nevec-legacy (Nevec)]

@grea$emonkey

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.

[andrewmcwatters-legacy (andrewmcwatters)]

@Nevec

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.

[editline]12:58PM[/editline]

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.

[Grea_eMonkey-legacy (Grea$eMonkey)]

@Nevec

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

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

[andrewmcwatters-legacy (andrewmcwatters)]

@andrewmcwatters

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.

This.

[editline]01:02PM[/editline]

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

is incorrect.

[editline]01:03PM[/editline]

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

surface.SScale = surface.ScreenScale[/lua]

however is.

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

[SteveUK-legacy (SteveUK)]

@grea$emonkey

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

uggggh.

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.

[andrewmcwatters-legacy (andrewmcwatters)]

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

[SteveUK-legacy (SteveUK)]

@andrewmcwatters

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.

[andrewmcwatters-legacy (andrewmcwatters)]

Ah, I see.

[Grea_eMonkey-legacy (Grea$eMonkey)]

@SteveUK

uggggh.

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.

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

[SteveUK-legacy (SteveUK)]

@grea$emonkey

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

yes