How can I retain the fidelity of text outlines when upscaling?

[geoWaffle]

The game I'm working on is rendered at 960 x 540; intended to be upscaled to 1920 x 1080 in actual gameplay (Or 4k, I suppose). All of the assets are drawn at this resolution, and the fonts are specifically chosen to look appropriate for the occasion, and both the game and its fonts have anti-aliasing disabled (as well as forcing resolutions to prevent eye-melting). For the most part, upscaling to fullscreen works entirely as intended, and the game is able to retain pixel-perfect accuracy.

The problem here stems from Renpy's outline feature clashing (that is to say, working entirely as expected) with the scaling feature.

cottagecheese.png (21.82 KiB) Viewed 576 times

See the attached image for an example of the problem. When upscaled in rendering to 1080p, the outlines will try and maintain an equivalent ratio of outline to text by doubling both; at the same time also doubling the number of visible pixels. This is best seen in the bottom corners of the individual letters.

I'm sure there are some hacky workarounds for this problem (say, creating drop-shadows with the outlining and then using differently offset instances of those to create the effect of a pixel-accurate outline), but all of these ideas seem less than ideal. I've been checking around the documentation, but haven't been able to find anything simpler that will work.

For reference, this is what the outline code currently looks like.

Code: Select all

define gui.text_outlines = [ (2, "#000", 1, 1) ]
define gui.label_text_outline_scaling = "step"

## As well as this, later on in the code...

define config.nearest_neighbor = True

As it stands, the only way for the game to be pixel accurate is for it to be rendered at 960 x 540, which is obviously a problem.

If there's a way of doing this that I'm simply missing, I would really appreciate it if someone could help out. Equally, I would appreciate being told that what I'm trying to accomplish is impossible so I can stop wasting my time and just try and do something else visually with the font.

[strayerror]

Would using absolute in your outline definition help?

By default, size, xoffset and yoffset are scaled with the text. When given as the absolute type, they are not scaled. For example:

i.e.

Code: Select all

define gui.text_outlines = [ (absolute(2), "#000", absolute(1), absolute(1)) ]

Docs page: https://www.renpy.org/doc/html/style_pr ... y-outlines

[geoWaffle]

Would using absolute in your outline definition help?

That was actually what I tried first, and on paper it seems like it's exactly what I want. It does, after all, keep the exact pixel count.

... Relative to the size of the game window.

It does FEEL like it should be that simple though, right?

Maybe what I want is something that can change what absolute considers the window size to be, or something? That's just idle speculation, though.

[geoWaffle]

I got around to trying one of my ideas for some sort of hacky workaround.

Visually, it has only minor differences from the original, but upscales perfectly to 1920 x 1080 while retaining defined pixelated edges.

cottagecheese2.png (20.49 KiB) Viewed 480 times

This is what it looks like. Of course, the visuals are no longer the problem.

This is what the code looks like.

Code: Select all

define gui.text_outlines = [ (0, "#000", -1, 0), (0, "#000", -1, -1), (0, "#000", 0, -1), (0, "#000", 1, -1), (0, "#000", 1, 0), (0, "#000", 1, 1), (0, "#000", 0, 1), (0, "#000", -1, 1), (0, "#000", 0, 0), (0, "#000", 2, 0), (0, "#000", 2, 2), (0, "#000", 0, 2), (0, "#000", 1, 2), (0, "#000", 2, 1), (0, "#000", 3, 1), (0, "#000", 3, 2), (0, "#000", 3, 3), (0, "#000", 2, 3), (0, "#000", 1, 3) ]

All in all, an unpleasant solution. The code is basically indecipherable, and the entire process had to be meticulously worked out in Clip Studio Paint just to get some sort of easy visual reading on what's actually going on with the numbers. If I want to make adjustments, it won't be impossible, but it certainly won't be easy; extra outlines with this method require exponentially more code since the space that the dropshadows need to cover will be increased, but their actual size won't be.

It's stupid. But... It's not like it DOESN'T work...