visão macro do sistema

[kovarike]

1. Panorama do sistema “ideal” (visão macro)

---

O sistema final vira um pipeline de input com camadas bem separadas:

1. Device Layer (entrada)

• Descobre controles, identifica tipo (PS3/PS4/PS5), conexão (USB/Bluetooth)

• Garante “pegar o controle certo” e ignorar o virtual (anti-loop)

• Lida com hotplug e reconexões sem travar o output

1. Normalization Layer (estado interno padronizado)

• Converte tudo pra um estado único (botões, sticks, triggers) independente do modelo

• Corrige diferenças entre drivers/mapeamentos

• Aplica normalização estável (range, sinais, saturação)

1. Redundant Processing Core (robustez e precisão)

• Aplica filtros, anti-jitter, deadzone, curves, smoothing

• Valida estado para evitar spikes e drift

• Implementa redundância (buffers, sanity-check, fallback)

1. Output Layer

• Emite XInput via ViGEm (Xbox 360) com taxa estável

• Rate limiting inteligente (coalescing, envio sob mudança)

• Controle de latência sem “quebrar” o sistema

1. Profile/Policy Layer (regras por jogo)

• Regras por exe/jogo: invert Y, sens, curvas, deadzones etc.

• Detecta jogo ativo (foreground exe) e troca de policy suave

2. Lista de pontos para avançar (prioridade prática)

---

A) Compatibilidade de controles (PS3/PS4/PS5)

Objetivo: conectar e funcionar sempre, sem depender de gambiarra por jogo.

• Detecção real de tipo de controle

  • VID/PID + heurísticas por nome

  • reconhecer DS4/DS5/DS3 e também “genéricos”

• Bluetooth vs USB

  • tratar diferenças de ruído/jitter no BT (principalmente)

• HID fallback (quando SDL não dá conta ou mapeamento é ruim)

  • ler HID diretamente quando necessário (mais complexo, mas robusto)

Resultado: conecta qualquer controle e sempre dá output consistente.

B) Correções de eixo “definitivas” (inversão, swap, range)

Isso é ultra comum e tem que virar config e auto-detecção, não “hardcode”.

• Per-axis: invertX/invertY, swapXY, deadzone, curve, sensitivity

• Auto-calibração rápida opcional (modo “calibrate”):

  • usuário move stick pra cima → sistema confirma sinal esperado

  • salva em policy/profile

Resultado: nunca mais “cima vira baixo” dependendo do jogo/driver.

C) Motor de “precisão” (curvas + smoothing inteligente)

Para FPS a sensação muda totalmente com a curva certa.

• Curvas de resposta:

  • Linear (default)

  • Exponencial

  • S-curve (sigmoid)

  • Dual-zone (micro aim vs movimentação rápida)

• Smoothing adaptativo:

  • pouco smoothing em movimentos lentos (micro-aim)

  • mais smoothing em ruído e micro-jitter (parado)

• Anti-overshoot / anti-flick (opcional)

  • reduz “passar do alvo” em movimentos curtos

Resultado: fica “profissional”, sensação parecida com controle nativo bom.

D) Redundância real (fail-safe + anti-bug)

Pra você poder “ficar tranquilo” mesmo em 250–500Hz.

• Double-buffer / Triple-buffer do estado

• Sanity check por frame:

  • se delta do stick muda absurdo num frame → clamp

  • se triggers saltam de 0→255 sem transição → clamp/median

• Fallback neutro automático:

  • se desconecta, manda neutro e segura até reconectar

• Heartbeat do output:

  • manda estado neutro “keepalive” em intervalos maiores se parado (opcional)

Resultado: reduz risco de travar input ou ficar “preso” numa direção.

E) Latência com estabilidade (não é só “reduzir delay”)

O que dá lag muitas vezes é jitter de timing, não média.

• Clock de alta precisão:

  • use QueryPerformanceCounter pra agendamento do tick (melhor que SDL_GetTicks)

• Event coalescing:

  • agrega eventos e envia em tick fixo (você já faz isso, ótimo)

• Taxa adaptativa:

  • 250Hz é bom, mas pode subir para 500Hz se estável

  • ou reduzir automaticamente se CPU/OS estiver causando jitter

• Evitar “sleep cego”:

  • SDL_Delay(1) funciona, mas pode variar

  • melhor: “sleep até próximo tick” com QPC, usando Sleep(0) + busy-wait curto nos últimos micros (avançado)

Resultado: menos input lag “percebido” e menos inconsistência.

F) Output mais inteligente (ViGEm + XInput)

• Neutral clamp garantido sempre que perder foco/disconnect

• Consistency do range:

  • saturar -32768..32767

  • evitar -32768 na negação (você já tratou isso com neg_s16_safe, perfeito)

• Modo “XInput only” por jogo:

  • Fortnite geralmente quer só XInput, sem emular teclado/mouse junto

  • ter policy: output_mode = XINPUT_ONLY vs KBM

Resultado: jogos param de alternar “controle/teclado” e fica estável.

G) Observabilidade (debug e diagnósticos)

Isso te salva quando algo falhar em máquina de usuário.

• Logs estruturados (níveis: INFO/WARN/ERROR)

• Dump do device (VID/PID, name, mapping)

• Métricas:

  • Hz real do loop

  • jitter (ms)

  • drops (frames perdidos)

• “Debug overlay” opcional (ou console mode)

Resultado: dá pra diagnosticar qualquer bug sem adivinhar.

3. Bibliotecas e ferramentas recomendadas (por categoria)

---

Entrada / HID / Controle

• SDL3 (você já usa) ✅Bom pra padronizar, hotplug, mapeamento.

• hidapi (C)Quando precisar ler HID “na unha” (especialmente PS3/PS5 edge cases).

• **Windows Raw Input (Win32)**Alternativa pra capturar input de forma mais direta (mais baixo nível).

• ViGEmClient ✅Para emulação de controle Xbox.

Se o objetivo é “muito robusto”, ter um modo “SDL -> hidapi fallback” é uma evolução grande.

Tempo / Agendamento / Latência

• **QueryPerformanceCounter (WinAPI)**Melhor base para tick fixo e medição de jitter.

• SetThreadAffinityMask (opcional)Fixar thread em um core pode reduzir jitter em casos específicos.

• **Multimedia Class Scheduler Service (MMCSS)**Para priorizar thread de áudio/tempo real (precisa cuidado).(Em C, você pode usar AvSetMmThreadCharacteristics via avrt.dll.)

Filtros / Precisão

• Implementar você mesmo em C (recomendado) pois é leve:

  • One Euro Filter (ótimo para input)

  • EMA / Low-pass

  • Median filter (pra spikes)

  • Deadzone circular/elliptical

  • Curvas (expo/s-curve)

One Euro Filter é um grande “segredo” pra smoothing sem destruir micro-aim.

Config / Perfis

• cJSON ou yyjsonParser JSON rápido e confiável (melhor que parser manual)

• inih (INI)Se quiser configs simples e fáceis pro usuário

• toml++ (se fosse C++) — pra C puro, melhor INI/JSON

Build / Release / Packaging

• CMake + Ninja (mais rápido que MinGW Makefiles)

• GitHub Actions (você já começou) ✅

• Inno Setup ✅

• signtool / code signing (quando for distribuir “sério”)

• VirusTotal scan step (opcional, reduz falsos positivos com users)

Qualidade / Segurança / Diagnóstico

• clang-tidy / cppcheckAnálise estática

• AddressSanitizer (ASan) (em builds de teste)

• Dr. Memory (Windows)

• WinDbg (quando crash difícil)

• Crashpad / Breakpad (se quiser crash reports “pro”)

4. Melhorias “avançadas” que valem MUITO

---

1) Auto-calibração guiada

Um modo que:

• detecta sinal real de “cima” e ajusta invert automaticamente

• salva config

• resolve 80% das dores de eixo

2) Dynamic smoothing com One Euro Filter

• melhora mira

• reduz jitter do BT

• mantém responsividade

3) Policy por jogo (exe)

• Fortnite: XInput-only, deadzone específica, sens etc.

• GTA/Outros: diferente

4) Modo “safe output”

• se detectar perda de input, manda neutro

• previne bug de “andar sozinho”

5. Recomendações práticas (o que eu faria em ordem)

---

1. Transformar inversões/curvas/deadzones em config (nem que seja INI simples)

2. Implementar One Euro Filter nos sticks

3. Adicionar QPC para tick fixo + medição de jitter

4. Criar redundância de estado (sanity + fallback neutro)

5. Adicionar um modo de calibração

6. Refatorar em módulos (rcgm/core_input_engine)

7. Subir pipeline de release: build → dist → ISCC → release assets