Screen Scaling Quandary: Platform Dependent?

[orcmid]

Although we build raylib apps for specific platforms, there are times when there must be application customization at runtime because of configuration differences that impact the usability of the distributed application.

An important case is differences in screen resolution and screen size at that resolution. This is needed for determination of positioning of an application's window and in providing legible text in messages and elsewhere in the display.

Q1: Is this too much to expect of the BGI model that raylib is a modernization of?

Q2: In order to hide differences between platforms, is it useful to provide a companion library module that provides a general API but, depending on the platform, incorporates different platform-specific implementations?

This would not require modifications to raylib itself, but allow developers to introduce, use and contribute platform-specific versions at compile time. The general API would be usable prior to InitWindow() in order to obtain the characteristics of the available display that are important in providing a pleasant result to the app's user. Is this a worthwhile activity? 

I looked at Discussions #2999 and the earlier #1888. These all seem to be about configuring and compiling for a specific case, not dynamically adjusting. It is also unclear how one can dynamically adjust without first doing an InitWindow(). I am interested in programs discovering the screen characteristics, including the dpi, and then adjusting the presentation accordingly.

Update

I have been sketching out use of an API, nfoPixels.h and platform-adapting implementations, such as nfoPixels-Win32.c for the Windows Desktop. These will run independently of raylib, but have API functions that will assist a raylib app adjust to display resolution (size, dpi, and any OS-involvement) variations at run-time.

My attention is on other matters at the moment, but I wanted the trivial stub and basic approach available for others to review. My objective is to contend with Windows only, relying on C Language and Visual Studio Build Tools. The idea is for others to provide alternative nfoPixels-platform.c solutions using a commonly-agreed nfoPixels.h and its API usage.

See My Projects nfoPixels. There is explanatory material is in nfoPixels.txt and the skeletal nfoPixels.h.

Conceptual Model Challenge

Operating at the pixel level, it is not possible for nfoPixels to determine whether or an assumed-DPI placement fits in the actually-available display area. Fine-grained checking will determine fit within the physical display at its DPI, that is not useful except when full-screen operation is involved.

I also want the pixel-level nfoPixels operation to work as rapidly as possible, with integer scale factors (1x, 2x, etc.) returning as quickly as possible, with 1x being a straight pass-through.

I am adjusting the experimental descriptions in nfoPixels.h and nfoPixels.txt to deal with this difficulty.

---

Back Story

I have been happily building raylib demos, including an adaptation of the core_basic_windows.c file that I use to confirm correct installation and operation of my VCrayApp build set. Examples all build and display nicely on my old 30" (2560 x 1600, ~100 dpi) display. All the examples work great.

I recently acquired a laptop with a 14" (2400 x 1600, ~200 dpi) display. I had to change the Windows display-scale setting from the default 150% to 200% so that I could read text easily, including the labels on icons, the task bar, etc. It works reasonably well for old Windows apps that I still run, although the Window frame and its items are a bit puny. I can live with that.

When I compiled my examples on the new laptop, I was shocked to see that the resulting raylib Window was tiny and the text was barely readable. I'm about to install a new WQHD (3440 x 1440, ~110 dpi) monitor on my desktop also. I may see the same problem; I suspect not; we'll see. [side note: One reason for the new WQHD monitor, aside from the 30" display being 12 years old, is that it will work as an external monitor to the laptop. The adjustment that Windows makes to the desktop when switching between that monitor and the laptop display may be troublesome. I hope not.

[Peter0x44]

I believe users are expected to manage this on their own, with techniques like drawing to a RenderTexture and scaling, or using a Camera2D with zoom.

[orcmid]

@Peter0x44

I believe users are expected to manage this on their own, with techniques like drawing to a RenderTexture and scaling, or using a Camera2D with zoom.

I agree that is appropriate. However, it doesn't help beginners who find that existing examples render too small on one machine and not another, and the situation is not understood. I don't want beginners to be confronted with this on the first use of raylib.

I am also not proposing any modifications to raylib. nfoPixels.h is for independent usage, as is the nfoPixels-Win32.c that I am interested in. (That .c file does have safe and isolated windows.h dependencies, and versions for other platforms will also isolate low-level dependencies of some flavor.)

Finally, I think I am being misunderstood. I have always thought windows.h was a terrible idea and have avoided using it from the outset, usually finding the subordinate .h SDK files on which I had any actual dependencies. Dependency management has always been most important for me. I only use windows.h nowadays to demonstrate its isolation and/or where I need to explain something using practices that others, especially Visual Studio users, expect to see. The Serenity Prayer seems appropriate.