Doesn't work out-of-the box. Patches used for pkgsrc:
(http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/games/doomlegacy/patches/?only_with_tag=MAIN)
Notes:
The header file limits.h is is POSIX standard:
(http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html)
The function statvfs() is POSIX standard:
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/statvfs.html)
To make the code more portable, maybe the standard functions should be used by default and the OS-specific non-standard alternatives via #ifdef instead (but at least Linux has statvfs() too).
NetBSD doesn't have IPX support. Again the code would be more portable if "no IPX" would be the default (IPX enabled only on specific OS, that are known to support it).
src/Makefile was patched to honor hardening flags like FORTIFY_SOURCE and RELRO directly from build environment.
The source tree with the pkgsrc patches was tested to work on NetBSD/amd64 (64bit Little Endian) and Linux/ppc (32bit Big Endian) in SDL mode.
At least the statvfs() and IPX patches are required for NetBSD.
I have made up a patch that addresses most of these concerns.
Unfortunately, even though many systems are POSIX standard, this does not include all the systems that DoomLegacy supports. Even now I am careful not to break support for olde systems, even non-POSIX ones. That means lots of conditional code.
The USE_IPX is disabled for NETBSD.
SDL use of statvfs is enabled for NETBSD.
For the environment flags, it will require enabling COMP_ENVIRONMENT in the make_options file for netbsd. That allows us to turn it off, if needed.
This method is also used for the compiler environment variable CC.
I have attached here the proposed DoomLegacy patch file, so that you can check it over before I commit it to the SVN repository.
The proposed d34 patch.
Last edit: Wesley Johnson 2019-06-21
Proposed Makefile patch
Proposed make_options_nix
The make_options file rule fails because it uses nonstandard cp options:
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html)
NetBSD cp has no -n option.
I have tested to specify COMP_ENVIRONMENT=1 directly for make and this works.
The whole "make install" logic of the build systems fails too in so may ways, that I gave up to patch it. The pkgsrc package simply copies the files manually to the target locations. Looks like the FreeBSD people have solved it the same way:
(http://sources.freebsd.org/HEAD/ports/games/doomlegacy/Makefile)
Likely this has never worked on a Unix system with non-GNU userland.
My opinion: Not worth the work to reimplement in a portable way.
For the Launcher, the way to prevent it from starting is to include a dummy switch on the command line. DoomLegacy does not understand it, but it prevents the auto-start of the launcher, and does not issue any error messages.
The map zoom control should be fixed in the docs. While DoomLegacy is running, the SHIFT key is just another key, so the user cannot shift to get to "+". However, it is easier to tell them to use the PLUS key than it is to explain why they must use the EQUALS key.
Are you getting that EQUALS key change to work at all ?
The current pkgsrc package installs the doomlegacy binary directly for start by the user (and most users likely start it without reading the documentation first). My intention for the package was to give such users the shareware episode 1 by default (not the launcher).
Disabling the launcher with the option would require a small start script for the package. I will think about doing it this way in the future (to avoid the launcher
disable patch).
The reason for my keyboard mapping patch was that the "zoom in" function was not usable with my german keyboard (where '=' is mapped to "Shift-0"):
(https://en.wikipedia.org/wiki/File:KB_Germany.svg)
Pressing F1 inside the game shows a help screen which documents '+' for "zoom in". Then I patched for '+' and it worked for me (I thought the mapping to '=' was simply a mistake).
You have already explained the problem with Shift. Now, after a look at the british/american keyboard layout:
(https://en.wikipedia.org/wiki/File:KB_United_Kingdom.svg),
I can retrace the choice for '='. But this means with both, '+' or '=', it will be broken with one keyboard layout or the other.
BTW: Because the reference manual is detailed and lengthy, I have written a man page as a more brief overview of the most important things:
(https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/games/doomlegacy/files/)
OK, German keyboard needs to use "+", so I will have to test for both "=" and "+".
These changes are being done in the NETBSD patch in a way that does not disturb the other systems. In separate patches I will address the issues of POSIX, and other fixes that disturb the other systems compile. That way if there is a problem then I only have to back out of the patch that did the damage.
I cannot disable the launcher for the other ports. Windows and X11 both will start DoomLegacy from a graphical interface with no chance to enter command line parameters. That is why that condition is intercepted and directed to the internal launcher. That is also a hot item right now to reduce the need for any external launcher.
The dummy command line switch works on Win platforms, where they can enter a command line used to start the program when they click on the icon. If they don't enter a command line for the icon to use, they get the launcher. If they have entered command line parameters for the icon, they don't get the launcher.
It sounds like you have console users trying to start DoomLegacy, but you think they won't give it any parameters. Disabling the launcher will conflict with users trying to start DoomLegacy from the graphical interface (I assume you have X11 or something). That plan also only works for one wad that DoomLegacy would find by default. The great thing about Doom is all the other wads that can be played, and for that you need to specify them, thus the launcher. I think you could just as well tell them how to start the thing properly.
If you give them a script, call it by the name of the wad you are using for default:
d>> start_doom_demo
As soon as they get bored with that, they will learn how to start it right, and they quickly will find the launcher useful (I hope).
If they start DoomLegacy and immediately get the launcher, and cannot figure out what to do, then they will just have to read the docs enough to get it started. Sounds like a good way to get them to at least read an introductory doc. You can take advantage of that. Get them to read the first paragraph of your man page at least.
NETBSD has cp, but it does not have the -n switch.
I have spent weeks trying to write that thing to use commands that are common, and pretty much lost the battle. Win32 installer is almost entirely unique to Win32.
The -n switch on Linux cp means "no clobber", it does not write over any existing files.
Do you have a comparable option on the NetBSD copy command, or another copy command.
I have not used pkgsrc, as it is not native to Slackware Linux that I run.
If NetBSD is going to use pkgsrc for install (It looks to be standard for NetBSD) then there would be no point in trying to add NetBSD specific install conditional code.
There is already a separate installer written for the Win32 people, so I don't think all that Win32 make install is being used either. The Win32 people are just used to their binary installer, and are not familiar with the make install way of doing things.
Last edit: Wesley Johnson 2019-06-21
NetBSD (and POSIX in general) cp doesn't have a comparable option to "-n".
For a single file maybe this can be used as portable replacement:
if ! test -e target
then
cp source target
fi
or as a single line:
if ! test -e target; then cp source target; fi
There is a language option in DoomLegacy that will change some of the internal game text using a BEX file. It currenlty has some 3/4 finished French translations.
For german, the only thing that would be needed is to create a german.bex file, and edit it to be German.
It can specified on the command line.
b>> doomlegacy -lang german
If the BEX_LANGUAGE option is enabled in the doomdef.h file, then it will autoload a bex file named "lang.bex".
It being that most people just use the game in English, I currently don't keep all the print text entered into the BEX accessible language strings.
I have tested SVN revision 1448 and it works as expected (with my local patches dropped).
Thank you.