Improve font legibility
tbertels opened this issue · 11 comments
For some reason, version 0.97.0apha on SourceForge has better font legibility than v0.96.4-0.1.3
Do they use the same font?
v0.96.4-0.1.3 font legibility is similar to version 0.96.4 on SourceForge.
They should be using the same text. At least, I haven't made any deliberate modifications along those lines. There have been some changes to how the list of resolutions is generated, so maybe the INI file has wound up with a resolution that doesn't exactly match what this version wants, resulting in some extra scaling? Is this happening at multiple resolutions? Does being full screen and/or in windowed mode make any difference?
I've been meaning to rebase onto the newer SourceForge version, but there has been so much divergence that it will almost certainly be a bit of work. Last I looked, it seemed sensible to wait for the actual release of 0.97 (or, at least, for those changes to be merged back from the build-v0.97.0 branch into master). On the other hand, it's not like typing "git rebase ..." to see what falls out would take more than a few seconds...
In [Video], I have
Width = 1600 Height = 900 Physical Width = 1600 Physical Height = 900
I tried different resolutions with no change.
The version 0.97 isn't great either, the top of some buttons text is missing and the font isn't as legible as the original Dune one.
By the way, I've noticed a freetype.dll file in the version 0.97 folder.
It may be a good idea to try a different font than Philosopher-Bold.ttf, or even to let the user change the font.
It looks like the font anti-aliasing is actually doing something constructive now. It certainly isn't perfect, but it is less blocky and reminiscent of ringing in an over-sharpened photo, if a bit blurry and vague in places (e.g., turn on the FPS or time output and see what the top of a "3" looks like). If you get a chance, try a build that includes b9001ff5. The current "*-0.1.3-19-g93120d9d" binaries do include this change. The text spacing and centering isn't great, particularly when using a language other than English.
This is what it used to look like:
And this is what it looks like now:
Let me know if you're having worse problems than the above. Include a copy of the log file, if at all possible ("%APPDATA%/dunelegacy/Dune Legacy.log" on Windows and "~/.config/dunelegacy/Dune Legacy.log" on other systems).
A typeface selection setting was added to the INI file as "Typeface" under [Video]. See the commit message for, "Allow the INI to override the default typeface," for an example that uses Segoe UI directly from the Windows/Fonts directory.
As for DLLs, the Windows CI builds here all do static linking for everything. It seemed simpler than having to worry about keeping files that match well-enough together (and I've never understood the enthusiasm some Windows folks have for distributing private copies of "shared" libraries that are never actually shared, even if they are dynamically linked). The official SourceForge Dune Legacy binaries are dynamically linked with the SDL libraries, which use the freetype.dll under the hood for font rendering.
Thank you for this big improvement!
I'd have been kind of happy with it if it did look like your first screenshot, but it actually looked like this here:
I'm guessing the intention was to make it look like the bitmap font used in the house selection screen. But it made it difficult to read while playing.
A problem with anti-aliasing, is that it's made to work at 100% zoom. When playing at 1920x1080 x2, the anti-aliasing is visible:
2x
1x
Is there any way to use bigger font size instead of applying a 2x zoom? That is, to overlay the text (with twice bigger font size) after resizing the content.
Some of the text was rendered into the original game's images (the house selection screen you have above is an example), but something should be doable for the text that is actually being rendered as text. As you suggest, rendering the text at the higher resolution would make a whole lot more sense than scaling after rendering the text. Furthermore, I'm not sure it makes much sense having 1x and 2x scaling modes at a set of fixed resolutions. Perhaps it's an artifact of the pre-SDL2 implementation where there wasn't any GPU drawing assistance? A configurable continuous zoom factor that tries to keep the text at given physical size as the DPI changes, with the other elements scaling to match, might be doable without too much work.
And there doesn't seem to be a good reason why one shouldn't be able to resize the window when playing on the desktop...
Indeed, configurable continuous zoom factor for both the interface and the game itself would be great. Currently, the choice is difficult between 1x and 2x.
might be doable without too much work
The bit about, "without too much work," is debatable, but the ui-scale branch now has text rendered for the physical display resolution and seems playable, if not without some remaining graphical glitches. Window resizing has been enabled on that branch, but the size changes aren't handled properly yet, so things get a bit messy if the window is resized on anything but the main page.
That's great news!
I was waiting for the new build to test it, but I guess since it's in a branch, no build will be available for now.
I wouldn't worry too much about window resizing unless it's not too difficult to fix.
I've just got a couple more things I want to fix before merging the ui-scale branch into the main modernize branch. That would publish new pre-release builds under Releases. It would make the app responsive to windows DPI changes and render fonts at the display's native pixel resolution, but it would not yet include any greater control over the game map's zoom (the "F1", "F2", "F3" bit). I'll probably leave the window resizing alone since switching sizes has really been around for a long time (going to or from full screen mode is really a window size change).
On the other hand, anyone logged in to GitHub should be able to see the artifacts for any build (IIRC). If you go to the Actions tab and click one of the recent builds for that branch, what do you see?
Do you see a list of "Artifacts" like this at bottom of the page? (I do, but I'm a project member.)
Those links should be downloadable--at least they were a couple of years ago. They should be the normal release zip files stuffed inside another zip file.
If not, one could always install VS2022. The Community edition is free for anyone when working on open source projects. Include the "Desktop development with C++" workload, start "x64 Native Tools Command Prompt for VS 2022", then paste the build commands from the "Building" -> "Windows Build" section of the project's front page) to build it from scratch.
Thanks, these builds are indeed available in the Actions tab. 🙂
And wow, the text looks much better now, it's perfectly legible!
Here's a screenshot for comparison with the previous ones:
Same thing for the briefing text:
I think we can close this.
By the way, the last screenshots were with the Arial font.
The default font looks great too:
