D3D Grabbing (x64 build)

• When built x64, this version can inject 32- and 64-bit DirectX Processes
• Improved Injection stability, reduced overhead
• Does not grab every frame, customizable grab frequency
• Display a warning when DX hooking is enabled but not run as administrator
• Inject only fullscreen DX programs
• Un-Inject programs when quitting

Not tested on other platforms or with MinGW build Includes #40

+1

Actually, works for me with some extra hooking and compilation fixes. However, when fullscreen app has a resolution that differs from one Prismatik was launched against, hooking doesn't work: qCritical() << Q_FUNC_INFO << "illegal state, screens don't match: qt " << grabbedScreens[0].screenInfo.rect << ", remote proc's " << m_memDesc.width << "x" << m_memDesc.

Indeed. I did not change that part, that's what the current master does too. One could add a mechanism to scale the image to the resolution prismatik expects see https://github.com/woodenshark/Lightpack/blob/master/Software/grab/D3D10Grabber.cpp#L255

Actually this is what GrabberBase::reallocate is for: https://github.com/woodenshark/Lightpack/blob/master/Software/grab/GrabberBase.cpp#L122 It is called, when dimensions or grabbing widget positioning is changed.

In theory, whoever originally wrote the D3D10Grabber does not use the screensWithWidgets (and therefore the reallocate mechanism): https://github.com/woodenshark/Lightpack/blob/master/Software/grab/D3D10Grabber.cpp#L531

I do not think the GrabberBase can handle a scenario where the screens returned by screensWithWidgets have a resolution different from the resolution the widgets are specified in. The grab mechanism can handle offsets but not entirely different sizes: https://github.com/woodenshark/Lightpack/blob/master/Software/grab/GrabberBase.cpp#L158