remove the safeproc pseudo-windowport routines from
almost a decade ago.
A very early pass is made through the config file,
seeking out just the interface-related OPTIONS=windowport
and OPTIONS=soundlib and ignoring all other options in the
config file during that early pass, so the windowport
can be activated without the NetHack core initialization
in place that some of the other rcfile OPTIONS require.
Bundles the existing rcfile processing code into rcfile().
New functions to control which rcfile options will be
disregarded in the early config file pass, and which will be
processed:
set_all_options_disregarded();
set_all_options_heeded();
disregard_this_option(opt_xx);
heed_this_option(opt_xx);
Windows calls rcfile_interface_options(), which is
a bundling of a series of function calls to achieve
the desired result.
void
rcfile_interface_options(void)
{
allopt_array_init();
set_all_options_disregarded();
heed_this_option(opt_windowtype);
heed_this_option(opt_soundlib);
rcfile();
set_all_options_heeded();
disregard_this_option(opt_windowtype);
disregard_this_option(opt_soundlib);
}
remove the safeproc pseudo-windowport routines from
almost a decade ago.
A very early pass is made through the config file,
seeking out just the interface-related OPTIONS=windowport
and OPTIONS=soundlib and ignoring all other options in the
config file during that early pass, so the windowport
can be activated without the NetHack core initialization
in place that some of the other rcfile OPTIONS require.
Bundles the existing rcfile processing code into rcfile().
New functions to control which rcfile options will be
disregarded in the early config file pass, and which will be
processed:
set_all_options_disregarded();
set_all_options_heeded();
disregard_this_option(opt_xx);
heed_this_option(opt_xx);
Windows calls rcfile_interface_options(), which is
a bundling of a series of function calls to achieve
the desired result.
void
rcfile_interface_options(void)
{
allopt_array_init();
set_all_options_disregarded();
heed_this_option(opt_windowtype);
heed_this_option(opt_soundlib);
rcfile();
set_all_options_heeded();
disregard_this_option(opt_windowtype);
disregard_this_option(opt_soundlib);
}
Move the monster spell definitions there, and use hackery
(similar to objects.h) to generate enum and data from
the header file.
I have not tested Windows, VMS, or Amiga builds.
Cross-compiling NetHack with Visual Studio from an x64 platform to an ARM64
target presents some new build challenges.
In the current nethack.sln solution, the build attempts to execute the
several just-built tools during the build of various subprojects.
For example, when cross-compiling on a typical Windows 11 x64 machine
to build a target ARM64 Windows 11 package, the build process tries to
run the following just-built target tools:
(under a Debug build)
"$(ToolsDir)\Debug\ARM64\uudecode.exe"
"$(ToolsDir)\Debug\ARM64\makedefs.exe"
"$(ToolsDir)\Debug\ARM64\tilemap.exe"
"$(ToolsDir)\Debug\ARM64\tile2bmp.exe"
"$(ToolsDir)\Debug\ARM64\dlb.exe"
(under a Release build)
"$(ToolsDir)\Release\ARM64\uudecode.exe"
"$(ToolsDir)\Release\ARM64\makedefs.exe"
"$(ToolsDir)\Release\ARM64\tilemap.exe"
"$(ToolsDir)\Release\ARM64\tile2bmp.exe"
"$(ToolsDir)\Release\ARM64\dlb.exe"
Those fail to execute successfully on Intel x64 (or x86) since they
are actually ARM64 executables, and the build attempts to execute
them on the host Intel x64 hardware.
The situation is a little different if the cross-compile is carried out
on a Windows 11 ARM64 machine (such as SnapDragon).
On an ARM64 machine, the cross-compile to build a target Intel x64
Windows 11 package, tries to execute the following:
(under a Debug build)
"$(ToolsDir)\Debug\x64\uudecode.exe"
"$(ToolsDir)\Debug\x64\makedefs.exe"
"$(ToolsDir)\Debug\x64\tilemap.exe"
"$(ToolsDir)\Debug\x64\tile2bmp.exe"
"$(ToolsDir)\Debug\x64\dlb.exe"
(under a Release build)
"$(ToolsDir)\Release\x64\uudecode.exe"
"$(ToolsDir)\Release\x64\makedefs.exe"
"$(ToolsDir)\Release\x64\tilemap.exe"
"$(ToolsDir)\Release\x64\tile2bmp.exe"
"$(ToolsDir)\Release\x64\dlb.exe"
Those actual do succeed in executing on ARM64, because of the
"prism emulation" that is available on Windows 11 ARM64 operating
systems to allow x64 and x86 executables to run.
The following change adds some detection to build environment, leading
to the definition of a "HostTools" macro that leads to the native host
tools for those steps.
There is a catch:
It means that the native build of the interim tools for Windows 11 must
be executed prior to attempting a cross-compile build to a non-native
target. That ensures that the native x64 interim uudecode, makedefs,
tilemap, tile2bmp and dlb tools are available on the disk for use by
a subsequent cross-compile.
This change consistently switches to the use of the host-native
interim tools for uudecode, makedefs, tilemap, tile2bmp and dlb tools.
Technically, this change would not be strictly necessary on an
ARM64-hosted build that was targeting x64 or x86, because of the
available prism-emulation that allows ARM64, x64, and x86 images to
execute, but this maintains consistency of the build process on
either platform. It is also likely that the native host versions execute
more quickly than versions requiring the prism emulation, although
that isn't really a concern for a NetHack build.
The use of native host uudecode, makedefs, tilemap, tile2bmp and
dlb tools is done with the Unix-hosted cross-compiles to other
target platforms as well (on Linux or macOS).
This is the third of a series of savefile-related changes.
This adds early-days experimental support for a completely optional
'sfctool' utility (savefile conversion tool), to be able to export
a savefile's contents into a more portable format. There are likely
to be bugs at this stage. In this initial first-attempt, the export
format is a very simple ascii output.
NetHack can be built entirely, without also building this tool.
NetHack has no dependencies on the tool.
Attempts were made to minimize duplication of existing NetHack code.
To achieve that, unfortunately, #ifdef SFCTOOL and #ifndef SFCTOOL
had to be sprinkled around through some of the existing NetHack
source code, so that it could be re-used for building the utility.
The process for building the sfctool typically recompiles the source
files with #define SFCTOOL and a distinct object file with SF- is
produced.
sfctool notes:
Universal ctags is used and required to produce the sfctool utility.
Some targets were added to the Unix and Windows Makefiles to
facilitate the build process.
make sfctool
That should build a copy in util.
Note: At present, the Unix Makefiles do not copy sfctool over to the
NetHack playground during 'make install' or 'make update'.
Until that gets resolved by someone, The tool will
have to be manually copied there by the builder/admin if
desired.
cp util/sfctool ~/nh/install/games/lib/nethackdir/sfctool
Also, a separate Visual Studio sfctool.sln solution was written and
placed in sys/windows/vs. That has has only very limited testing.
Usage:
i) To convert an existing savefile to an exportascii format
that co-resides with the savefile:
sfctool -c savefile
That *must* be executed on the same platform / architecture /
data model that produced the save file in the first place.
ii) To unconvert an existing exportascii format export file to a
historical format savefile that can then be used by NetHack:
sfctool -u savefile
That must be executed on the same target platform / architecture /
data model that was used to build the NetHack that will
utilize the save file that results.
A Windows example:
sfctool -c Fred.NetHack-saved-game
That should result in creation of Fred.NetHack-saved-game.exportascii
from existing savefile:
%USERPROFILE%\AppData\Local\NetHack\3.7\Fred.NetHack-saved-game
A Unix example:
sfctool -c 1000wizard
That should result in creation of 1000wizard.exportascii.gz
from existing savefile in the playground save directory:
1000wizard.gz
Current Mechanics:
1. Makefile recipe, or script uses universal ctags to produce
util/sf.tags.
2. util/sftags is built and executed to read util/sf.tags and
generate: include/sfproto.h and src/sfdata.c.
3. util/sfctool is built from the following:
generated file compiled with -DSFCTOOL:
src/sfdata.c -> sfdata.o
existing files compiled with -DSFCTOOL:
util/sfctool.c -> sfctool.o
util/sfexpasc.c -> sfexpasc.o
src/alloc.c -> sf-alloc.o
src/monst.c -> sf-monst.o
src/objects.c -> sf-objects.o
src/sfbase.c -> sfbase.o
src/sfstruct.c -> sfstruct.o
src/nhlua.c -> sf-nhlua.o
util/panic.c -> panic.o
src/date.c -> sf-date.o
src/decl.c -> sf-decl.o
src/artifact.c -> sf-artifact.o
src/dungeon.c -> sf-dungeon.o
src/end.c -> sf-end.o
src/engrave.c -> sf-engrave.o
src/cfgfiles.c -> sf-cfgfiles.o
src/files.c -> sf-files.o
src/light.c -> sf-light.o
src/mdlib.c -> sf-mdlib.o
src/mkmaze.c -> sf-mkmaze.o
src/mkroom.c -> sf-mkroom.o
src/o_init.c -> sf-o_init.o
src/region.c -> sf-region.o
src/restore.c -> sf-restore.o
src/rumors.c -> sf-rumors.o
src/sys.c -> sf-sys.o
src/timeout.c -> sf-timeout.o
src/track.c -> sf-track.o
src/version.c -> sf-version.o
src/worm.c -> sf-worm.o
src/strutil.c -> strutil.o
This is the second of a series of changes related to save/restore.
No EDITLEVEL bump has been included, because although the code
is changed extensively by this, the content of the savefiles have
not been changed.
Push the use of the structlevel bwrite() and mread() function use
out of the core and into sfstruct.c. This is groundwork for upcoming
changes.
In the core, replace the bwrite() and mread() calls with the
use of type-specific savefile output (Sfo) and savefile
input (Sfi) macros. The macros are defined in a new header file
savefile.h, which also contains the prototypes for the sfo_* and
sfi_* functions that the macros ultimately expand to. The functions
themselves are in src/sfbase.c.
On C99, each Sfo or Sfi macro expansion refers directly to the
corresponding type-specific sfo_* or sfi_* function.
If C23 or later is is use, the majority (all but 3 types) of the
macros refer to a single _Generic output routine sfo(nhfp, dt, tag),
and a single _Generic input routine sfi(nhfp, dt, tag), which handles
the dispatch of the type-specific underlying functions. This was
somewhat experimental, but turned out to be practical because the
compiler would gripe if the type for a variable was not included in
the _Generic when passed as an argument, so it could be fixed.
This alters the savefile verication process by having a common set
return values for the related functions such as uptodate(),
check_version(), etc. The new return values return more information
about savefile incompatibilities, beyond failure/sucess. The
additional information will be useful for an upcoming addition.
The expanded return values are:
SF_UPTODATE (0) everything matched and looks good
SF_OUTDATED (1) savefile is outdated
SF_CRITICAL_BYTE_COUNT_MISMATCH (2) critical size count mismatch
SF_DM_IL32LLP64_ON_ILP32LL64 (3) Windows x64 savefile on x86
SF_DM_I32LP64_ON_ILP32LL64 (4) Unix 64 savefile on x86
SF_DM_ILP32LL64_ON_I32LP64 (5) x86 savefile on Unix 64
SF_DM_ILP32LL64_ON_IL32LLP64 (6) x86 savefile on Windows x64
SF_DM_I32LP64_ON_IL32LLP64 (7) Unix 64 savefile on Windows x64
SF_DM_IL32LLP64_ON_I32LP64 (8) Windows x64 savefile on Unix 64
SF_DM_MISMATCH (9) some other mismatch
The callers in the core have been adjusted to deal with the expanded
return values.
Other miscellaneous inclusions:
- go.oracle_loc -> svo.oracle_loc.
- add a bit (1UL << 30) to called SFCTOOL_BIT as groundwork
for changes to follow.
