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.
Move the core's global restoring flag (not the same as main()'s
local resuming flag) to a more logical place. Add a saving flag
in the process, but it isn't being set or cleared anywhere yet.
(Once in use it will probably fix the exception during save that
was just reported, but before that it would be useful to figure
out what specifically caused the event.)
The program_state struct really ought to be standalone rather
than part of struct g but I haven't made that change.
Removing an unused variable for wishing and some reformatting
that whent along with it got mixed in. Removes some trailing
whitespace in sfstruct.c too.
Only lightly tested...
Update the cross-compiling doc at the top.
Remove sys/msdos/Makefile1.cross, sys/msdos/Makefile2.cross, and
sys/msdos/msdos-cross-compile.sh as they are no longer required.
Remove occurrences of CROSSCOMPILE_HOST as the host-side of a
cross-compile can be determined from:
defined(CROSSCOMPILE) && !defined(CROSSCOMPILE_TARGET)
without the additional macro.
- If you want to obtain the djgpp cross-compiler and tools/libs for MSDOS,
which is available for linux and macOS, you can use the following script
to obtain it:
sh sys/msdos/fetch-cross-compiler.sh
That script won't install anything, it is just file fetches. It will
store the cross-compiler in subfolders of lib and the hints files are
configured to find it appropriately there.
Note: Both the fetch and the msdos cross-compile package target require
unzip and zip to be available on your host build system.
Cross-compiler bits:
https://github.com/andrewwutw/build-djgpp
and the pre-built binary for your platform from:
https://github.com/andrewwutw/build-djgpp/releases/download/v3.0/
and a DOS-extender (for including in msdos packaging) from
http://sandmann.dotster.com/cwsdpmi/csdpmi7b.zip
and pdcurses from:
https://github.com/wmcbrine/PDCurses.git
The MSDOS cross-compile can then be carried out by specifying
CROSS_TO_MSDOS=1 on the make command line.
For example:
make CROSS_TO_MSDOS=1 all
make CROSS_TO_MSDOS=1 package
You can explicitly include tty and curses support if desired, otherwise
you'll end up with a tty-only cross-compile build:
make WANT_WIN_TTY=1 WANT_WIN_CURSES=1 CROSS_TO_MSDOS=1 all
Also note that building the msdos targets using the make command
above, does not preclude you from building local linux or macOS
targets as well. Just drop the CROSS_TO_MSDOS=1 from the make
command line.
The cross-compiler hints additions are enclosed inside ifdef sections
and won't interfere with the non-cross-compile build in that case.
- should work on linux or MacOS to build an msdos zipfile distribution
- no longer requires env variables be set ahead of it because it will set some
defaults within
- you must have zip and unzip on your system though
- you have to "make fetch-lua" first if you haven't already done that
- script takes care of obtaining the djgpp-cross-compiler etc, then
uses it to build msdos NetHack
- to clean and rebuild from scratch:
make -f sys/msdos/Makefile1.cross clean
Also updates the travis build to Ubuntu focal because of an
ar libfl.so.2 shared library load error on xenial that was
easier to just get away from by moving to focal.
The host build portion using sys/msdos/Makefile1.cross) was failing because it
was attempting to compile the generated tile.o which is using hack.h.
gcc -o../util/tilemap host_o/tilemap.o
A new ../src/tile.c has been created
gcc -c -O -I../include -I../sys/msdos -DDLB -DUSE_TILES -DCROSSCOMPILE -DCROSSCOMPILE_HOST -ohost_o/tile.o ../src/tile.c
In file included from ../include/hack.h:201:0,
from ../src/tile.c:3:
../include/dungeon.h:70:5: error: unknown type name ‘lua_State’
lua_State *themelua; /* themerms compiled lua */
^
../sys/msdos/Makefile1.cross:286: recipe for target 'host_o/tile.o' failed
make: *** [host_o/tile.o] Error 1
I don't think think the tile.o is required on the host build build portion,
so it is probably an error in the Makefile. Try removing it.
recover had deviated somewhat from NetHack in its
file expectations:
1) A couple of 3.7 fields needed to be accommodated.
2) hard-coded file size values had deviated.
The file sizes are now in an added header file named "filesize.h",
which is included at the bottom of config.h.
There will likely be another commit to write the filename size ahead
of the file name so that the precise number of characters can be read,
but since that will break existing saves, it can go in along with another
save-breaking commit.
This commit doesn't not alter savefiles written by nethack so does not
require an editlevel bump. It does alter the read-in expectation in
recover to match the game and this get recover working again.
Some BIOSes allow calling the window function directly, bypassing the
logic that distinguishes this call from other BIOS calls. Should be
faster on some systems.
This was not previously done because the palette was not correctly set
up, and QEMU gave incorrect colors. The palette setup function now
falls back to the standard BIOS function if the VESA BIOS function
fails, which resolves the issue with QEMU. The mode selection logic now
favors 8 bit color if the tile set is compatible.
Using 8 bit mode means fewer writes to memory and fewer uses of the
BIOS window function.
Attempt to test whether Lua fetch succeeded (and pdcurses for windows
and msdos as well)
If those prerequisite fetches and untars didn't work, just exit without
marking the travis-ci build as a failure so that the development team
isn't notified about something transient that they don't need to fix
in the code.
