Вопрос Rust — Оптимизация ESP: Bones, Scatter Read и кэширование

[hex_cat]

Оптимизация ESP в Rust — это всегда борьба за миллисекунды кадра.
Часто бывает так: скорости чтения памяти (shared memory) вроде хватает, а на выходе получаем дерганую картинку и просадки FPS. Особенно больно становится, когда дело доходит до отрисовки скелетов на большой дистанции.

Ситуация следующая: используется метод Shared Memory, чтение само по себе быстрое. Логика разделена на три потока: оверлей, быстрый тред для критичных данных и медленный для всего остального. Оверлей вроде не тупит, но итоговый результат все равно выглядит неоптимизированным.

Что стоит разобрать в первую очередь:

1. Чтение костей (Player Bones). Главный вопрос — как тянуть кости максимально эффективно? Юзать scatter/batch read или продолжать читать по одной кости? В Unity-движке иерархия костей может быть довольно разбросанной, и одиночные запросы просто убивают производительность на дистанции.
2. Кэширование данных. Очевидно, что координаты и хп нужно обновлять постоянно. Но такие вещи, как имена игроков, активные предметы или статические смещения в структурах, можно смело кэшировать. Вопрос в том, где грань между «актуально» и «тормозит систему».
3. Разделение потоков. Даже если оверлей вынесен отдельно, синхронизация между fast/slow тредами может создавать микро-фризы. Если основной цикл отрисовки ждет ответа от буфера, который еще не обновился, получаем визуальный статтер.

Спойлер: Технические заметки

При работе с Shared Memory критически важно минимизировать lock contention. Если вы используете мьютексы на каждый чих — FPS скажет «пока». Лучше смотреть в сторону двойной буферизации (double buffering). Что касается костей в Расте: эффективнее прочитать весь массив структур за раз, чем бегать по указателям Transform для каждой части тела отдельно.

Интересно послушать, как вы реализуете отрисовку скелетов на 50+ метров, чтобы картинка не превращалась в слайд-шоу при забитом сервере.

Реальная производительность ESP часто упирается не в скорость чтения, а в неэффективную обработку полученных буферов.

 

[TheXSVV]

ESP на Rust (Unity) — узкое место не в Shared Memory, а в парсинге Transform Hierarchy.

**Почему читать кости по одной — самоубийство:**

В Unity каждая кость — это отдельный `Transform` с компонентами `position` и `rotation`. Чтение 50 костей * 30 игроков = 1500 отдельных RPM-запросов. Даже с DMA это 2-3 мс простоя.

**Scatter read (батч) — обязателен:**

```cpp
typedef struct _BONE_DATA {
Vector3 pos;
Quaternion rot;
} BONE_DATA;

// Собираем все адреса костей в массив
HANDLE process;
void* boneAddresses[50 * MAX_PLAYERS];
BONE_DATA results[50 * MAX_PLAYERS];

// Один вызов NtReadVirtualMemory для всех (через RtlReadMemory)
RtlReadMemory(process, boneAddresses, results, sizeof(BONE_DATA) * count);
```

**Главный фикс для дальних дистанций (50+ м):**

**Не рисуй скелеты на дистанции.** Переключайся на упрощённый ESP (box + HP bar):
- дистанция < 30 м → скелет + оружие
- 30-70 м → box + HP + дистанция
- >70 м → только точка (или никнейм)

**Смещения костей кэшируй до первого изменения `m_Children`.** У Unity `Transform` меняется только при смене скина/оружия, а не каждый кадр.

**Разделение потоков — твоя проблема:**

Не синхронизируй через мьютексы в оверлее. Делай **double buffering**:
```cpp
struct FrameData {
Vector3 bones[50];
int count;
};
FrameData dataBuffer[2];
volatile int writeIdx = 0;
volatile int readIdx = 0;

// Поток чтения
dataBuffer[writeIdx] = newData;
writeIdx = 1 - writeIdx;

// Поток отрисовки
FrameData* drawData = &dataBuffer[readIdx];
readIdx = 1 - readIdx;
```

Никаких мьютексов → микрофризы уходят.

**Итог по Rust ESP 2025:**

- **Scatter read** — обязательно
- **LOD для скелетов** — решает 80% тормозов на дистанции
- **Double buffering** — убирает статтер
- Кэшируй `m_GameObject` → `Transform` (меняется редко), а не позиции (меняются каждый кадр)