I have a basic menu screen on a project with the standard options of play, quit etc.
The buttons change colours on the different states and all woks fine in the editor.
When the game is packaged, it runs on a MacBook pro fine with the menu buttons working as specified and are clickable. So this suggest that basics things like hit-test and z-order are correct.
However, when the exact same project is run on a iMac with a retina display, the project opens fine, the menu is displayed but NONE of the buttons can be clicked.
From the research I have done there seems to be an issue with how the interface is scaled on different screen sizes. However, I am at a loss as how to fix it.
Any help or advice on this issue would be appreciated.
macbook works, retina imac fails, that difference points at dpi scaling breaking the cursor to widget hit test mapping rather than your ui logic.
things to check, in order of likelihood:
- an invisible overlay swallowing clicks: on a different aspect ratio or scale, a background image or dim panel that sits beside the buttons on the macbook can end up exactly over them on the imac. on any widget that covers the screen (background, vignette, focus panel) set visibility to hit test invisible or not hit testable instead of just opacity zero. this is the most common cause and takes a minute to rule out.
- dpi scaling: if the project uses a custom dpi curve (project settings, ui, dpi scaling), test with rule set to shortest side and no custom curve. curves that return large scale factors are known to desynchronize slate hit testing on retina displays, where the backing resolution differs from the window resolution.
- fullscreen mode: on the imac test in windowed and borderless. fullscreen on retina renders at backing resolution while the cursor is reported in window points on some driver combinations, so buttons highlight (mouse move works through the viewport) but click coordinates land elsewhere. borderless usually sidesteps it.
- verify with data: bind a debug print on mouse position from the player controller and on the button hover event. if hover never fires while mouse position prints sane values, it is the hit test scale mismatch above. if hover fires but click does not, look at input mode and the focus path instead.
- application scale: in project settings, rendering, check application scale is 1 on mac targets.
if it turns out to be the retina fullscreen mismatch, running borderless with the backbuffer at window resolution is the shipping safe choice for mac builds.
Many thanks for that list of possible problems, it has given me some homework to do. and areas to look at.
I did make a version of the app that ran at 1280x720 windowed and that has run fine on both machines. So your post confirms what I am seeing at full screen. (The window layout, mechanics etc all work fine but something is messing with the scaling, or is blocking things.)
Do similar issues exist on the windows side, if I ever want to make a version that runs on that platform?
short answer: yes, the same family of issue exists on windows, it just shows up less often and through different doors.
the windows version of this is display scaling. most modern laptops ship at 125 or 150 percent scaling, and 4k desktops often run 150 or higher. unreal is dpi aware on windows so slate usually keeps the cursor and hit testing in sync, but the mismatch appears when app scale or a custom dpi curve stacks on top of the os scaling, or when a window is dragged between monitors with different dpi (a 4k screen at 150 percent next to a 1080p at 100 percent can transiently desync hit tests in some engine versions until the window is refocused). same symptoms as your imac: hover may work, clicks land somewhere else.
what carries over from the mac checklist, basically all of it:
keep application scale at 1 and test at 125 and 150 percent os scaling, since that is where real users actually sit. if you use a custom dpi curve, sanity check the scale factors it returns at common resolutions.
the invisible overlay sweep applies on every platform, aspect ratio changes move things under full screen panels on windows exactly like on mac.
prefer windowed fullscreen (borderless) as the default fullscreen mode on windows too. exclusive fullscreen has its own quirks with overlays and alt tabbing, and borderless keeps the cursor coordinate space matched to the backbuffer.
the good news from your test: a fixed 1280x720 windowed build running correctly on both machines confirms your layout and hit test logic are fine. the problem is isolated to the fullscreen scale path. the robust shipping pattern on both platforms is the same: design resolution plus a scale box so the layout adapts, dpi rule set to shortest side (or a gentle curve), application scale 1, borderless as the default fullscreen mode. get that combination right and the same umg works from a 1080p laptop up to a retina imac without per platform fixes.
One curiosity about this whole thing was the 1280 x 720 build had a resizable window. Resizing window to fill the iMac screen still allowed the buttons to work. So that is confusing. Still trying to figure it all out.
Again many thanks for the information.
that resizable window detail is actually the most diagnostic data point yet, it isolates the failure precisely.
resizing a window keeps it composited: the backbuffer tracks the window size, the cursor is reported in the same coordinate space, and slate hit testing stays in sync no matter how big you drag it. going true fullscreen on a retina imac is the only thing left that changes the coordinate math: exclusive fullscreen switches the display to its native backing resolution (a 5k imac is 5120x2880 backing at 2x), and on some engine and macos combinations the cursor keeps being reported in logical points while the viewport hit tests in backing pixels. buttons render where you expect, hover may even fire, clicks land at double the coordinates. your windowed tests prove layout, dpi curve and widget logic are all fine, because all of those stay identical while resizing. the only variable left is the display mode switch itself.
there is a ten second experiment that confirms it: in the broken fullscreen mode, click not on a button but at roughly half the distance from the top left corner to where the button appears. if the button responds to that click instead, the hit test is running at 2x your cursor position, which is the points vs backing pixels mismatch, case closed.
the fix: run mac targets in windowed fullscreen (borderless) rather than exclusive fullscreen. it is settable in the video options (windowed fullscreen) or forced via r.FullScreenMode 1, keeps the window composited so the coordinate spaces stay matched, and is the shipping safe default on mac. if you genuinely need exclusive fullscreen, test it at the display’s native resolution rather than a scaled mode like 1080p on a 5k panel, the mismatch is worst when the mode switch rescales the backing buffer.
one last thing worth checking, because it would make your whole dataset consistent: modern macbook pros are retina too, so look at which window mode the game actually defaulted to on the macbook. those defaults live in each machine’s gameusersettings, so the macbook may simply have been running windowed while the imac defaulted to exclusive fullscreen. if so, nothing about the two machines contradicts each other, and locking the default mode to borderless on mac closes it everywhere.
LOL still struggling here to get the full screen iMac UI to be clickable.
I have reduced the code to the following:
This works on the MacBook Pro but although it does display the screen full screen on the iMac pro and the UI is displayed, none of the buttons on the UI are clickable.
So obviously I am missing something. Any pointers in the right direction would be appreaciated.
As a side note, if I query the overall scalability after the save settings above with:
It prints scalability level - -1 (thats right it reports it as -1) All just doing my head in. LOL.
Ah -1 just means that it is a non-standard setup. Not sure how that is the case but that is what the tech docs say.
