New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normalise the zoom on various screens. #222
Comments
is this noutbook? |
This is not a high end monitor. It is a Dell 1907FP at 1280x1025 resolution. At higher resolution the size discrepancy would be greater. It is unplayable. Edit: The command task bar also suffers from being just a bit too small on all windows. Just compare it's size in vanilla, where it stretches across the whole screen. Edit: oops, that is the wrong monitor. The main monitor, pictured here is a generic non-PnP monitor, a TV used as a monitor, at 1920 x 1200 resolution, as specified in the command line parameters. |
Viewable Size 19" You check in config you write all right? =] |
We currently don't do any scaling - if a sprite is 10 pixels wide, it'll be 10 pixels at 640x480 (the original resolution), so 1/64th of the width of the screen. It'll also be 10 pixels wide at 1920x1080, 1/192nd of the screen. The render backend supports the scaling, we could even add fancier shaders in the future, but currently the mouse code doesn't work properly with that - making it kinda useless. |
... although Alexei managed to do so for the cityscape screen, enabled by command line parameters. |
Patrick so you try change resolution by commands |
There's the options: Framework.Screen.ScaleX and Framework.Screen.ScaleY that can be used to do the renderer scaling for the whole surface. They take an integer percentage - IE the default is "100", "50" would make things twice the size on-screen (IE it renders internally at half the resolution of the display window). But I believe this screws up the mouse input events, as they aren't scaled in the same way, so it's not really useful right now as it means the interactive areas are as if it wasn't scaled at all, so where the game thinks you 'clicked' isn't the same place where the mouse cursor is drawn... But as this just uses the default linear blending, it's no different to just setting the Framework.Screen.Height/Width to a lower resolution and using your window systems window scale instead... If you want it to look like vanilla, just set the resolution to 640x480 and be done with it. |
OK, I see there is a ticket for mouse behaviour with scaling. Does that replace this ticket? |
So, basically, the issue for you is that while zoomed out city looks good and makes sense, zoomed out (to the same screen size) battlescape looks tiny and is not comfortable to play. Do I understand you properly now? If, as you say, it's really unplayable for many people (I dunno, for me it's no problem to play battlescape in 1080p, but maybe I'm just used to it over the time spend developing it) that means we should implement separate scaling settings somewhere along the road to OpenApoc 1.0. Because if we just implement scaling, then people would have to constantly switch from low scale factor in city to high scale in battle. Mouse ticket does not replace this ticket, it's about what JonnyH described above, the fact that we don't support scaling properly yet even though we have it. |
Separate scaling for each of {Cityscape isometric, Cityscape map, Battlescape isometric, Battlescale map} may make sense. And on top of that I feel that UI scaling within them may make sense if possible - having a 640x480 equip screen (for example) in the middle of a 4k display would look pretty silly IMHO... I'd see that as a "post 1.0" feature though. Arguably, anything but a single "global" scale could be considered post-1.0 - as I suspect a global 1.5x/2x scale would be fine for "most" use cases. And people who want the "vanilla" experience can just leave it as 640x480 and use their windowing system scaler. |
"--Framework.Screen.Width=1024 --Framework.Screen.Height=480 --Framework.Screen.Fullscreen=1" is a workable compromise with the current build, but I look forward to not having to do this because it causes my existing apps to be redistributed about my 3 monitors. So let's flag this for "post 1.0". |
The main cityscape screen obeys command line or config file parameters such as "OpenApoc.exe --Framework.Screen.Width=1920 --Framework.Screen.Height=1200" but other screens do not, making them difficult to play on large modern monitors.
See the photos, and sorry about the blurring.
The text was updated successfully, but these errors were encountered: