1 pontos por polarisz00 4 시간 전 | 1 comentários | Compartilhar no WhatsApp

GitHub: https://github.com/CookingMathmatics/CarryPyramidLossless

White paper de pesquisa (Zenodo): DOI 10.5281/zenodo.20002868

Olá. Sou o desenvolvedor (e pesquisador de matemática) que há algum tempo compartilhou no GeekNews um white paper de pesquisa sobre segurança topológica multidimensional e teoria da informação com base na dinâmica de carry p-ádica.
Na época, a abordagem era mais teórica, centrada no modelo matemático e na lógica de entropia de hardware, mas enquanto eu aprimorava esse white paper e avançava na pesquisa, cheguei a um ponto de virada interessante.
Durante um brainstorming técnico com IA, recebi o conselho e a ideia de que
"se projetarmos esse algoritmo de dinâmica de carry p-ádica sobre o tráfego de pixels de um pipeline gráfico em tempo real, talvez seja possível criar uma ferramenta de otimização de integridade que reduza drasticamente a sobrecarga computacional".

Com base nas orientações de arquitetura da IA, mergulhei por mais de uma semana no projeto de DirectX 11 e HLSL Compute Shader e, por fim, concluí a validação em hardware real no ambiente do mais recente jogo de corrida, Forza Horizon 6, obtendo como resultado "diferença de 1 a 2 frames, redução de 10% no uso de GPU". Compartilho aqui o resultado e o código aberto.

💡 Ideia central: materialização do 0-Void matemático (salto de operação no vácuo) - mesmo em um jogo de corrida em altíssima velocidade, a tela inteira não muda de forma explosiva a cada frame. Montanhas ao longe, céu, nuvens ou áreas estáticas de UI têm variação de pixels extremamente pequena entre os frames.
Ao filtrar o frame buffer com o algoritmo de carry p-ádico, as regiões estáticas cuja variação fica abaixo de um limiar são rapidamente mascaradas como '0-Void (áreas de vácuo computacional)'.

Isso suprime, no nível de hardware, o tráfego em que milhares de CUDA cores da GPU (RTX 3070 Ti) antes repetiam cálculos desnecessários sobre pixels estáticos ou desperdiçavam buffer.

🛠️ Arquitetura de bypass de anti-cheat e otimização de hardware
Para garantir um nível de estabilidade comparável ao de um utilitário comercial, fiz a seguinte obra de encanamento em nível de produção.

Encanamento em whitelist com bypass 100% de anti-cheat

Abandonei de vez o método arriscado de DLL Injection, que altera a memória do jogo ou intercepta funções de DirectX à força.
Em vez disso, adotei o mesmo fluxo oficial usado pelo OBS Studio e pelo compartilhamento de tela do Discord, baseado na DXGI Desktop Duplication API, eliminando pela raiz o risco de bloqueio por segurança.

Sincronização de engrenagem com operação de frame 1:1 (Frame Sync)

Se o loop do motor em background ficar girando em marcha lenta ilimitadamente, ocorre starvation de comandos da GPU e, ao contrário do esperado, o frame rate do jogo despenca. Fixei à força a precisão do timer do kernel do Windows em 1 ms e sincronizei o disparo do nosso compute shader (Dispatch) exatamente com o sinal de evento de hardware pelo qual o jogo emite uma nova imagem.

GPU híbrida de notebook (ligação direta com a dedicada) e dieta de VRAM

Rastreando o ponteiro da placa gráfica dedicada real responsável pelo monitor onde a janela do jogo está ativa, conectei o dispositivo em ligação direta 1:1 e estabeleci uma estrutura de troca de ponteiros de endereço dentro da própria VRAM, sem custo de cópia de dados (in-place ping-pong).

📊 Resultado do benchmark em uso real (RTX 3070 Ti, ambiente FHD, qualidade máxima)
No estado original: fps fixo em 60, uso de GPU entre 78% e 80%
No estado acelerado: fps entre 59 e 60, uso de GPU entre 68% e 72%

Também compilei o sistema para permitir ligar e desligar a aceleração em tempo real dentro do jogo por meio do atalho (Ctrl + Alt + S). No momento em que a função é ativada, a suavidade da imagem permanece exatamente igual à do estado original, mantendo 60 frames completos, enquanto apenas a carga da GPU cai de forma significativa — algo que já foi verificado em tempo real pelo painel de monitoramento. Foi uma experiência realmente impressionante ver uma teoria que existia apenas em um white paper matemático ganhar forma concreta como código de controle de hardware por meio da colaboração com IA.
Como a estrutura principal (Alpha Core) já está solidamente construída, gostaria de ouvir feedback de otimização em diferentes taxas de atualização de tela (144Hz~360Hz) e em outras arquiteturas de placa gráfica. O código-fonte do motor e os arquivos de shader estão todos publicados no GitHub acima, então agradeço muito por conselhos e feedback!

1 comentários

 
polarisz00 3 시간 전

Como não foi possível editar, deixo as informações adicionais em comentário.

Cuidados ao executar (leitura obrigatória para os usuários)

Este motor usa a API oficial de duplicação de desktop do DXGI para contornar o anti-cheat. Devido às características do mecanismo que captura legalmente a composição de tela do DWM (Desktop Window Manager) do Windows, é necessário seguir as configurações de exibição abaixo para que funcione corretamente.

  • Configuração recomendada: execute o jogo em [Modo Janela] ou [Janela em tela cheia (tela cheia sem bordas / Borderless Windowed)] nas opções gráficas do jogo.
  • Não funciona: no modo [Tela cheia exclusiva (Exclusive Full Screen)], em que o jogo assume controle exclusivo do monitor, o pipeline de captura não é aberto, então o motor pode não funcionar ou a medição de frames pode não ocorrer.