Issue reported by argrath: building with 'address sanitizing'
reported tile2bmp writing out of array bounds after the addition
of the generic object tiles.
'MAGICTILENO' in tile2bmp.c is extremely fragile. It was already
inaccurate before the generic tiles, but had a big enough value to
handle the final row of tiles prior to that.
Fixes#955
Add 17 fake objects to objects[], one for each object class. All
specific color as gray. They're grouped at the start--actually near
the start since "strange object" is still objects[0]--rather than
being among the objects for each class. init_object() knows to start
at [MAXOCLASSES] instead of [0]; other code that loops through every
object might need adjusting.
For potions, non-stone gems, and non-novel/non-Book_of_the_Dead
spellbooks that don't have obj->dknown set, display the corresponding
generic object rather the object itself. Fixes the longstanding bug
of seeing color for not-yet-seen objects whose primary distinguishing
characteristic is their color. Walking next to a generic object
while able to see its spot will set dknown and redraw as specific.
It's slightly disconcerting to have objects change as you reach them;
I hope it's just a matter of becoming used to that. (If there is any
code still changing the hero's location manually instead of using
u_on_newpos(), it should be changed to use that routine.)
Most of the new tiles are just a big rendering of punctuation
characters. The potion, gem, and spellbook ones could be cloned from
a specific object in their class and then have the color removed. I
started out that way but wasn't happy with the result. I'm not
artisticly inclined; hopefully someone else will do better. Each of
them is preceded by a comment beginning with "#_"; the underscore
isn't required, just being used to make the comments stand out a bit.
Invalidates existing save and bones files.
Accept
<start of line><optional whitespace>#<anything>
as a comment in win/share/{monsters,objects,other}.txt. Existing
<start of line><optional whitespace># tile <rest of line>
is grandfathered in as data.
It wouldn't take much more to accept
<data><optional whitespace>#<rest of line>
comments too but this hasn't gone that far.
Reading the colormap at the beginning of each of the three files
used "%[A-Za-z0-i]" to read one characer into a two-character array.
Change that to "%1[A-Za-z0-9]" so that it can't overflow the buffer
if the input data gets accidentally or maliciously mangled. (Not a
security issue.)
Remove a spurious blank line from objects.txt.
Also, clean up some warnings when compiling gifread.c for gif2txt
although I ultimately didn't do anything with that.
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.
Instead of using index() macro defined to strchr, use C99 strchr.
Instead of using rindex() macro defined to strrchr, use C99 strrchr.
If you want to try building on a platform that doesn't offer those
two functions, these are available:
define NOT_C99 /* to make some non-C99 code available */
define NEED_INDEX /* to define a macro for index() */
define NEED_RINDX /* to define a macro for rindex() */
warning: for tile 250 (numbered 250) of objects.txt,
found 'huge chunk of meat' while expecting 'enormous meatball'
../win/share/objects.txt: 460 tiles
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.
Change the inner workings of the experimental TTY_PERM_INVENT.
Switch to delivering the content to tty for the experimental perm_invent
via the existing window port interface (start_menu(), add_menu(), end_menu).
This also adds a new window port interface call ctrl_nhwindow() for
delivering information to the window port, and/or obtaining specific
information from the window port. The information and requests can
be extended as required. To be documented later once the changes settle
down.
Due to the intrusive nature of these changes and the possibility of
some bugs in the new code, I'm going to leave TTY_PERM_INVENT commented
out in the repository for a day or two. Anyone wishing to test it out
can do so by uncommenting TTY_PERM_INVENT in config.h.
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
xchar
|
-----------------------
| | |
coordxy xint16 xint8
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
This increments EDITLEVEL in patchlevel.h
Add a non-string identifier to window_procs for use in runtime
identification of the current window port being used.
Use a macro WPID to add the identification at the top of the
various existing window_procs declarations. It expands to the
existing text string, as well as the newly added field wp_id
with a wp_ identifier.
For example, WPID(tty) expands to: "tty", wp_tty
The generated wp_tty must be present in the wp_ids enum at
the top of include/winprocs.h.
The WINDOWPORT(x) macro has been updated to expand to a simple
value comparison (port.wp_id == wp_x), instead of a
string comparison.
(user-side decisions really, but as it stands right now
user-side decisions/options are made and processed by the core)
add a parameter to add_menu so color can be passed
Add a new window-port interface function
perminvent_info *
update_invent_slot(winid window, int slot, perminvent_info *);
That should be nice and flexible and allow exchanges of useful
information between the core and the window port. Information
to be exchange can be easily modified in include/wintype.h as
things evolve.
Information useful to the core can be exchanged from the
window-port in struct to_core.
Information useful from the core to the window-port can be
passed in struct from_core.
I'm not going to update any docs until much later after things
are fully working and settled.
This also doesn't fix or have anything to do with existing
TTY_PERM_INVENT issues.
Add new routine 're_alloc()' that functions as MONITOR_HEAP-aware
libc realloc(). 'nhrealloc()' is the version that passes source
file and line info if built with MONITOR_HEAP enabled. The heaplog
data might now contain '<' (freed by realloc), '>' (replacement
allocation by realloc), and '*' (resized by realloc) entries in
addition to the previous '+' (allocated) and '-' (freed) entries.
heaputil has already been updated in the NHinternal repository.
Move FITSint_() and FITSuint_() from hacklib.c to alloc.c so that
they can be accessed by miscellaneous utility programs.
Remove three or four copies of FITSint_() that were duplicated in
utility programs like dlb and tile2bmp due to those not having
access to src/hacklib.o. They do have access to src/alloc.o (and
util/panic.o).
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.
observed: parallel build attempts of makedefs that trampled over
one another.
attempted workaround: Add a dependency as per Pat R's suggestion.
observed: Concurrent header file movement collisions were sometimes
causing file busy errors and build failures.
workaround: Eliminate tile.h header file movement from the
Makefile build so that the collisions won't occur with that
particular file. Leave the header file tile.h in win/share as it
is in the distribution and just adjust the include path in the
rule for the specific files that use it.
observed: tiletxt.c created on-the-fly from Makefile echo statements
sometimes resulted in garbled and duplicate content in it when
parallel makes were involved, and that caused a build failure.
workaround: Instead of creating a tiletxt.c on-the-fly via echo
statements in the Makefile, simplify things and use that
same #include "tilemap.c" approach but make it an actual file
in the distribution. That makes it available for other platforms
too.
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.
commit b88e17d04ec2bb37e2c12842e9f4c4a9 changed the order of some
objects but neglected to update the win/share/objects.txt tiles
to match.
In fairness, the error-alerting was broken at the time but has
since been resolved.
warning: for tile 46 (numbered 46) of objects.txt,
found 'lance' while expecting 'angled poleaxe / halberd'
warning: for tile 47 (numbered 47) of objects.txt,
found 'angled poleaxe / halberd' while expecting 'long poleaxe /
bardiche'
warning: for tile 48 (numbered 48) of objects.txt,
found 'long poleaxe / bardiche' while expecting 'pole cleaver / voulge'
warning: for tile 49 (numbered 49) of objects.txt,
found 'pole cleaver / voulge' while expecting 'pole sickle / fauchard'
warning: for tile 50 (numbered 50) of objects.txt,
found 'broad pick / dwarvish mattock' while expecting 'pruning hook /
guisarme'
warning: for tile 51 (numbered 51) of objects.txt,
found 'pole sickle / fauchard' while expecting 'hooked polearm /
bill-guisarme'
warning: for tile 52 (numbered 52) of objects.txt,
found 'pruning hook / guisarme' while expecting 'pronged polearm /
lucern hammer'
warning: for tile 53 (numbered 53) of objects.txt,
found 'hooked polearm / bill-guisarme' while expecting 'beaked polearm /
bec de corbin'
warning: for tile 54 (numbered 54) of objects.txt,
found 'pronged polearm / lucern hammer' while expecting 'broad pick /
dwarvish mattock
warning: for tile 55 (numbered 55) of objects.txt,
found 'beaked polearm / bec de corbin' while expecting 'lance'
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.
