nethack-gwaa-kiwi/nethack
1
0
Fork 0
Code Pull Requests Activity

more #H8609 - tty status condition rendering

Browse Source 
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.
This commit is contained in:
PatR
2019-05-20 05:26:19 -07:00
parent cbb3dbb5f5
commit 4c93e1fa21
2 changed files with 25 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/fixes36.3
View File

@@ -1,4 +1,4 @@
$NHDT-Branch: NetHack-3.6 $:$NHDT-Revision: 1.8 $ $NHDT-Date: 1558248715 2019/05/19 06:51:55 $
$NHDT-Branch: NetHack-3.6 $:$NHDT-Revision: 1.10 $ $NHDT-Date: 1558355176 2019/05/20 12:26:16 $
This fixes36.3 file is here to capture information about updates in the 3.6.x
lineage following the release of 3.6.2 in May 2019. Please note, however,
@@ -16,8 +16,6 @@ when examining the map with '/' or ';', picking a symbol which is used for
billing and payment issue as a result of glob coalescing
glob pricing did not consider weight properly
glob shop interaction improved to handle more of the expected scenarios
remove the for-loop short circuit in render_status() that was preventing
the copy of BL_CONDITION tty_status values from NOW to BEFORE
Fixes to Post-3.6.2 Problems that Were Exposed Via git Repository
@@ -37,6 +35,10 @@ curses: if message window is only one line, cancelling some prompts with ESC
left the prompts visible on the message line instead of erasing them
curses: support EDIT_GETLIN (but like with tty, it's disabled by default) to
pre-load an earlier response as the default answer for some prompts
tty: re-do one optimization used when status conditions have all been removed
and remove another that tried to check whether condition text to be
displayed next was the same as the existing value; sometimes new
status condition wouldn't be shown unless a screen redraw was forced
Windows: some startup error messages were not being delivered successfully

36
win/tty/wintty.c
View File

@@ -1,4 +1,4 @@
/* NetHack 3.6 wintty.c $NHDT-Date: 1558330407 2019/05/20 05:33:27 $ $NHDT-Branch: NetHack-3.6 $:$NHDT-Revision: 1.205 $ */
/* NetHack 3.6 wintty.c $NHDT-Date: 1558355176 2019/05/20 12:26:16 $ $NHDT-Branch: NetHack-3.6 $:$NHDT-Revision: 1.206 $ */
/* Copyright (c) David Cohrs, 1991 */
/* NetHack may be freely redistributed. See license for details. */
@@ -4065,10 +4065,10 @@ int sz[3];
* - Is the additional processing time for this worth it?
*/
if (do_field_opt
/* These color/attr checks aren't right for
'condition'; is it safe to assume that same text
means same highlighting for that field? If not,
we'd end up redrawing conditions every time. */
/* color/attr checks aren't right for 'condition'
and neither is examining status_vals[BL_CONDITION]
so skip same-contents optimization for conditions */
&& idx != BL_CONDITION
&& (tty_status[NOW][idx].color
== tty_status[BEFORE][idx].color)
&& (tty_status[NOW][idx].attr
@@ -4123,7 +4123,7 @@ status_sanity_check(VOID_ARGS)
{
int i;
static boolean in_sanity_check = FALSE;
static const char *idxtext[] = {
static const char *const idxtext[] = {
"BL_TITLE", "BL_STR", "BL_DX", "BL_CO", "BL_IN", "BL_WI", /* 0.. 5 */
"BL_CH","BL_ALIGN", "BL_SCORE", "BL_CAP", "BL_GOLD", /* 6.. 10 */
"BL_ENE", "BL_ENEMAX", "BL_XP", "BL_AC", "BL_HD", /* 11.. 15 */
@@ -4151,7 +4151,7 @@ status_sanity_check(VOID_ARGS)
* a recent code change has caused a failure to reach
* the bottom of render_status(), at least for the BL_
* field identified in the impossible() message.
*
* That could be because of the addition of a continue
* statement within the render_status() for-loop, or a
* premature return from render_status() before it finished
@@ -4384,8 +4384,8 @@ render_status(VOID_ARGS)
if (!status_activefields[idx])
continue;
x = tty_status[NOW][idx].x;
text = status_vals[idx];
tlth = (int) tty_status[NOW][idx].lth;
text = status_vals[idx]; /* always "" for BL_CONDITION */
tlth = (int) tty_status[NOW][idx].lth; /* valid for BL_CONDITION */
if (tty_status[NOW][idx].redraw || !do_field_opt) {
boolean hitpointbar = (idx == BL_TITLE
@@ -4397,7 +4397,11 @@ render_status(VOID_ARGS)
* | Condition Codes |
* +-----------------+
*/
if (num_rows == 3) {
bits = tty_condition_bits;
/* if no bits are set, we can fall through condition
rendering code to finalx[] handling (and subsequent
rest-of-line erasure if line is shorter than before) */
if (num_rows == 3 && bits != 0L) {
int k;
char *dat = &cw->data[y][0];
@@ -4424,8 +4428,7 @@ render_status(VOID_ARGS)
tty_status[NOW][BL_CONDITION].x = x;
tty_curs(WIN_STATUS, x, y);
}
bits = tty_condition_bits;
for (c = 0; c < SIZE(conditions); ++c) {
for (c = 0; c < SIZE(conditions) && bits != 0L; ++c) {
mask = conditions[c].mask;
if (bits & mask) {
const char *condtext;
@@ -4441,8 +4444,10 @@ render_status(VOID_ARGS)
condtext = conditions[c].text[cond_shrinklvl];
if (x >= cw->cols && !truncation_expected) {
impossible(
"Unexpected condition placement overflow");
"Unexpected condition placement overflow for \"%s\"",
condtext);
condtext = "";
bits = 0L; /* skip any remaining conditions */
}
tty_putstatusfield(condtext, x, y);
x += (int) strlen(condtext);
@@ -4451,8 +4456,7 @@ render_status(VOID_ARGS)
term_end_color();
End_Attr(attrmask);
}
if (!(bits &= ~mask))
break;
bits &= ~mask;
}
}
/* 'x' is 1-based and 'cols' and 'data' are 0-based,
@@ -4553,7 +4557,7 @@ render_status(VOID_ARGS)
x += tlth;
}
finalx[row][NOW] = x - 1;
/* reset .redraw and .dirty now that they're rendered */
/* reset .redraw and .dirty now that field has been rendered */
tty_status[NOW][idx].dirty = FALSE;
tty_status[NOW][idx].redraw = FALSE;
tty_status[NOW][idx].sanitycheck = FALSE;