Add MG_BW_LAVA to mapglyph() instead of hijacking MG_DETECT. Used
to display lava in inverse video if color is disabled and lava is
using the same display character as water (which is the default).
(The use_inverse option must be enabled for tty to honor it. X11's
text mode doesn't care. Win32 does care but probably shouldn't--it's
not a case like tty where the hardware might not support it.)
This implements both MG_DETECT and MG_BW_LAVA for X11, but only if
the program is built with TEXTCOLOR enabled. Those should work even
when color is not supported, but I suspect that configuration is
unlikely to ever be used so didn't want to spend the time to figure
out how to do it. (The relevant data is overloaded on the color
data, so not available when TEXTCOLOR is disabled.)
The win32 revision is untested.
Color was only being tracked for locations that had the pile of
objects flag set. And hilite_pile made a monster on a pile take
on the color of the top object of the pile.
This restores the tracking of color for the whole map, and makes
highlighted piles be drawn in inverse like highligted pets. The
drawing routine doesn't know the difference (but could tell, if
necessary, by testing whether the glyph is an object or a monster).
Also, variables 'inbuf', 'inptr', and 'incount' were global; limit
their scope to winmap.c.
The three line change I made previously to implement highlighting for
prompts that ask for single-character input was easy and worked well
for a tiles map, but it didn't look very good for a text map. This
handles both text map and tile map and also adds a configurable
'highlight_prompt' X resource to let the user enable or disable the
feature. The resource template file (win/X11/NetHack.ad, copied to
$HACKDIR during install) now has it enabled by default.
The highlighting--more specifically, the "lowlighting" when no prompt
is active--still looks bad if the map window has a vertical scrollbar
on left edge. I don't have any inspiration about how to fix that up.
The big memory allocation for tiles that was unfreed according to
heaputil was actually freed by X according to a comment in the code.
But free it explicitly for #if MONITOR_HEAP so that the alloc/free
tracking stays accurate.
Also, the cached extended commands menu was not being freed, so take
care of that. I wasn't sure where to handle it; I ended up making it
happen when the map window is torn down.
Update the unix Makefiles and the older OSX hints files to handle the
pile marker tile overlay. I didn't touch hints/macosx10.10 and .11
since I think there's still a merge for them pending.
A couple of formatting tweaks for bemain.c are included, for no
compelling reason. What are the odds that anyone will every build
that again?
Changes to be committed:
modified: doc/window.doc
modified: include/qt_win.h
modified: include/trampoli.h
modified: include/winX.h
modified: include/wingem.h
modified: include/winprocs.h
modified: include/wintty.h
modified: src/display.c
modified: src/windows.c
modified: sys/amiga/winami.p
modified: sys/amiga/winfuncs.c
modified: sys/amiga/winproto.h
modified: sys/wince/mswproc.c
modified: sys/wince/winMS.h
modified: win/Qt/qt_win.cpp
modified: win/X11/winmap.c
modified: win/chain/wc_chainin.c
modified: win/chain/wc_chainout.c
modified: win/chain/wc_trace.c
modified: win/gem/wingem.c
modified: win/gem/wingem1.c
modified: win/gnome/gnbind.c
modified: win/tty/wintty.c
modified: win/win32/mswproc.c
modified: win/win32/winMS.h
print_glyph now takes a second parameter.
Tiles on tiled ports always looked odd on places like the plane of air
where the background color of the tile didn't match the general background
of the surrounding area.
3.6 made that even worse and more glaringly noticeable with the introduction
of darkened room tiles.
The code to actually send something useful through the new parameter
for window ports to take advantage if they want will follow.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
Suppress close to 400 warnings generated by gcc on the win/X11/*.c code,
most due to -Wwrite-strings which makes string literals implicitly have
the 'const' attribute. (Since modifying a string literal results in
undefined behavior, that is an appropriate check to have enabled, but
it can be troublesome since string literals have type 'char *' and code
that uses them that way is correct provided it avoids modifying them.)
113 warning: initialization discards qualifiers from pointer target type
127 warning: assignment discards qualifiers from pointer target type
29 warning: passing argument discards qualifiers from pointer target type
109 warning: unused parameter
12 warning: comparison between signed and unsigned
The nhStr() hack casts to 'char *', explicitly removing 'const', for
situations where it isn't feasible to make code directly honor const.
The vast marjority of uses are for the second parameter to XtSetArg(),
which is a macro that actually performs an assignment with the second
argument rather than passing it in a function. It takes values like
'XtNtop', which doesn't need to be altered (although in many places I
changed that to nhStr(XtNtop) for uniformity with the surrounding code,
and 'XtNbottom', which does need to have the extra const stripping to
avoid a warning. Go figure.
The nhUse() hack actually uses its argument in a meaningless way if the
code is compiled with FORCE_ARG_USAGE defined. When GCC_WARN is defined,
FORCE_ARG_USAGE will be enabled if it hasn't been already. Example:
/*ARGUSED*/
int foo(arg)
int arg; /* not used */
{
+ nhUse(arg);
return 0;
}
The extra line will expand to ';' when FORCE_ARG_USAGE is not defined
or too
nhUse_dummy += (unsigned)arg;
when it is. I figured direct assignment might lead to a different
warning by some compilers in a situation like
nhUse(arg);
nhUse(otherarg);
where the first assignment would be clobbered by the second, and using
bitwise operations or safer '+= (arg != 0)' would most likely generate
more non-useful code. Some tweaking might turn out to be necessary.
There is a lot of code affected by this, and Pat Rankin correctly
observes that it would be better to store roguelike as a level flag
rather than just using Is_rogue_level. A note for the future.
- reduce the number of symbol tables for each graphics
set {PRIMARY, ROGUESET} from three {map, oc, mon}
tables for each of the display symbols, the loadable symbols,
and the rogue symbols, to one continguous table for
each:
showsyms: the current display symbols
l_syms: the loaded, alterable symbols
r_syms: the rogue symbols
- Modify mapglyph so that the index into the symbolt table is
available as a return value (it was a void function), rather than
just the char converted from the glyph.
- That makes it possible for a window port to use the same
index value to extract from another table (perhaps a unicode
table) for a different set of display symbols. The index
is much more useful than trying to convert the character
into another type of symbol, as some contributed patches
have done.
- It is much easier to load a single alternative flat table to
make substitutions, since the corresponding value just
has to get placed into the same index offset in the
alternative table.
This also fixes a bug I found in botl.c, where you could
go to the rogue level, and the bottom line gold symbol
was not being updated with the new character as it should.
The reason was because the gold value had not changed,
only the field symbol used had changed.
This updates multiple ports to place a (void) cast on
the mapglyph call, now that it returns a value, so this
is going to generate a lot of diff e-mails.
From a bug report: fix a typo for mouse
position handling in set_button_values(). I have no way to test this,
nor can I tell whether it could have ever impacted anyone. The old code
clearly had a mistake and the fix is obvious.
This isn't really a bug, but I find it does make the map scrolling in
the generic X11 version a lot less distracting. The original behavior
produces certain boundaries where, when the cursor moves back and forth
across that boundary, the map scrolls with each crossing. This is
particularly annoying in places like Sokoban where the player makes that
kind of movement frequently causing large jumps of the map each time.
Changing the border and delta constants in winmap.c as below eliminates
that behavior, as well as making the cursor easier to track by tending
to recenter it whenever the map shifts.
I noticed a few panic messages contained newlines, and one included a naked
carriage return. panic() adds a newline itself, and also generally ensures
the message will be on a new line (the initial "oops" ensures the message
itself will be on a new lines). This patch removes the unneeded characters.
Add support for hilite_pet to X11 text map mode (hilite_pet was already
supported when tiles were enabled). While testing this, I found a missing
newsym() in the code implementing the creation of a "tame" monster.
Prompted by a question from Pat a long time back, this change finally allows
tiles or text map mode to be chosen dynamically at runtime (using the
"tiled_map" option) rather than having to pick it via an X resource and
keep your selection until you exit. This brings map mode selection up to a
level similar to most other graphical window ports.
In addition, the map mode automatically switches to text on the Rogue
level, also like other graphical window ports.
The default mode for the X11 binary is now tiles, once again, like most (all?)
other graphical window ports.
The patch also removes some dead X11 code that is unlikely to be useful again.
This is an initial round of SAFERHANGUP hangup changes. It introduces
SAFERHANGUP, provides the core framework, and enables it for UNIX.
Window-port changes are provided for win/tty, win/X11 and win/gnome. Qt
changes should be forthcoming after having Warwick look at them.
window.doc is updated so windowport maintainers have an clue what needs to
be done to support SAFERHANGUP.
- change the way the tile sizes are calculated, based on the image size,
so non-square tiles can once again be supported.
- fix Gnome port so it can actually display non-square tiles, several
height/width uses were backwards
- update Install.X11 to note the number of tiles per row in the XPM image
- support X11 tile files (with or without XPM) that are 40 tiles wide
- rearrange some X11 code to share more code between XPM & non-XPM options
- clean out some deprecated X11/winmap.c #ifdefs
- update Qt code minimally to handle such an XPM file
