Please do that. There should always be built-in ways to get dimensions of these sorts of things.
Finally! more control over the notch!
I never really liked how Roblox handled the notch, and now game get to choose.
As a UI Designer, I am going to have so much fun with this control.
And will it be possible to determine via a script if players are using a notched device? ( UserInputService.IsNotched
Maybe? )
As shown above, the UIs have the same position with the same size. Will this also affect frames with size 1,0,1,0
? Will the frame cover the whole screen (notch and all that, IgnoreGuiInset
is set to true
)?
Does this also allow for screens with rounded corners, but without notches, for example the Pixel 4? Occasionally I find games that have text anchored to the corners end up having important information clipped only partially legible (playersā stats for example).
Have your ScreenGui have the ScreenInsets property to Enum.ScreenInsets.None to take up the fullscreen.
Yeah, itās quite annoying at times having to deal with rounded corners.
I assume though that if you donāt have a notch, you should be able to make the rounded corners less of an annoyance with this option, itās not the best solution but it should work for now:
A punchhole cutout should work in most cases.
On some devices, this will mean that a notch is drawn on your screen at all times, doesnāt seem to happen for me though.
Hopefully this update does include support for rounded corners though.
This is amazing! Hopefully in the future Roblox will add physical device testing like other game engines have, developing for alternative platforms is basically impossible without this.
That wonāt work because then your content would be placed underneath the notch and you wouldnāt be able to easily prevent that without offsetting by some arbitrary (and possibly inconsistent) amount.
Personally, Iām a huge advocate for this update. Plenty are the times where Iām screen recording on my phone or taking a screenshot and Iām ending up with the dreaded black bar that I manually have to clip out. I am also quite pleased whenever all the screen estate is being used.
But, thereās one caveatā¦
Instead of scaling frames that are supposed to fill the entire screen (which I suspect can cause some issues), why not give us an option to specify whether the notched area is displayed or not? It feels more intuitive this way as older games can have notch rendering off and new places have it on by default.
Edit: just watch Ettlobās video and it seems like Roblox isnāt keen on adding this option, which is fine. Hopefully the actual result works well.
Iām a bit skeptical about seeing what UI would look like on devices with irregular shapes (besides rounded or notched screens as they typically have safe areas)
Hi @dragonfrosting, I have tracked down the cause of the IgnoreGuiInset issue. TeamCreate mode is currently not supported for this beta feature (I have updated the announcement post above with this info).
Can you check if the placefile where you are seeing the issue has TeamCreate enabled? You can check this in the View>Team Create window in Studio.
Hi @PeZsmistic, thanks for pointing this out! This is a known issue that we hope to have fixed during the beta period of this feature.
Hi @OneEDM, thanks for your feedback!
We selected the new emulation devices so that they represent different screen cutout geometries (side/center holepunch, notch) that are common across many mobile phones.
The new emulation devices were also chosen because they include some of the most popular notched devices (by playtime) currently playing Roblox.
Hi @BillB1ox, thanks for the feedback!
You can detect if a player is using a notched device by checking the hardware safe area inset sizes. If the safe insets are zero, the user is using a non-notched (simple rectangle) screen.
Show code...
type inset4 = {left: number, top: number, right: number, bottom: number}
local function getHardwareSafeAreaInsets()
local playerGui = game.Players.LocalPlayer.PlayerGui
assert(playerGui)
local fullscreenGui = playerGui:FindFirstChild("_FullscreenTestGui")
if not fullscreenGui then
fullscreenGui = Instance.new("ScreenGui")
fullscreenGui.Name = "_FullscreenTestGui"
fullscreenGui.Parent = playerGui
fullscreenGui.ScreenInsets = Enum.ScreenInsets.None
end
local deviceGui = playerGui:FindFirstChild("_DeviceTestGui")
if not deviceGui then
deviceGui = Instance.new("ScreenGui")
deviceGui.Name = "_DeviceTestGui"
deviceGui.Parent = playerGui
deviceGui.ScreenInsets = Enum.ScreenInsets.DeviceSafeInsets
end
local tlInset = deviceGui.AbsolutePosition - fullscreenGui.AbsolutePosition
local brInset = fullscreenGui.AbsolutePosition + fullscreenGui.AbsoluteSize
- (deviceGui.AbsolutePosition + deviceGui.AbsoluteSize)
local result: inset4 = {left = tlInset.X, top = tlInset.Y, right = brInset.X, bottom = brInset.Y}
return result
end
In Team Create sessions this seems to be disabling IgnoreGuiInsets locally (it just keeps turning off!). This is only happening for me, no other people are experiencing it. I am in the beta channel, whereas they are not.
Thanks for reporting this! Yes, this is a known issue, currently TeamCreate does not work with this beta feature. I updated the announcement post above to reflect this.
Yes, thatās correct. If you have a Frame with Size={1, 0}, {1, 0}
and it is in a ScreenGui with IgnoreGuiInset=true
, then the frameās background will be expanded to cover the full screen (assuming ScreenGui.SafeAreaCompatibility=FullscreenExtension
, the default value).
The UserInputService and mouse options definitely need to be supported, including with respect to Gui objects. We do this translation math all the time in respect to viewport units, and this math is pretty manual. Not having this be supported will break our games without having to instantiate new instances to keep everything working.
Additionally, it would be useful for the camera to potentially have a property for Camera.UnclippedViewportSize
and also a way to query just the safe space from the camera too. In certain cases this could be the same (think Viewport). Besides that, Iām hoping my math continues to work, as long as FOV is with respect to the viewport space, I think weāll be good.
Otherwise, Iām excited for the additional immersion.
What if there is a UISizeConstraint inside of it? Right now we use a UISizeConstraint to float UI elements towards the middle for ultra-wide support.