Performance profiling showed that multiple strcmpi() calls were
occurring each and every time a character was going to the map.
This update:
- honors the WC_COLOR capability
- It allows a window-port to control individual color availability should the window-port wish to do so.
- Makes checking on the individual colors for the active window-port is a straightforward table lookup at the CLR_ offset.
iflags.use_color remains a master on/off switch for use of color, regardless of the capability
compiled into the game (default TRUE).
The has_color() routine, which is now a shared routine in src/windows.c, could likely be made
into a simple macro to eliminate the function call, but this update does not go that far.
This hits a lot of port files due to the window-port interface change, mostly cookie-cutter.
the return value from condition_size() was unused so
eliminate an unused variable warning and rename the function
to better reflect that it updates tty_status[NOW][BL_CONDITION].lth
Another part of github issue 227. Casting a function pointer when
passing it to another function is iffy when lying about the return
type. tputs() expects a routine which returns int, so give it one.
Other xputc() usage is equivalent to putchar(), so define xputc()
with the same function signature as that has.
The tputs() declarations in system.h should probably be changed
(third argument is a function which takes an int rather than
unspecified parameters) but I've left them alone. I made that change
to tputs() in sys/share/tclib.c though.
NT and MSDOS changes are untested. tclib.c compiles ok with clang-
as-gcc on OSX but hasn't been tested with the port that uses it (VMS).
When we were saving message history as part of a game save for insurance,
we were calling remember_topl() and thus inappropriately changing topline
state. This would cause us to mis-manage the topline in subsequent calls
to update the topline.
The code has been re-worked to fix the issue, reduce complexity and make
the code clearer.
When we save gamestate as part of making an insurance snapshot, we will
save message history which will clear toplines but leaving window state
in tack including the need for more.
When fuzzing, we would increment ttyDisplay->inmore but then prematurely
exit more() leaving ttyDisplay->inmore set.
Under various conditions, we can request to remember the topline when
the topline had not yet been acknowledged leaving toplin state in an
inappropriate state.
Highlighting via attributes got broken three months ago. May or
may not have been noticeable depending upon which attributes are
supported. Too many variations of attribute designations...
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
This time prompting isn't adversely affected.
This effectively reverts 1ad2415315
because it was interfering with prompts that spanned more than one
line (by inserting '--More-- + erase' between displaying of prompt and
getting input for the answer).
So we're back to the situation where autodescribe feedback when moving
the cursor will leave text on the second line if it generates text too
wide for one line. (^R redraws the screen correctly.)
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
The earlier fix removed a valid optimization which happened to be
implemented incorrectly. Put that back. It also left an invalid
optimization when applied to conditions. Remove that one.
I don't think either of these explains truncating 'y' off of "Hungry"
which was shown in one of the reports.
Reported as #H8609 (1679)
Some code recently added to render_status() for BL_CONDITION:
if (!tty_condition_bits)
continue;
was short-circuiting the required copy of NOW
values to BEFORE values for later comparison
further down in the for-loop.
tty_status[BEFORE][idx] = tty_status[NOW][idx];
This caused some fields to be bypassed for rendering
once no more tty_condition_bits were set because the
length comparisons would match.
DEC C in one of its non-ANSI modes didn't like
fieldorder = test ? &array1 : &array2;
It first complained that '&' applied to an array has no effect (which
was typically true in pre-ANSI environments) and once those '&'s are
ignored, the attempted assignment didn't match the variable's type.
That code was actually more complicated that it needed to be; slightly
simpler code works as intended.
Enable blink and dim for the TERMLIB + !NO_TERMS configuration of the
tty interface. Blink now works the same as in the curses interface
for status highlights. The terminal emulator I'm using has an escape
sequence for dim but it evidently doesn't do anything (same no effect
as with curses), so that isn't adequately tested.
Take care of a minor 'TODO' and make another stab at getting truncated
encumbrance and/or level-description to reset to full size when enough
space becomes available.
Noticed while testing statuslines on a small terminal window. Using
the cursor to pick locations that panned the map to view a new subset
would end up showing a new view of the regular map rather than a
different section of what was currently displayed. For farlook that
caused monsters to take on new hallucinatory forms which was fairly
inconsequential, but for #terrain and various forms of detection it
reverted to the ordinary map instead of showing the map features that
the player requested or the temporarily revealed monsters and such.
Most interfaces keep track of the whole map and just show their view
of the new subset when panning, similar to redisplay after being
covered up and then re-exposed, but tty isn't doing that. I made
same change to Amiga as to tty since the code it was using was very
similar. I haven't touched any of the other interfaces and assume
that they don't need this. I've verified that curses and X11 don't.
Implement the 'statuslines' option for tty. 2 and 3 line status are
similar to curses. Tty's version doesn't include insertion of extra
spaces for enhanced readability, or ignoring 'showexp' when space is
needed for other fields, or right justifying 'score' and suppressing
it when there isn't room for the entire number. It continues to have
abbreviated condition and encumbrance descriptions that curses lacks
which get used when the normal ones take up too much space.
'statuslines' can be set with 'O' so it is feasible to switch back
and forth between 2 and 3 lines on the fly. But only if the display
is at least 25 lines (actually ROWNO+4) or else CLIPPING is enabled
at build time.
This fixes the bug where after resorting to abbreviated condition
values it sometimes (always?) wouldn't switch back after more room
became available. Abbreviated encumbrance values had problems too
(lack of leading space and not changing value if encumbrance changed
to anything other than unencumbered) and this fixes that as well.
Catch up with curses and have hitpointbar work even if statushilites
is 0 to suppress other highlighting. Indirectly fixes #H8389 by
making the circumstance which triggered that bug no longer do so.
The fuzzer likes to set options randomly; the combination of
DECgraphics symbol set (on a display capable of rendering it) plus
eight_bit_tty produces a bizarre map display. Make DECgraphics
override eight_bit_tty rather than the other way around.
