Tonight's game on OpenPOWER: System Shock Enhanced Edition
Shockolate requires CMake and SDL2, and FluidSynth is strongly advised. Don't let Shockolate build with its bundled versions: edit CMakeLists.txt and change all "BUNDLED" libraries to "ON" (don't forget the quote marks). Once set, building should work out of the box (tested on Fedora 34):
mkdir build
cd build
cmake ..
make -j24 # or as you like
cd ..
ln -s build/systemshock systemshock
(The last command is to make running the binary a little more convenient.)
Now we need to provide the resources. For FluidSynth, you'll need a soundfont (I used the default that comes with Fedora's package). If you have the DOS/Windows CD-ROM, insert it now. We will assume it is mounted at /run/media/censored/EA.
mkdir res
cd res
ln -s /usr/share/soundfonts/default.sf2 default.sf2
cp -R /run/media/censored/EA/hd/data .
cp -R /run/media/censored/EA/hd/sound .
chmod -R +w . # if copying from CD makes things read only
cd data
rm -f intro.res
rm -f objprop.dat
cp /run/media/censored/EA/cdrom/data/* .
cd ../..
Then start the game with ./systemshock. The resolutions and choice of renderer (software or OpenGL) are set from the in-gameplay menu (press ESC). Shockolate also implements WASD motion (as well as the classic arrow keys) and F to toggle mouselook. Note that OpenGL is somewhat darker than software mode. It's not clear if this is actually a bug.
Playing System Shock Enhanced Edition in Shockolate is just a more convenient way to get the DOS assets since Shockolate just uses those and not any of the patches (more about this in a second); gameplay and features are the same. Also, GoG only distributes it as a Windows installer and the file structure is a bit different. Use innoextract to break the installer EXE apart into a separate directory and delete everything but sshock.kpf, which is a cloaked ZIP archive containing the game assets. In your Shockolate source directory (note that this also creates res/, so if you did the steps above delete it first),
mkdir ssee
cd ssee
unzip /path/to/sshock.kpf
cd ..
mkdir res
mv ssee/res/pc/hd/data res
cp ssee/res/pc/cdrom/data/* res/data/
mv ssee/res/pc/hd/sound res
rm -rf ssee # if you want
ln -s /usr/share/soundfonts/default.sf2 res/default.sf2
Then start the game with ./systemshock.
Oddly, although Shockolate was based on the (IMHO) superior Power Mac release, it doesn't seem to properly support its higher-resolution assets (SSEE does and includes a converted set, but the source for that — unlike Strife — isn't currently available). I actually own this version also. One rather unique reason to own it is because the cutscenes and audio files are all playable in QuickTime, so if you don't feel like slogging through the entire game you can just listen to the audio logs or go straight to the ending using a Mac emulator. However, you need to do a little song and dance to mount the HFS volume on Linux (as root):
losetup /dev/loop0 /dev/sr0 # or where your drive is
partx -av /dev/loop0
This will respond with something like
partition: none, disk: /dev/loop0, lower: 0, upper: 0
/dev/loop0: partition table type 'mac' detected
range recount: max partno=2, lower=0, upper=0
/dev/loop0: partition #1 added
/dev/loop0: partition #2 added
and you should see it mount in your desktop environment (note that many applications won't understand the resource fork). Do losetup -D before ejecting the physical disc. As a parenthetical note, since SSEE is presumably derived from the GPL-released Mac source code, you would think it, too, would be GPL. But I'm uncertain of the exact history there.
Salt the fries.
Just an addendum,
ReplyDeleteThe losetup stuff in here is great for sane distributions. Ubuntu stopped being sane (for loopback) with their SNAP packages, all of which use loopback to function, and so not only is loop0 not an option, but numerous others are also in use. The way I normally script around this:
# This will find an open loop device and use it
losetup -f /dev/sr0
# Note the loopback that was chosen
export CDLOOP=$(losetup | grep /dev/sr0 | awk '{print $1}')
partx -av ${CDLOOP}
# Put all the toys away
umount ${CDLOOP}*
# Detach just the one loopback
losetup -d ${CDLOOP}
Note that all of these workarounds are unnecessary if your distro hasn't hijacked the loopback mechanism.
Weird. Thanks for the tip. Why did they do that, do you think?
DeleteSNAP is a parallel package system. It allows them to bring in a bunch of newer software in a way that doesn't affect pre-existing APT installed DEB packages. The pathing is just put in front so the SNAPs get used first. I guess they just figured that nobody was really using loopback, and they might as well take advantage of it. My work laptop (work standardized on x64 Dell 13" XPS laptops and thunderbolt/USB-C docking stations with VMWare Workstation under Windows and Ubuntu 20.04 x64 on that . . . ick) typically loads new loopbacks as /dev/loop14 because commonly installed SNAPs are already eating up loop0 through loop13.
Delete