SteamEmulator
Release 06.2023
Este é um emulador de vapor que emula os recursos on -line do Steam em uma LAN. Funciona no Linux e no Windows. Para um readme sobre como usá -lo, veja: o relevo readme
Você substitui a API do Steam .Dll ou .So pelo meu (para etapas completas, consulte o readme de liberação) e, em seguida, você pode colocar o Steam no lixo e jogar seus jogos no único jogador na LAN sem Steam (assumindo que os jogos não tenham DRM e use Steam para on -line).
Se você é um desenvolvimento de jogos e cometeu o erro de depender muito da API do Steam e deseja lançar a versão do seu jogo sem ele e não deseja reescrever seu jogo, isso é para você. É licenciado LGPLV3+, portanto, o único código -fonte que você precisa publicar é o código -fonte deste emulador (e somente se você fizer modificação).
Substitua o Steam_API (64) .dll (libsteam_api.so no Linux) do jogo com o meu. Para o Linux, verifique se a API original tiver 32 bits, você use uma construção de 32 bits e se for 64 bits, você usa uma construção de 64 bits.
Coloque um arquivo Steam_appid.txt que contém o Appid do jogo ao lado dele, se ainda não houver um.
Se o seu jogo tiver um Steam_API original (64) .dll ou libsteam_api. tão mais antigo que maio de 2016 (no Windows: Properties-> assinaturas digitais-> Timestamp) Você pode precisar adicionar um Steam_Interfaces.txt ao lado da minha biblioteca do emulador se o jogo não estiver funcionando. Existe um script Linux para gerá -lo na pasta Scripts deste repositório.
Para mais informações, consulte: O Release ReadMe
Você pode baixar as compilações Git mais recentes para Linux e Windows no site do GitLab Pages e os lançamentos estáveis na seção de liberação deste repositório.
Uma das razões pelas quais fiz esse código aberto é porque quero contribuições. A menos que seu código esteja relacionado ao material experimental, ele precisa funcionar no Linux e no Windows. Ter um comportamento preciso é mais importante do que fazer os jogos funcionarem. Ter um comportamento impreciso pode corrigir um jogo, mas vai quebrar os outros.
#Goldberg: matrix.org
Dependências: Protobuf-Lite
Instale o protobuf-lite (o pacote de dev) e o protoc (ou protobuf-compiler ou o que for chamado em sua distro) usando o gerenciador de pacotes.
Então faça: make
E ele criará a construção de lançamento (não se esqueça de adicionar algo como -j8 se o seu computador não for uma merda e você deseja que ele seja construído a uma velocidade decente).
Para construir a construção de depuração: make debug
Meu makefile é uma merda, então você pode precisar: make clean se desejar criar a construção de depuração depois de criar a versão de liberação ou o oposto.
Para minha versão de lançamento, construo -o no Steamos usando o script build_steamos.sh . Para que funcione, você precisa de uma versão x86 do Protobuf instalada em: ../protobuf/prefix_x86/ e uma versão x64 instalada em: ../protobuf/prefix/
A primeira coisa que você deve fazer é instalar o Git para o Windows. Git for windows
Em seguida, instale as ferramentas do Visual Studio: Microsoft Build Tools (certifique -se de instalar as ferramentas de compilação C ++. Basta selecionar C++ build tools no instalador e pressione Instalação.)
Crie uma nova pasta em algum lugar do seu computador.
Entre nessa pasta, clique com o botão direito do mouse em Abra o prompt de comando git. (Clique com o botão direito do mouse na pasta-> git bash aqui)
Execute os comandos:
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
Isso deve construir e instalar todas as dependências e clonar o repo. Alguns comandos como o bootstrap-vcpkg.bat e a instalação vcpkg podem demorar um pouco.
Então, para construir a versão experimental de depuração: build_win_debug_experimental.bat
Para construir a versão de liberação Run: build_win_release.bat
Se, por algum build_set_protobuf_directories.bat
Vá na pasta Goldberg_emulator e clique com o botão direito do mouse no prompt de comando git. (Clique com o botão direito do mouse na pasta-> git bash aqui)
Execute o comando:
git pull
Os seguintes metas estão incluídos na configuração do CMake para este projeto:
Embora todos os alvos estejam incluídos para todas as plataformas/variantes de construção, há alguns pontos a serem observados:
A configuração do CMake para este projeto também inclui suporte de instalação. A instalação do projeto resultará em um conjunto mais limpo de arquivos de saída (que os arquivos de construção bruta) e copiarão sobre os leitura, ferramentas e outros arquivos de suporte apropriados do diretório de projetos. Esta instalação está estruturada como seguinte:
+ 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
Observe que se nenhum CMAKE_INSTALL_PREFIX definir estiver definido para geração de cmake (ou outro método de definir um diretório de instalação personalizado é usado) Os diretórios de instalação específicos do sistema operacional são usados: estes são:
c:/Program Files/${PROJECT_NAME}/usr/localConsulte a seção 'Alterar o diretório de instalação' deste ReadMe para obter mais informações.
+ some-top-level-folder
|- vcpkg
|- goldberg_emulator
bootstrap-vcpkg.bat na pasta de instalaçãovcpkg install protobuf --triplet x64-windows-static && vcpkg install protobuf --triplet x86-windows-staticEste repositório inclui um arquivo cmakesettings.json que contém as configurações para as seguintes plataformas de destino e variantes de construção:
Essas configurações devem ser carregadas automaticamente ao abrir a pasta Goldberg_emulator no Visual Studio. Para obter mais informações sobre como usar essas configurações (e o projeto CMake no Visual Studio em geral), consulte: https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019
O Visual Studio construi para as configurações Windows e WSL de serão emitidas para a seguinte pasta: ${projectDir}out${workspaceHash}build<configuration name>
Você também pode optar por instalar diretamente do Visual Studio. O Visual Studio é instalado para as configurações do Windows, serão produzidas para a seguinte pasta: ${projectDir}outinstall<configuration name>
Enquanto o uso dessas configurações são alguns pontos a serem observados:
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"
Observe que, se você estiver usando as ferramentas de compilação para o Visual Studio 2019, o caminho para o vcvars64.bat é um pouco diferente:
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"
Observe que se você estiver usando as ferramentas de construção do Visual Studio 2019, o caminho para o VCVars86.bat é um pouco diferente:
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
Para definir o gerador, apete -se -G "<Generator Name>" por exemplo
cmake .. -G "Ninja" -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="..vcpkgscriptsbuildsystemsvcpkg.cmake"
Para definir o tipo de compilação, append -DCMAKE_BUILD_TYPE:STRING="<Build Type>" por exemplo
cmake .. -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="..vcpkgscriptsbuildsystemsvcpkg.cmake" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo"
Para definir a compilação experimental, append -DEMU_EXPERIMENTAL_BUILD:BOOL=ON por exemplo
cmake .. -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="..vcpkgscriptsbuildsystemsvcpkg.cmake" -DEMU_EXPERIMENTAL_BUILD:BOOL=ON
Para construir uma configuração CMake gerada com Ninja:
cd "<build folder>"
ninja
Para usar uma direção de instalação personalizada, append -DCMAKE_INSTALL_PREFIX:STRING="<Custom Installation Directory>" por exemplo
cmake .. -DCMAKE_INSTALL_PREFIX:STRING="./install/" -DVCPKG_TARGET_TRIPLET:STRING="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE:STRING="..vcpkgscriptsbuildsystemsvcpkg.cmake" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo"
Se você não deseja predefinir o diretório de instalação durante a etapa de geração, também pode usar uma ferramenta de construção ou substituição específica do sistema operacional, alguns exemplos disso são:
nmake install prefix="<Custom Installation Directory>"make DESTDIR="<Custom Installation Directory>" install Eu acho que a maneira como outros emuladores de vapor têm uma ini quando você define tudo em uma configuração por jogo é burro. As únicas coisas que devem ser definidas em uma configuração por jogo são as coisas específicas para esse jogo como o Appid, DLC, Mods, versões de interface, etc ...
O restante como seu nome deve ser definido em um local global, porque eu não gosto de ter que definir todos os nomes de todos em uma ini para cada jogo que copio para as pessoas quando quero copiar jogos para eles jogar na minha LAN.
Meu emu é feito de uma maneira que você pode instalá -lo em um jogo e copiar o jogo para as pessoas e elas não precisam mudar nada.
Concordo que o fato de ter vários arquivos pode ser burro, mas na verdade não é. Seu sistema de arquivos é um banco de dados, por que você precisaria replicar isso fazendo um arquivo de configuração quando pode ter muitos. É muito mais fácil gerenciar a codificação.
Não há diferença na funcionalidade entre a versão normal do Windows e a versão Linux. O Windows possui uma construção experimental que possui recursos que só fazem sentido no Windows.
Leia isso se quiser saber o que é: o Readme experimental
É tão ilegal quanto o vinho ou qualquer emulador de console do HLE. Tudo isso é remover a dependência do vapor de seus jogos a vapor.
Não quebra nenhum DRM. Se o jogo tiver uma proteção que não permita que você use uma DLL de API de vapor personalizada, ele precisa ser quebrado antes de usar meu emulador. O vapor é um DRM, tanto quanto qualquer API é um DRM. O Steam possui DRM real chamado Steamstub, que pode ser facilmente rachado, mas isso não o quebra para você.
Não, não me importo em fazer esses jogos funcionarem porque eles usam APIs como o coordenador de jogos que nenhum outro jogo usa. A válvula também continua mudando -os.
No entanto, se alguém desperdiça seu tempo para fazê -los trabalhar e eu ficarei feliz em fundir o trabalho deles.
