Added LunaLuaSetWindowScale and LunaLuaGetWindowSize

[MrDoubleA232]

Adds two FFI functions:

• LunaLuaSetWindowScale, which sets the size of the window relative to the framebuffer's size. Perhaps useful for a menu option on its own, but can also be used for resizing the window after modifying the framebuffer size. The scale is applied together with the DPI scale, rather than overwriting it. It also won't do anything in fullscreen.
• LunaLuaGetWindowSize, which returns the current size of the window. It is relative to the DPI scale, so a 1200x900 window with a 1.5x DPI scale with still return 800x600.

If there are any issues with this implementation or a better way to go about things, let me know!

[Bluenaxela]

I've been thinking about this topic a bit.

Some things I had in mind, that you accounted for and I'm glad to see:

• Not messing up the current size if fullscreen
• If necessary shifting the window to not be off-screen.

Some things I think it's missing:

• A scale that is too big to fit on the monitor should not be permitted, there should be a cap on the scale based on rcWork
• A true scale (not DPI adjusted) smaller than 0.5x the framebuffer size should not be permitted, because below that isn't really usefully playable even on low resolution monitors and the downscaling will begin to have aliasing.
• When the window is fullscreen, this shouldn't quite do nothing... rather, it should change the size the window will restore back to if and when fullscreen is turned off. This can be done with GetWindowPlacement, then adjust coordinates in rcNormalPosition within the WINDOWPALCEMENT structure, then call SetWindowPlacement with no changes to other fields. When constraining the value of rcNormalPosition, make note that it uses workspace coordinates, rather than screen coordinates like SetWindowPos and monitorInfo.rcWork do, so there's going to be an offset.
• I have some doubts that applying the scale together with DPI scale is the best choice for all circumstances, or even most. If the DPI scale is 1.5x it's generally fine, but if it's more like 1.33x then it may lead to more blur than desirable. There's a reason the 'snap' points when dragging for window size are at multiples of half the framebuffer size, using actual resolution and not dpi-adjusted resolution. Code that wants to set window scale to a fixed value should probably pick such a snap point most of the time even in the case that the DPI scale is something funny like 1.33x. There's merit to code that calls this defaulting to a scale that is sensible for the DPI scale, but the DPI scale shouldn't get in the way of being able to round the true scale to the nearest 0.5x. Maybe also should have a function to query the current DPI scale. I'm open to other ideas for how to achieve these goals too.

In addition. I was thinking about the idea of implementing a Graphics.adjustWindowScale() function which accepts no arguments, and bundles together what I'd consider the "best practice" for what to do following a change in framebuffer size:

1. Read the window's size (true, not DPI adjusted, this is important... and rcNormalPosition size rather than current size so you get the restore size if it's fullscreen currently)
2. Divide that by the height of the current main framebuffer to get the current scale according to height
   (Alternatively, could use the square root of the ratio of area? Undecided if area-preserving or height-preserving is better)
3. Round to the nearest multiple of 0.5
4. Limit to maximum scale allowed by the monitor (rounded down to nearest 0.5, accounting for both height and width)
5. Then set the window scale accordingly

This method tries to combine respecting whatever the player has done with window size already, with rounding to a clean-looking window size of the appropriate aspect ratio.

[MrDoubleA232]

This is really helpful feedback! I'll try to implement the points that you mentioned into this once I get the chance.