Il s'agit d'un émulateur à vapeur qui émule les fonctionnalités en ligne Steam sur un LAN. Il fonctionne à la fois sur Linux et Windows. Pour un ReadMe sur la façon de l'utiliser, voir: la version Readme
Vous remplacez l'API à vapeur .dll ou .so par la mienne (pour les étapes complètes, consultez la version ReadMe), puis vous pouvez mettre de la vapeur dans la poubelle et jouer à vos jeux en solo sur LAN sans vapeur (en supposant que les jeux n'ont pas de DRM et utilisez de la vapeur pour en ligne).
Si vous êtes un jeu en développement et que vous avez fait l'erreur de dépendre trop de l'API Steam et que vous souhaitez publier la version de votre jeu sans elle et ne pas vouloir réécrire votre jeu, c'est pour vous. Il s'agit de LGPLV3 + sous licence, donc le seul code source que vous devez publier est le code source de cet émulateur (et seulement si vous y apportez une modification).
Remplacez le Steam_API (64) .dll (libsteam_api.so sur Linux) du jeu avec le mien. Pour Linux, assurez-vous que si l'API d'origine est 32 bits, vous utilisez une version 32 bits et si elle est 64 bits, vous utilisez une version 64 bits.
Mettez un fichier Steam_appid.txt qui contient l'apprid du jeu juste à côté s'il n'y en a pas déjà un.
Si votre jeu a un Steam_API original (64) .dll ou libsteam_api.so plus âgé que mai 2016 (sur Windows: Properties-> Signatures numériques-> horodatage), vous devrez peut-être ajouter un Steam_interfaces.txt à côté de ma bibliothèque d'émulation si le jeu ne fonctionne pas. Il y a un script Linux pour le générer dans le dossier Scripts de ce dépôt.
Pour plus d'informations, voir: la version Readme
Vous pouvez télécharger les derniers builds Git pour Linux et Windows sur le site Web des pages GitLab et les sorties stables dans la section de version de ce repo.
L'une des raisons pour lesquelles j'ai fait ce code open source est que je veux des contributions. À moins que votre code ne soit lié aux éléments expérimentaux, il doit fonctionner sur Linux et Windows. Avoir un comportement précis est plus important que de faire fonctionner les jeux. Avoir un comportement inexact peut réparer un jeu, mais il en cassera les autres.
#Goldberg: matrix.org
Dépendances: Protobuf-Lite
Installez Protobuf-Lite (le package de développement) et Protoc (ou Protobuf-Compiler ou quel que soit son appel dans votre distribution) à l'aide de votre gestionnaire de packages.
Alors faites: make
Et il construira la version de version (n'oubliez pas d'ajouter quelque chose comme -j8 si votre ordinateur n'est pas une merde et que vous voulez qu'il construise à une vitesse décente).
Pour construire la construction de débogage: make debug
Mon Makefile est nul, vous devrez peut-être faire: make clean si vous voulez construire la construction de débogage après la construction de la version de libération ou le contraire.
Pour ma version Build, je le construis sur SteamOS à l'aide du script build_steamos.sh . Pour qu'il fonctionne, vous avez besoin d'une version x86 de Protobuf installée sur: ../protobuf/prefix_x86/ et une version x64 installée sur: ../protobuf/prefix/
La première chose que vous devez faire est d'installer Git pour Windows. Git pour Windows
Installez ensuite Visual Studio Build Tools: Microsoft Build Tools (assurez-vous d'installer les outils de construction C ++. Sélectionnez simplement C++ build tools dans l'installateur et appuyez sur Installer.)
Créez un nouveau dossier quelque part sur votre ordinateur.
Accédez à ce dossier, puis cliquez avec le bouton droit, ouvrez l'invite de commande GIT. (Clic droit dans le dossier-> git bash ici)
Exécutez les commandes:
git clone https://github.com/Microsoft/vcpkg
cd vcpkg
./bootstrap-vcpkg.bat
./vcpkg install protobuf --triplet x86-windows-static
./vcpkg install protobuf --triplet x64-windows-static
cd ..
git clone https://gitlab.com/Mr_Goldberg/goldberg_emulator.git
cd goldberg_emulator
Cela devrait construire et installer toutes les dépendances et cloner le repo. Certaines commandes comme l'installation Bootstrap-VCPKG.BAT et VCPKG peuvent prendre un certain temps.
Ensuite, pour construire la version expérimentale de débogage exécutée: build_win_debug_experimental.bat
Pour construire la version de version exécutée: build_win_release.bat
Si pour une raison quelconque, vous souhaitez définir les répertoires Protobuf sur quelque chose de différent, vous pouvez modifier: build_set_protobuf_directories.bat
Allez dans le dossier Goldberg_Emulator, puis cliquez avec le bouton droit d'ouvrir l'invite de commande GIT. (Clic droit dans le dossier-> git bash ici)
Exécutez la commande:
git pull
Les cibles suivantes sont incluses avec la configuration CMake pour ce projet:
Bien que toutes les cibles soient incluses pour toutes les plates-formes / variantes de construction, il y a quelques points à noter:
La configuration CMake de ce projet comprend également l'installation de la prise en charge. L'installation du projet se traduira par un ensemble plus propre de fichiers de sortie (que les fichiers de construction bruts) et copiera les réadmes, outils et autres fichiers de support appropriés du répertoire des projets. Cette installation est structurée comme suivi:
+ install-folder
|- (lib)steam_api(64).[dll|so]
|- (lib)steamclient(64).[dll|so]
|- (lib)steamnetworkingsockets(64).[dll|so]
|- Readme_release.txt
|- Readme_debug.txt // Only for debug build's
|- Readme_experimental.txt // Only for experimental build's
|- steam_appid.EDIT_AND_RENAME.txt
|- steam_interfaces.EXAMPLE.txt
|+ lobby_connect
|- lobby_connect(64)(.exe)
|- Readme_lobby_connect.txt
|+ tools
|- generate_interfaces(64)(.exe)
|- find_interfaces.ps1
|- find_interfaces.sh
|- Readme_generate_interfaces.txt
|+ steam_settings.EXAMPLE
|- ... // steam_settings example files
Notez que si aucun CMAKE_INSTALL_PREFIX Define est défini pour la génération CMake (ou une autre méthode de définition d'un répertoire d'installation personnalisé est utilisée) Les répertoires d'installation spécifiques au système d'exploitation par défaut seront utilisés, ce sont:
c:/Program Files/${PROJECT_NAME}/usr/localVeuillez consulter la section «Modifier le répertoire d'installation» de cette lecture pour plus d'informations.
+ some-top-level-folder
|- vcpkg
|- goldberg_emulator
bootstrap-vcpkg.bat à partir du dossier d'installationvcpkg install protobuf --triplet x64-windows-static && vcpkg install protobuf --triplet x86-windows-staticCe repo comprend un fichier cmakesettings.json qui contient les configurations pour les plates-formes cibles et les variantes de construction suivantes:
Ces configurations doivent être chargées automatiquement lors de l'ouverture du dossier Goldberg_Emulator dans Visual Studio. Pour plus d'informations sur la façon d'utiliser ces configurations (et le projet CMake dans Visual Studio en général), veuillez consulter: https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019
Visual Studio Builds pour Windows et WSL Les configurations de seront publiées au dossier suivant: ${projectDir}out${workspaceHash}build<configuration name>
Vous pouvez également choisir d'installer directement à partir de Visual Studio. Visual Studio Installations pour les configurations de Windows sera publiée au dossier suivant: ${projectDir}outinstall<configuration name>
Lors de l'utilisation de ces configurations, il y a quelques points à noter:
call "<Path to Microsoft Visual Studio Installation Folder>2019VCAuxiliaryBuildvcvars64.bat"
cd "<build folder>"
cmake "<goldberg_emulator src folder>" -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="<vcpkg installation folder>scriptsbuildsystemsvcpkg.cmake"
Notez que si vous utilisez les outils de construction pour Visual Studio 2019, le chemin vers le VCVARS64.bat est légèrement différent:
call "<Path to Build Tools for Visual Studio 2019 Installation Folder>2019BuildToolsVCAuxiliaryBuildvcvars64.bat"
call "<Path to Microsoft Visual Studio Installation Folder>2019VCAuxiliaryBuildvcvars64.bat"
cd "<build folder>"
nmake
call "<Path to Microsoft Visual Studio Installation Folder>2019VCAuxiliaryBuildvcvars64.bat"
cd "<build folder>"
nmake install
call "<Path to Microsoft Visual Studio Installation Folder>2019VCAuxiliaryBuildvcvars86.bat"
cd "<build folder>"
cmake "<goldberg_emulator src folder>" -DVCPKG_TARGET_TRIPLET:STRING="x86-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="<vcpkg installation folder>scriptsbuildsystemsvcpkg.cmake"
Notez que si vous utilisez les outils de construction pour Visual Studio 2019, le chemin vers le VCVARS86.BAT est légèrement différent:
call "<Path to Build Tools for Visual Studio 2019 Installation Folder>2019BuildToolsVCAuxiliaryBuildvcvars86.bat"
call "<Path to Microsoft Visual Studio Installation Folder>2019VCAuxiliaryBuildvcvars86.bat"
cd "<build folder>"
nmake
call "<Path to Microsoft Visual Studio Installation Folder>2019VCAuxiliaryBuildvcvars86.bat"
cd "<build folder>"
nmake install
sudo apt install build-essential )sudo apt install cmake )sudo apt install libprotobuf-dev protobuf-compiler ) cd "<build folder>"
cmake "<goldberg_emulator src folder>"
cd "<build folder>"
make
cd "<build folder>"
make install
Pour définir le générateur, appelez -G "<Generator Name>" par exemple
cmake .. -G "Ninja" -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="..vcpkgscriptsbuildsystemsvcpkg.cmake"
Pour définir le type de build, append -DCMAKE_BUILD_TYPE:STRING="<Build Type>" par exemple
cmake .. -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="..vcpkgscriptsbuildsystemsvcpkg.cmake" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo"
Pour définir la version expérimentale, appelez -DEMU_EXPERIMENTAL_BUILD:BOOL=ON par exemple
cmake .. -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="..vcpkgscriptsbuildsystemsvcpkg.cmake" -DEMU_EXPERIMENTAL_BUILD:BOOL=ON
Pour construire une configuration cmake générée avec ninja:
cd "<build folder>"
ninja
Pour utiliser une direction d'installation personnalisée, appelez -DCMAKE_INSTALL_PREFIX:STRING="<Custom Installation Directory>" par exemple
cmake .. -DCMAKE_INSTALL_PREFIX:STRING="./install/" -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="..vcpkgscriptsbuildsystemsvcpkg.cmake" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo"
Si vous ne souhaitez pas prérégler le répertoire d'installation pendant l'étape de génération, vous pouvez également utiliser un outil de construction ou un écrasement spécifique du système d'exploitation, certains exemples sont:
nmake install prefix="<Custom Installation Directory>"make DESTDIR="<Custom Installation Directory>" install Je pense que la façon dont les autres émulateurs à vapeur ont un INI lorsque vous définissez tout sur un paramètre par jeu est stupide. Les seules choses qui devraient être définies sur un paramètre par jeu sont les choses qui sont spécifiques à ce jeu comme l'apprid, le DLC, les mods, les versions d'interface, etc ...
Le reste comme votre nom devrait être fixé dans un endroit mondial parce que je n'aime pas avoir à définir tous les putains de nom de tout le monde dans un INI pour chaque jeu que je copie aux gens quand je veux leur copier des jeux pour jouer sur mon LAN.
Mon EMU est faite d'une manière que vous pouvez simplement l'installer sur un jeu, puis copier le jeu aux gens et ils n'ont rien à changer.
Je suis d'accord que le fait que j'ai plusieurs fichiers pourrait être stupide, mais ce n'est en fait pas. Votre système de fichiers est une base de données, alors pourquoi devriez-vous reproduire cela en faisant un fichier de configuration alors que vous pouvez en avoir beaucoup. Il est beaucoup plus facile de gérer le codage.
Il n'y a pas de différence de fonctionnalité entre la version Windows normale et la version Linux. Windows a une version expérimentale qui a des fonctionnalités qui n'ont du sens que sur Windows.
Lisez ceci si vous voulez savoir ce que c'est: la lecture expérimentale
Il est aussi illégal que le vin ou tout émulateur de console HLE. Tout cela est de supprimer la dépendance à la vapeur de vos jeux Steam.
Il ne casse aucun DRM. Si le jeu a une protection qui ne vous permet pas d'utiliser une DLL API à vapeur personnalisée, elle doit être fissurée avant d'utiliser mon émulateur. La vapeur est un DRM autant que toute API est un DRM. La vapeur a un DRM réel appelé SteamStub qui peut facilement être fissuré, mais cela ne le fissurera pas pour vous.
Non, je me fiche de faire fonctionner ces jeux parce qu'ils utilisent des API comme le coordinateur du jeu qu'aucun autre jeu n'utilise. Valve continue également à les changer.
Cependant, si quelqu'un d'autre perd son temps pour les faire fonctionner et que je fusionnerai volontiers leur travail.