ENHANCED_SYMBOLS is defined by default in config.h.
The msdos build tried to #undef ENHANCED_SYMBOLS
in tilemap.c, but doing it in there created a mismatch
between the data struct definition for glyph_map in wintype.h
and the initializers generated in tilemap.c
Move the msdos build catch for ENHANCED_SYMBOLS to
one single place in config1.h so that the code and data agree.
move the custom color data into its own field in the glyphmap
and disassociate it from the unicode/utf8 stuff.
move the glyphcache stuff during options processing and parsing
into new file glyphs.c and out of utf8map.c, and make it
general, and not part of ENHANCED_SYMBOLS.
Do the groundwork for allowing glyph color customizations to
work when any symset is loaded and not restrict it only to
the enhanced1 H_UTF8 symsets.
The customizations in effect are still affiliated with a particular
symset.
Also closes#1224, but the PR itself references a data structure
made obsolete by this commit. The curses comment from the PR was
added into the code.
The PR also made several suggestions, but only the first
one has been included in this commit (and no longer based on
the handler), that being:
"allow defining colors if other symbol handling modes are used
(possibly limited to the standard 16 colors)."
FredrIQ also wrote the following suggestions in PR#1224:
Something I was also contemplating, unrelated to implementation of this
support in curses, would be the ability for the following:
allow defining colors if other symbol handling modes are used (possibly limited to the standard 16 colors)
allow defining attributes (for example: glyph:G_pet_female_kitten:U+0066/red/underline)
allow specifying glyphs as wildcards for defining global color/attribute changes
Something I also want to see are keywords for "don't change the current defined data". If this
were to be added, you could for example do this:
OPTIONS=glyph:G_*_fox:U+0064/blue
OPTIONS=glyph:G_statue_*:basechar/gray/underline
for "make all foxes use a blue color, make all statues gray with underline" without needing
to specify the relevant character for every statue. This ("basechar", "basefg", etc)
should perhaps also be added for MENUCOLORS and statushilites, so that you can, for
example, underline all items being worn without needing to specify a bunch of
near-duplicate rules for combining BUC colors + underline worn items
as per #1064
new .h files: hacklib.h selvar.h stairs.h
new .c files: calendar.c, getpos.c, report.c, selvar.c, stairs.c,
strutil.c, wizcmds.c
cleanup of hacklib.c and mdlib.c
hacklib contains functions that do not have to link with the core
relocate wiz commands from cmd.c to wizcmds.c
relocate CRASHREPORT stuff to report.c
relocate getpos stuff from do_name.c to getpos.c
remove temporary struct definition from extern.h
cross-compile PRE-section split into cross-pre1.370 and cross-pre2.370
Windows sys/windows/Makefile.nmake and sys/windows/Makefile.mingw32 and
visual studio project file updates
Unix sys/unix/Makefile.src, sys/unix/Makefile.utl
populate selvar.c and selvar.h
build on MS-DOS (not cross-compile) Makefile updates
for sys/msdos/Makefile.GCC (untested)
vms updates for above (untested)
tilemap isn't linked with util/panic.o so doesn't have access to
panic(). Despite that, linking on OSX found panic() somewhere.
(It doesn't do format argument substitution, just prints out the
argument we pass as format string, then aborts.)
Instead of calling panic(), print a message to stderr, delete the
incomplete tile.c whose construction has failed, and exit with
failure status. Linking with panic.o wouldn't handle the message
and final failure but not help with the incomplete output file part,
so this hasn't done that.
I'm headed back to the drawing board for some tiles changes I was
attempting, but before tossing what I had I've extracted a modest
amount of cleanup for the code in win/share/tilemap.c. Some
formatting, a bit of generated formatting, make ENHANCED_SYMBOLS
less intrusive, and an error check to prevent a crash in tilemap
I triggered. Also avoid one in nethack caused by an object (not
included here) which had a description but no name.
Some static analyzers flagged the last-resort values as
out of bounds (which they were).
There's a small number of other complaint-suppression items in here too,
but nothing drastic.
The preprocessor directives in win/tty/wintty.c were crossed-up
under MSDOS build. I think I got them straightened out now.
For a crosscompile situation, the tilemap utility (which runs on
the host) needs to produce an output src/tile.c that is compatible
for the target platform.
Don't use ENHANCED_SYMBOLS under MSDOS, for now anyway.
A new feature, enabled by default to maximize testing, but one which can
be disabled by commenting it out in config.h
With this, some additional information is added to the glyphmap entries
in a new optional substructure called u with these fields:
ucolor RGB color for use with truecolor terminals/platforms.
A ucolor value of zero means "not set." The actual
rgb value of 0 has the 0x1000000 bit set.
u256coloridx 256 color index value for use with 256 color
terminals, the closest color match to ucolor.
utf8str Custom representation via utf-8 string (can be null).
There is a new symset included in the symbols file, called enhanced1.
Some initial code has been added to parse individual
OPTIONS=glyph:glyphid/R-G-B entries in the config file.
The glyphid can, in theory, either be an individual glyph (G_* glyphid)
for a single glyph, or it can be an existing symbol S_ value
(monster, object, or cmap symbol) to store the custom representation for
all the glyphs that match that symbol.
Examples:
OPTIONS=glyph:G_fountain/U+03A8/0-150-255
(Your platform/terminal font needs to be able to include/display the
character, of course.)
The NetHack core code does parsing and storing the customized
entries, and adding them to the glyphmap data structure.
Any window port can utilize the additional information in the glyphinfo
that is passed to them, once code is added to do so.
Also, consolidate some symbol-related code into symbols.c, and remove it from
files.c and options.c
When trap detection finds trapped doors and trapped chests, it shows
those as bear traps. When the hero comes within view, they revert to
normal and the detected trap is forgotten. This doesn't change that,
it is just groundwork to be able to show them distinctly. Like the
TT_BEARTRAP patch, it increments EDITLEVEL so this seemed like a good
time to put the groudwork in place.
There shouldn't be any visible changes even though internal glyph and
tile values have been renumbered after inserting two new entries.
Adding traps after S_vibrating_square was quite a hassle and suffered
though a couple of off-by-one errors that weren't trivial to find and
fix.
The tilemap change provides three variables that used to be
uppercase compile macros in the past, and Amiga (and other ports?) used
them.
The other change just uncomments the header file include.
../win/share/tilemap.c: In function ‘init_tilemap’:
../win/share/tilemap.c:705:61: warning: ‘%s’ directive writing up to 255 bytes into a region of size 122 [-Wformat-overflow=]
705 | Sprintf(tilemap[GLYPH_MON_MALE_OFF + i].name, "male %s", buf);
| ^~ ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 6 and 261 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:705:9: note: in expansion of macro ‘Sprintf’
705 | Sprintf(tilemap[GLYPH_MON_MALE_OFF + i].name, "male %s", buf);
| ^~~~~~~
../win/share/tilemap.c:706:64: warning: ‘%s’ directive writing up to 255 bytes into a region of size 118 [-Wformat-overflow=]
706 | Sprintf(tilemap[GLYPH_PET_MALE_OFF + i].name, "%s male %s", "pet", buf);
| ^~ ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 10 and 265 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:706:9: note: in expansion of macro ‘Sprintf’
706 | Sprintf(tilemap[GLYPH_PET_MALE_OFF + i].name, "%s male %s", "pet", buf);
| ^~~~~~~
../win/share/tilemap.c:707:67: warning: ‘%s’ directive writing up to 255 bytes into a region of size 113 [-Wformat-overflow=]
707 | Sprintf(tilemap[GLYPH_DETECT_MALE_OFF + i].name, "%s male %s", "detected", buf);
| ^~ ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 15 and 270 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:707:9: note: in expansion of macro ‘Sprintf’
707 | Sprintf(tilemap[GLYPH_DETECT_MALE_OFF + i].name, "%s male %s", "detected", buf);
| ^~~~~~~
../win/share/tilemap.c:708:67: warning: ‘%s’ directive writing up to 255 bytes into a region of size 115 [-Wformat-overflow=]
708 | Sprintf(tilemap[GLYPH_RIDDEN_MALE_OFF + i].name, "%s male %s", "ridden", buf);
| ^~ ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 13 and 268 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:708:9: note: in expansion of macro ‘Sprintf’
708 | Sprintf(tilemap[GLYPH_RIDDEN_MALE_OFF + i].name, "%s male %s", "ridden", buf);
| ^~~~~~~
../win/share/tilemap.c:709:55: warning: ‘%s’ directive writing up to 255 bytes into a region of size 119 [-Wformat-overflow=]
709 | Sprintf(tilemap[GLYPH_BODY_OFF + i].name, "%s %s", "body of", buf);
| ^~ ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 9 and 264 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:709:9: note: in expansion of macro ‘Sprintf’
709 | Sprintf(tilemap[GLYPH_BODY_OFF + i].name, "%s %s", "body of", buf);
| ^~~~~~~
../win/share/tilemap.c:710:63: warning: ‘%s’ directive writing up to 255 bytes into a region of size 111 [-Wformat-overflow=]
710 | Sprintf(tilemap[GLYPH_BODY_PILETOP_OFF + i].name, "%s %s", "piletop body of", buf);
| ^~ ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 17 and 272 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:710:9: note: in expansion of macro ‘Sprintf’
710 | Sprintf(tilemap[GLYPH_BODY_PILETOP_OFF + i].name, "%s %s", "piletop body of", buf);
| ^~~~~~~
../win/share/tilemap.c:732:62: warning: ‘%s’ directive writing up to 255 bytes into a region of size 120 [-Wformat-overflow=]
732 | Sprintf(tilemap[GLYPH_MON_FEM_OFF + i].name, "female %s", buf);
| ^~ ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 8 and 263 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:732:9: note: in expansion of macro ‘Sprintf’
732 | Sprintf(tilemap[GLYPH_MON_FEM_OFF + i].name, "female %s", buf);
| ^~~~~~~
../win/share/tilemap.c:733:65: warning: ‘%s’ directive writing up to 255 bytes into a region of size 116 [-Wformat-overflow=]
733 | Sprintf(tilemap[GLYPH_PET_FEM_OFF + i].name, "%s female %s", "pet",
| ^~
734 | buf);
| ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 12 and 267 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:733:9: note: in expansion of macro ‘Sprintf’
733 | Sprintf(tilemap[GLYPH_PET_FEM_OFF + i].name, "%s female %s", "pet",
| ^~~~~~~
../win/share/tilemap.c:735:68: warning: ‘%s’ directive writing up to 255 bytes into a region of size 111 [-Wformat-overflow=]
735 | Sprintf(tilemap[GLYPH_DETECT_FEM_OFF + i].name, "%s female %s",
| ^~
736 | "detected", buf);
| ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 17 and 272 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:735:9: note: in expansion of macro ‘Sprintf’
735 | Sprintf(tilemap[GLYPH_DETECT_FEM_OFF + i].name, "%s female %s",
| ^~~~~~~
../win/share/tilemap.c:737:68: warning: ‘%s’ directive writing up to 255 bytes into a region of size 113 [-Wformat-overflow=]
737 | Sprintf(tilemap[GLYPH_RIDDEN_FEM_OFF + i].name, "%s female %s",
| ^~
738 | "ridden", buf);
| ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 15 and 270 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:737:9: note: in expansion of macro ‘Sprintf’
737 | Sprintf(tilemap[GLYPH_RIDDEN_FEM_OFF + i].name, "%s female %s",
| ^~~~~~~
../win/share/tilemap.c:739:55: warning: ‘%s’ directive writing up to 255 bytes into a region of size 119 [-Wformat-overflow=]
739 | Sprintf(tilemap[GLYPH_BODY_OFF + i].name, "%s %s", "body of", buf);
| ^~ ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 9 and 264 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:739:9: note: in expansion of macro ‘Sprintf’
739 | Sprintf(tilemap[GLYPH_BODY_OFF + i].name, "%s %s", "body of", buf);
| ^~~~~~~
../win/share/tilemap.c:740:63: warning: ‘%s’ directive writing up to 255 bytes into a region of size 111 [-Wformat-overflow=]
740 | Sprintf(tilemap[GLYPH_BODY_PILETOP_OFF + i].name, "%s %s",
| ^~
741 | "piletop body of", buf);
| ~~~
In file included from ../include/config.h:643,
from ../include/hack.h:10,
from ../win/share/tilemap.c:20:
../include/global.h:254:24: note: ‘sprintf’ output between 17 and 272 bytes into a destination of size 127
254 | #define Sprintf (void) sprintf
../win/share/tilemap.c:740:9: note: in expansion of macro ‘Sprintf’
740 | Sprintf(tilemap[GLYPH_BODY_PILETOP_OFF + i].name, "%s %s",
| ^~~~~~~
cc -rdynamic -lm -o tilemap tilemap.o ../src/objects.o \
../src/monst.o ../src/drawing.o
Compiling with NO_TILE_C defined results in preventing USE_TILES
from being defined and that causes display.c to use alternate code.
Construct src/tile.c such that nethack links successfully if the
configuration specifies NO_TILE_C but the Makefile goes ahead and
builds tile.c, compiles it, and links with it, otherwise it conflicts
with that alternate code. Prior to this, linking gave two complaints
about duplicate symbols and failed.
I tried building with MONITOR_HEAP defined for the first time in a
while. It wasn't pretty.
date.c was calling libc's strdup() instead of our dupstr() so alloc.c
wasn't tracking those allocations when/if MONITOR_HEAP is enabled.
Then it called free() which is actually a call to nhfree() in that
situation. If the file of allocations and releases was subsequently
fed to heaputil, it would complain about freeing pointers that hadn't
been allocated.
Worse, makedefs and tilemap wouldn't link. For MONITOR_HEAP,
makedefs was undefining free() in order to avoid nhfree() but it now
links with date.o so got nhfree() calls anyway. And it wouldn't link
because that routine isn't available without alloc.o. tilemap
doesn't link with date.o but it does call malloc() and free() and it
wasn't undefining free(), so looked for nhfree() when linking and got
the same no-such-routine failure.
The 5 glyphs are now unaligned_altar, chaotic_altar, neutral_altar,
lawful_altar, and high_altar. The latter is only mapped if you are
on astral or sanctum levels.
sp_lev.c: In function ‘lspo_altar’:
sp_lev.c:3962:9: warning: declaration of ‘shrine’ shadows a global
declaration [-Wshadow]
3962 | int shrine;
| ^~~~~~
In file included from ../include/hack.h:217,
from sp_lev.c:14:
../include/display.h:959:5: note: shadowed
declaration is here
959 | shrine
| ^~~~~~
The walls for the mines, gehennom, knox, and sokoban had been
changed at the "tile"-level, with no awareness of the core game,
or non-tile interfaces.
- Expand the glyphs to include a set of walls for the main level
as well as each of those mentioned above.
Altars had been adjusted at the map_glyphinfo() level to substitute
some color variations on-the-fly for unaligned, chaotic, neutral,
lawful altars, and shrines. The tile interface had no awareness of
the feature.
- Expand the glyphs to include each of the altar variations that
had been implemented in the display code for tty-only. This required
the addition of four placeholder tiles in other.txt. Someone with
artistic skill will hopefully alter the additional tiles to better
reflect their intended purpose.
Explosions had unique tiles in the tile window port, and the display
code for tty tinkered with the colors, but the game had very little
awareness of the different types of explosions.
- Expand the glyphs to include each of the explosion types: dark,
noxious, muddy, wet, magical, fiery and frosty.
Pile-markers to represent a pile had been introduced at the
display-level, without little to no awareness by the core game.
- Expand the glyphs to include piletops, including objects,
bodys, and statues.
Recently male and female variations of tiles and monsters had been
had been introduced, but the mechanics had been mostly done at the
display-level through a marker flag. The window port interface then
had to increment the tile mapped to the glyph to get the female version
of the tile.
- Expand the glyphs to include the male and female versions of the
monsters, and their corresponding pet versions, ridden, detected
versions and statues of them.
Direct references to GLYPH_BODY_OFF and GLYPH_STATUE_OFF
in object_from_map() in pager.c were getting incomplete results.
- Add macros glyph_to_body_corpsenm(glyph) and
glyph_to_statue_corpsenm(glyph) macros for obtaining the corpsenm
value after passing the glyph_is_body() or glyph_is_statue() test.
Other relevant notes:
- The tile ordering in the win/share/*.txt tile files has been altered,
other.txt in particular.
- tilemap.c has had a lot of alterations to accommodate the expanded
glyphs. Output that is useful for troubleshooting will end up in
tilemappings.lst if OBTAIN_TILEMAP is defined during build.
It lists all of the glyphs and which tile it gets mapped to, and also
lists each tile and some of the references to it by various glyphs.
- An array glyphmap[MAXGLYPH] is now used. It has an entry for each
glyph, ordered by glyph, and once reset_glyphs(glyph) has been run, it
contains the mapped symindex, default color, glyphflags, and tile
index.
If USE_TILES is defined during build, the tile.c produced from the
tilemap utility populates the tileidx field of each array element with
a glyph-to-tile mapping for the glyph. Later on, when reset_glyphmap()
is run, the other fields of each element will get populated.
- The glyph-to-tile mapping is an added field available to a window
port via the glyphinfo struct passed in the documented interface. The
old glyph2tile[] array is gone. The various active window ports that
had been using glyph2tile[] have been updated to use the new interface
mechanism. Disclaimer: There may be some bug fixing or tidying
required in the window port code.
- reset_glyphmap() is called after config file options parsing
has finished, because some config file settings can impact the results
produced by reset_glyphmap().
- Everything that passes the glyph_is_cmap(glyph) test must
return a valid cmap value from glyph_to_cmap(glyph).
- An 'extern glyph_info glyphmap[MAX_GLYPH];' is inserted into the
top of only the files which need awareness of it, not inserted into
display.h. Presently, the only files that actually need to directly
reference the glyphmap[] array are display.c, o_init.c (for shuffling
the tiles), and the generated tile.c (if USE_TILES is defined).
- Added an MG_MALE glyphflag to complement the MG_FEMALE glyphflag.
- Provide an array for wall colorizations. reset_glyphmap() will draw
the colors from this array: int array wallcolors[sokoban_walls + 1];
The indices of the wallcolors array are main_walls (0), mines_walls
(1), gehennom_walls (2), knox_walls (3), and sokoban_walls (4).
In future, a config file option for adjusting the wall colors and/or
an 'O' option menu to do the same could be added. Right now, the
initializaton of the wallcolors[] array entries in display.c leaves the
walls at CLR_GRAY, matching the defsym color.
- Most of the display-level kludges for some of the on-the-fly
interface features have been removed from map_glyphinfo() as they
aren't needed any longer. These glyph expansions adhere more closely to
the original glyph mechanics of the game.
- Because the glyphs are re-ordered and expanded, an update to
editlevel will be required upon merge of these changes.
This evolves and hopefully eases the game-build requirements by
removing game-compile dependencies on any header files generated
by the makedefs utility, including:
date.h dependency and its inclusion is removed and comparable functionality
is produced at runtime via new file src/date.c.
pm.h dependency and its inclusion is removed and comparable functionality is
produced by moving the monster definitions from monst.c into new header
file called monsters.h and altering them slightly. The former pm.h header
file #define PM_ values are now replaced with appropriate emitted enum
entries during the compiler preprocessing.
onames.h dependency and its inclusion is removed and comparable functionality
is produced by moving the object definitions from objects.c into new header
file called objects.h and altering them slightly. The former onames.h header
file #define values are now replaced with appropriate emitted enum entries
during the compiler preprocessing.
artilist.h has been slightly altered, and the former onames.h artifact-related
header file #define ART_ values are now replaced with appropriate emitted enum
entries during the compiler preprocessing.
makedefs can still produce date.h (makedefs -v), pm.h (makedefs -p), and
onames.h (makedefs -o) for reference purposes. They won't be used during
the compiler.
The other uses for makedefs remain. They are used to prepare external
file content that the game utilizes, not prerequisite code for the
compile:
makedefs -d (database)
makedefs -r (rumors)
makedefs -h (oracles)
makedefs -s (epitaphs, engravings, bogusmons)
date.c
Pull the code for date/time stamping from mdlib.c into date.c.
Set date.o to be dependent on source files, header files, and .o files
so that date.o is rebuilt from date.c when any of those changes, thus
ensuring an accurate date/time stamp. It also includes git sha
functionality formerly done by makedefs writing #define directives
into include/date.h. For unix it passes the git info on
the compile line for date.c (via sys/unix/hints/linux.2020, macOS.2020)
nethack --dumpenums (optional, but on by default)
Allow developer to obtain some internal enum values from NetHack
without having to resort to an external utility such as
makedefs.
Uncomment #define NODUMPENUMS in config.h to disable this.
The updates to sys/windows/Makefile.gcc have not been tested yet.
There were multiple symbol-related lists that had to be kept
in sync in various places.
Consolidate some of that into a single new file
defsym.h
with a set of morphing macros that can be custom-called from
the various places that use the sym info without maintaining
multiple occurrences. Most maintenance can be done there.
Rename monsym.h to sym.h since it looks after some
symbols not related to monsters now too.
The defsym.h header file is included in multiple places to
produce different code depending on its use and the controlling
macro definitions in place prior to including it.
Its purpose is to have a definitive source for
pchar, objclass and mon symbol maintenance.
The controlling macros used to morph the resulting code are
used in these places:
- in include/sym.h for enums of some S_ symbol values
(define PCHAR_ENUM, MONSYMS_ENUM prior to #include defsym.h)
- in include/objclass.h for enums of some S_ symbol values
(define OBJCLASS_ENUM prior to #include defsym.h)
- in src/symbols.c for parsing S_ entries in config files
(define PCHAR_PARSE, MONSYMS_PARSE, OBJCLASS_PARSE prior
to #include defsym.h)
- in src/drawing.c for initializing some data structures/arrays
(define PCHAR_DRAWING, MONSYMS_DRAWING, OBJCLASS_DRAWING prior
to #include defsym.h)
- in win/share/tilemap.c for processing a tile file
(define PCHAR_TILES prior to #include defsym.h).
Microsoft and other non-GNU compilers don't recognize gcc tricks
like /*NOTREACHED*/ to suppress individual warnings. clang recognizes most
of them because it tries to be gcc-compatible. Because of that, a lot of
potentially useful warnings have had to be completely suppressed in the
past in all source files when using the non-gcc compatible compilers.
Now that the code is C99, take advantage of a way to suppress warnings for
individual functions, a big step up from suppressing the warnings
altogether.
Unfortunately, it does require a bit of ugliness caused by the
insertion of some macros in a few spots, but I'm not aware of
a cleaner alternative that still allows warnings to be enabled
in general, while suppressing a warning for known white-listed
instances.
Prior to the warning-tiggering function, place whichever one of
the following is needed to suppress the warning being encountered:
DISABLE_WARNING_UNREACHABLE_CODE
DISABLE_WARNING_CONDEXPR_IS_CONSTANT
After the warning-triggering function, place this:
RESTORE_WARNINGS
Under the hood, the compiler-appropriate warning-disabling
mechanics involve the use of C99 _Pragma, which can be used
in macros.
For unrecognized or inappropriate compilers, or if
DISABLE_WARNING_PRAGMAS is defined, the macros expand
to nothing.
add MALE, FEMALE, and gender-neutral names for individual monster species
to the mons array. The gender-neutral name (NEUTRAL) is mandatory, the
MALE and FEMALE versions are not.
replace code uses of the mname field of permonst with one of the three
potentially-available gender-specific names.
consolidate some separate mons entries that differed only by species into a
single mons entry (caveman, cavewoman and priest,priestess etc.)
consolidate several "* lord" and "* queen/* king" monst entries into
their single species, and allow both genders on some where it makes some
sense (there is probably more work and cleanup to come out of this at some
point, and the chosen gender-neutral name variations are not cast in stone
if someone has better suggestions).
related function or macro additions:
pmname(pm, gender) to get the gender variation of the permonst name. It
guards against monsters that haven't got anything except NEUTRAL naming
and falls back to the NEUTRAL version if FEMALE and MALE versions are
missing.
Ugender to obtain the current hero gender.
Mgender(mtmp) to obtain the gender of a monster
While the code can safely refer directly to pmnames[NEUTRAL] safely in the
code because it always exists, the other two (pmnames[MALE] and
pmnames[FEMALE] may not exist so use:
pmname(ptr, gidx)
where -ptr is a permonst *
-gidx is an index into the pmnames array field of the
permonst struct
pmname() checks for a valid index and checks for null-pointers for
pmnames[MALE] and pmnames[FEMALE], and will fall back to pmnames[NEUTRAL] if
the pointer requested if the requested variation is unavailable, or if the
gidx is out-of-range.
Allow code to specify makemon flags to request female or male (via MM_MALE
and MM_FEMALE flags respectively)to makedefs, since the species alone doesn't
distinguish male/female anymore. Specifying MM_MALE or MM_FEMALE won't
override the pm M2_MALE and M2_FEMALE flags on a mons[] entry.
male and female tiles have been added to win/share/monsters.txt.
The majority are duplicated placeholders except for those that were
separate mons entries before. Perhaps someone will contribute artwork in the
future to make the male and female variations visually distinguishable.
tilemapping via has the MALE tile indexes in the glyph2tile[]
array produced at build time. If a window port has information that the
FEMALE tile is required, it just has to increment the index returned
from the glyph2tile[] array by 1.
statues already preserved gender of the monster through STATUE_FEMALE
and STATUE_MALE, so ensure that pmnames takes that into consideration.
I expect some refinement will be required after broad play-testing puts it to
the test.
consolidate caveman,cavewoman and priest,priestess monst.c entries etc
This commit will require a bump of editlevel in patchlevel.h because it alters
the index numbers of the monsters due to the consolidation of some. Those
index numbers are saved in some other structures, even though the mons[] array
itself is not part of the savefile.
Window Port Interface Change
Also add a parameter to print_glyph to convey additional information beyond
the glyph to the window ports. Every single window port was calling back to
mapglyph for the information anyway, so just included it in the interface and
produce the information right in the display core.
The mapglyph() function uses will be eliminated, although there are still some
in the code yet to be dealt with.
win32, tty, x11, Qt, msdos window ports have all had adjustments done to
utilize the new parameter instead of calling mapglyph, but some of those
window ports have not been thoroughly tested since the changes.
Interface change additional info:
print_glyph(window, x, y, glyph, bkglyph, *glyphmod)
-- Print the glyph at (x,y) on the given window. Glyphs are
integers at the interface, mapped to whatever the window-
port wants (symbol, font, color, attributes, ...there's
a 1-1 map between glyphs and distinct things on the map).
-- bkglyph is a background glyph for potential use by some
graphical or tiled environments to allow the depiction
to fall against a background consistent with the grid
around x,y. If bkglyph is NO_GLYPH, then the parameter
should be ignored (do nothing with it).
-- glyphmod provides extended information about the glyph
that window ports can use to enhance the display in
various ways.
unsigned int glyphmod[NUM_GLYPHMOD]
where:
glyphmod[GM_TTYCHAR] is the text characters associated
with the original NetHack display.
glyphmod[GM_FLAGS] are the special flags that denote
additional information that window
ports can use.
glyphmod[GM_COLOR] is the text character
color associated with the original
NetHack display.
Support for including the glyphmod info in the display glyph buffer
alongside the glyph itself was added and is the default operation.
That can be turned off by defining UNBUFFERED_GLYPHMOD at compile time.
With UNBUFFERED_GLYPHMOD operation, a call will be placed to map_glyphmod()
immediately prior to every print_glyph() call.
drawing.c doesn't include extern.h, so the def_char_... functions
it defines aren't preceded by a prototype. Having such guaantees
that code in other files sees the same argument types as in the
defining code.
Switch win/share/*.c from hack.h to config.h plus miscellaenous
other headers. It's possible that there is conditional code that
didn't get exercised in my testing. The Unix Makefiles don't deal
with safeproc.c or tileset.c so I just compiled those without any
attempt to link.
This adds a pair of new glyphs: GLYPH_UNEXPLORED and GLYPH_NOTHING
GLYPH_UNEXPLORED is meant to be the glyph for areas of the map that
haven't been explored yet.
GLYPH_NOTHING is a glyph that represents that which cannot be seen,
for instance the dark part of a room when the dark_room option is
not set. Since the symbol for stone can now be overridden to
a players choice, it no longer made sense using S_stone for the
dark areas of the room with dark_room off. This allows the same
intended result even if S_stone symbol is mapped to something visible.
GLYPH_UNEXPLORED is what areas of the map get initialized to now
instead of STONE.
This adds a pair of new symbols: S_unexplored and S_nothing.
S_nothing is meant to be left as an unseen character (space) in
order to achieve the intended effect on the display.
S_unexplored is the symbol that is mapped to GLYPH_UNEXPLORED, and
is a distinct symbol from S_stone, even if they are set to the same
character. They don't have to be set to the same character.
Hopefully there are minimal bugs, but it is a deviation from a
fairly long-standing approach so there could be some unintended
glitches that will need repair.
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.
