Implement arbitrary display scaling for hardware accelerated rendering

[svenstaro]

This fixes #13482. There is no drawback with this method as the scaling and rendering is extremely fast and implementation is obviously very simple. I added an option to toggle between nearest neighbor scaling and linear scaling to make both camps happy.

[svenstaro]

Tested in software and hardware, by the way.

[svenstaro]

This also fixes #933.

[svenstaro]

Before

After

[remyroy]

This looks great! I have not tested anything about this PR, I just like how its going.

[OzoneH3]

This dosen't fix #933 at all. This is just up/downscaling the viewport on resize and dosen't increase/decrease the available viewport. Also only working for tiles versions.

It sure is a nice addition to have but the scaling should be configureable through the option itself and doing a resize should do whats needed for #933.

[svenstaro]

Oh, so #933 is for automatically resizing the terminal width/height while this rescales the contents of the viewport to make it fit the desired window size. How do you envision this to work together with resizing of the terminal size? There is only one possible action on window resize and that is either rescale or resize. Also, you want an option for toggling this behavior?

[OzoneH3]

Right, thats why there should be a float option to set the scale factor. eg: 1.0 for default size. with 1.5 it would be 50% bigger. The on resize should change the viewport for curses and tiles without scaling eighter.

I don't know much about how SDL works but maybe something like this should work?!
SDL_RenderSetLogicalSize( renderer, WindowWidth * factor, WindowHeight * factor ); would need to be called only when the scale factor changes or on game load.

[kevingranade]

I merged along with some additions to the option handling, namely having an option for no scaling and making it the default. "no drawback" is a bit of a stretch, both scaling modes look absolutely terrible on my system, which is why disabling scaling is going to remain the default.

[svenstaro]

@OzoneH3: No, the logical size has to stay constant. That is basically your game viewport. The window viewport is different in that it is the one used for determining how much scaling has to occur between the logical size and the actual size. I'm certainly open for defining a scaling factor but in that way, we can't nicely make the window fill the whole screen. The SDL logical size can also letterbox the game which the scaling factor sadly can't.

@kevingranade: Could you post a screenshot with the linear scaling mode? That one should really nice. I do like the option stuff you added.

In general, I think the scaling mode should be expanded by another option (maybe called "terminal size"?) which, instead of graphically rescaling the viewport, will resize the number of ingame tiles (as per #933, I understand). What do you think about that?

[OzoneH3]

There is a ingame option to resize the ingame viewport width/height. With #933 the on resize should handle that instead for tiles and curses.

[svenstaro]

I'd be down for implementing the game tile-based resizing but I need more instructions on how I should combine that with resampling of the viewport. Dragging the window + scale factor was the suggestion. Are you guys ok with that? The scale factor certainly has the advantage of users being able to find a binary factor (such as 2, 4, etc) that doubles the size of all pixels which improves the looks because it doesn't really interpolate any pixels (as 1.3 would, for instance) and as such tile sets will look way better.

To summarize: Window dragging resizes the game viewport. Scale factor resizes SDL viewport. This would make it less manageable I think but maybe it's a better suggestion. This is for the SDL version.

For the terminal version, scale factor will be ineffective because the font size depends on the terminal's font size. Game viewport scaling will still be nice to have on terminal, though I suspect it will be slightly harder to implement.

Opinions?

[kevingranade]

I suspect the problem I was seeing with scaling was that it was doing some odd ratio like 5/6 or 6/5, I suspect if you're scaling up by enough (more or less anything you do on a HDPI screen for example) it'll look great, but if it's scaling to a resolution too close to native, it's going to look bad. I'll post a screenshot once I'm back at my computer.