Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
This outlines my plan for fixing our issues relating to zoom, custom resolutions, and HiDPI support in one fell swoop. I've referred to it several times in the past, so I figure it is time to document this properly. From my perspective this supersedes all the previous tickets, but of course others are free to argue against this.
Two new dropdowns are included in the display settings: UI resolution and World resolution (like UT3 and i'm sure other games have done). They contain values for "Native", a selection of popular defaults with a fixed width and a height calculated from the aspect ratio, and a "custom" option that exposes text fields for entering a manual width. These set the (fixed) size of the UI, and the default size/zoom of the world.
Players can use ctrl + scroll to arbitrarily zoom the world (but not the UI) between the minimum and maximum limits (explained below). The
The world rendering (everything that scales with the world, so this excludes selection decorations, target lines, etc) is rendered into a framebuffer that is configured a viewport size calculated from the zoom and default resolution, and the result is rendered using a quad covering the window viewport. The UI rendering (everything else from the world, and then the widgets) is similarly rendered first into a framebuffer (maybe the same as the first, depending on the cost of reconfiguring a buffer vs switching to a new one), and then scaled to fill the screen.
The default "Native" value is calculated by the window / display size divided by the native pixel scale (queried from SDL). The pixel scale will be 2 for retina displays under OSX, or between 0.75 and 2 (I think?) for the different DPI options under Windows. We can calculate the pixel scale by comparing the resolution that we asked for with the output from SDL_GetRendererOutputSize. The minimum supported resolution is defined in mod.yaml (with defaults for our mods of 1024 x 700), and the maximum values are queried from the GPU (the smaller of
To enable HiDPI rendering we need to set
The world is always rendered with a "zoom" of 1 into the framebuffer, so all of the fiddly code using Viewport.Zoom can be removed (yay!). The shader-level hack for rendering the depth buffer can also be removed in favour of rendering the depth texture from the framebuffer.
I'm considering playing this in WINE because it isn't natively playable in 4k resolution (3840x2160). WINE has a DPI setting which I can double (from 96dpi to 192dpi) and use WINE apps normally.
The biggest issue for me is I can't see the text and graphics without having my nose an inch off the screen.
I've tried OPENRA_DISPLAY_SCALE and it looks good. However, after I use it, it also scale the map and the units, just like double pixeling. When I don't scale, I can see a whole small map without scrolling in a 4k display, so what I want is not scaling the map, and just scale the menu and minimap on the right.
New user impression using release-20190314: Oof. My native resolution is 1080p. By default some of the text is almost too small to read, while the movies take up only 25% of the screen.
Using the hidden fullscreen resolution option is broken - the game does ugly nearest neighbor scaling of the UI, and thinks you're clicking in a different place than where the mouse cursor is at.
Using hidden fullscreen resolution with legacy fullscreen seems to be the best option. At 720p I can actually read the mission detail text, and the videos aren't ridiculously tiny.
I would actually prefer the game run at 1080p, but scale (preferably bilinear) the text and videos to something reasonable.