It's confusing and served no purpose; a spoiled player knew what it is,
an unspoiled player might think it was a hook-hand or something. Now
they all show up as grappling hook.
groundwork only - window port interface change
This changes the last parameter for add_menu() from a boolean
to an unsigned int, to allow additional itemflags in future
beyond just the "preselected" that the original boolean offered.
There shouldn't be any functionality changes with this groundwork-only
change, and if there are it is unintentional and should be reported.
the prompting on Windows wasn't working correctly if a prior game had crashed
and the self-recover feature was trying to kick in. This impacts tty, curses,
and mswin (GUI).
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.
With 3.7+ aspirations of improving savefile interoperability between 32-bit
and 64-bit builds, as well as between platforms, it is better to not have
the underlying struct/array content be conditional.
This splits off some of the MAIL code into MAIL_STRUCTURES code. In theory,
since MAIL_STRUCTURES is unconditionally included, the macro could
just go away and leave that code unconditional, but this commit doesn't
go that far.
Moved the code page 437 mapping table to winnt.c so that it could be
used in window and console clients.
Added check that fonts support unicode values we use from code page 437.
Use unicode to draw text if font supports it otherwise use ASCII.
Modify win/share/tilemap.c so that generated source file src/tile.c
uses similar formatting to the other sources. Mainly, avoid tabs and
use 4 columns indentation instead of 8 columns in the short routine
near the end.
tilemap.c still treats STATUES_LOOK_LIKE_MONSTERS as conditional.
The main sources made that unconditional prior to release of 3.6.0.
win/share/tileset.c seems only to be used by the MSDOS port, but it
compiles cleanly on OSX after these changes.
A file pointer was passed to fclose() twice, second time potentially
causing problems. There were cases of potentially null pointers
being passed to free() too. That should be safe these days, but it's
something we've tried to hard to avoid and would probably trigger
complaints from our own MONITOR_HEAP code if that ever got applied
here.
The value calculated for total_tiles_used never got adjusted for
displaying statues-as-monsters. The most common configuration(s)
using tiles don't care, but the combination of X11 plus USE_XPM
needs an accurate value there.
This is from the pull request for the assertion failure fix. It
did not mention how to reproduce the assertion failure, just added
casts to a bunch of isspace/isprint/tolower calls that didn't already
have such.
I removed an obsolete change for win/tty/topl.c and changed the
win/win32/mswproc.c code to avoid using an expression with side-effects
(*colorstring++) in calls to tolower() in case someone overrides that
with a macro which evaluates its argument more than once as some pre-
ANSI ones used to do. Not tested, might have typos....
sys/wince/*.c still needs similar casts.
Reported 11 months ago for 3.4.3, the tile for wrinkled spellbook
has a spurious brown spot on the far right. Several other books
have spots drawn outside the book proper for tile decoration, but
that doesn't seem to apply here. The report suggested changing
'K' to 'M', but that just changes it into a spurious white spot.
Change the stray 'K' to '.' to make the odd spot go away.
FDECL(foo, (boolean)) ought to have been using (BOOLEAN_P), but
the tiles code isn't including the header which defines that, so
change the argument to int.
Just noticed that a change of mine to src/drawing.c 2.5 weeks ago
("zap beam symbol descriptions -- they aren't walls") triggered a
set of four complaints when processing tiles.
