original code:
if (linestart && (*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
linestart = FALSE;
} else {
(void) putchar(*cp);
}
new code:
if (linestart) {
if (SYMHANDLING(H_UTF8)) {
/* FIXME: what is actually in that line? is it the \GNNNNNNNN or UTF-8? */
g_putch(*cp);
} else if ((*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
}
linestart = FALSE;
} else {
(void) putchar(*cp);
}
The new code didn't output a character if linestart was true and the character did
not have bit 0x80 set.
fixed code:
if (linestart) {
if (SYMHANDLING(H_UTF8)) {
/* FIXME: what is actually in that line? is it the \GNNNNNNNN or UTF-8? */
g_putch(*cp);
} else if ((*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
} else {
(void) putchar(*cp);
}
linestart = FALSE;
} else {
(void) putchar(*cp);
}
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
- Microsoft Visual Studio 2017 Community Edition v 15.9.47
- Microsoft Visual Studio 2019 Community Edition v 16.11.13
- Microsoft Visual Studio 2022 Community Edition v 17.1.5
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.
artifact.c: In function 'dump_artifact_info':
artifact.c:1088:37: warning: '%s' directive writing up to 255 bytes into a region of size 218 [-Wformat-overflow=]
1088 | Sprintf(buf, " %-36.36s%s", artiname(m), buf2);
| ^~ ~~~~
In file included from ../include/config.h:652,
from ../include/hack.h:10,
from artifact.c:6:
../include/global.h:255:24: note: 'sprintf' output between 39 and 294 bytes into a destination of size 256
255 | #define Sprintf (void) sprintf
artifact.c:1088:13: note: in expansion of macro 'Sprintf'
1088 | Sprintf(buf, " %-36.36s%s", artiname(m), buf2);
| ^~~~~~~
Place built libraries for Lua and pdcurses into lib instead of the
more transient src/o subfolder.
Remove a kludge involving sys/windows/stub-pdcscrn.c.
Don't link pdcurses into NetHackW.exe (required a couple of stubs
since NetHack.exe and NetHackW.exe currently share object files
under the visual studio nmake build.
(Note: This may require a couple of follow-on minor modifications
to the mingw build. If so, the CI will flag that for us after this
commit)
nhmall