1f6c1d0f42
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.
145 lines
5.7 KiB
Plaintext
145 lines
5.7 KiB
Plaintext
NetHack 3.7 tile.doc $NHDT-Date: 1596498338 2020/08/03 23:45:38 $ $NHDT-Branch: NetHack-3.7 $:$NHDT-Revision: 1.8 $
|
|
|
|
Window ports can optionally make use of the tiles (pictures for NetHack
|
|
symbols) found in this directory. They are distributed in a text format
|
|
with routines to help in converting them to a system's preferred format
|
|
and using them there. The original tiles were provided by Warwick Allison.
|
|
|
|
The tile distribution format for monsters.txt, objects.txt, and other.txt
|
|
starts with a palette header like:
|
|
|
|
A = (0, 0, 0)
|
|
...
|
|
P = (254, 254, 254)
|
|
|
|
and then each tile has an entry like:
|
|
|
|
# tile 292 (comment identifying tile)
|
|
{
|
|
AAAAGHPAAAAACDAA
|
|
AAAFGDEMLOCNAAAA
|
|
...
|
|
}
|
|
|
|
Each port can convert these .txt files to whatever format it wants the
|
|
game executable to use, probably providing only one merged output file.
|
|
See the tilemap.c discussion at the bottom for more hints on adding tiles.
|
|
|
|
|
|
Shared code provided for conversion utilities:
|
|
|
|
tile.h contains shared declarations.
|
|
|
|
tiletext.c defines the external variables from tile.h and supplies
|
|
the external routines for reading and writing the defined text format.
|
|
|
|
Each conversion utility is expected to use tiletext.c and provide code of
|
|
its own for reading and/or writing another format. The important global
|
|
variables implement a colormap shared between tiletext.c and the other
|
|
half of utilities. As an example of conversion utilities, we provide
|
|
txt2ppm (tiletext.c + ppmwrite.c) and gif2txt (tiletext.c + gifread.c).
|
|
(Sorry, we're not paying Unisys patent royalties for the right to provide
|
|
you with a gifwrite.c, which would necessarily use the LZW compression
|
|
algorithm they claim.)
|
|
|
|
The text I/O routines are:
|
|
|
|
boolean fopen_text_file(const char *filename, const char *type);
|
|
select file for subsequent tile I/O
|
|
"type" a la fopen
|
|
returns FALSE if file not opened, otherwise reads/writes header
|
|
(including colormap) and sets up to decode/encode tiles
|
|
int fclose_text_file();
|
|
close file
|
|
boolean read_text_tile(pixel[TILE_Y][TILE_X]);
|
|
returns FALSE if no next tile in current file
|
|
otherwise TRUE and insert the tile in the provided array
|
|
boolean write_text_tile(pixel[TILE_Y][TILE_X]);
|
|
writes tile
|
|
|
|
There are some additional shared routines provided for writers:
|
|
|
|
void set_grayscale(boolean g);
|
|
do grayscale color substitutions when reading the tile text file
|
|
void init_colormap();
|
|
initialize the output colormap from the input one
|
|
must be called before opening output file as colormap is part of header
|
|
void merge_colormap();
|
|
merge the current input colormap into the output one
|
|
|
|
Due to the amount of state being kept, only one text or gif file can be
|
|
open at a time. If you are combining multiple files into one other-format
|
|
file with a single common colormap, you may need to open each source file
|
|
and merge their colormaps into a common colormap before processing any tiles.
|
|
|
|
Although there are expected to be only 16 colors in the distribution tiles,
|
|
conversion programs should be prepared to accept up to MAXCOLORMAPSIZE
|
|
colors and map them to a smaller number if their port requires it.
|
|
|
|
|
|
Expected sequence for editing tiles:
|
|
edit foo.txt
|
|
|
|
-or-
|
|
|
|
run txt2ppm foo.txt foo.ppm
|
|
convert ppm to gif, either via ppmtogif from pbmplus/netpbm or
|
|
stripping the first 15 bytes of foo.ppm (containing the
|
|
size of the image) and feeding the rest to any raw-24bit-
|
|
image-reading program
|
|
edit tiles with gif-editing program
|
|
run gif2txt foo.gif foo.txt
|
|
|
|
|
|
When converted to ppm, monsters.ppm, objects.ppm, and other.ppm are:
|
|
each a single ppm format (rgb triples with header)
|
|
20 tiles across, however many down (need "blank" tile to fill in
|
|
extras on last row -- currently alternating pixels in
|
|
first and second colors)
|
|
allows looking at tiles en masse for comparison or whatever
|
|
|
|
The gif reading routines accept further variations so long as the gif is
|
|
n*TILE_X pixels across.
|
|
|
|
The gif I/O routines are:
|
|
|
|
boolean fopen_gif_file(const char *filename, const char *type);
|
|
select file for subsequent tile I/O
|
|
"type" a la fopen
|
|
returns FALSE if file not opened, otherwise reads gif header
|
|
(including colormap) and sets up to decode tiles
|
|
int fclose_gif_file();
|
|
tear down decode mechanism
|
|
close file
|
|
boolean read_gif_tile(pixel[TILE_Y][TILE_X]);
|
|
returns FALSE if no next tile in current file (including when any
|
|
remaining tiles are "blank"),
|
|
otherwise TRUE and insert the tile in the provided array
|
|
|
|
|
|
Array provided by shared code for NetHack use, by compiling and running
|
|
tilemap.c to form tile.c:
|
|
|
|
glyph_map glyphmap[MAXGLYPH];
|
|
maps glyph number to tile number, ( and later to ttychar, symidx,
|
|
glyphflags) for display purposes, assuming (non-blank) tiles are
|
|
numbered sequentially through monsters/objects/other
|
|
|
|
tilemap.c (shudder) accounts for things disappearing due to compilation
|
|
options -- there should be a tile for everything appearing under any
|
|
supported option, but under some options some tiles won't be referenced.
|
|
Therefore, tilemap.c has the knowledge to provide the comments for gif2txt
|
|
and is compiled with GIF2TXT to link in there, along with the various
|
|
strings for things that are compiled in (monst.o etc.).
|
|
|
|
If you add monsters/objects/other things to NetHack and need to add tiles
|
|
to go with them, just add an entry in the right place in the appropriate
|
|
.txt file, and one to tilemap.c if the new item is conditionally compiled.
|
|
While the "comment identifying tile" in the .txt file must be correct,
|
|
the number of the tile need not be, and can just be a duplicate of the
|
|
tile on either side (or any other integer, for that matter). In an
|
|
official release, the tiles in a .txt file will be numbered consecutively
|
|
so that you may cross-reference with a graphics format, but the conversion
|
|
code does not care about the numbering. (In fact, running txt2ppm, ppmtogif,
|
|
and gif2txt gives you a consecutively numbered version of the .txt file.)
|