[FeatureRequest] Game scaling

[crypt47]

Pixels are getting smaller and smaller and for me it's a deal breaker to play HHoM2 on modern monitors. Lots of games already implemented pixel scaling by nearest neighbor, so will fheroes2 I hope.

[Branikolog]

Hi, @crypt47 !
Nearest scaling can be switched on in .cfg file. Is this what you're looking for?

[crypt47]

For that you have to switch game resolution to nearest suitable and it's ok to have some black borders, if it doesn't fit perfectly on wide screen.

Currently we do not draw any black borders

What is was trying to say is I would expect a foolproof switching to full screen mode, instead of it plays cleaver and hides something from me (and I file a bug report anyway). Because at this point the feature doesn't work for me at all. I've check Xorg, it gets modes from EDID, so it's normal. What you are doing, when trying to match window and fullscreen resolution is not.

Btw how to call a resolution change screen again after first run?

[oleg-derevenetz]

What is was trying to say is I would expect a foolproof switching to full screen mode

Yeah, that's why it does not currently add unsupported resolutions left and right.

Btw how to call a resolution change screen again after first run?

New Game (on main screen) -> Settings -> Graphics Settings.

[crypt47]

Yeah, that's why it does not currently add unsupported resolutions left and right.

It would be better if it change resolution correctly at full screen according to max hardware resolution...

New Game (on main screen) -> Settings -> Graphics Settings.

Thanks. I couldn't rid off system resolutions with xrandr (and I don't consider this hacking as valid way to run a game), so I patched your source so now it adds ''unsupported resolutions" with the rest of others and I finally could use them and do something more fun with the program.

[oleg-derevenetz]

It would be better if it change resolution correctly at full screen according to max hardware resolution...

It does change resolution "correctly". What you are in fact asking is to support non-standard resolutions (not supported by the hardware) in the fullscreen mode by using a different resolution and customizing the in-game picture with "black bars". Sorry, but this is not a priority.

As for the logic of finding the available scaled resolutions, I proposed the PR #7051 with the logic described here - there should be 960x540x2 "virtual" resolution for your 1920x1080 "hardware" resolution and 640x512x2 "virtual" for your 1280x1024 "hardware", both are safe for the fullscreen mode.

As for windowed mode, with SDL2 you can do this:

Ubuntu.-.VMware.Workstation.17.Player.Non-commercial.use.only.2023-04-23.01-12-37.mp4

but the window size is currently not saved to the fheroes2.cfg.

[crypt47]

What you are in fact asking is to support non-standard resolutions

I don't see why. I ask you to put FullHD picture on my FullHD monitor and the in-game resolution stays 640x480. Anyway see below, how I done that.

but the window size is currently not saved to the fheroes2.cfg.

I played windowed mode yesterday. What I did:

1. Added x2 modes in your code.
2. Selected 640x480x2.
3. Undecorated and Maximized window by means of WM, not F4. Some open source GUI can save such properties per application.

As a result not only I got what I need, the mode also doesn't have black stripes on top and bottom. Vertical size of the picture is 1080. So yes, there comes "non-standard resolutions". Even though I wasn't expecting to get it. Maybe you can explain. Also please notice, that deviation from your logic and changing your code gives perfect results.

The cursor doesn't scale, but that's a minor issue.

[oleg-derevenetz]

I don't see why. I ask you to put FullHD picture on my FullHD monitor and the in-game resolution stays 640x480.

Once again. You can do this in windowed mode by stretching the window. But scaled resolution 640x480x2 requires to have support for the corresponding "native" resolution 1280x960, because when you press the F4 to enter the full-screen mode, the video driver will be requested to switch to 1280x960 and it will fail to do that, so we can't just add such resolutions to the list left and right. However, when you press F4 with the stretched window with 640x480 resolution (even if it is stretched to 1920x1080, just like in your case - in fact, it's 1440x1080 with black bars), app will still ask the video driver for 640x480 and if it supported (and it is supported in your case according to the xrandr output), then no issues will arise.

Anyway see below, how I done that.
Maximized window by means of WM, not F4.

So you did it in the windowed mode, not in the full screen mode. No video mode change was performed by the video driver.

As a result not only I got what I need, the mode also doesn't have black stripes on top and bottom.

If your current "native" resolution is 1920x1080, then 640x480 will be scaled to 1440x1080, so you will have the black stripes left and right, not top and bottom.

Also please notice, that deviation from your logic and changing your code gives perfect results.

Only while you stay in windowed mode and don't ask the video driver to switch to this "non-standard resolution" by pressing the F4 button.

The cursor doesn't scale, but that's a minor issue.

Turning on the software cursor in the fheroes2.cfg should resolve this issue.

[oleg-derevenetz]

In-hardware emulation when you put video driver in 640x480 mode is ugly everywhere by definition.

Well, as far as I'm aware of this topic, often the scaling is performed not even by video driver / video card, but by the monitor itself, and that naturally gives deplorable results, because monitors are relatively stupid. However, some video cards have support for GPU scaling (for example, this can be turned on for some AMD cards), and in this case GPU may (in theory) apply more sophisticated scaling algorithms than those that are currently supported by SDL (linear and nearest neighbor), and 640x480 in "true" full-screen may look better than those that are scaled by software (and work faster because they are performed on GPU, possibly using some this-GPU-specific implementation).

[crypt47]

In-hardware - I meant by the monitor. Anyway, I spent sometime with an engine, everything pretty much works, but for some reason the animation blocks any actions of the player. For example: the new structure in the castle takes a while to appear, and you can't just leave. It's everywhere in the game and you can't play it as fast as you like.

[oleg-derevenetz]

For example: the new structure in the castle takes a while to appear, and you can't just leave. It's everywhere in the game and you can't play it as fast as you like.

That's exactly how it works in the original game. In the original game, you should wait until the new building is fully "built" before taking any other action, etc.

[crypt47]

For example: the new structure in the castle takes a while to appear, and you can't just leave. It's everywhere in the game and you can't play it as fast as you like.

That's exactly how it works in the original game. In the original game, you should wait until the new building is fully "built" before taking any other action, etc.

I thought so. But it's annoying a bit.

[oleg-derevenetz]

I thought so. But it's annoying a bit.

Well, there is, for example, a proposal to give the player the opportunity not to wait for the end of the introductory music at the beginning of the battle: #7067. But it is not merged yet. Perhaps in the future there will be similar proposals for other pauses of this kind.