[UI] px versus scr

Is it best to set UI dimensions using “px” or “scr”? What is “scr”?

For instance, I have a string of text in a label. Should I use pixel dimensions or something else?

Does the font size increase as players increase the resolution of their display?

Thanks!

Scr is “screen”. For example, if you have a 1920x1080 screen,
w = 0.5,h = 0.5,wr = "scr",hr = "scr"
means 960x540 on your screen. And if your friend has a 1280x720 screen, it will be 640x360 then.

2 Likes

you were faster than me ^^

“scr” = screen, as explained above
"scr_min" = smaller dimension of the screen (for a 19201080, it would be 1080)
“scr_max” = smaller dimension of the screen (for a 1920
1080, it would be 1920)
“par” = parent (the reference is the parent of the current ui element)
“px” = pixel
"1" = don’t know, seems new since 2.0, I need to investigate

Where do you see that?

possibly stuff like these (from logo.lua):

visible = 1,
sector = 1,
lockAspect=2,

Looks like it’s a boolean?

1 = true ?
2 = false ?

  • “px” - Pixels (scale can apply)
  • “abs_px” - Pixels (never scaled)
  • “scr” - Screen (Width or Height by context)
  • “scr_min” - Smallest of Screen Width/Height
  • “scr_max” - Largest of Screen Width/Height
  • “scr_43” - Width or Height of value resulting in a 4:3 ratio fit of Screen
  • “par” - Parent (Width or Height by context)
  • “par_min” - Smallest of Parent Width/Height
  • “par_max” - Largest of Parent Width/Height

The Layout engine is pretty powerful - sometimes it just take a bit of pen & paper to get exactly what you want from it.

3 Likes

Sure - in LUA. But I meant, in reference to where you’d see ‘px’, ‘par’, ‘scr’, etc… :slight_smile:

1 Like

Hi @BitVenom !

in unitcapinfopopup.lua for example (wr = “1”) :

– Unit cap item to clone
{
type = “Frame”,
name = “frmItemToClone”,
autosize = 1,
giveParentMouseInput = 1,
visible = 0,
arrangetype = “horiz”,

    Layout = {
        size_WH = { w = 1, h = 1, wr = "1", hr = "px" },                                
    },
    ;

for sector, I don’t know, but for lockAspect, it forces the ratio between width and height if I remember well (lockAspect=2 means that the elements will always be twice wide than high)

Thanks a lot for this list @BitVenom ! It will help a lot for my tutorial ! :smiley:

In that context, it is actually at typo - ONLY the values I’ve listed are valid (I am looking at the code). The default, given that it is invalid, would be ‘scr’ - but also in this context, notice it says ‘autosize=1’ - to really it is adjusted to the contents, and being born with ‘take up the whole screen’ isn’t a problem.

Negative lockAspect works too - I think the best way to explain that is ‘use inverse of this aspect, as best-fit’.

Positive lockAspect means ‘shrink to correct aspect’, so if the shape is too wide, it thins; if it is too tall, it shortens. It always gets smaller.

Negative lockAspect was added later, and means ‘grow to correct aspect’ - Doing the inverse, getting larger on whichever axis would match the requested aspect.

1 Like

Yeah, I just checked all the others ui file, and the “1” is only there. Silly me for not having done that before ^^

REALLY greeaat infos there ! Thanks ! :smiley:

I think I will have a big list of questions for you later on UI stuff, if you don’t mind of course :slight_smile:

But if I have a text label, which measure should I use so that the label is the same (relative) size on all monitors?

The layout values are for the boxes/rectangles on the screen. These have ZERO to do with text.

Text can have a specific pixel value size set (many examples) - and that will scale if the control is scaled. Or, they can just use a named style, which can, based on how the font file itself is setup, scale or change thickness based on user-screen size.

Text can also be flagged as scaling to stay within the bounds it is placed, etc.

Then what do the number arguments of UI_SetElementSize and UI_SetElementPosition mean now?

They set the size/pos of the element in Pixels relative to 800x600 (in other words 800x600 is the whole screen) - these were kept this way due to legacy UI code that relied on that. I may be able to make a new interface for extended UI editing… but patience will be required, HODOR/RODOH needs attention first.

1 Like

me gusta, OVER 9000

don’t worry about time too much. I, for one, have waited more than 10 years, just to have the kind of explanations you’ve already given here and in other threads. We can wait a little bit longer I think :wink: