I have been using
[lua]
ScrW() / number
[/lua]
others use
[lua]
ScrW() * number
[/lua]
and some even use
[lua]
local multiplier_x, multiplier_y = 1280, 1024
( number ) * ( ScrW() / multiplier_x )
[/lua]
but which one is the best to use for creating HUD? Also when making VGUI componets on DermaPanel, should I get panel:GetTall()/GetWide() and then calculate ScrW/ScrH with it?
The last version is the worst, because you are doing more calculations every frame.
First two are pretty much equal ( although I heard that multiplication is faster than division )
Actually, you can set up the modifier once and adjust it when the resolution changes. Here's my documentation on the first method which lets you "hard-code" the x, y, w, and h values to a specific resolution then create a modifier based on the current-users resolution </>/= 1 which is then multiplied accordingly to x, w, and y, h.
[url]https://dl.dropboxusercontent.com/u/26074909/tutoring/hud/understanding_hardcoding_of_screensizes.lua.html[/url]
Here's a basic hook that will fire when resolution changes: [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_hooks/acecool_hook_playerchangedresolution/gm_playerchangedresolution.lua[/url]
And, an example of how to use it: [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_hooks/acecool_hook_playerchangedresolution/example_usage.lua[/url]
Basically, just set up your hard-coded values, create the modifiers by dividing the hard-coded resolution by the current user resolution ( and update it when resolution changes ) so you're only multiplying the key values by the modifiers.
[QUOTE=Acecool;47071643]Here's a basic hook that will fire when resolution changes: [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_hooks/acecool_hook_playerchangedresolution/gm_playerchangedresolution.lua[/url][/QUOTE]
[code]
hook.Add( "Initialize", "Resolution Change", function()
vgui.CreateFromTable {
Base = "Panel",
PerformLayout = function()
hook.Run( "ResolutionChanged", ScrW(), ScrH() )
end
} : ParentToHUD()
end )
hook.Add( "ResolutionChanged", "Resolution Change", function( w, h )
print( "OH NO THE RESOLUTION CHANGED TO " .. w .. "x" .. h )
end )
[/code]
The only issues with that is the HUD panel doesn't invalidate when GM is resized from an outside source, and you're parenting something to the HUD where it can't be retrieved from a get-children call; additionally if you resize it and it gets resized again it uses a different size than the engine. It's too easy to de-sync.
Other than that, it is a more efficient design and it is cheaper to call because it's only being called when the engine calls it; the issue with resizing from an outside source can easily be resolved with a pull request so the window when changed invalidates the hud panel, and the children issue is already posted as an issue.
Seems I didn't update my code either or changed it to an older version which doesn't seem to work properly ( or hook.Call requires a GM function to be present while hook.Run doesn't seem to need it?? ); I'll update mine in a bit.
[QUOTE=Acecool;47072563]The only issues with that is the HUD panel doesn't invalidate when GM is resized from an outside source[/QUOTE]
This'll cause ScrW and ScrH to return false values anyway as the entire game just downscales or upscales. It ain't supported.
[QUOTE=Acecool;47072563]and you're parenting something to the HUD where it can't be retrieved from a get-children call;[/QUOTE]
I don't see why you'd need to. Either way, you can get the HUD panel and call GetChildren on it quite happily.
[QUOTE=Acecool;47072563]additionally if you resize it and it gets resized again it uses a different size than the engine. It's too easy to de-sync.[/QUOTE]
It'll always be using the same values as the game's HUD uses.
If you think that can de-sync, you think every panel in the game can de-sync.
I do think it is an elegant solution; I just mentioned some flaws ( which really don't matter that much ). For example I changed resolution with outside source, ScrW and ScrH reported the new width/height but the hook didn't fire. Although someone doing this is rare ( It was done with my auto-sizer that ensures GMod is always in the same place on my left monitor, same screen-size, etc... )..
When you resize it with a small resolution, it doesn't scale nicely; it actually turns to crap. Another reason why someone doing this would be rare.
Unless I'm doing something wrong though, the child function is broken for vgui parented to hud: [url]https://dl.dropboxusercontent.com/u/26074909/tutoring/_utilities/concommand_clearvgui.lua[/url]
I didn't test with GetHUDPanel(), but I did use GetParent on my Panel referenced in the code above and GetChildren appeared to work fine on that. Perhaps either ChildCount is wrong or it is not 0-indexed, I checked neither of these as I just used "for k, v in pairs( panel:GetParent():GetChildren() ) do".
I notice a potential issue in your code where you are handling the callback for the parent of each recursed panel before its children. This'll probably cause some issues because you're also removing the panels in the callback.
Depth first traversal will probably serve better here. Although, if it is only used for removing panels, you could benefit from just checking if the panel is valid before recursing or not recursing at all.
Using deep-first causes the gmod client to crash if I recall correctly; and yes that clearvgui removes but the callback can be changed to do whatever.
I'll see about adding in an alternative to GetHUDPanel( ) to target it or change how it loops and re-verify then update the code if necessary.
Sorry, you need to Log In to post a reply to this thread.