- bmp2iff_host: convert nhtiles.bmp to Amiga IFF tile files. Uses
the AMIV UI palette in pens 0-15, remaining pens filled with tile
colors sorted by frequency.
Usage: bmp2iff_host -planes N input.bmp output.iff
- xpm2iff_host: convert XPM to IFF for tomb.iff (RIP screen).
Adapted from xpm2iff.c, Copyright (c) 1995 Gregg Wonderly.
- Auto-select tiles32.iff (5 planes) or tiles16.iff (4 planes)
based on screen color depth at runtime.
- Fix NO_GLYPH in amiv_lprint_glyph: return early to prevent
blitting with uninitialised data (caused black spots).
- Add AmigaFont symbol set to dat/symbols for AMII text mode.
Add Henry Spencer's BSD regex implementation (from ixemul) to provide
POSIX regular expressions for the Amiga port, enabling menu coloring
and config file pattern matching.
Copyright (c) 1992 Henry Spencer, The Regents of the University of
California. BSD license.
Update the Amiga Intuition window port (AMII/AMIV) for the 3.7
window_procs API. Key changes:
- Update all window function signatures for 3.7
- Add assembly trampolines for AmigaOS register-based callbacks
- Convert all K&R function definitions to C99
- Add cross-compilation build system (cross-pre1/pre2/post.370)
using bebbo's m68k-amigaos-gcc with -noixemul -std=gnu17 -m68000
- Clipping fixes: viewport centering, simplified ScrollRaster,
duplicate Ctrl-R suppression, glyph buffer invalidation
- Add menucolor support in menu rendering
- Move native txt2iff.c and xpm2iff.c to outdated/
- Add nethack.cnf and README.amiga
Move the active Amiga source files back into their proper locations.
Legacy native build files (Makefile.ami, Build.ami, etc.) remain
in outdated/ as they are not used by the cross-compilation build.
The existing detection logic was not working on any groff since at least
1.22.3 (November 2014), as could be seen by uncommenting the "$(info
...)" line. The regex used to match "nroff --version" output was
insufficiently flexible.
Fixes:
$ (cd doc && rm -f Guidebook && PATH=$HOME/groff-1.22.3/usr/bin:/bin make Guidebook) | grep NROFF
NROFFISGROFF=
$ (cd doc && rm -f Guidebook && PATH=$HOME/groff-1.22.4/usr/bin:/bin make Guidebook) | grep NROFF
NROFFISGROFF=
$ (cd doc && rm -f Guidebook && PATH=$HOME/groff-1.23.0/usr/bin:/bin make Guidebook) | grep NROFF
NROFFISGROFF=
$ (cd doc && rm -f Guidebook && PATH=$HOME/groff-HEAD/usr/bin:/bin make Guidebook) | grep NROFF
NROFFISGROFF=
Use a different approach in Make to recording groff detection. Use
"grep -c" (which is POSIX-conforming) to count the number of matches so
that we can use the contents of the Make macro `NROFFISGROFF` as a sort
of Boolean, which reads more idiomatically (in my opinion).
Further, instead of trying to lexically analyze a matched line in the
output of "nroff --version" and parse components of a version number out
of it, use GNU troff's built-in facility for extracting its minor
version number by storing the output of a tiny *roff document that
reports that datum (and nothing else).
Ignore warnings in category "scale" in any version of groff, because the
`tmac.n` macro package provokes them.
Clarify comments.
With sys/unix/hints/linux.370, if GDBPATH doesn't exist, comment out
the GDBPATH line in sysconf during 'make install' or 'make update'.
[ macOS apparently uses sys/unix/hints/macosx.sh to do its sysconf manipulation,
so there is no corresponding change for sys/unix/hints/macOS.370 ]
Closes#1477
windows/windsys.c:263:15: warning: format string is not a string literal
(potentially insecure) [-Wformat-security]
263 | msmsg(buf);
| ^~~
../sys/windows/windsys.c:263:15: note: treat the string as an argument to avoid this
263 | msmsg(buf);
| ^
| "%s",
../sys/windows/windsys.c:267:20: warning: format string is not a string literal
(potentially insecure) [-Wformat-security]
267 | raw_printf(buf);
| ^~~
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).
