Last year, I managed to get a second hand Talos 2! Among things I wanted to do with this platform (test open source software and contribute), I was curious to see which games would work on this development machine. I installed Debian 11 and equipped the board with 32 GB of RAM and a Radeon RX570 connected to my monitor with HDMI (that also carries audio) with a 1920x1080 display.

This is a first article with games that are the easiest to build or install. I propose tests and report results, some of them are playable with only the BMC framebuffer (limited to non-OpenGL games or with software renderer).

I am not a great gamer … I prefer programming. And you will notice that reading this article. Testing a game, I also had a look at technical aspects of the project: language, code style, documentation …

Most of the games have been tested on my x86_64 Debian to validate and give a base (CPU: Intel i5-6200U @ 2.8 GHz and 16 GB of RAM, GPU: Intel Skylake GT2, HD Graphics 520).

This is a kind of training before trying to test or port more complex projects.

The good old Amiga games

Back to the origin. Most of them are based on Amiga games. Maybe because I am still an Amiga user and developer.

ZGloom

https://github.com/Swizpig/ZGloom

I forgot it even if it is a reimplementation of the Amiga game Gloom. I tried it after reading this article on talospace blog. Then I even provided some patches :-D I played several levels and noticed no crash or particular bugs. However, enabling compiler sanitizers (I like to do that), some issues related to resources and threads were found. Also note that, surprisingly, compilation by default has no optimization option! To display FPS, that come with the map, just press TAB during the game. This is not documented. I chose to compile with the optimization option -O2 and got 960 FPS on the PC and more than 1100 FPS on Talos 2 … I would have expected a bigger difference. Note that using clang, it increases to 1500 FPS.

SDLPop

https://github.com/NagyD/SDLPoP

This is a reimplementation (in C) of the hit by Jordan Mechner, Prince of Persia, obtained with the disassembly of the original DOS version. It provides many features explained in a clear and complete readme, with all options and game controls, and information to build the game. Just go into src directory and run make all. The final executable prince is created in the root project directory. Now it appears be quite simple in terms of graphics but the character animation still reminds how it was acclaimed when the game went out.

It worked on Amiga but I’ve seen an issue was reported about endianness on big-endian targets

REminiscence

https://github.com/chermenin/REminiscence

Again, a project that implements an engine (using C++17), here for the Flashback game. It requires data from the original game, the Amiga version or the one from GOG. It produces en executable named fb … but why? That’s always disturbing to me who likes explicit naming. Maybe to prevent copyright violation?

I will have to test with data from the Amiga. But right now, I used the GOG version, first installed on Windows and copied. Once the GOG version is installed, copy the directory FlashBack_Data/StreamAssets/data where the executable is and rename it DATA.

The introduction sequence can’t be skipped!

It was reported that musics could be got there but I had no success with them.

Hurrican

https://github.com/HurricanGame/Hurrican

Another hit from the Amiga! I’m not good at all at this kind of game so I give up very quickly. But it is free and comes with its data. And I remembered that I played an older implementation of this project on AmigaOS4 thanks to the port by my friend Huno. It also introduces OpenGL in our list of games, with a good range of OpenGL versions, from GL1 to GL3, including ES variants.

There are 2 readme files and it seems there are also to ways to compile it, with cmake or directly with make but this last one does not work. So just follow the description of the standard build provided in README.md

git clone --recurse-submodules https://github.com/HurricanGame/Hurrican.git
cd Hurrican/Hurrican
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make

Then copy the hurrican executable in the Hurrican directory so that it can access the ./lang directory (or it will fail to execute). With OpenGL1, the game is only display on a small part in the center of the fullscreen. OpenGL2 (default mode) and OpenGL3 worked on my Talos 2. The game is great and beautiful, with nice effects.

ScummVM

This huge project proposes to play old adventure games, reimplementing their engines. We don’t know when it will stop growing but at least, it allows to play numerous good old adventure games. Not only Amiga ones but I started to played adventure games on Amiga: Monkey Island, Gobliiins, Simon The Sorcerer, The Legend of Kyrandia …

For the few 3D games supported, it has 3 GL backends: OpenGL, OpenGL with shaders, software (TinyGL).

Building ScummVM is an example of stafisfaction about knowing I own a Power9 based machine. So faast compared to other machines I use to build it.

I tried several old games and they work so far. Then I also tried 3D games because they are more prone to have problems but they also work well: Escape From Monkey Island, Grim Fandango and The Latest Journey. I didn’t checked Myst 3 but it should work too.

I see nothing more to add. I would be interested to know if some games have issues on Power9 because I already contributed small patches to this active project that I want to support.

First person shooters, the PC area

Let’s enter into a new dimension … the new game style that contributed to kill the Amiga.

Doom

As it was ported to Amiga few days after the source code was released (I ran it on my A1200 with a 68030 accelerator), it is truly a PC game.

Quickly tried with DosBox on the PC but may be a topic of another article dedicated to emulators (170 FPS, with the formula (x/y)*35). If you want to play Doom more conveniently, there are several engines and some of them come with your distribution:

  • Chocolate Doom, originally based on the Doom sources, it aims to accurately reproduce the original DOS version of Doom and other games based on the Doom engine in a form that can be run on modern computers

  • Crispy Doom is a friendly fork of Chocolate Doom that provides many enhancements (graphically but not only)

  • PrBoom+ that is itself a fork of PrBoom, that was a Doom port ; it provides improvements (OpenGL rendering, etc.) and also allows to play Doom2 mods.

They come with free data (freedom) but I quickly switched to the original WAD file and ran crispy-doom -iwad ~/Games/DOS/DOOMS/DOOM1.WAD -timedemo DEMO1.

On the PC, both engines give around 350 FPS. prboom-plus gives 620 FPS. On the Talos 2, I get:

  • Chocolate Doom: between 1000 and 1500 FPS depending on the demo
  • Crispy Doom: between 560 and 630 FPS
  • PrBoom+ : between 630 and 730 FPS

Quake / Darkplaces

https://github.com/xonotic/darkplaces

This is a Quake1 engine written in C and SDL, that supports 2 OpenGL versions: OpenGL 3.2 or OpenGLES 2.0. It is also available from Debian repository. No problem with this game.

Running timedemo timedemo1 in the game console, I get:

  • on PC: FPS: 340 FPS
  • on Talos 2: 500 FPS

Doom 64

https://github.com/svkaiser/Doom64EX

Doom 64 was published on Nintendo 64 and it was rather well rated.

Get and build the project sources:

git clone https://github.com/svkaiser/Doom64EX.git
cd Doom64EX/
git submodule update --init --recursive
mkdir build 
cd build
cmake ..
make -j4

Then, for the game data, you need the z64 rom file, to give to doom64ex -wadgen. I got a segmentation fault … at the end:

Writing IWAD File...

Successfully created /home/mathias/.local/share/doom64ex/doom64.wad
Writing Soundfont File...

Successfully created /home/mathias/.local/share/doom64ex/doomsnd.sf2
Segmentation fault

Good enough to get a working set of generated files.

Then run ./doom64ex and enjoy! Or almost, on Talos 2, with the key to go back, he runs in front of him!

sm64

https://github.com/sm64-port/sm64-port

After Doom on Nintendo 64, let’s continue with another hit from the console before finishing with a bonus game.

This engine will allow you run Super Mario 64 on Linux using the original ROM that needs to be computed to generate the game data. I chose to try the project sm64-port/sm64-port that was forked from n64decomp/sm64. It has been forked itself by sm64pc/sm64ex …

The project is weel organized with minimal configs for clang-tidy and clang-format.

The README explains clearly what is needed to build the game and the procedure is simple: copy the z64 baserom file into the project directory (with the name baserom.eu.z64 for the european version) and build with make specifying the language: make VERSION=eu. On Talos 2, I had to remove the option -march=native because the compiler said it was not known, you can also replace it by -mcpu=power9 like saif in this forum topic

The last commit was pushed 2 years ago …

Note that the game keeps the keyboard configuration and the fullscreen option (and only that) in sm64config.txt. To run the game, write the command ./build/eu_pc/sm64.eu.

I tried to connect a gamepad (Logitech WingMan) and the game became totally jerky (until I unplugged it), on both PC and Talos 2, with debug messages:

Dropping frame
Frame too late by 18 vsyncs
Reseting timer
Frame too late by 5 vsyncs
Dropping frame

StarWars: OpenJK

https://github.com/JACoders/OpenJK

This is an implementation of the engine that will allow you to play Jedi Academy and Jedi Outcast. I only have the former, bought on GOG and installed on Windows to move data from it.

Numerous warnings with the default build on PC. The code is both (and more or less equally) in C and C++. The project compiles with no problem and it was supposed to be portable because it was already ported on newgen Amiga systems years ago.

I advise to follow what is written in the compilation guide, that is to say give a prefix (with cmake -DCMAKE_INSTALL_PREFIX=<path> ..) to point of the GameData directory path … except that instead of putting files there, it did that in a JediAcademy subdirectory:

JediAcademy/jampgamex86_64.so
JediAcademy/openjk_sp.x86_64
JediAcademy/openjk.x86_64
JediAcademy/openjkded.x86_64
JediAcademy/rdsp-vanilla_x86_64.so
JediAcademy/rd-vanilla_x86_64.so
JediAcademy/base/cgamex86_64.so
JediAcademy/base/uix86_64.so
JediAcademy/OpenJK/cgamex86_64.so
JediAcademy/OpenJK/jagamex86_64.so
JediAcademy/OpenJK/jampgamex86_64.so
JediAcademy/OpenJK/uix86_64.so

So the content of JediAcademy directory has to be other one level up. Or on the other way, for the -DCMAKE_INSTALL_PREFIX cmake option value, choose the path where you want to create the game directory JediAcademy and then copy there the base directory from the original game.

Note that on Talos 2, for all files, x86_64 is replaced by ppc64le in their names.

What is also strange is that the documentation asks to rename executable files like openjk_sp.x86_64 (_sp for single player) in jasp but the install make target does not do that!

Even if graphics look a bit old (but the game is), it is easy to control and the atmosphere is great (the music obviously contributes to that).

Conclusion

I finished this first initiatory trip with a game that I never played before and I was pleased to start playing it.

All tested games build and run quite well, what was not completely surprising. They are rather good old games, well supported and ported to several targets.

Some games are playable with DosBox, ScummVM or Wine. I didn’t tested the later because it won’t work directly on Power9, that would require the use of Hangover

I plan to update this article with news that may happen. I also have ideas for other games or engines, to address in future articles.