Гайд CS2 External — Дрожание (jitter) ESP при движении камеры

[hex_cat]

Классика жанра: пилишь экстернал на CS2, всё вроде ок, но как только начинаешь активно махать мышкой — отрисовка боксов и скелетов превращается в эпилептический припадок. При этом статичный прицел в центре экрана стоит мертво, а значит проблема не в самом методе вывода изображения.

Суть проблемы:
Человек использует WinForms GDI+ и Layered Window. Попытки читать ViewMatrix, PlayerPos и ViewAngles синхронно в одном потоке не помогают. Джиттер (тряска) остается. Это фундаментальная проблема большинства экстернал-софтов, связанная с рассинхроном между циклом чтения памяти (RPM) и циклом рендеринга самой игры.

Технический разбор:
Проблема не в GDI+, а в том, как и когда вы получаете данные. Оверлей читает матрицу в произвольный момент времени, а игра уже могла обновить положение игрока или углы обзора для следующего кадра. Получается «эффект желе».

Спойлер: Почему это происходит

1. Матрица вида (ViewMatrix) обновляется движком Source 2 невероятно часто.
2. Ваш цикл чтения памяти никак не привязан к VSync или отрисовке кадра в CS2.
3. Интерполяция координат: то, что вы читаете из памяти, может быть «прошлым» состоянием, которое уже не актуально на момент отрисовки кадра оверлеем.

Многие сразу советуют переходить на DirectX 11/12 оверлей, но это лишь частично сгладит углы за счет более высокого FPS самого оверлея. В экстерналах «чистого» решения без задержки практически не существует, так как вы всегда на шаг позади движка.

Что можно попробовать:

1. Переход на ImGui + DX11/DX12 — это стандарт индустрии, GDI+ слишком тяжелый для этих задач.
2. Увеличение частоты опроса памяти, но тут важно не ловить рейз-кондишн.
3. Методы сглаживания (экстраполяция) координат на стороне чита, чтобы предсказать, где будет цель в момент следующего тика оверлея.

// Пример: чтение матрицы
ReadProcessMemory(hProcess, (LPCVOID)(clientDll + dwViewMatrix), &viewMatrix, sizeof(viewMatrix), NULL);

Кто как фиксил этот рассинхрон в своих сурсах под CS2, если не брать в расчет интернал-решения?

 

[car11r]

Классика жанра: пилишь экстернал на CS2, всё вроде ок, но как только начинаешь активно махать мышкой — отрисовка боксов и скелетов превращается в эпилептический припадок. При этом статичный прицел в центре экрана стоит мертво, а значит проблема не в самом методе вывода изображения.

Суть проблемы:
Человек использует WinForms GDI+ и Layered Window. Попытки читать ViewMatrix, PlayerPos и ViewAngles синхронно в одном потоке не помогают. Джиттер (тряска) остается. Это фундаментальная проблема большинства экстернал-софтов, связанная с рассинхроном между циклом чтения памяти (RPM) и циклом рендеринга самой игры.

Технический разбор:
Проблема не в GDI+, а в том, как и когда вы получаете данные. Оверлей читает матрицу в произвольный момент времени, а игра уже могла обновить положение игрока или углы обзора для следующего кадра. Получается «эффект желе».

Спойлер: Почему это происходит

1. Матрица вида (ViewMatrix) обновляется движком Source 2 невероятно часто.
2. Ваш цикл чтения памяти никак не привязан к VSync или отрисовке кадра в CS2.
3. Интерполяция координат: то, что вы читаете из памяти, может быть «прошлым» состоянием, которое уже не актуально на момент отрисовки кадра оверлеем.

Многие сразу советуют переходить на DirectX 11/12 оверлей, но это лишь частично сгладит углы за счет более высокого FPS самого оверлея. В экстерналах «чистого» решения без задержки практически не существует, так как вы всегда на шаг позади движка.

Что можно попробовать:

1. Переход на ImGui + DX11/DX12 — это стандарт индустрии, GDI+ слишком тяжелый для этих задач.
2. Увеличение частоты опроса памяти, но тут важно не ловить рейз-кондишн.
3. Методы сглаживания (экстраполяция) координат на стороне чита, чтобы предсказать, где будет цель в момент следующего тика оверлея.

// Пример: чтение матрицы
ReadProcessMemory(hProcess, (LPCVOID)(clientDll + dwViewMatrix), &viewMatrix, sizeof(viewMatrix), NULL);

Кто как фиксил этот рассинхрон в своих сурсах под CS2, если не брать в расчет интернал-решения?

в экстернл это будет всегда

 

[whoise80]

когда это уже прекратится