BrickBattle Reborn has an issue where the killfeed text labels, which are using AutomaticSize, will size themselves such that when the text is actually rendered, it wraps when it shouldn’t.
Please make sure this is manually overrideable.
Can you provide instructions for overriding fast flags without using third-party software? Is there a file somewhere I can modify, safely, without executing untrusted code on my computer?
Can you provide instructions for overriding fast flags without using third-party software? Is there a file somewhere I can modify, safely, without executing untrusted code on my computer?
I wrote a brief guide here:
Is it possible to add such a feature flag that allows the 2D UI layers to render at full resolution (i.e. before this update), as has been done for the game viewport?
It’s all well and good having the 3D viewport more or less as it was before, but it does little to remedy the usability issues when all the UI elements and Humanoid names/chat bubbles are still being scaled up.
Can you show a screenshot, indicate what game you are seeing this on, and at what DPI scale? The DPI scaling should make the text and other UI appear at the same size, but render at a higher resolution. If we enabled HiDPI without scaling, then everything would look much smaller. The scaling is what makes things look the same size, despite the resolution change.
175% Scale (Windows 8.1 DPI Scaling) at 1920x1080 screen
This issue WAS fixed but right now again, this issue makes the UI bigger in every game I join in
This is what it looks like (Game version):
And this is what it SHOULD look like (Studio version):
cc @Stalkalek
What you’re seeing, where the viewport is at full resolution but the GUI elements are scaled correctly, is actually correct and intended behavior. I understand that you’ve gotten used to seeing the GUI elements displayed at your native pixel density, but when DPI scaling is in effect this is actually not correct - the GUI elements should be scaled up by whatever percentage your DPI scaling is set to, which is usually 125% at 1080p and 250% at 4K (although I personally use 200% at 4K).
@nacasagu: I have a checklist for you or your team to ensure that DPI scaling is working correctly and that compatibility with existing games is maintained. Try to hit every point.
GUIs are scaled up according to the device’s scaling factor. Text Stroke and UIStroke width are specified in density-independent pixels, not hardware pixels.
AbsoluteSize and AutomaticSize of TextLabels is calculated correctly. Text does not wrap when the text label’s size is perfectly equal to the bounds of the text.
The viewport is displayed at full native resolution to avoid scaling artifacts. This must be opt-out so that players get a correct, pixel-accurate experience by default, but can disable it if their GPU is not powerful enough.
Camera.ViewportSize still reports in density-independent pixels so that it can be used for sizing GUIs.
Camera:ViewportPointToRay and related functions consume/return density-independent pixels so that they can be used for GUI positioning.
You may want to add a Camera.AbsoluteViewportSize so that games can detect the scaling factor. They should be able to function without needing to care, if everything is properly in density-independent pixels, but being able to know how many physical pixels correspond to a DIP is useful sometimes.
No Lua-accessible functions or properties in the engine deal in native pixels. Everything is in density-independent pixels.
GuiObject.Size, GuiObject.Position, GuiObject.AbsoluteSize, GuiObject.AbsolutePosition, all UDim/UDim2 propertiesTextLabel.TextSize, TextLabel strokeUIStroke.ThicknessCamera functions dealing in pixelsTextService methodsWith DFFlagDisableDPIScale set to true, and DFFlagVariableDPIScale2 set to false, I am still getting a blurry viewport with scaling artifacts.
EDIT: Sorry! I had the path wrong. Mine was %LocalAppData%\Roblox\Versions\version-53d1b11b188e46c2\ClientSettings\ClientSettings.json when it should have been %LocalAppData%\Roblox\Versions\version-53d1b11b188e46c2\ClientSettings\ClientAppSettings.json. Changing the name fixed it. TYSM!
Contents of the file for anyone in future:
{"DFFlagDisableDPIScale":true,"DFFlagVariableDPIScale2":false}
P.S. Do you have a method of enabling the DPI scaling in Roblox Studio? It’s been enabled on macOS for years. Would love to get that back on my new Windows PC.
Well, changing the FFlags doesn’t have an effect for me… (yes I double checked path, filenames and contents)
The best way I can describe the issue for me is all Roblox UI (including the loading screen when you start any game) seems maybe 1.25x bigger than it originally was.
Roblox Studio looks the way it always did, this only seems to affect the Roblox player.
Can this please be fixed soon? I understand some people can manually fix it with FFlags, but I think it’s safe to say the average Roblox user wouldn’t know how to edit FFlags or even know what they are.
See the quote below for explanation.
FFlagClientEnableHiDpi2 is the flag controlling the UI scaling. I would highly recommend you get used to the new UI scaling, though.
“Override high DPI scaling behavior” is supposed to be for getting it to run at your native resolution. Not for making the UI smaller. The UI becoming smaller was an accident. Now the UI is what it should be - native resolution, no pixellation.
Hi @octav20071 - just wanted to follow up with you. Are you still experiencing issues? If so, would you be able to reply back with an RBLX that demonstrates the issue?
Thank you!
Hi @hoontee - are you still seeing issues on mobile? If so, do you have an RBLX file that you can attach that demonstrates the issue?
Thank you.
Hi @DeniedTriangles - is this issue still occurring for you? If so, would you please attach an RBLX file demonstrating the issue for us to investigate?
Thank you!
Nope, it was fixed a few weeks ago. I notice that the resolution is higher today which is neat 
Hi @Ryhr , thank you for providing the repro file. After investigation, we found that in this place, you had the parent frame as a scrollingFrame, the AutomaticCanvasSize is on. In the UIListLayout, the HorizontalAlignment is Center, which makes the scrollingFrame’s “startPoint” the center of the UIList. If you wish to make the scrollingFrame to scroll from the leftmost of the list, you can change the HorizontalAlignment to Left. If that’s not the unexpected behavior you were talking about, I’d assume you were pointing out the end state of scrolling does not stop at the rightmost of the UIList, which means the AutomaticCanvasSize’s calculation didn’t take the Alignment of the UIListLayout into account, which may require some further investigation. Please verify with the HorizontalAlignment change mentioned above to see if that fix your issue. Or could you please provide with more detailed unexpected behavior in this case and the expected behavior? Thank you!
This is a reply to you that provides you with the unexpected behavior that has more details and the expected behavior.
Reproduction file (AutomaticCanvasSize set to x, HorizontalAlignment set to Center).rbxl (38.7 KB)
Reproduction file (AutomaticCanvasSize set to x, HorizontalAlignment set to Right).rbxl (38.7 KB)
Reproduction file (AutomaticCanvasSize set to y, VerticalAlignment set to Center).rbxl (38.7 KB)
Reproduction file (AutomaticCanvasSize set to y, VerticalAlignment set to Bottom).rbxl (38.7 KB)
Reproduction file (AutomaticSize set to x, HorizontalAlignment set to Center).rbxl (38.7 KB)
Reproduction file (AutomaticSize set to x, HorizontalAlignment set to Right).rbxl (38.7 KB)
Reproduction file (AutomaticSize set to y, VerticalAlignment set to Center).rbxl (38.7 KB)
Reproduction file (AutomaticSize set to y, VerticalAlignment set to Bottom).rbxl (38.7 KB)
Hi @Ryhr , appreciated your detailed description and repro files. If I’m understanding this correctly, the expected behavior is:
Since our design of AutomaticSize is to follow the behavior when there is no AutomaticSize set but set the size correctly, we can look at the problem when AutomaticSize is off. If you have a duplicate of this UI structure and turn all the AutomaticSize off, and set the canvas size to the AbsoluteContentSize of the UIListLayout manually, you can see that setting the HorizontalAlignment to Center or Left or Right doesn’t trigger any change. Because the starting status of the canvas position is 0. And the UIListLayout should fill the canvas since they are the same size.
If you want the starting status of the ScrollingFrame is to scroll from the center, you should probably consider using Left Alignment and changing the CanvasPosition correctly to the center, or using UIPageLayout. The AutomaticCanvasSize can only calculate the canvas size, but not change any position.
But there is indeed some issue with the AutomaticCanvasSize here that the UIListLayout is positioned incorrectly. We will keep investigating this problem.
Please feel free to let us know if the expected behavior understood above is incorrect.
Hi, it’s me again, I’m still having issues with outlines of various objects…
The button has a UIStroke with Bevel and a thickness of 2. This image is taken when I had the FFlagClientEnableHiDpi2 disabled. (a bit hard to tell with the screenshot but the right/bottom strokes are thinner than the top/left)
This is a screenshot taken when I had the FFlag enabled. Now the stroke is even and looks normal:
The issue is, with the FFlag enabled all my Roblox UI seems significantly smaller, and as qwertyexpert says having it disabled is the right way. I’ve messed around with other FFlags but FFlagClientEnableHiDpi2 is the only one that affects this for me.
This is incorrect - the UI elements should be scaled to your screen size, however, the stroke shouldn’t be rounding to the nearest pixel (I also have this issue where there’s a gap between the background color and the stroke). I believe this is due to the stroke not supporting subpixel precision for size or thickness.
This should be fixed by a recent Roblox update, could you re-test this and verify if it’s still an issue?
This issue still happens, unfortunately. I’m assuming its because it’s trying to scale half or quarter a pixel, and its rounding to the nearest pixels instead.
I understand why they would round the pixel instead of making a blurry line, but I think Roblox should opt for consistent stroke thickness rather than display accuracy.
