DPI/Scaling anomalies - use_drawable_resolution not functioning as expected.

In this forum we discuss the future of Ren'Py, both bug fixes and longer-term development. Pre-releases are announced and discussed here.
Post Reply
Message
Author
User avatar
Tayruu
Regular
Posts: 118
Joined: Sat Jul 05, 2014 7:57 pm

DPI/Scaling anomalies - use_drawable_resolution not functioning as expected.

#1 Post by Tayruu » Sat Jan 05, 2019 1:55 am

Okay, I know I've posted about this before, but this is a different machine, and I've done my best to explain all the details of behaviours I've observed.
My problem is that due to DPI/scaling in Windows, it makes Ren'py behave in ways that I don't think are intended.

So I have two machines: a Surface Pro 5 with a resolution of 2736x1824, with a scaling setting of 200%. Then I have my desktop with 1920x1080 and no scaling.
My project, is 1280x720. On the Surface, thanks to the scaling, it renders at double the size at 2560x1440.

Here are some notable settings I've messed with to work with this scaling:

Code: Select all

    import os
    os.environ["RENPY_HIGHDPI"] = "1.0" (or comment out)
    config.nearest_neighbor = T/F
    config.use_drawable_resolution = T/F
    config.drawable_resolution_text = T/F
By default, these settings are False or commented out. Displayables are rendered blinear, and the full "physical" resolution of the window is used. Depending on the settings, the following things can occur:
  • Blurring images made originally for non-scaled resolution. (To be expected, really.)
  • Glyphs of text will jitter about as they're being rendered/typed on screen.
  • Zoomed displayables render distorted when transitions play.
  • CTC will not be centred on text moved via {vspace}
The following are links to screenshots showing the various ways this affects one scene in particular. I have a background showing a computer screen, and inside that is a scaled-down view of the computer's desktop and text. This is made up of a few images (desktop elements) and screens (text contents and notifications).

This is with the settings as their defaults. This works fine without OS scaling, but with it it'll cause the CTC bug and text jitter bug.

This seems fine, but is where the issue of use_drawable_resolution comes in. When transitions play, even simple fades, all elements suddenly blur, as if rendering at the internal resolution. The state of the screen mid-transition is what I expect to be the default. But for some reason, despite use_drawable_resolution being False, the desktop contents render crisp in idle state.

The same thing happens with nearest neighbour. This is the screen's resting state, and here it is mid-transition. Athough in this case it looks notably worse. I've mostly been using nearest neighbour for pixel accuracy's sake, to see my game as someone without high-DPI would. As this affects other zooms too though, it's probably not good.

Then we have turning off high-DPI via the first os.environ setting. By setting it to "1.0" (a string) I get the game to render in actual native resolution. It looks as expected, with no blurring during transitons. This also results in my mouse cursor rendering at 200% like the rest of the game. However this causes the game window to start anchored to the bottom-right of the screen, and I can't get this to fix. (os.environ['SDL_VIDEO_CENTERED'] = "1" doesn't work.) Going full-screen makes only the top-left quarter of the game show on-screen.
(Actually it's not strictly true nothing happens during transition - some mask edges and fill shapes have single pixel distortions during transitions, but it's a minor bug, comparatively.)


~ ~ ~


So okay you're probably thinking "wait, don't you already have your solution?" I mean, yes, but bugs aside it might also not be the solution others want.
Some people might want to have their game render crisp at whatever resolution, but this has jittering text and misaligned CTC.
Some might not want to mess with os.environ["RENPY_HIGHDPI"], but find the visual glitches during transitions immersion breaking.
And others might want to be stricter about the way their game renders, thus use the former code, but doing this results in the game window not displaying correctly.

I hope this information is useful.

Post Reply

Who is online

Users browsing this forum: No registered users