search

CleverRaven / Cataclysm-DDA

Cataclysm - Dark Days Ahead. A turn-based survival game set in a post-apocalyptic world.
http://cataclysmdda.org
Other
10.27k stars 4.12k forks source link

Window scaling overhaul #17135

Closed ehegnes closed 7 years ago

ehegnes commented 8 years ago

I spent ~15 minutes fiddling with "Terminal {width,height}" in the settings, restarting the game every time I changed the settings. I was finally satisfied with the aspect ratio and scaling of CDDA — then I hid my WM's top bar. I spent another ~5 minutes painfully configuring.

My main issues regard the following. The current system:

I can't imagine a scenario where one would not want the aspect ratio to be the same ratio as the window. I also figure that, if we can detect the expected external resolution, it must be trivial to reverse that calculation, based on the window size, to get an internal representation (rows and columns).

I propose the following:

I'd like to do all of the above, but it would be nice to be given some input and critique. Am I missing anything? Am I proposing something that is inherently flawed? Are there any constraints on the resolution (such as conforming to a resolution that evenly truncates the tiles)?

Mentioning @RabbitB, since they wrote the only resolution code I bothered looking at yet and may have valuable insight.

narc0tiq commented 8 years ago

This all seems reasonable. To the best of my knowledge, the only reason it hasn't been done yet is because nobody's done it yet.

illi-kun commented 8 years ago

I have nothing against smart definition of height and width on first run (instead of setting of plain 80x24) but removing of such options for window mode is a regression (and we already have fullscreen mode which manage screen resolution automatically, afaik).

BevapDin commented 8 years ago

Duplicate of #933

ehegnes commented 8 years ago

@BevapDin thank you for alerting me to that. Obviously, my search was not comprehensive enough, for which I apologize. Should I close this issue and comment on the one you mentioned?

Notably, this would have some enhancements over both of the proposed PRs, which were abandoned.

@illi-kun, I would not be removing the fullscreen functionality. I don't understand why the internal representation should be exposed to the user in the options. Also, as I understand it, fullscreen mode uses the same resolution as specified by "Terminal {width,height}" and applies upscaling, so fullscreen mode would not be managing (changing) the internal resolution in the current implementation, but it would have an effect on it in my implementation.

Rivet-the-Zombie commented 8 years ago

I don't understand why the internal representation should be exposed to the user in the options.

What if I want to size it up to fill my screen, then manually reduce one dimension in order to expose a strip of the stuff behind the game window?

ehegnes commented 8 years ago

@Rivet-the-Zombie, would that not be the same as playing in windowed mode and drag-resizing the window to fill all but that strip of the screen? Would saving/restoring the dimensions on program close/start (like mentioned above) be suitable?

Rivet-the-Zombie commented 8 years ago

@Rivet-the-Zombie, would that not be the same as playing in windowed mode and drag-resizing the window to fill all but that strip of the screen?

You're right; there wouldn't really be any difference on the user-end.

Would saving/restoring the dimensions on program close/start (like mentioned above) be suitable?

That would be capital!

pingpong2011 commented 8 years ago

I think the most obvious problem with auto-tiling and stuff is cross-system compatibility issues. SDL makes for a nice cross-platform library, but I'd still be concerned about support.

Second, most internal stuff probably uses buffers specified by start-up values. If resolutions can be changed on the fly, it'd probably require a lot of re-writing the rendering code to shuffle the row and column values.

Removing the manual set options is a huge no-no. Just no. It works, and nobody has complaints other than "well I had to restart a few times". You can access them to modify them, but I will always want an option to disable whatever window/library mechanisms you use and use the numbers in a config, because the automatic methods will inevitably break, via system or internal program changes.

As for a "scaling factor" option, it seems like there should be a filter-based arbitrary scaling option (linear, integer, something), a per-pixel font height/width option, and "custom" for when you define all the fonts in fonts.json.

crinkelitehttps commented 8 years ago

Maybe just add a few common presets, like 16:9, 16:10 and 5:4. Then you can let the edge cases fiddle with the width/height settings

illi-kun commented 7 years ago

This issue was closed as it appears inactive.

Reducing open issues to those which are (or will) be actively worked upon helps us focus our efforts. This issue has not been deleted - it still appears in searches and if it contains relevant information you are encouraged to continue to link to it.

If this issue was a bug

It should be reopened if it can be reproduced in the current build. You can obtain the most recent copy here. Please check there is not a more recent report of this bug before doing so. If no more recent report exists you should continue the discussion in this issue.

If this was a feature request

If the consensus was that the idea was good you could consider submitting an implementation via a PR. If you want to comment further please do so here as opposed to opening a new issue. Before posting check nobody has already made the same point and consider whether your comments are likely to lead to an implementation. If you have doubts about either consider instead voting for the issue

If you want to work on this issue

Then either assign it to yourself or if you are unable to do so claim it via adding a comment. Please don't assign others or make a general request for action.