larger console size

[hirdrac]

Would like to make changes to the current hard-coded display sizes:

• change hard coded values in ui.h to configurable values
  • curses (Linux) implementation could base values on console size at start-up
  • Windows could use configurable values with a larger default (100 x 45 perhaps)
• split ui.h SEE/SEEX/SEEY values from actual view size - increasing the displayable view size shouldn't affect map generation

[zaimoni]

1) Windows default would have to react to tiles vs non-tiles mode (it is already very wide with 16x16 tiles) The configuration points I anticipated when setting up ui.h are VIEW and PANELX (with minimum values current values). I would accept converting these two to options with explicitly checked minimum values.

1a) VIEW has to be an odd number. I don't want to mess with trying to define what "centered" means on a square with even sides.

2) I would expect the new option enum values to be added "just before" NUM_OPTION_KEYS in option.h. (Fonts are special snowflakes, at this time; their editing UI would be "strange" even after implementation.) Other implementation details should be calculated from their meaning (e.g., they are OPTTYPE_INT). Macros wrapping read-only access methods to the values represented by VIEW and PANELX would be acceptable as a backward-compatibility measure to minimize code churn when wiring in. The only method of writing the values in-game should be the options screen. If altering font-size current triggers screen resize currently, altering these values should also trigger screen resize.

3) The layout of all screens would have to be converted to automatically respond to the values named in ui.h (this is part of why I extracted that header in the first place). This is not explicitly known to be the case currently (I have adjusted things piecemeal but no systematic conversion). The trunk would be in Przybylski's Star status (potentially unplayable, release not allowed) as long as this verification was incomplete after the options had started being wired in.

3a) The above alignment subtask may need an explicit checklist, readable by everyone involved.

[zaimoni]

Current maximum VIEW is 121 [ ((MAPSIZE/2)SEE)2+1 ]; any larger can try to read terrain grids that are not in the reality bubble.

[zaimoni]

I've started a commit series for explicitly checking that the SEE, SEEX, and SEEY constants are being used strictly for submap coordinate conversion. (these currently have the same numerical value as VIEW_CENTER . This re-specification is required, to do the changeover in a trunk-safe fashion).

I'm not sure this is important enough to actively adjust the a priori release window (Oct 1 - Nov 30) for 0.2.4 .

[zaimoni]

Internal checklists for this: all uses of SEE are thought to be accurate (i.e, actually reference the submap structure, not the view radius, technological teleportation range, etc.) C:Whales' SEEX and SEEY are not verified, as of time of commenting.

I'll need to keep an eye on instability from introducing std::function. (besides reports of gratuitous value-copying and RAM allocation behind the scenes, Franci's test drivers have seen some awesome miscompiles.)

[zaimoni]

Having some problems obtaining legible checklists from Visual Studio (my primary view is the symbol-search results; cut-pasting "unsorts" them and thus isn't a good option for building a public checklist).

Internal checklists for the automatic layout setup (so that wiring in configuration for VIEW and PANELX "just works").

• SEE (done)

• SEEX: actively scheduled on my end

• SEEY: not intentionally started

• newwin calls: not intentionally started. The dimensions of these windows, and their positions, have to react "appropriately". All UI elements (whether explicit subwindows, or implicit) should either have constant dimensions, or have dimensions in principle computable from VIEW and PANELX. I'm imagining the layout "as if" done by Tk/Tcl's pack layout manager https://www.tcl.tk/man/tcl/TkCmd/pack.htm .

Constant UI element dimensions may belong in ui.h, especially if they influence many window layouts (like the minimap UI).

Left to my own devices, the above is the order I will schedule these checklists in. I'm generally going through the Visual Studio search results in alphabetical order.

Regarding patches based on the above checklists:

• Patches based on auditing newwin should not conflict with the SEEX audit.

• SEEY is "riskier" as usually if SEEX is used SEEY is also used nearby.

• I'm not interested in relabeling SEEX or SEEY to SEE in-place (as opposed to part of a local re-implementation based on vector arithmetic, etc.).

Note that the SEE constant family is acceptable when actually working with the submaps (e.g., any expression involving MAPSIZE is working with the reality bubble and can be left alone for this purpose). Only code concerned with screen display has to switch to VIEW_CENTER from the SEE constant family, to avoid breaking. Game mechanics should not be using the SEE constant family (but the fact they are defined that way in C:Whales should be documented inline, in case that becomes relevant for e.g. game balance.)

[zaimoni]

Internal checklists "completed" re SEEX/SEEY two days ago. Plan is to split daily time budget between the newwin calls (again, working in alphabetical file order) and technical issues exposed by those commits (currently, buildout of add_item with rvalue reference signature)

[zaimoni]

Checklist re newwin calls is messy. Went ahead and mirrored this : https://github.com/zaimoni/Cataclysm/wiki/Checkpoint:-newwin-call-audit-(which-ones-will-break-on-introducing-resizable-screen) .

[zaimoni]

Checklist re newwin calls is done. I'm going to tolerate https://github.com/zaimoni/Cataclysm/issues/105 , as C:Whales had the same breakage.

I need to know whether game::intro() has any chance of working on ncurses. The corresponding fix for the in-house curses simulation, looks like

• detaching the implementation of getmaxx(nullptr) and getmaxy(nullptr) from the underlying screen, instead direct-computing the limits. This makes the return value of these limits accurate.

• check whether pre-existing option values for VIEW and PANELX are "legal". If not "legal" (including "not present"), compute "optimal" VIEW and PANELX and save to options.

• edit options screen for VIEW and PANELX will have to pay attention to legality checks as well.

• optionally, build out graphical resize handling. I'm seeing references to extensions to curses, that do not play nice with the readline library: https://linux.die.net/man/3/resizeterm and https://bugs.python.org/issue2675 .

[hirdrac]

• I can check any changes you make for Linux
• Probably best not doing anything complicated with curses - just assume no terminal resizing after startup.
• Would be nice if all curses calls were encapsulated in one place and not called directly throughout the code (Windows code wouldn't need to emulate the curses interface as well). A lot of work needed for this one though.

[zaimoni]

I.e., current game.cpp/intro() is simply invalid starting just before the while loop, which is inherited from C:Whales (it assumes resizing would be viable).

If the results for getmaxx(stdscr) and getmaxy(stdscr) from initscr are "as large as feasible", then defaulting the dimensions based on that should be fine. The naive approach for that for catacurse.cpp had a critical failure : tiles stopped loading.

[zaimoni]

Finally got the in-house curses simulation to "behave" on the most recent push.

• The options UI should handle both the screen height (VIEW) and one of PANELX or SCREENWIDTH (the difference between these is VIEW). The missing option will have to be computed. It's tempting to go with VIEW and SCREENWIDTH as these are directly constrained by getmaxy and getmaxx, respectively.

• I don't have a formal issue with making Windows simulate the curses API; I just don't like committing to the indefinite time cost of forking PDCurses (to fit the tile support in). Cf. https://github.com/wmcbrine/PDCurses .

• I would not object to a restructuring of the code base to more clearly separate UI code from data structures (ideally, anything with a direct representation in the savefile would be UI-ignorant; don't see that completely happening as there's some natural tie-ins to the player class. Most/all other classes with a JSON representation should not be UI-aware.)