Xipho

Да, введи проверку на nil для переменной Bottom

Как один из вариантов

Есть строка, которая сигнализирует о событии. Можно поискать в ресурсах игры эту строку, затем поискать в коде игры, что на эту строку ссылается. Из этого можно выйти на код проверки, и там уже посмотреть, что с этим можно сделать.

Неправильно ты понял. Рекомендую внимательно читать документацию movsd помещает 4 байта из источника (esi) в приемник (edi). repe повторяет действие своего операнда, при каждом повторе добавляя смещение к источник и приемнику, и уменьшая счетчик ecx. Это повторяется до достижения счетчиком нуля.

Годный урок! Посмотрел с перемоткой, мне понравилось )

Хорошее исследование провел, а у меня так руки и не дошли за эти выходные

Немного оффтопа - тут я вспомнил "войну" с одним покерным румом, для которого я как-то писал бота )) Вспомнил, и нервно захихикал от слов "никак бы не спалили... потому что... имитирует нажатие клавиш..." )) Впрочем, к онлайн играм, чаще всего, так строго не относятся ) Кстати, вместо отсылки сообщений можно использовать SendInput - у нее более широкие возможности https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendinput https://stackoverflow.com/a/22419083 Более широкие - например, можно имитировать сразу нажатие двух клавиш - сброс бомбы и отмену сброса следующей. Тогда, возможно, во втором потоке надобность отпадет.

Так тебе же Партизан выше написал - x64dbg/x32dbg с плагином ScyllaHide

Исходя из твоей задачи (помним про 200 миллисекунд), таймер может не подойти, потому что у него не гарантировано срабатывание точно по его истечению. Таймер гарантирует срабатывание не раньше заданного интервала, но не регламентирует точность. Смотри, как бы тебя не забанили за использование такой программы

Что это значит?

С точки зрения чистоты кода, у тебя сейчас поток выполняет две разные задачи - выставляет флаг и потом, в зависомости от этого флага, действует. В целом, для небольшого функционала можно и так оставить. В твоем случае, чтобы проц не долбился в сотку, можно добавить sleep на 5-10 милисекунд, мне кажется, это должно решить твою проблему. Но если совсем по фен-шую делать - можно вынести функционал отправки клавиш и проверки режима в отдельный поток с бесконечным циклом и задержкой. А по клавишам поток создавать и убивать. Тогда и флаг не понадобится )

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

Из того, что я прочитал, я увидел следующую картину - быстрое чтение и выполнение каких-либо действий нужно только тогда, когда mode включен. Если я правильно понимаю, вынесение кода ожидания горячих клавиш в отдельный поток не решит проблему стопроцентной загрузки процессора - тебе всё равно придется добавлять ожидание хотя бы 5 милисекунд (для твоего интервала в 200 милисекунд это не должно быть критично). По остальному - не видя код перед глазами довольно сложно искать пути оптимизации.

1. Идешь в хранилище исходников CheatEngine (сиречь репозиторий) 2. Находишь там раздел, где публикуются проблемы программы 3. Публикуешь туда описание ошибки, которая у тебя возникает и сценарий для ее воспроизведения 4. Ждешь, когда ошибку поправят.

HDC hdcColor = CreateCompatibleDC(compatibleDC.origDC); HDC hdcMask = CreateCompatibleDC(compatibleDC.origDC); HBITMAP prevColor = reinterpret_cast<HBITMAP>(GetCurrentObject(hdcColor, OBJ_BITMAP)); HBITMAP prevMask = reinterpret_cast<HBITMAP>(GetCurrentObject(hdcMask, OBJ_BITMAP)); HBITMAP color = CreateCompatibleBitmap(compatibleDC.origDC, 32, 32); HBITMAP mask = CreateCompatibleBitmap(compatibleDC.origDC, 32, 32); HICON icon1 = reinterpret_cast<HICON>(LoadImageW(WGW::hInstance, MAKEINTRESOURCE(_IDI_FRUT), IMAGE_ICON, 32, 32, 0)); SelectObject(hdcColor, color); SelectObject(hdcMask, mask); ICONINFO iconInfo{ 0 }; BITMAP bitmap{ 0 }; GetIconInfo(icon1, &iconInfo); GetObjectW(iconInfo.hbmMask, sizeof(bitmap), &bitmap); SelectObject(hdcColor, iconInfo.hbmMask); BitBlt(compatibleDC.origDC, 0, 0, bitmap.bmWidth, bitmap.bmHeight, hdcColor, 0, 0, SRCAND); SelectObject(hdcMask, iconInfo.hbmColor); BitBlt(compatibleDC.origDC, 0, 0, bitmap.bmWidth, bitmap.bmHeight, hdcMask, 0, 0, SRCINVERT); DrawIconEx(compatibleDC.origDC, 50, 0, icon1, 32, 32, NULL, NULL, DI_MASK | DI_IMAGE); HBITMAP prevColor = reinterpret_cast<HBITMAP>(GetCurrentObject(hdcColor, OBJ_BITMAP)); HBITMAP prevMask = reinterpret_cast<HBITMAP>(GetCurrentObject(hdcMask, OBJ_BITMAP)); Зачем это предварительное расшаркивание? SelectObject возвращает замещенный объект Дальше. Если мне не изменяет память, при создании GDI структур их нельзя вчистую нулями заполнять. У большинства из них есть поле dwSize, которое нужно заполнять, чтобы функции, использующие эти структуры, корректно отрабатывали. Но тут это не точно. Для загрузки иконок вроде как есть LoadIcon, заточенный специально под иконки Ну а артефакты говорят о том, что ты неправильно работаешь с маской. В случае с иконками, помнится, использовал режим SRCPAINT. Но это для старых иконок, где фон, по сути, был черным. По остальному - на выхах, если будет время, попробую освежить контекст в голове по рисованию с GDI. Но что-то ты явно с маской делаешь не так.