Seegras Logbook

For some time I noticed some serious problems with Minecraft: It was a resource-hog, slow and depending on the modpack, on the lower end of fps, that’s like 15, on my old RTX2060 and on my newer RX7800XT. Even with the rendering distance capped to 16 or 12 to make it playable.

A few weeks ago it also started braking steam. Like, making it impossible to run Steam at the same time as Minecraft without Steam becoming a slideshow. Something was off.

I had the slight suspicion games using Vulkan did behave better, and weren’t causing the issue, so I wanted to try it with Minecraft as well. There is VulkanMod for Minecraft, and there are even a few modpacks like Vulkan Optimized and Vulkan32. I tried both of these, and ended up using Vulkan Optimized as a base for adding a few other mods, like Journeymap, Tech Reborn or AE2. No Create though, as this is incompatible with VulkanMod. And there it was. 60fps with a rendering distance of 32. While running Steam at full steam, pun intended, at the same time.

I was also now clear that my OpenGL was horribly broken, and I couldn’t find any hint of “how”, as at the same time the performance under Vulkan was marvellous. And how could I run any other Minecraft modpack, not just those using version 1.20.1 and 1.21.1 on fabric, without Create or Hephaestos mods, under Vulkan?

Turns out, there is a translation layer available, called Zink which is part of Mesa. Alright, let’s try:

$ MESA_LOADER_DRIVER_OVERRIDE=zink  glxinfo 
name of display: :0
DRI3 not available

That wasn’t quite encouraging, especially since:

$ xdpyinfo | grep DRI3  
    DRI3

It’s configured and working, of course.

Turns out this is a bug or regression on X11 (Seems to work on Wayland), and if you also give it LIBGL_KOPPER_DRI2=1, it works:

$ MESA_LOADER_DRIVER_OVERRIDE=zink LIBGL_KOPPER_DRI2=1  glxinfo | grep "OpenGL renderer" 
OpenGL renderer string: zink Vulkan 1.3(AMD Radeon RX 7800 XT (RADV NAVI32) (MESA_RADV))

And oh, boy, it works. I put these two variables into the env of the PrismLauncher settings of All The Fabric 5 and this is the result:

And, what you can’t see here, is that the render distance is at max, which happens to be 62(!) with All The Fabric 5. It’s glorious.

I’ll now go and test this out with some modpacks that had gotten unplayably slow before: Project Architect 2, ATM10, AoF7…

This is an older design of a silent dropper item elevator. It’s not initially by me, but it could be that I modified it. Still, I think it’s one of the best designs, because:

• silent
• items can be inserted at any level
• Either has a footprint of 2×9 or can be arranged in an L-shape.

It does have a problem, and that is that sometimes the dropper(s) that get fed with items can get filled up and stuck.

Anyway, here’s the schematic:

• ItemElevators.schematic

The fact is, beginning with Unity 4, just about all games run on Linux as well. Unless they’re buggy, explicitly check for the platform or use plugins not available on Linux.

I found this Howto in Russian on how to fix an incomplete Unity runtime so it runs on Linux, could reproduce the effects, and so here’s the writeup in English on how it’s done.

This is how the minimal Unity-runtime for Linux looks:

├── player_Data
│   ├── Mono
│   │   ├── etc
│   │   ├── x86
│   │   │   └── libmono.so
│   │   └── x86_64
│   │   . └── libmono.so
│   ├── Plugins
│   │   ├── x86
│   │   │   └── ScreenSelector.so
│   │   └── x86_64
│   │   . └── ScreenSelector.so
├── player.x86
└── player.x86_64

The word “player” is replaced by the actual name of the game. Note that these files are the same for every game that uses the same Unity version.

Find Version

Within the existing player_Data directory, you’ll find a file named mainData. This contains the Unity version, and you will need to add the correct version of the Linux runtime, so you’ll first need to extract that version:

head mainData | strings | head -1

if this doesn’t get you the version, the game uses a very old Unity, which has the version information towards the end of the file, but for which no Linux support exists anyway.

Get runtime

Now you need to find the correct runtime. You can check mainData of Unity games supported on Linux, and copy the respective files over. Something like this:

find . -name mainData -print0 | xargs --null grep --with-filename "4.5.5f1"

of course, some people already have collections of runtimes, like this: https://cloud.mail.ru/public/6SdA/BBgyg3kjy

if the runtime you need isn’t available on your system, you can extract it from the official releases with 7z. The not-so-nice part is, every release comes as a huge .exe with a size of 1GB or more. And there are a lot of releases:

• http://unity3d.com/get-unity/download/archive
• http://unity3d.com/unity/beta/archive
• http://unity3d.com/unity/qa/patch-releases

The useful files within the extracted release are below linuxstandalonesupport/Variations/ you’ll need the files libmono.so, ScreenSelector.so and LinuxPlayer per 32bit/64bit environment.

Find Plugins

After you have all the files from the runtime in the right places, and have renamed them accordingly, you might have noticed, that there are some dll-files in the Plugins directory. You’ll need to add Linux versions for most of these.

Luckily, there are some very well known plugins, they are used all over the place, and some come with the source as well:

• CSteamworks.dll: these are from “Steamworks.NET”, and they’re available from https://github.com/rlabrecque/Steamworks.NET The Linux version is called libCSteamworks.so, as usual, put the right versions into the directories x86/x86_64 below Plugins.
• SteamworksNative.dll (and SteamworksManaged.dll): They’re from “Ludosity’s Steamworks Wrapper”, https://github.com/reallyjoel/Ludosity-s-Steamworks-Wrapper and 32bit only.
• XInputInterface.dll: apparently comes from https://github.com/speps/XInputDotNet
• steam_api.dll: Sometimes the developer has implemented the access to the Steam API by itself, in that case, you’ll only need libsteam_api.so
• FMODUnity.dll: This comes from http://www.squaretangle.com/FMODUnity.html. Source available.
• fmod.dll is http://www.fmod.org/download/ There is no source, but precompiled plugins fo 32bit and 64bit. Difficult to find the one you need.
• AkSoundEngine.dll is part of https://www.audiokinetic.com/ There’s a lot of versions of precompiled plugins available, but its difficult to find out which one you might need
• UWKPlugin.dll comes from https://github.com/uWebKit/uWebKit No compiled plugins for Linux are available, but the source is.

The .unitypackage-files can be extracted with tar xvaf, but they consist of a salad of directories. file */asset can tell you what is what, the corresponding filenames are in */pathname.

Fix .unitypackage files

The .unitypackage-files a lot of plugins are delivered in can be extracted with tar xvaf, but they consist of a salad of directories. file */asset can tell you what is what, the corresponding filenames are in */pathname.

This here makes a directory tree from the pathname files:
for i in *; do mkdir -p `dirname $(head -1 $i/pathname)` ; done
And this here moves the assets into it and renames them:
for i in *; do mv $i/asset $(head -1 $i/pathname) ; done

Cosmetics

You now can do some cosmetics. Fix the ScreenSelector background:
convert ScreenSelector.bmp ScreenSelector.png
And the Icon:
wrestool -x --type=14 Game.exe | convert ico:-[6] Game_Data/Resources/UnityPlayer.png

Testing

Start the game with a logfile parameter to get warnings about missing libraries and other problems:
player.x86 -logfile out.log
As mentioned before, “player” needs to be replaced with the actual name of the game, and the binaries named accordingly.

Results

I basically went over my whole collection of not-yet-available for Linux Unity games I have on steam. I annotated the runtime version and troubles they might have.

Working Games

• 1954 Alcatraz (4.0.1f2)
• Coldfire Keep (4.3.4f1)
• Dead Bits (4.1.3f3)
• DeadEffect (4.6.0f3)
• Depths of Fear Knossos (4.6.1f1)
• Final Dusk (4.6.1f1)
• Gravi (4.5.5f1)
• Huntsman The Orphanage (4.2.2f1 needs LD_LIBRARY_PATH for libsteam.api.so)
• Last Inua (4.2.2f1)
• Lifeless Planet (4.6.7f1)
• Once Bitten, Twice Dead! (4.6.1f1)
• Overcast – Walden and the Werewolf (4.1.3f3)
• PaperSorcerer (4.1.5f1)
• Red Lake (4.3.4f1)
• StickItToTheMan (4.3.2f1)
• The Dead Linger (4.6.0b20 Some black textures)
• The Hat Man Shadow Ward (4.3.4f1)
• Train Town (4.5.0f6)
• Urja (4.5.4f1)
• YearWalk (4.5.5f1)

Games Having Trouble

Most of these run, but are also unplayable. Some are playable, but not enjoyable because of missing textures or missing sound.

• Air Buccaneer (4.2.0f4 can’t connect to network?)
• BridgeProject (4.5.3f3 x86 crashes, x86_64 does not accept input)
• Dead Island Epidemic (4.6.1f1 libs missing, among them http://www.squaretangle.com/FMODUnity.html)
• Deus Ex The Fall (4.3.4f1 needs LD_LIBRARY_PATH for libsteam.api.so; Wwise sound engine wrong version, playable)
• Empyrion – Galactic Survival (5.2.3f1 hanging?)
• Joe Dever’s Lone Wolf (4.5.4f1 self-written plugins)
• Melissa K and the Heart of Gold (4.5.3f3 hanging?)
• Might & Magic X – Legacy (4.2.2f1 hanging?)
• realMyst Masterpiece Edition (4.5.5p4 broken menu, needs uWebKit)
• Slender – The Arrival (4.5.1p3 Texture problems, playable)

Shader Problems

The following games all have shader problems. Which basically means you would need to decompile Managed/Assembly-CSharp.dll and replace the shaders to use there, or to extract the .asset-files and create them anew. Some of these games are playable as they are, but certain things will show up pink.

• Astral Terra (5.1.2f1 Shader Problems)
• Avenging Angel (5.1.0f3 Shader problems)
• Godus Wars (5.2.2f1 Shader problems)
• GunsNZombies (5.2.2f1 Shader problems, crashes)
• Reign Of Kings (5.1.1p2 Shader problems, needs LD_LIBRARY_PATH for libsteam.api.so)
• StarForge (4.5.5f1 Shader problems, needs LD_LIBRARY_PATH for libsteam.api.so)
• The Forest (5.1.3p3 Shader problems)
• The Tower (5.1.2f1 Shader problems)
• Treeker – The Lost Glasses (5.1.2f1 Shader problems, playable)

Broken on Purpose

• BlockStory (4.6.8f1 Steam-Error: “Not available on your current platform”)
• Magnetic Cage Closed (4.3.4f1 Steam-Error: “Not available on your current platform”)
• Republique (5.2.2p4 Steam-Error: “Not available on your current platform”)
• Stranded Deep (5.2.2f1 Steam-Error: “Not available on your current platform”)
• Subnautica (5.2.3f1 Steam-Error: “Not available on your current platform”)

Unsupported

• Blackguards (3.5.6f4)
• Cognition (3.5.7f6)
• Commander Jack (3.5.7f6)
• creavures (3.4.2f2)
• Dementium 2 (3.5.7f6)
• Dungeonland (3.5.6f4)
• DysanTheShapeshifter (3.4.2f2)
• Seamulator 2009 (2.1.0f5)
• ShadO (3.5.2f2)
• Shelter (3.5.7f6)
• Theatre Of The Absurd (3.5.0f5)
• Them – The Summoning (3.4.2f2)
• The Witcher Enhanced Edition (3.5.2f2)
• Truffle Saga (3.5.7f6)
• UnearthedEpisode1 (3.5.7b1)

Abstract

Most action-games, even the ones set in fantasy-environments
concentrate on ranged weapons, or do have only a very limited support for
non-ranged weapons, limited moves, thrusts and slashes. More so if they’re
first person perspective. Most RPGs on the other hand just display some
pre-defined moves, according to whether the agent hits or not, which
in turn is mostly defined by the stats of the agent and some dice. This
essay will present you with an action-oriented alternative combat-system for
first-person perspective-games

Premises

Real medieval hand-to-hand-combat is completely different than what
ever is depicted in movies or computer-games. The aim is to incorporate
these realities into a game-engine.

• Armour is as light as possible, designed to be as much as
  protective as possible against specific threats and weapons. Chain mail
  for instance was designed against slashes, but not against thrusts.
  Armour is also nearly impenetrable against those specific threats. You
  cannot, for instance, pierce late medieval plate armour with a bow or
  light crossbow.
• Arms are as light as possible as well, and change with time
  to accomplish a very specific goal, to inflict damage to a very specific
  target. A flail is only useful against opponents wielding shields, but
  in that case very much so, because you can hit them behind their shields.
  A lucerne hammer won’t inflict more damage than a sword, but is able to
  penetrate plate armour, thus only appeared with the appearance of plate
  armour.
• Style arms and armour dictate how you are able to fight. You
  can’t just bang on plate with your sword and hope to break it some time.
  You could try to thrust into weak spots instead. There is no “parry” or
  hard block with weapons, instead real medieval combat focuses on
  counterattacks or avoidance.
• Damage is primarily done to the opponent. The chance of
  damaging the armor in a way that it isn’t protective anymore is
  about null. But the armour will afflict your damage if not cancel
  it altogether. As part of a simple damage-model, fatigue could be
  used, thus making wounded agents slower. In extreme cases, limbs
  could be severed, limiting the physical possibilities of the agent
  further.

[If you’re objecting now, you’re probably wrong. If you’re not
practicing medieval armed combat and regularly wear armor, you most
certainly are]

Needs

Here we look at the technical needs to incorporate this into a game.

• 3D-Engine Most basic. Mort probably any good one will do,
  focus on large seneries is best, as well it should be able to handle
  a great many objects with different textures (or shaders to accomodate
  for the lack of textures).
• physics-engine is probably the most important part. Not only
  it has to apply phisics to normal objects, but also to players, and most
  importantly to weapons as well. It also needs the capability to define
  objects which can damage other objects, namely cut and pierce according
  to with which force/speed it is applied.

How it works

For ranged weapons, its simple. You target preferably a weak spot of
your opponent, and on a hit, your arrow or whatever will maybe hit some
armour, pierce it or not, and inflict a wound.

For hand-to-hand combat, you use your mouse. left button slahes, right
button thrusts; and it does it when you release the button, thus making
it possible to direct the weapon with movements of the mouse while holding
down the button. Its possible in that way, not only to direct your weapon
exactly to where you want to, like a thrust into the eyes, but also to
counter a thrust with a slash.

The weapons will of course have different mass and impact, thus making
it possible to pierce a plate armour with a lucerne hammer, or to thrust
through chain-mail with a one-and-a-half-handed sowrd.

Fatigue will be essential, making people wearing heavy armour or other
load tired and slow down very fast; opening the possibility for lightly armed
fighters to win nevertheless, even when one has to hit one small weak
spot in the enemys armour.

A further idea for more realism is that, poeple having mass, you can
define that some armour has sizes. Maybe three sizes for chain mail,
but very fine-grained sizes for plate armour. This way, most plate
armour found would be useless and could only be sold. This also balances
the inflation of armour.

Examples

To slay a wolf, you just target the wolf, go near enough and thrust or
slash anywhere. You could target the head or try to sever one of its legs.
The wolf isn’t armoured, so it doesn’t matter too much where you hit.

To fight a barbarian which wears a chain mail gets a bit more
difficult. Will you try a thrust to his head, or maybe a slash to his legs,
where he is unarmoured? Or maybe just thrust anywhere, in the hope your
long sword is able to pierce his armour?

The knight in plate armour is a very dangerous opponent. You could thrust
to his axles, or maybe run around him in order to make him tired (and then
thrust), run away, and so on.

Peter Keel,