Снимок экрана приложений использующих DirectX

[Axenic]

Проблема в следующем GDI+ делает снимок экрана когда попало, и очень часто бывает, что кадр ещё полностью не отрендился, а снимок экрана уже делается, из-за чего не все эелементы окна попадают в кадр.

Fraps делает снимки как надо и так понял он использует для снятие скриншотов технологию DirectX.

Я ничего не понимаю в DirectX и мне не сильно хочется тратить 2-3 месяца на его изучение чтобы узнать написать только одну функцию. Для моего проекта мне вполне хватает GDI+ который я по мере продвижения подучиваю.

Если у кого-нибудь есть функция, которая делает снимок игры в полноэкранном режиме и записывает это все в Bitmap, то выложите пожалусто. И если у Вас её нет, но вы знаете как просто её написать, тоже выложите

[zubr]

Задача однозначно не в одну функцию. Тебе надо получить HDC оверлея, а для этого надо получить доступ к интерфейсу IDirectDraw процесса, осуществляющего вывод видеопотока через DirectX. Если это твой процесс то задача решается просто, иначе надо перехватывать API-функцию DirectDrawCreate. Ну и еще вариант - видео-драйвер-фильтр.

[Axenic]

Загрузил

[Алексей++]

Задача однозначно не в одну функцию. Тебе надо получить HDC оверлея, а для этого надо получить доступ к интерфейсу IDirectDraw процесса, осуществляющего вывод видеопотока через DirectX. Если это твой процесс то задача решается просто, иначе надо перехватывать API-функцию DirectDrawCreate. Ну и еще вариант - видео-драйвер-фильтр.

о, я так понимаю, это то, что мне сейчас надо ) А как такой перехват функции DirectDrawCreate делается ?

[zubr]

Алексей1153++, есть множество способов перехвата API-функций (подмена адреса перехватываемой функции в библиотеке, подмена адреса функции в адресном пространстве процесса, использование DebugApi), также есть несколько способов внедрения в адресное пространство чужого процесса (хук, CreateRemoteThread). Все это с примерами есть на wasm.ru. Также у Рихтера есть примеры. Правда во всех этих способах есть особенности, связанные с админскими правами, битностью системы (x86, x64).

Добавлено через 6 минут и 46 секунд:
Также надо будет и DirectDrawCreateEx перехватывать. С точки зрения простоты, то проще миррор-видеодрайвер замутить, просто пример из DDK скомпилировать и установить, но тормоза при этом ощутимые, да и полномочия нужны админские при установке + перезагрузка системы.

[Алексей++]

zubr, да, я уже понял, что это не то немного ) Вечером поизучаю, как до поверхности (surface) десктопа добраться

[zubr]

Алексей1153++, если там DirectX, то других вариантов нет.

[Алексей++]

так, что-то я запутался, с чего начинать. Всё-таки перехватить функцию DirectDrawCreateEx надо сначала ? Или же при помощи DX API можно прямо как-то с видеопамяти весь текущий битмап вытащить ?

[zubr]

Насколько я помню, интерфейсы DirectX не предоставляют методов для возможности перехватывать чужой видеопоток.
Поэтому остаются менее документированные способы перехвата. Перехватив DirectDrawCreateEx и DirectDrawCreate мы можем получить указатель на объект IDirectDraw, а у этого интерфейса есть метод получения указателя на объект IDirectDrawSurface. В свою очередь у объекта IDirectDrawSurface есть метод GetDC. Получив контекст видеопотока с ним можно работать как с обычным контекстом монитора.

[Алексей++]

ок, спасибо. А перехват надо в отдельной DLL делать, я правильно понимаю ? И ещё - как определить, что поверхность принадлежит именно десктопу? Или там у них нет различий - поверхность всегда одна и та же?

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

[zubr]

Почему только декстоп? А если юзер открыл винамп с фильмом, здесь не декстоп, но на рабочем столе видео присутствует. По логике любое приложение, использующее DirectX, чтобы получить объект IDirectDraw, использует DirectDrawCreateEx или DirectDrawCreate. Определить можно имя процесса в котором произошло обращение к вышеуказанным функциям. Для перехвата надо внедряться в адресное пространство чужого процесса, а для этого можно использовать глобальный хук (dll), также можно делать инжект в внедряемый процесс, тут тоже удобнее всего, чтобы внедряемый код был в виде dll. Можно перехватывать, вообще не внедряясь в чужой процесс, для этого можно использовать DebugApi, тогда твой код перехвата может находиться в потоке основного приложения, причем для каждого перехватываемого процесса надо будет соответственно создавать отладочный поток в основном приложении. У каждого из способов перехвата есть свои преимущества и недостатки, трудно сказать, какой из них лучше.

[Алексей++]

Самым привлекательным по описанию для меня показался этот способ

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

попробую разобраться

[zubr]

Недостатки этого метода:
1. Требуются админские полномочия, про UAC не знаю, не проверял, возможно будет выскакивать.
2. Зачастую разработчики ПО защищают свои проги от отладки, в этом случае будет облом, хотя при определенных извращениях защиту можно обойти (на хитрую ж..пу есть хрен с винтом, а на хр. с винтом есть ж..па с закоулками).
3. Если понадобится отключиться от отлаживаемого процесса, то это надо делать корректно, иначе можно убить отлаживаемый процесс.