An alternative for the multi-window interface?

[42ump0gp]

Hi!

I really want to play Angband, Tales (or Troubles) of Middle Earth and Sil but I don't like the multi-window interface. I have two major problems with it:

1. I want to play in full screen. (A maximized window is not full screen.)
2. I don't like the fonts and not having the option to use my own fonts.

Can I play Angband and variants in Command Prompt like NetHack and Umoria? That would solve both problems. If I can't find a good alternative I'll have to settle for the latest DOS versions.

I use Windows. I don't know how to compile.

[PowerWyrm]

I think you can use the GCU port.

[42ump0gp]

Thanks for the suggestion! What is the GCU port? How do I use it?

[backwardsEric]

It's another front end. It uses the ncurses library to handle playing Angband in a terminal emulator. If the terminal emulator supports going fullscreen, you'd have the fullscreen mode you'd prefer.

There's no prebuilt executables for the GCU front end so compiling the game would be necessary. From other's reports, compiling the GCU front end on Windows using Cygwin, msys2, or mingw is possible. Some discussion of that is here, http://angband.oook.cz/forum/showthr...639#post156639 .

[42ump0gp]

Thank you! I'll look into it.

[tom]

So I tried this also. I got the msys2 build to compile (with the post-4.2.4 fixes), but when I run it, it says "Error opening terminal: xterm".

By the way, how are bog-standard Angband windows binaries built? Is it Visual Studio? Asking because I'm sitting on some variant code that I might like to inflict on the world some time soon, but as a Linux user I'm extremely windows-clueless.

[backwardsEric]

So I tried this also. I got the msys2 build to compile (with the post-4.2.4 fixes), but when I run it, it says "Error opening terminal: xterm".

That message is coming from the ncurses library. Likely, it's because the terminal you're running in isn't in ncurses' terminal database (the lookup for that is influenced by the contents of the TERM and TERMINFO environment variables). This older discussion (mostly about getting something built in msys2 to work with a mintty terminal), https://sourceforge.net/p/msys2/disc...read/f81f0b97/ , might be helpful.

By the way, how are bog-standard Angband windows binaries built? Is it Visual Studio? Asking because I'm sitting on some variant code that I might like to inflict on the world some time soon, but as a Linux user I'm extremely windows-clueless.

It's being built with a mingw cross-compiler on Linux (Ubuntu). The GitHub action that handles building the release is more involved, but this is the one for doing a basic compilation: https://github.com/angband/angband/b...s/windows.yaml . It's basically following the instructions in https://angband.readthedocs.io/en/la...ows-with-mingw .

[smbhax]

It's being built with a mingw cross-compiler on Linux (Ubuntu). The GitHub action that handles building the release is more involved, but this is the one for doing a basic compilation: https://github.com/angband/angband/b...s/windows.yaml .

In WSL Ubuntu, I tried

~~~~
./autogen.sh
./configure --enable-win --build=i686-pc-linux-gnu --host=i686-w64-mingw32 --enable-skip-old-int-typedefs
make
~~~~

like in those instructions but when trying to run the .exe in src or out I got missing zlib and libpng12 dll errors; copying those dlls into the dir with the exe worked around that, but then another error would come up that's too terse for me to figure out:

"The procedure entry point e could not be located in the dynamic link library \\[.exe path]"

It's basically following the instructions in https://angband.readthedocs.io/en/la...ows-with-mingw .

Tried those too

~~~~~
./configure --enable-win --build=i686-pc-linux-gnu --host=i586-mingw32msvc
make install
~~~~~

but I get this while building

~~~~~~
Successfully compiled z-dice.c.
Successfully compiled z-expression.c.
z-file.c:29:11: fatal error: windows.h: No such file or directory
29 | # include <windows.h>
| ^~~~~~~~~~~
compilation terminated.
Failed to compile z-file.c!
make[4]: *** [../mk/buildsys.mk:383: z-file.o] Error 1
make[3]: *** [../mk/buildsys.mk:137: all] Error 2
make[2]: *** [mk/buildsys.mk:144: subdirs] Error 2
make[1]: *** [mk/buildsys.mk:135: all] Error 2
make: *** [mk/buildsys.mk:664: install] Error 2
~~~~~~~


Argh I suppose it's all just packages I haven't installed or something. Also the .exe is coming out at 7.33 MB which is quite a bit bigger than the standard one. Sorry for the horrible noobishness. = o

[backwardsEric]

In WSL Ubuntu, I tried

~~~~
./autogen.sh
./configure --enable-win --build=i686-pc-linux-gnu --host=i686-w64-mingw32 --enable-skip-old-int-typedefs
make
~~~~

like in those instructions but when trying to run the .exe in src or out I got missing zlib and libpng12 dll errors; copying those dlls into the dir with the exe worked around that, but then another error would come up that's too terse for me to figure out:

"The procedure entry point e could not be located in the dynamic link library \\[.exe path]"

If you had used "make install" rather than "make", zlib and libpng12 would have been copied to the same directory as the executable. The procedure entry point could not be found message has been reported before, http://angband.oook.cz/forum/showpos...&postcount=253 . I didn't figure out what was causing it then, except that it went away when the executable was built with the version of mingw (5.0.3-1) in Ubuntu 18.04. Executables built with mingw 7.0.0-2 in Ubuntu 20.04 triggered that error, at least for one person using Windows 8.1.

Tried those too

~~~~~
./configure --enable-win --build=i686-pc-linux-gnu --host=i586-mingw32msvc
make install
~~~~~

but I get this while building

~~~~~~
Successfully compiled z-dice.c.
Successfully compiled z-expression.c.
z-file.c:29:11: fatal error: windows.h: No such file or directory
29 | # include <windows.h>
| ^~~~~~~~~~~
compilation terminated.
Failed to compile z-file.c!
make[4]: *** [../mk/buildsys.mk:383: z-file.o] Error 1
make[3]: *** [../mk/buildsys.mk:137: all] Error 2
make[2]: *** [mk/buildsys.mk:144: subdirs] Error 2
make[1]: *** [mk/buildsys.mk:135: all] Error 2
make: *** [mk/buildsys.mk:664: install] Error 2
~~~~~~~

When updating the compilation instructions, I left the reference to the i586-mingw32msvc variant of the cross-compiler as it was since I wasn't sure if it was still relevant or not. On the systems, I have ready access to (the Ubuntu runners on GitHub and Debian 11) the mingw cross-compiler packages install the i686-w64-mingw32 variant (the one you used above). z-file.c is the first source file (the other is main-win.c) that tries to pull in windows.h. So if windows.h isn't present in the i586-mingw32msvc environment or if finding it requires a -I option to set an additional directory to search, that would explain the error message.

[smbhax]

If you had used "make install" rather than "make", zlib and libpng12 would have been copied to the same directory as the executable. The procedure entry point could not be found message has been reported before, http://angband.oook.cz/forum/showpos...&postcount=253 . I didn't figure out what was causing it then, except that it went away when the executable was built with the version of mingw (5.0.3-1) in Ubuntu 18.04. Executables built with mingw 7.0.0-2 in Ubuntu 20.04 triggered that error, at least for one person using Windows 8.1.

Duly noted, thanks! = ) Updated "make" to "make install" in my notes, and if I ever need to try compiling the Windows version again I'll hunt down how to sync back to that older version of mingw.

[backwardsEric]

Duly noted, thanks! = ) Updated "make" to "make install" in my notes, and if I ever need to try compiling the Windows version again I'll hunt down how to sync back to that older version of mingw.

Which version of Windows and mingw did you use when you got the procedure entry point could not be found message? The system for building Angband's Windows releases has to change in the near future so I'm trying to determine if the version of mingw (8.0.0-1) in Ubuntu 22.04 will avoid that problem.

[smbhax]

Which version of Windows and mingw did you use when you got the procedure entry point could not be found message? The system for building Angband's Windows releases has to change in the near future so I'm trying to determine if the version of mingw (8.0.0-1) in Ubuntu 22.04 will avoid that problem.

Microsoft Windows 11 Home, Version 10.0.22000 Build 22000

Not sure if this is the right package to check but apt list reports

gcc-mingw-w64-base/focal,now 9.3.0-7ubuntu1+22~exp1ubuntu4 amd64 [installed,automatic]

"sudo apt-get install gcc-mingw-w64-base" resulted in "gcc-mingw-w64-base is already the newest version (9.3.0-7ubuntu1+22~exp1ubuntu4)."

[Bill Peterson]

The system for building Angband's Windows releases has to change in the near future.

Could you say a few words about this? The last time I compiled Angband was on Linux, but I suppose I should get up to speed if I want to get involved with the Sil rewrite

[backwardsEric]

Could you say a few words about this? The last time I compiled Angband was on Linux, but I suppose I should get up to speed if I want to get involved with the Sil rewrite

The Windows releases are currently built on Linux using mingw configured as a cross-compiler. In particular, it's done on GitHub using an environment (Ubuntu 18.04 with additional preinstalled software) prepackaged by GitHub (a GitHub "runner"). GitHub is phasing out Ubuntu 18.04 (current termination date is April 1st, 2023) so something different will have to be done for the releases. An easy way to handle the change would be to use a different GitHub runner, either using Ubuntu 20.04 or 22.04. Both have newer versions of the cross-compiler, and the version on 20.04, at least, generated FAangband executables that didn't run on Windows 8.1.

[smbhax]

If you had used "make install" rather than "make", zlib and libpng12 would have been copied to the same directory as the executable. The procedure entry point could not be found message has been reported before, http://angband.oook.cz/forum/showpos...&postcount=253 . I didn't figure out what was causing it then, except that it went away when the executable was built with the version of mingw (5.0.3-1) in Ubuntu 18.04. Executables built with mingw 7.0.0-2 in Ubuntu 20.04 triggered that error, at least for one person using Windows 8.1.

With the build procedure update ( http://angband.oook.cz/forum/showthread.php?t=11350 ) I tried compiling the Windows version again myself under WSL Ubuntu with

./autogen.sh
./configure --enable-win --build=i686-pc-linux-gnu --host=i686-w64-mingw32 --enable-skip-old-int-typedefs
make install

and the old "procedure entry point e" run error is gone, but now double-clicking the generated .exe just leaves the mouse pointer busy for a while, then nothing (and I have to kill the "Angband (32 bit)" task).

Ah, if copy the angband dir (minus src dir) from the \\wsl$ directory to a regular directory on my hard drive and try running angband.exe from there, I get an "angband.exe - Application Error" pop-up window:

The application was unable to start correctly (0xc00000005).
Click OK to close the application.