Hi, This is a port libCSteamworks, a commonly used library with games like the ones we can run with games/fna primarily. It is part of my work to have better compatibility for more of those games.
For explanation, here is a schematic of common use of Steam libraries
in how they are distributed with Linux as the usual target platform:
(FNA/MonoGame) Game
|
Steamworks.NET.dll
|
libCSteamworks.so
|
libsteam_api.so
Currently, a stubbed Steamworks.NET.dll from games/steamworks-nosteam
cuts these calls short, but there are issues with different versions
and missing functionality that cause problems.
Since the import of games/goldberg_emulator, we have an implementation
of libsteam_api.so that can handle most API calls just fine, so the
need for the large stub library is gone.
Future versions of fnaify (and planned successor IndieRunner) are
therefore designed to leave the bundled Steamworks.NET.dll in place, and
rely on libCSteamworks.so and libsteam_api.so in the ld.so path for
compatibility where needed.
The code is from MIT-licensed GitHub repository. This is missing some
API used in some games (likely a local addition done for the games) and
the patches for src/steam_api.cpp contain missing API - some as calls to
libsteam_api functions, others for now as stubs.
Given the above layers, in order to test this port one needs a game that
uses these dependencies, and then run it without removing
Steamworks.NET.dll while having this port installed. Current checkout of
fnaify [1] can be used to test - it doesn't remove Steamworks.NET.dll
anymore (use the bundled fnaify.dllmap.config!):
$ cd /path/to/game/directory
$ /path/to/fnaify -c /path/to/fnaify.dllmap.config
There are many games that use these layers. You can try this out for
example with the game Salt & Sanctuary (on Steam, e.g. via steamctl).
The FNA games that use this are pretty much all proprietary. Maybe just
look if the port makes sense for an ok without runtime testing...
[1] https://github.com/rfht/fnaify
libcsteamworks.tgz
Description: application/tar-gz
