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.
This fixes the issue brought up at https://www.reddit.com/r/nethack/comments/dv3pae/curses_and_the_numberpad/?st=k3hgply6&sh=dbc2bf7d .
I don't know why the "regular" (tty) method doesn't seem to work for him,
but I'm going to chalk it up to a PDCurses oddity. What I do know, however,
is that the alternate method I added a year ago or maybe longer, that allows
numpad usage even with number_pad:0 (to retain the default keybindings in case
an user is used to them, while keeping number pad behaviour making sense,
similar to NetHack4+friends) was only partially implemented, for some reason.
This adds the rest of the keys, meaning that this means of key interpretation
should be more realible. KEY_A2/B1/B3/C2 are not standard keys in the Curses
documentation, and is thus behind an ifdef -- but PDCurses, amongst other
implementations, makes use of them.
As a side effect, Home/End/PgUp/PgDn are now interpreted as diagonal movement,
since some terminals interpret number_pad keys that way. I do not consider this
a problem since they went unused in normal gameplay anyway (This does not
interfere with menus or similar).
'orient' is the name of an enum defined in wincurs.h so don't use it
as a variable name in cursstat.c. My compiler didn't complain using
'-Wshadow' but apparently some other one does.
Make the same change in the dead code located in the second half of
that file, plus a couple of formatting tweaks.
From hardfought; latest gcc complains that /* fall through other stuff */
doesn't match its pattern for /* fall through */ comment indicating
that omitted 'break' statement is intentional and one switch case is
deliberately continuing into the code for another.
Menus with wide header or separator lines were rendered wide enough
to avoid wrapping those lines, but ones with narrow header/separators
and wide selectable entries were limited to half the display even
though lots of lines that would fit with full width were being wrapped.
Change the latter behavior.
Menus are right justified with the edge of the map when narrower than
it, left justified otherwise, and if the display is wider than the map,
they'll extend beyond its right edge. (That hasn't actually changed;
it's just that left-justification is more likely now that menus will
be wide enough to show wide inventory lines without wrapping.)
Get rid of my ridiculous hack to force wider menu for the 'symset'
and 'roguesymset' sub-menus of 'O' since it's no longer useful.
There's still room for improvement. If any lines need to be wrapped
despite using the full width, or perhaps are just a lot wider than
most of the entries, menu width could be narrowed to just enough for
'normal' lines to fit so that one or two really long entries don't
distort the menu. That's a bit more complicated than I want to deal
with right now. [If implemented, it would be relevant for tty too.]
travis updates for Windows deploy
Change zip file name from NetHack.zip
to
NetHack-x86-beta$TRAVIS_TAG.zip
where $TRAVIS_TAG represents the tag info.
Also, log the commands from the sh script in win/win32/vs2017 to the build log.
Moved the travis visual studio build bash script to live outside of
the travis YML file. Updated the script to use powershell to generate
ZIP file form the binary results.
Deploy Windows build ZIP file to github releases if build has commit
has been tagged. Build will be marked pre-release.
Fixes#235
For initial options under curses, specifying 'DECgraphics' as a
boolean rather than as 'symset:DECgraphics' wasn't overriding the
new default 'symset:curses'. Since previously DECgraphics was
rejected for curses, it's possible that no one noticed.
Primary and rogue symbols were being set to default if primary hadn't
been given a value, possibly clobbering rogue symbols if those had
been given a value. Initialize them independenly.
Return early from curses_convert_glyph() if the value doesn't have
the 8th bit set since it now deals exclusively with DECgraphics
handling. Force a sane value for returning early on rogue level.
Move a declaration that became mid-block when a preceding 'if () {'
got removed to top of block suppress warning about C99 feature.
Add new entry for the curses symset change to fixes36.3.
This time I'm putting things in as-is before making a few tweaks.
The pull request was three or four separate changes. I used the
patch instead so they've been collected into one commit.
Highlighting for monsters shown due to extended monster detection and
for lava shown in black and white didn't work because that keys off
of 'iflags.use_inverse' (actually a macro for 'iflags.wc_inverse') and
curses wasn't enabling that window-capability option. To be fair, it
was probably unconditional at the time the curses interface was first
developed. It checked for whether a monster was supposed to be drawn
with inverse highlighting but wouldn't draw it that way because the
flag was always false. Inverse b&w lava is relatively new and curses
hadn't been taught about it.
Various other things such as pets (if hilite_pet is on) and object
piles (if hilite_pile is on) get highlighted with inverse video when
use_color is off, regardless of whether use_inverse is on or off.
That's probably a bug.
Fixes#230
Incorporate github pull request #230, support for DECgraphics-style
line drawing in the curses interface. I've rewritten the
curses_convert_glyph() part so that it doesn't require C99 and
doesn't reinitialize its pair of arrays for every character written
to the map. The DECgraphics conversion is now a straight char for
char one, DEC line drawing code to ACS, without regard to what map
symbol is intended or what 'cursesgraphics' uses for that symbol.
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).
Have the 'menucolors' option control menu color pattern matching
(instead of curses-specific 'guicolor') for all menus, not just for
the persistent inventory window.
Commit e3af33c9db in June changed
curses handling for perm_invent to strip off doname()'s "a ", "an ",
or "the " prefix in order to shorten inventory entries and get a
couple of significant extra characters before end-of-line truncation.
That had an unintended impact on menu colors pattern matching for
patterns which expected the article prefix. Do the matching before
stripping off the prefix instead of after so that the matching gives
the same results as when used on a normal inventory menu (even though
this means that from the user's perspective most perm_invent entries
will have invisible text at the start).
Also for menu colors, don't require curses-specific 'guicolor' option
be enabled when the general, more-specific 'menucolors' option exists
to control menu coloring. (curses was requiring that both be True.)
