Introducing backing scale #1269

colincornaby · 2022-12-05T05:02:07Z

This change introduces the idea of a backing scale into the engine. Backing scale refers to the difference between the resolution of the window that Uru is running in, and the resolution of the frame buffer backing it.

For example, on a 4k Retina display, the window may only have a resolution of 1920x1080, while the actual Metal/DX/OpenGL frame buffer has a resolution of 3840x2160. The backing scale would be 2.

Different UI elements can use the backing scale to resize accordingly. This change alters the behavior of progress bars and the intro movie to account for the backing scale. Cursor should also change with the backing scale - I'm still working on pulling that together for this pull request.

Text rendering should also take into account the backing scale (although this PR does not make all the required changes.) A backing scale of 2 would imply that a 12 point font should render at twice the DPI. I've made some initial progress for this on macOS.

Backing scale is also useful if Uru ever chose to use DLSS/MetalFX upscaling. If the engine is under-rendering, backing scale can be used to push the UI elements back into a size the user expects.

colincornaby · 2022-12-09T05:11:25Z

I'm looking at cursor scale again. Cursor scale is its own function right now in the Mac client. In some ways this makes sense - plMouseDevice is not owned by plClient and can't trivially just inherit settings. There are accessibility reasons that the cursor may also want to be its own scale down the road.

I may reintroduce the cursor scale as is - even though it's parallel to the backing scale and not directly affected by it. There could be further iteration on cursor scale later.

colincornaby · 2022-12-09T06:23:36Z

Something weird is going on in Windows font rendering. It's not behaving how I expect it to, and this pull request is causing font spacing to not behave correctly on Windows. Still checking it over.

colincornaby · 2022-12-10T19:19:53Z

I'm kind of fumbling around in the Win32 client (never done serious Win32 before) and I've got backing and cursor scale hooked up in Windows as well.

I enabled HiDPI in Windows by tweaking the manifest. I have not committed that change in since it probably requires more testing, and there have been known issues around HiDPI.

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
	<asmv3:application>
		<asmv3:windowsSettings>
			<dpiAware xmlns="https://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
		</asmv3:windowsSettings>
	</asmv3:application>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/>
    </dependentAssembly>
  </dependency>
</assembly>

Hoikas · 2022-12-10T19:22:14Z

I haven't read the code yet, but we probably want to avoid using the manifest for this because DPI Awareness v2 in the manifest will lock us to Windows 10 v1703. Instead, we'll want to use LoadLibrary to call the appropriate SetThreadDpiAwareness function.

colincornaby · 2022-12-10T19:25:24Z

Thanks! I was unsure how to opt in to functions from newer versions of Windows. There are better DPI check functions to use on newer Windows as well.

I'm also unsure if cursor scale and backing scale should be more closely related or stay separate options - but that's why this PR is a draft.

Hoikas · 2023-01-08T02:36:42Z

I've built a set of DPI awareness changes for Windows on top of this PR on my fork that might be useful. My branch seems to fix the problems in #636.

colincornaby · 2023-02-17T06:35:43Z

Your changes look good to me.

I'll reset this to your branch's head and then graduate this to a full PR. Your comments indicate there might be a few things not done yet, but we can look at that on deeper review.

colincornaby · 2023-02-17T06:36:26Z

I wrote that I'd bring in your branch's head. It's already here! Never mind.

Sources/Plasma/Apps/plClient/plClient.cpp

colincornaby · 2023-03-18T23:58:10Z

@Hoikas - I'm going to look at this again on macOS. Was there any more work you wanted to do on Windows? So far this has worked well on Windows for me, but I know there are some todos in the code comments.

Hoikas · 2023-03-19T00:01:31Z

I don't think there's anything else I want to do right now.

colincornaby · 2023-03-19T00:02:30Z

I'll do a final checkover. I'm fine dealing with any Mac specific issues directly on the Mac branch. But I do want to make sure there isn't anything critical with the core implementation.

colincornaby · 2023-03-19T06:25:22Z

Something is subtlety wrong with Windows font rendering at HiDPI. The spacing is off. I think it's due to an issue with the font map that's created. I'll investigate more.

colincornaby · 2023-03-20T21:26:13Z

Some details about the Windows font issue I'm looking at.

Here's what the current master branch looks like on the load screen:

And here's what this branch looks like on a HiDPI display:

The HiDPI issue has some subtle issues. The "Downloading" text is slightly too high and the detail text below the progress bar is spaced slightly too close.

Here's a graphic that better shows the issue:

I spent some time going through the rendering code, and have started to believe the issue might be in the Win32 code that creates the font texture. On the left is the HiDPI font texture, and on the right is the normal font texture. I did a 2x nearest neighbor scale on the low rest font texture to make it comparable to the 1x texture.

There seems to have been a padding change over the original 1x map. This could be working its way into the renderer causing the text to be pushed up. That would push the top text away from the progress car, and the bottom text closer to the progress bar.

This is my best lead so far. Examining the original Direct3D rendering with PIX and the metrics being created on the fly - everything in those components seems to be in order. The font map is the only thing I'm finding that looks wrong.

My strength is in Quartz2D text rendering but I'll do some Win32 digging to see what I can figure out. I might pull this code out into it's own app to do some quicker debugging.

Hoikas · 2023-03-20T21:28:45Z

It's probable that there are some non-DPI aware APIs being called in the debug text renderer that I didn't catch. 😞

colincornaby · 2023-03-20T21:30:44Z

It's probable that there are some non-DPI aware APIs being called in the debug text renderer that I didn't catch. 😞

Possible. But this code is strange in that Cyan created it to be DPI aware - but it may have never really worked. AFAIK the DPI check would never have been tested at anything but the default 96 DPI.

dpogue · 2023-03-20T21:39:46Z

Alternatively, maybe we write an implementation of this using freetype2 so that it's cross-platform? (Since I'm going to end up needing to do that for OpenGL anyways, if someone wants to do that work for me... 😛)

colincornaby · 2023-03-20T21:45:52Z

Alternatively, maybe we write an implementation of this using freetype2 so that it's cross-platform? (Since I'm going to end up needing to do that for OpenGL anyways, if someone wants to do that work for me... 😛)

I feel like you might have just volunteered yourself. 😛

With FreeType2 we'd still want to make sure that everything lines up the same which might be tricky. I'm getting the sense a lot of this font code just happened to work and had some amount of magic numbers, which is being upset by the DPI work. I cleaned a lot of that up on the renderer side. And while I don't see any magic numbers in the font map code - something is clearly up.

colincornaby · 2023-03-27T04:19:58Z

Update on where I am with this:

There are issues with how the text rendering code was originally written. Plasma wasn't intended to be DPI aware when it shipped, so they're understandable.

I'm going to grab this graphic from Stackoverflow to demonstrate the issue:

TrueType fonts have layout metrics that define the layout of the glyphs. This spacing is not guaranteed to be stable between font sizes or faces.

Plasma lays out text from the top of the character. But Courier New specifically does not have consistent top padding between font sizes for its glyphs. This is causing the text's offset to shift between font sizes.

A fix would be using the text baseline (the green line) for text layout. This line is stable in relation to the glyphs and would be more predictable between font sizes. Unfortunately, this requires passing through additional metrics about the font and re-writing some rendering code.

I have most the work done, but right now I'm just making sure I didn't break the standard DPI on Windows.

colincornaby · 2023-04-14T01:58:01Z

Sources/Plasma/PubUtilLib/plPipeline/plTextFont.cpp

@@ -136,23 +157,57 @@ uint16_t  *plTextFont::IInitFontTexture()
    // Loop through characters, drawing them one at a time
    RECT    r;
    r.left = r.top = 0;
-    r.right = r.bottom = 10;
+    r.right = 1;
+    r.bottom = 10;
    FillRect( hDC, &r, (HBRUSH)GetStockObject( GRAY_BRUSH ) );

    // (Make first character a black dot, for filling rectangles)
    SetPixel( hDC, 0, 0, RGB( 255, 255, 255 ) );


Does anyone know what lines 158 through 165 are about? The first character is going to be a space, which feels sufficient. I have no idea what this other code is doing. @dpogue @Hoikas

That looks a little bit like it's drawing a cursor, assuming you mean:

RECT r; r.left = r.top = 0; r.right = r.bottom = 10; FillRect( hDC, &r, (HBRUSH)GetStockObject( GRAY_BRUSH ) ); // (Make first character a black dot, for filling rectangles) SetPixel( hDC, 0, 0, RGB( 255, 255, 255 ) );

Not sure about the SetPixel() call though.

…GDI.

…to the patcher

…exture buffer

Sources/Plasma/Apps/plClient/CMakeLists.txt

Hoikas · 2023-06-25T20:05:04Z

Sources/Plasma/FeatureLib/pfDXPipeline/plDXPipeline.cpp

@@ -3337,6 +3337,7 @@ bool  plDXPipeline::CaptureScreen( plMipmap *dest, bool flipVertical, uint16_t d
    }
    else
    {
+        // FIXME: DPI awareness


This function is never used anywhere, so omitting should be fine for now, IMO.

Sources/Plasma/PubUtilLib/plPipeline/CMakeLists.txt

Sources/Plasma/PubUtilLib/plPipeline/plTextFont.cpp

Hoikas · 2023-06-25T20:11:48Z

Sources/Plasma/PubUtilLib/plPipeline/plTextFont.cpp

-    nHeight = -MulDiv( fSize, GetDeviceCaps( hDC, LOGPIXELSY ), 72 );
-    fFontHeight = -nHeight;
-
+    int nHeight = -MulDiv( fSize, plWinDpi::Instance().GetDpi(), 72);


Is this ever re-done when the DPI changes while the game is running?

DPI change is treated as a device reset IIRC just like any other resolution change - which should flush textures like this one.

I don't know that this path has ever been fully tested however.

Co-authored-by: Adam Johnson <[email protected]>

Hoikas · 2023-06-25T21:01:02Z

Still waiting on the update to cmake/Dependencies.cmake, then we should be good to go.

colincornaby · 2023-06-25T21:55:49Z

Still waiting on the update to cmake/Dependencies.cmake, then we should be good to go.

Not seeing that comment, guessing it's just buried in the others. But I'm guessing the change you'd like to see is FreeType moving to required from optional?

Hoikas · 2023-06-25T22:05:41Z

Yes, per @dpogue

colincornaby force-pushed the backing-scale-changes branch from 46ccb75 to 228b610 Compare December 5, 2022 05:32

colincornaby force-pushed the backing-scale-changes branch from cb24c65 to 0e91d15 Compare January 8, 2023 06:06

colincornaby marked this pull request as ready for review February 17, 2023 06:36

dpogue reviewed Feb 17, 2023

View reviewed changes

Sources/Plasma/Apps/plClient/plClient.cpp Outdated Show resolved Hide resolved

colincornaby force-pushed the backing-scale-changes branch 2 times, most recently from 4bb5dc8 to c25f554 Compare April 12, 2023 05:20

colincornaby commented Apr 14, 2023

View reviewed changes

colincornaby force-pushed the backing-scale-changes branch 3 times, most recently from 9049200 to c41e984 Compare April 17, 2023 05:13

colincornaby force-pushed the backing-scale-changes branch 2 times, most recently from 2b611b3 to 5dcb92f Compare April 28, 2023 00:34

colincornaby added 13 commits June 17, 2023 15:45

Initial cut of Freetype code. Stilll a bit of a mess. Still a lot of …

075df94

…GDI.

Cleaning up size issues and removing likely dead code

6d311d3

Fixes for FreeType font layout

808ad18

Allowing banner images in login screens to scale and hacking HiDPI in…

f72b890

…to the patcher

More changes to make plWinDPI modular

92ecbd4

Applying suggestions from code review

bc2eb34

Cleaning up text font and putting Mac in Freetype path

49bd069

Fix suggestion for 32 bit Windows

f90e247

Rolling back some anti-hinting to see if Windows is fixed

c616762

Alloc larger textures if needed, adding asserts

1161188

Using fFontHeight for font texture size calc

3f48626

Initialize fTextureWidth and fTextureHeight _before_ allocating the t…

a00aca1

…exture buffer

Using plWinDPI for DPI checks

020a9a4

colincornaby force-pushed the backing-scale-changes branch from ca29f47 to 020a9a4 Compare June 17, 2023 22:45

dpogue mentioned this pull request Jun 21, 2023

First pass of OpenGL rendering pipeline #1201

Draft

Adding link to plWinDPI from plPipeline on Win32

e470284

Hoikas reviewed Jun 25, 2023

View reviewed changes

colincornaby and others added 2 commits June 25, 2023 13:27

Apply suggestions from code review

1a51fa6

Co-authored-by: Adam Johnson <[email protected]>

Moving FreeType to end of list

4673e0f

dpogue linked an issue Jun 25, 2023 that may be closed by this pull request

Garbled Text when System Scaling >= 300% #1214

Closed

Making FreeType required

8c02a4b

Hoikas approved these changes Jun 25, 2023

View reviewed changes

dpogue approved these changes Jun 26, 2023

View reviewed changes

dpogue merged commit 45f3fa2 into H-uru:master Jun 26, 2023

dpogue mentioned this pull request Jul 7, 2023

Game is pixelated when using HiDPI Scaling on Windows #636

Closed

Hoikas mentioned this pull request Oct 15, 2023

Display Modes for New Renderers #1502

Open

patmauro mentioned this pull request Nov 2, 2024

Names of the people are far away #1620

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introducing backing scale #1269

Introducing backing scale #1269

colincornaby commented Dec 5, 2022 •

edited

Loading

colincornaby commented Dec 9, 2022

colincornaby commented Dec 9, 2022

colincornaby commented Dec 10, 2022

Hoikas commented Dec 10, 2022

colincornaby commented Dec 10, 2022

Hoikas commented Jan 8, 2023

colincornaby commented Feb 17, 2023 •

edited

Loading

colincornaby commented Feb 17, 2023

colincornaby commented Mar 18, 2023

Hoikas commented Mar 19, 2023

colincornaby commented Mar 19, 2023

colincornaby commented Mar 19, 2023

colincornaby commented Mar 20, 2023 •

edited

Loading

Hoikas commented Mar 20, 2023

colincornaby commented Mar 20, 2023

dpogue commented Mar 20, 2023

colincornaby commented Mar 20, 2023

colincornaby commented Mar 27, 2023

colincornaby Apr 14, 2023

Hoikas Apr 15, 2023

Hoikas Jun 25, 2023

Hoikas Jun 25, 2023

colincornaby Jun 25, 2023

Hoikas commented Jun 25, 2023

colincornaby commented Jun 25, 2023

Hoikas commented Jun 25, 2023

Introducing backing scale #1269

Introducing backing scale #1269

Conversation

colincornaby commented Dec 5, 2022 • edited Loading

colincornaby commented Dec 9, 2022

colincornaby commented Dec 9, 2022

colincornaby commented Dec 10, 2022

Hoikas commented Dec 10, 2022

colincornaby commented Dec 10, 2022

Hoikas commented Jan 8, 2023

colincornaby commented Feb 17, 2023 • edited Loading

colincornaby commented Feb 17, 2023

colincornaby commented Mar 18, 2023

Hoikas commented Mar 19, 2023

colincornaby commented Mar 19, 2023

colincornaby commented Mar 19, 2023

colincornaby commented Mar 20, 2023 • edited Loading

Hoikas commented Mar 20, 2023

colincornaby commented Mar 20, 2023

dpogue commented Mar 20, 2023

colincornaby commented Mar 20, 2023

colincornaby commented Mar 27, 2023

colincornaby Apr 14, 2023

Choose a reason for hiding this comment

Hoikas Apr 15, 2023

Choose a reason for hiding this comment

Hoikas Jun 25, 2023

Choose a reason for hiding this comment

Hoikas Jun 25, 2023

Choose a reason for hiding this comment

colincornaby Jun 25, 2023

Choose a reason for hiding this comment

Hoikas commented Jun 25, 2023

colincornaby commented Jun 25, 2023

Hoikas commented Jun 25, 2023

colincornaby commented Dec 5, 2022 •

edited

Loading

colincornaby commented Feb 17, 2023 •

edited

Loading

colincornaby commented Mar 20, 2023 •

edited

Loading