Наложение на полноэкранное 3D-приложение

Ну вот еще один пример. Xfire - это программа чата, которая накладывает свой интерфейс на игры, чтобы вы могли получать сообщения во время игры. Они делают это, редактируя d3d / opengl DLL на уровне памяти процесса, например, вставляя переходы сборки. Я знаю это, потому что их метод приводил к сбою моего мода, и я действительно видел странный ассемблерный код, который они вводили в d3d9.dll.

Итак, вот как это делает Xfire:

1. нацелить процесс игры
2. поиск в памяти процесса для d3d.dll / opengl.dll
3. внедрить в процесс DLL, содержащую пользовательскую логику интерфейса
4. подключать функции интерфейса к потоку программы, вручную записывая переходы сборки в функции d3d / opengl, находящиеся в памяти процесса

Нет другого мыслимого способа, поскольку вам нужно захватить графическое устройство, принадлежащее этой игре. Готов поспорить, что Steam делает это так же, как Xfire. Так что да, это нелегкий способ сделать это, если только кто-то не создал полезную библиотеку, чтобы делать все, что вам нужно, на низком уровне.

Вы также спросили о затемнении игровой графики под вашим оверлеем. Это простой вызов DrawPrimitive для рисования прозрачного прямоугольника с заливкой на экране.

Создал Gist с полным кодом здесь

Это довольно эзотерическое искусство, и есть несколько способов сделать это. Я предпочитаю то, что называется Direct3D Wrapper. Прошло много лет с тех пор, как я сделал это, но однажды я сделал это с игрой. Возможно, я упустил некоторые детали, но я просто надеюсь проиллюстрировать идею.

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

HRESULT IDirect3DDevice9::EndScene()
{
   // draw overlays here

   realDevice.EndScene();
}

Затем мы компилируем его в DLL с именем d3d9.dll и помещаем в каталог исполняемого файла игры. Настоящий d3d9.dll должен находиться в папке / system32, но игра сначала просматривает текущий каталог, а вместо этого загружает наш. Как только игра загружается, она использует нашу DLL для создания экземпляра нашего класса-оболочки. И теперь каждый раз, когда вызывается EndScene, выполняется наш код, чтобы отрисовывать на экране то, что мы хотим.

Я думаю, вы можете попробовать тот же принцип с OpenGL. Но я думаю, что некоторые современные игры пытаются это предотвратить, чтобы предотвратить подделку.

Я думал об этом. Для OpenGL я бы подключил SwapBuffers WGL к обходным путям, рисовал свои материалы после игры, а затем сам менял буферы местами.

Я делал наложения как с окнами просмотра DirectX, так и с WPF (на самом деле, одно и то же), используя наложение, чтобы рисовать приятные 2D-элементы GDI + поверх 3D-визуализаций.

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