Jump to content

Recommended Posts

I have created a lot of arma dialogs only to find out that the position and size of the dialogs vary a lot depending on screen resolution and UI size. And because I have like hundred of controls in my mission I would like to fix this problem by editing only the grid define macros instead of every control it self

 

Here's what I have:

 

#define UI_GRID_X    (safezoneX)
#define UI_GRID_Y    (safezoneY)
#define UI_GRID_W    (5 * 0.5 * pixelW * pixelGrid)
#define UI_GRID_H    (5 * 0.5 * pixelH * pixelGrid)
#define UI_GRID_WAbs    (safezoneW)
#define UI_GRID_HAbs    (safeZoneH)

 

And typical control would have it's position like this:

 

    x = -10 * UI_GRID_W + UI_GRID_X;
    y = 11 * UI_GRID_H + UI_GRID_Y;
    w = 40 * UI_GRID_W;
    h = 9 * UI_GRID_H;

 

I think all there is to do is edit the UI_GRID_X so that all the dialogs are centered on screen. But I haven't been able to figure the right math for this, although it shouldn't be too hard... 

 

What I have tried is to get the percentage of current screen resolution vs the resolution the dialogs were created and use that somehow to adjust the UI_GRID_X but I haven't been able to figure this out yet. (I'm also keeping the UI size to normal for now to keep this simple)

 

Any suggestions/solutions are welcome

 

thx 🙂

 

 

Share this post


Link to post
Share on other sites

Welcome to the world of Arma GUI scaling and "responsive" design

 

I think first it will be helpful to affirm your understanding of the different UI scaling commands:

  • Viewport (no auto-scaling commands) - Absolute position (expressed in percentage) as if a 4:3 screen was superimposed over your current monitor
  • safeZoneX - Offset necessary to apply to Viewport to get the real "0" value on monitor. Scaled to "real" monitor size behind the scenes (using resolution set from settings menu)
  • safeZoneY - Same as above but for Y axis
  • safeZoneXAbs - Same as safeZoneX but scaled for multiple monitor setup (if 1 monitor then the same as safeZoneX)
  • safeZoneW - Scaling factor to get the real width of monitor. Scaled to "real" monitor size automatically (using resolution set from settings menu)
  • safeZoneH - Same as above but for height
  • safeZoneWAbs - Same as safeZoneW but scaled for multiple monitor setup (if 1 monitor then the same as safeZoneW)
  • pixelH - Height of 1 pixel
  • pixelW - Height of 1 pixel
  • pixelGrid - Grid size based on screen resolution, interface size and configs (I don't know this system very well so this is just copied from elsewhere on the wiki). Pixel grid seems to be 12x6 so I'm not sure where you got "(5 * 0.5 * pixelW * pixelGrid)" from

Have a look at the SafeZones page on the wiki for a write-up (I recommend looking at all the pictures first then try to make sense of the words). Also check out Arma 3: Pixel Grid System for information about the pixelGrid.

 

You're mixing up 2 different UI systems without having a strong understanding of them which is adding to the confusion (safezone and pixel), stick with 1. Since I'm most familar with safeZone, I'll continue with that. First change your defines to all be in safezone types:

#define UI_GRID_X    (safezoneX)
#define UI_GRID_Y    (safezoneY)
#define UI_GRID_W    safeZoneW
#define UI_GRID_H    safeZoneH
#define UI_GRID_WAbs    (safezoneWAbs)
#define UI_GRID_XAbs    (safezoneXAbs)
/*#define UI_GRID_HAbs    (safeZoneH) */ //There is no such thing has HAbs or YAbs in arma, multimonitor setups are assumed to be in-line, horizontal, so these are not necessary

Before we even get to scaling, a history lesson is in order. In the early days of computing when CRT screens were the height of technology (think 90's and earlier TV's eh?). In case you need a refresher, they were those big, heavy, and square behemoths that everybody and their grandmother seemed to have and displayed nothing but General Hospital after school. Well those monitors had an aspect ratio of 4:3. This kind of monitor has been given a somewhat (un)affectionate moniker of "squares" by me, although you can clearly see now that they were not quite square

 

Why does Arma support this even though every monitor you have touched in the past 10 years (probably) has been 16:9? Arma is old. Older than 2013 when Arma 3 was released. This codebase has been evolving since OFP which was released in 2001. Now since the first LCD monitors were not created until the mid 90's (and they were 4:3 too anyway),  OFP was more than likely going to be played on a 4:3 monitor, which would have been the most common aspect ratio of the time.

 

Now, let's talk about scaling. If you have a 1080p monitor (first of all your aspect ratio is 16:9). This is better for humans to look at because it takes up more of your active vision (4:3 monitors had dead-space on either side where your brain could pay attention to things not on the monitor). There is some math stuff, dealing with the golden ratio (Wikipedia), that I don't quite understand, but my previous sentence should more than explain it. Anyway, since we have affirmed your knowledge on the different scaling commands it should be easy to understand that accurately placing components on the screen in Arma requires 3 things, a percentage of how much of the Viewport, multiplied by scaling factor (width or height), plus Offset (X or Y). Thus:

(0 * safeZoneW) + safeZoneX //left edge of current resolution
(0 * safeZoneH) + safeZoneY //top edge of ''
(1 * safeZoneW) + safeZoneX //right edge of ''
(1 * safeZoneH) + safeZoneY //bottom edge of ''
//Can, of course, be simplified to:
safeZoneX
safeZoneY
safeZoneW + safeZoneX
safeZoneH + safeZoneY

I hope this helps to demystify GUI scaling in Arma somewhat for you

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for the info @dreadedentity ! I'm trying to understand all of this but the problem... 

 

21 minutes ago, dreadedentity said:

First change your defines to all be in safezone types:

 

At this point I am not looking for the "correct way" to setup the defines but rather trying to salvage my existing dialogs/controls without having to redo everything 🙂

 

Share this post


Link to post
Share on other sites

That's what I'm trying to highlight, you've applied a strange scaling factor to all of your controls and now you input values from -10 to 40 to get screen position and control size. Regardless of safezone or pixelGrid, values should be supplied as a percentage of the viewport, they should only ever be between 0 and 1, that's what everyone will be familiar with...

 

I'm unfamiliar with your process but I think it's quite standard to save your controls as "GUI Editor" format as well as class controls due to the GUI Editor automatically importing clipboard data. I think the best option for you would be to load the editor format, fix scaling, then re-export

Share this post


Link to post
Share on other sites
6 hours ago, dreadedentity said:

Regardless of safezone or pixelGrid, values should be supplied as a percentage of the viewport,

PixelW/H/Grid are pixel dimensions in safezone values. Grid is just a format of multiple pixels so you don't have to specify everything in pure pixels, which would be tedious. PixelGrid splits your vertical resolution by 64 (UIMaxScaleGrids) and picks the closest whole number that's divisible by 4 (UIScaleFactor). Multiply/dividing this grid size gives you bigger/smaller grids to work with. However, you should never divide by more than UIScaleFactor or multiply by anything other than n/UIScaleFactor as otherwise, this will provide positions that are not pixel perfect, potentially causing artifacts.

 

7 hours ago, dreadedentity said:

You're mixing up 2 different UI systems without having a strong understanding of them which is adding to the confusion

No, he is using pixelgrids, you still need to anchor to a known position safezoneX/safezoneY/safezoneW/safezoneH to position off of.

 

14 hours ago, gc8 said:

 x = -10 * UI_GRID_W + UI_GRID_X;

w = 40 * UI_GRID_W;

This does not really make sense. You start the element 10 grids off of the left-hand side of the screen, then the element is 40 grids wide. So only 30 grids of whatever the element is being visible?

 

Share this post


Link to post
Share on other sites
12 hours ago, Larrow said:
On 5/11/2022 at 1:00 PM, gc8 said:

 x = -10 * UI_GRID_W + UI_GRID_X;

w = 40 * UI_GRID_W;

This does not really make sense. You start the element 10 grids off of the left-hand side of the screen, then the element is 40 grids wide. So only 30 grids of whatever the element is being visible?

 

 

That's what i get when I hit ctrl+shift+S in the GUI editor. I forgot where I got those defines from....

Share this post


Link to post
Share on other sites

well i solved this problem by making a script that centers the dialog. But I'd still like to learn how to use the GUI editor correctly so that dialogs created stay at same position regardless of viewport and UI size.

How do you do this? What are the correct grid values you give to the GUI editor?

 

thx!

Share this post


Link to post
Share on other sites

https://community.bistudio.com/wiki/Arma_3:_GUI_Coordinates#Using_the_grids_in_the_GUI_Editor

For centered dialogs you use the GUI_GRID_CENTER macros, so GUI_GRID_CENTER_X, -Y, -W and -H. H and W are the same for all GUI_GRIDS, you can paste the values from the page i linked above. For x and y you have to replace the macros in "\a3\ui_f\hpp\definecommongrids.inc" with actualy commands (a bit of work but you only have to do it once). Or you can use my mod:

There is a page on the Extended Debug Console where you can set these values permanently.

Share this post


Link to post
Share on other sites

@7erra thx for the reply! I am using your mod. I just don't know what values to put there as the GRID_ macros?

 

I have tried both UI_GRID_ and GUI_GRID_ but neither seems to work on different UI sizes

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×