Оптимизация отрисовки кастомных ESP-боксов: почему ваш ImGui тормозит и как это исправить

[AntoninaErshova]

Часто вижу в разделе разработки софта под игры одну и ту же ошибку: новички лепят отрисовку ESP-боксов через стандартный AddRect или, что еще хуже, через циклы отрисовки линий AddLine для каждого ребра. Когда на экране 20+ противников, FPS начинает ощутимо проседать, особенно если вы тянете данные из памяти процесса в каждом кадре без кэширования.

В чем проблема?​

Основной затык не в самой отрисовке, а в избыточных вызовах функций рисования и постоянном пересчете координат W2S (World to Screen) внутри цикла рендеринга. Каждая такая операция — это лишние такты процессора и нагрузка на шину. Если вы используете ImGui, помните, что он формирует список вершин (vertex buffer) для GPU. Чем больше вызовов функций Add*, тем тяжелее этот буфер.

Практическое решение​

Чтобы ускорить отрисовку, нужно соблюдать три правила: батчинг, минимизация W2S и уход от float к int там, где точность до пикселя не критична.

• Делайте все расчеты координат один раз за кадр во внешнем цикле и сохраняйте их в структуру.
• Используйте AddRectFilled только для полупрозрачных фонов, не злоупотребляйте антиалиасингом (флаг ImDrawFlags_AntiAliasedLines), он жрет ресурсы на тонких линиях.
• Если пишете на C++, используйте SIMD-инструкции для массового пересчета координат матриц.

Важный нюанс: если вы рисуете сложные фигуры или кастомные бары здоровья, лучше заранее подготовить текстурный атлас и выводить его через AddImage, чем рисовать десятки мелких примитивов.

Недавно я проводил тесты производительности разных методов рендеринга оверлеев, и

Гости не видят ссылку Войти или зарегистрироваться

показал, что переход на использование DrawList напрямую с предварительной аллокацией памяти под вершины дает прирост до 15% FPS на слабых конфигурациях.

Пример оптимизированного подхода на C++​

// Вместо 4-х AddLine используем один AddRect
ImGui::GetBackgroundDrawList()->AddRect(p_min, p_max, color, 0.0f, ImDrawFlags_None, 1.0f);

Также советую выносить логику фильтрации целей (проверка на видимость, дистанцию) в отдельный поток, чтобы рендер-поток не ждал ответа от движка или драйвера. В PHP-панелях управления читами (если кто-то еще пишет бэкенд на них) применяйте ту же логику: отдавайте на фронт только готовый JSON с координатами, не заставляйте JS делать тяжелую математику на лету.
Кто как решает вопрос с мерцанием при наложении нескольких слоев? Поделитесь опытом в комментариях.