ReHLDS

HLDS de engenharia reversa (com correção de erros)​

O que é isso?
ReHLDS é um resultado da engenharia reversa do HLDS original (compilação 6152/6153) usando informações de depuração DWARF embutidas na versão linux do HLDS, engine_i486.so. Juntamente com a engenharia reversa, muitos defeitos e (potenciais) bugs foram encontrados e corrigidos.

Objetivos do projeto
Fornecer uma versão mais estável (do que oficial) do servidor dedicado Half-Life com API estendida para mods e plugins.
Otimizações de desempenho (uso de SSE para matemática vetorial, por exemplo) é outra meta para o futuro.

Como posso usá-lo?
O Rehlds é totalmente compatível com o mais recente HLDS oficial baixado pelo steamcmd. Tudo o que você precisa fazer é baixar os binários do rehlds e substituir o original swds.dll (Windows)/engine_i486.so (Linux). Para Windows, você também pode copiar um arquivo swds.pdb com uma informação de depuração.

Atenção! O Rehlds não é compatível com plataformas antigas de 5xxx ou inferiores baixadas pelo hldsupdatetool.

Os binários do Rehlds requerem conjuntos de instruções SSE, SSE2 e SSE3 para serem executados e podem se beneficiar do SSE4.1 e do SSE4.2.
O diretório bin do arquivo contém 2 subdiretórios, ‘bugfixed’ e ‘pure’.

A versão ‘pure’ é projetada para funcionar exatamente como motor hlds oficial.
A versão ‘bugfixed’ contém algumas correções e melhorias.

Atenção! Rehlds binário não é compatível com hlds originais, já que é compilado com compiladores diferentes daqueles usados para hlds originais. Isso significa que plugins que fazem análise de código binário (Orpheu por exemplo) provavelmente não funcionarão com rehlds.

Configurando
Versão corrigida de erros (bugfixed) do rehlds contém algumas cvars adicionais:

[spoiler title=’Cvars adicionais’ style=’default’ collapse_link=’false’]

listipcfgfile
// Arquivo para proibições de ip permanente. Padrão: listip.cfg

syserror_logfile
// Arquivo para o log de erros do sistema. Padrão: sys_error.log

sv_auto_precache_sounds_in_models <1 | 0>
// Retorna automaticamente os sons anexados aos modelos. Deault: 0

sv_delayed_spray_upload <1 | 0>
// Carrega sprays personalizados depois de entrar no jogo em vez de conectar. Aumenta a velocidade de upload. Padrão: 0

sv_echo_unknown_cmd <1 | 0>
// Eco no console ao tentar executar um comando desconhecido. Padrão: 0

sv_rcon_condebug <1 | 0>
// Imprime rcon debug no console. Padrão: 1

sv_force_ent_intersection <1 | 0>
// Em um plug-in de terceiros usado para forçar a colisão de entidades SOLID_SLIDEBOX. Padrão: 0

sv_rehlds_force_dlmax <1 | 0>
// Força o cvar cl_dlmax de um cliente para 1024. Isso evita uma excessiva fragmentação de pacotes. Padrão: 0

sv_rehlds_hull_centering <1 | 0>
// Use o centro do casco em vez do canto. Padrão: 0

sv_rehlds_movecmdrate_max_avg
// Nível médio máximo de ‘move’ cmds para ban. Padrão: 400

sv_rehlds_movecmdrate_avg_punish
// Tempo em minutos para o qual o jogador será banido (0 – Permanente, use um número negativo para um chute). Padrão: 5

sv_rehlds_movecmdrate_max_burst
// Max estourou o nível de ‘move’ cmds para ban. Padrão: 2500

sv_rehlds_movecmdrate_burst_punish
// Tempo em minutos para o qual o jogador será banido (0 – Permanente, use um número negativo para um chute). Padrão: 5

sv_rehlds_send_mapcycle <1 | 0>
// Enviar mapcycle.txt na mensagem serverinfo (comportamento do HLDS, mas não é utilizado no cliente). Padrão: 0

sv_rehlds_stringcmdrate_max_avg
// Nível médio máximo de cmds ‘string’ para ban. Padrão: 80

sv_rehlds_stringcmdrate_avg_punish
// Tempo em minutos para o qual o jogador será banido (0 – Permanente, use um número negativo para um chute). Padrão: 5

sv_rehlds_stringcmdrate_max_burst
// Nível máximo de burst dos cmds ‘string’ para ban. Padrão: 400

sv_rehlds_stringcmdrate_burst_punish
// Tempo em minutos para o qual o jogador será banido (0 – Permanente, use um número negativo para um chute). Padrão: 5

sv_rehlds_userinfo_transmitted_fields
// Os campos Userinfo somente com essas chaves serão transmitidos aos clientes via rede. Se não estiver definido, todos os campos serão transmitidos (exceto o prefixo sublinhado). Cada chave deve ser prefixada por barra invertida, por exemplo “\name\model\*sid\*hltv\bottomcolor\topcolor”. Padrão: “”

sv_rehlds_attachedentities_playeranimationspeed_fix
// Correções O bug com a velocidade de animação de marcha aumenta quando o jogador tem algumas entidades conectadas (objetivos). Pode causar atrasos de animação quando cl_updaterate está baixo. Padrão: 0

[/spoiler]

Comandos
Versão corrigida do rehlds contém um comando adicional:
rescount
// Imprime a contagem total de recursos pré-armazenados no console do servidor

reslist <sound | model | decal | generic | event>
// Imprime separadamente os detalhes dos recursos pré-armazenados para sons, modelos, decalques, genéricos e eventos no console do servidor. Útil para gerenciar recursos e lidar com os limites de precache do goldsource.

Binários compilados estão disponíveis aqui: aqui
Você pode tentar jogar em um dos servidores brasileiros que usam o rehlds: aqui

Ultima Atualização ↴

Otimização de performance: resultados
Maio de 2015 foi o mês de otimização de desempenho para o projeto ReHLDS: centenas de execuções de profiler e milhares de linhas de alterações de código levaram a um aumento de desempenho de mais de 2x. Neste artigo, vou compartilhar os resultados dos testes de desempenho, mas antes disso, vou mergulhar no histórico técnico e falar sobre o gravador e player demo da Rehlds, o recurso que permite testar o código ReHLDS e fazer benchmarks.

Gravador / player demo ReHLDS
O gravador e player demo ReHLDS são partes do conjunto de testes ReHLDS que, em poucas palavras, é o dispositivo de teste ‘caixa preta’. Para entender como funciona, devemos tratar o ReHLDS como a caixa preta que consome dados de serviços externos, processa e envia dados de volta. Os serviços são APIs conhecidas: API do Win32, biblioteca C padrão, API do Steam.

Antes de podermos fazer um teste de ‘caixa preta’ devemos interceptar o fluxo de dados entre o ReHLDS e serviços externos e escrevê-lo em algum arquivo chamado ‘ReHLDS test demo’:

Agora podemos executar o ReHLDS no modo de teste e alimentar os dados do arquivo que registramos na etapa anterior. Também devemos nos certificar de que o ReHLDS produza a mesma saída produzida por (Re) HLDS durante a gravação da demonstração de teste:

Dessa forma, podemos reproduzir o cenário gravado quantas vezes precisarmos. Também podemos fazer algumas modificações no código e garantir que ele ainda produza a mesma saída da versão original (não modificada) – é assim que os testes de integração existentes funcionam. Outro fato interessante sobre este conjunto de testes é que não dependemos mais de coisas externas como temporizadores do SO e rede: quando o ReHLDS chama recvfrom () no modo de teste, o interceptador apenas lê o próximo pacote gravado do arquivo; quando ReHLDS chama Sleep (), nada acontece (o interceptor apenas garante que Sleep seja a próxima função que foi chamada pelo aplicativo original). Isso significa que o ReHLDS sempre consome 100% de um núcleo de CPU no modo ‘teste de demonstração’, o que, por sua vez, o torna adequado para o benchmarking.

No entanto, este conjunto de testes não é uma bala de prata. Como requer que o fluxo de dados de saída seja bit a bit idêntico ao fluxo que foi gravado em um arquivo de demonstração, não é possível testar FPU => SSE otimizações dessa forma, porque as instruções SSE têm menor precisão que as FPUs e, portanto, pode produzir resultados diferentes para quase todas as operações. Os resultados serão muito próximos uns dos outros (ex. 5.01234 vs 5.01233), mas eles não serão iguais a bit-a-bit.

Configuração de benchmark
Para fins de benchmarking, 9 demos de ReHLDS foram registrados:

• 3 no motor de ações e gamedll stock
• 3 em motor otimizado e gamedll stock
• 3 no motor otimizado e gamedll otimizado

“Otimizado” significa otimizações que quebram a compatibilidade do fluxo de dados de saída binária com versões de ações do gamedll/engine.

As demonstrações foram gravadas no seguinte ambiente:

• 32 bots (controlados pelo FakePlayer v1.11) jogando em de_aztec
• SO = Windows, Mod = Counter-Strike, mp_timelimit = 20, sys_ticrate = 100
• HLDS compilação 6153 com o Metamod 1.21p37 mas sem o AmxModX
• ReHLDS v0.2

A sessão de benchmarking consiste em reproduzir demos em cada uma das seguintes configurações de ambiente:

Motor	GameDLL	Metamod
Stock	Stock	Stock
Stock	Stock	Opt
Opt pedantes	Stock	Stock
Opt pedantes	Stock	Opt
Opt	Stock	Opt
Opt	Opt	Opt

Agora vamos passar pelos elementos de configuração:

• As otimizações pedantes do mecanismo são otimizações que não quebram a compatibilidade do fluxo de dados de saída binária com a versão de Stock do mecanismo
• As otimizações do mecanismo consistem em otimizações pedáticas, além de algumas alterações de algoritmo e uso de SSE em várias funções
• As otimizações do Metamod consistem em ignorar interceptores para as seguintes funções: AddToFullPack, ModelIndex, IndexOfEdict, CheckVisibility, GetCurrentPlayer, DeltaUnsetFieldByIndex. Isso significa que os plugins de metamod não podem interceptar chamadas para essas funções
• A otimização da GameDLL é a função AngleQuaternion reescrita usando instruções SSE

Resultados de referência
Demos em cada configuração foram jogadas 3 vezes, a duração média foi usada como resultado. 6 sistemas diferentes foram usados para executar benchmark. Resultados brutos estão disponíveis aqui.

[spoiler title=’Imagens e Gráficos – Clique no + para ver o spoiler’ style=’default’ collapse_link=’false’]

1. Normalize a duração de cada demonstração como se tivesse 120.000 quadros resolvendo a equação simples x/120 = duração/num_frames
2. Calcule a duração média de 3 demos de teste para cada configuração para cada CPU

E há um gráfico com todos os resultados:

Gráficos para cada CPU:
     

[/spoiler]

Análise
Vê-se claramente que a configuração totalmente otimizada de ReHLDS (E: Opto, G: Opt M: Opt) é muito mais rápida (2,5 a 3 vezes) do que a configuração de Stock em todos os processadores.

Agora vamos passar por cada componente de configuração e examinar seu impacto no desempenho.

Metamod: Stock x Otimizado
Ignorar a invocação de plug-ins em 6 funções (que são conectadas muito raramente) resulta em 20% a 30% de ganho de desempenho.

Motor: Stock HLDS vs ReHLDS com otimizações pedantes
Um pacote de otimizações ReHLDS dá 65% a 110% (geralmente em torno de 90%) de ganho de desempenho.

Motor: ReHLDS w. pedantic Opt vs ReHLDS com todas as otimizações
O uso de SSE em vez de FPU em vários lugares dá 11% de ganho de desempenho.

Motor: GameDLL: Stock vs Otimizado
Uma função (AngleQuaternion) reescrita usando SSE oferece 6% de ganho de desempenho.

Conclusão
Eu não sei o que dizer, na verdade os números falam por si.

Como usar?
ReHLDS é totalmente compatível com o HLDS original. Tudo o que é exigido de você é carregar os arquivos binários rehlds e substituir o swds.dll (Windows) ou engine_i486.so (Linux) original. Nesse caso, antes de substituir o mecanismo, o servidor deve ser atualizado via steamcmd para o mais recente 6xxx + beta.

O diretório de arquivos bin contém 2 subdiretórios, ‘bugfixed’ e ‘pure’.

O puro é projetado para funcionar exatamente como o HLDS original da válvula.
O bugfixed contém algumas correções e melhorias.

Atenção! Arquivos ReHLDS são binários incompatíveis com o HLDS original, conforme compilado por outro compilador. Isso significa que os plugins que fazem análise de código binário (Orpheu, por exemplo) provavelmente não funcionarão com rehlds. Assim, o dproto também não funcionará. Mas para a maioria dos plugins, já existe um substituto melhorado.

O que isso nos deu?
Tornou-se possível não apenas estudar o motor, mas também fazer mudanças facilmente nele. Anteriormente, isso exigia módulos de escrita que remendam a memória, o que é bastante trabalhoso. Isso é adequado apenas para corrigir bugs críticos para os quais as explorações já foram escritas, já que para cada bug pequeno, a criação de patches é muito ruim. Agora você pode corrigir qualquer erro do motor sem problemas e fazer melhorias nele. No futuro, será possível esquecer o HLDS da Valve e manter o mecanismo do servidor sozinho.

Wiki original post: The performance
Referências: GitHub – Dreamstalker
Tópico/tradução por: onixs