High-DPI disable / force resolution

[computistxyz]

Recent updates of Ren'Py have added support for high-DPI monitors. However, whilst my game runs at a resolution of 1920x1080 (and did so perfectly smoothly despite said updates), the engine now recognises my 3840x2160 display and runs to match the native resolution, with no added benefit to the source graphics yet with a substantial and unacceptable lag introduced - the cursor graphic is now smaller (the only thing which reflects the finer DPI) and lags an awful amount.

If I set my system display down to 1920x1080 (thus disallowing said high-DPI) the game runs perfectly fine again as it once did, but the fact I have to do that is not exactly a solution. Is there some way to disable this new high-DPI mode, replicating old behaviour and running at the actual 1920x1080 it is defined to in terms of height and width in the settings? Or, if not, how might I go about forcing the platform into a particular resolution, somewhat crude as that may be (a behaviour quite common in commercial games, especially older ones in light of bigger monitors)?

[Narcosis]

Having same issue here. Considering my game runs at ultra low resolution by choice, this function is nothing but an eyesore, especially if you're aiming for retro graphics (Game is running in 320x200, native resolution in this case was 1280x1024). Compare it with the previous version, before the function was implemented.

Is there any way to disable it and if there isn't, any chance we'll get some kind of an optional switch soon™?

[Yukari]

I'm having the same problem. A fix for this would be nice.

[morganw]

Having same issue here. Considering my game runs at ultra low resolution by choice, this function is nothing but an eyesore, especially if you're aiming for retro graphics (Game is running in 320x200, native resolution in this case was 1280x1024). Compare it with the previous version, before the function was implemented.

Have you got nearest neighbour rendering turned on?

Code: Select all

config.nearest_neighbor = True

Plus you can lock the scaling multiplier to whole numbers.

Code: Select all

def force_integer_multiplier(width, height):
  multiplier = min(width / config.screen_width, height / config.screen_height)
  multiplier = max(int(multiplier), 1)
  return (multiplier * config.screen_width, multiplier * config.screen_height)

config.adjust_view_size = force_integer_multiplier

[Narcosis]

I didn't try with the scaling multiplier, but I always used the nearest neighbour interpolation since it was implemented; results were great. I'm using a custom made bitmap font and at the moment, nearest neighbour interpolation still seems to work, but only for the graphics; something keeps on overriding it for the font rendering, tho.

edit:
Locking the multiplier doesn't help, nor change anything, either. Font is still blurry, even with the nearest neighbour interpolation turned on; turning it off blurs the whole game screen.

[morganw]

I just realised, it's your project I referenced when I was having trouble with a low resolution game.

Have you also tried...

Code: Select all

config.use_drawable_resolution = False

I'm using a TTF font and haven't seen an issues at 1920 x 1200, but I guess that might not be a high enough resolution to trigger any scaling in Windows.

[Narcosis]

Have you also tried...

Code: Select all

config.use_drawable_resolution = False

That's exactly what I was looking for! Thank you very much.

Hopefully I won't come into any more rendering issues. I'll still have to check, whether it's possible to have a custom kind of mouse cursor, which would scale appropriately to the resolution; irc, Pytom said it's (or wasn't) really possible due to the way Renpy handled cursor drawing - when I resize, the icon image doesn't scale with the resolution. I'll have to either drop it, or find a way that would at least replace the x2 scale cursor I use for Fullscreen mode with a standard size to match the pixels.

I just realised, it's your project I referenced when I was having trouble with a low resolution game.

Ah yes, that's mine. Are you interested in a similiar "retro feel" design as well?

[morganw]

I would have thought you could change the cursor size based on the same multiplier that is used for scaling the screen. Not actually scaling the cursor, but just setting a different cursor based on the multiplier in the config.adjust_view_size function, e.g. multiplier is 2, so set the cursor to be one that is twice the original size.

I am interested in the "retro feel", your project looks pretty cool. I'm using the same game resolution but my issues have mostly been around full screen scrolling performance; when using nearest neighbour rendering and a low game resolution the scrolling seems to be more inconsistent in speed (compared to scrolling with a higher game resolution). I'm guessing having a smoothed delta time for scrolling would help, but I was going to do some more testing before raising it as an issue / feature request.

[Narcosis]

I would have thought you could change the cursor size based on the same multiplier that is used for scaling the screen. Not actually scaling the cursor, but just setting a different cursor based on the multiplier in the config.adjust_view_size function, e.g. multiplier is 2, so set the cursor to be one that is twice the original size.

That's a neat idea. I'll definately check out if it's possible to make it work like that.

I'm using the same game resolution but my issues have mostly been around full screen scrolling performance; when using nearest neighbour rendering and a low game resolution the scrolling seems to be more inconsistent in speed (compared to scrolling with a higher game resolution). I'm guessing having a smoothed delta time for scrolling would help, but I was going to do some more testing before raising it as an issue / feature request.

It propably depends on the kind of the end effect you'd like to achieve; majority of 8-bit systems couldn't really handle multi-layered graphics scrolling due to massive hardware limitations; not that it was entirely impossible, just difficult to pull off. One of the games, which actually managed to do that was the C64 port of Amiga's Shadow of the Beast, which had superb pixel-precise scrolling on many different panes:

https://youtu.be/3upIiioeVjM

It's not 100% smooth, but runs and looks gorgeous. for a game, that's basically a generation younger and works on a far greater hardware, C64 version is considered one of the best and most faithful ports ever made.

[morganw]

I did some testing today (just scrolling a single image) on three different computers and an iPad, and I see the same jitter in any type of linear scrolling. It's present at higher resolutions too (I also see it in the ATL demos and the Pong mini-game, in the tutorial game) but becomes more apparent when the game resolution is lower. It's masked out somewhat by scrolling at higher speeds or by using a non-linear transform. Using a faster computer reduces it, but the slower computers only show moderate CPU usage (less than 20%), so I think it's just that a faster computer is more likely to run the engine loop with time to spare and so the delta time is less likely to be skewed. I think I'll probably open it as an issue just to check that this is the case.

Regardless of the above though, I've tested a lot of other engines and Ren'Py stands out as one of the few where resolution and images are handled as transparently as possible. At the moment I'm testing with a spritesheet (cropped in transforms), which ensures everything is in the image cache, but also highlights when images aren't pixel perfect as the bleed colour for the spritesheet will appear along one edge. As long as nearest neighbour rendering is on, everything has looked correct on every device I've tested on. I did use to have an Amiga, so I guess I am quite fussy when it comes to scrolling...

[Narcosis]

I did some testing today (just scrolling a single image) on three different computers and an iPad, and I see the same jitter in any type of linear scrolling. It's present at higher resolutions too (I also see it in the ATL demos and the Pong mini-game, in the tutorial game) but becomes more apparent when the game resolution is lower. It's masked out somewhat by scrolling at higher speeds or by using a non-linear transform. Using a faster computer reduces it, but the slower computers only show moderate CPU usage (less than 20%), so I think it's just that a faster computer is more likely to run the engine loop with time to spare and so the delta time is less likely to be skewed. I think I'll probably open it as an issue just to check that this is the case.

As far as I can think of, the only elements, which would benefit from scrolling in a vn would be panoramic backgrounds with moving clouds, but due to distance, it's obviously going to move slowly. Unless some really weird stuff will happen on screen, I'm perfectly fine with linear movement, as it kind of mimics the slowness of complex graphics drawing, present on C64.

I'd like to stay faithful to the original hardware limitations of C64, but it seems I'll have to take a couple of liberties; considering the game will have multilayered graphics, animated high-res sprites (lip flap, eye blinking, as well as simple character movement animations), along with a textbox and mouse cursor, it's already too much for a stock C64 to handle. A visual novel in the likes of those from NEC PC's wouldn't be possible on C64 hardware, mainly due to massive memory limitations (only 64kb of memory) and slow CPU speed. I'm actually tempted to limit the framerate, to give it that slight choppiness to the animations and mouse cursor movement.

Ren'py seems like the best choice in terms of available tools, as it already gives a working mainframe, you can easily prototype your game on.

[computistxyz]

(For some weird reason, I only just got notified about any replies to this topic haha)

I still haven't been able to resolve this issue from my perspective. I've tried setting config.use_drawable_resolution to False, but this didn't seem to change anything; when running the game on a display higher than 1920x1080, the engine still attempts to match the high-DPI and introduce needless amounts of general lag and cursor size dissonance.

[morganw]

I think at the moment the default behaviour is to always use the native resolution of the screen, in order to preserve image quality and ensure that everyone can play the game. "config.use_drawable_resolution" lets you use the game's resolution for most of the transforms, but the final result will be drawn using the native resolution of the screen.

[computistxyz]

I've just isolated the problem still further:

If the game launches in fullscreen mode, it will re-adapt to the higher native resolution. This will then sustain if switching into windowed mode.

If the game launches in windowed mode, it will correctly launch in 1920x1080. However, attempting to switch to fullscreen mode still has a newly introduced bug wherein the screen turns permanently black with the game still running, until the game is quit and re-opened.

So, it seems to me that there's some sort of adaptation being done in the launch procedures, in which the game will re-adapt to higher DPI IF it is to launch in fullscreen mode. So, there's two things at play here:

• Some way of disabling this behaviour when launching in fullscreen mode
• Fixing the turns-to-black bug when switching from window to fullscreen in-game

[PyTom]

Can you give a sample game, so I can try that out on my hardware?