Original Post
Intro This sample demonstrates the second technique that can be used to render content on-top of other Direct3D applications. The first technique, overlays, is rather general purpose; it is not tied to Direct3D. You can use overlays to render on-top of everything. This technique, on the other hand, is closely tied to Direct3D. Due to its special-purpose nature, you lose some benefits and gain others. What you lose is that you can only draw on-top of Direct3D9 applications. What you gain is that you become Direct3D itself, so you're not limited to just drawing anymore. You can do things like count the number of batches submitted per frame, the number of triangles, replace textures, etc. In this sample, we use Windows hooks to inject our DLL code into a specific process - the target process - that uses Direct3D9. Our injected code replaces Direct3DCreate9 with our own function that calls the standard Direct3DCreate9, but returns our implementation of IDirect3D9, MyDirect3D9. MyDirect3D9 stores a pointer to the original IDirect3D9 interface, so you can do anything you like by forwarding the function calls you don’t want to change and rewriting the ones you want to. The actual hooking is done using APIHijack, with very minor modifications to make it build under VC++ 2003 and 2005. Namely, a couple of reinterpret_cast’s here and there. The sample is divided into 2 projects: A DLL containing interface implementations and APIHijack, and a launcher console application. Visual C++ 2003 and 2005 solutions are provided. The launcher is a simple Unicode application that sets up the single piece of information that the DLL needs: The target process name. In order to make things simple, the launcher is passed the target process name (i.e. exe name) as a command-line argument. It then creates or updates a registry key, HKEY_CURRENT_USER\Software\Direct3D-Hook, to store the name in its default value. The non-Unicode DLL, whose DllMain is entered whenever a process is loaded, compares the name of the loaded process to that in the registry and hooks Direct3D if they’re the same. It also gives an info beep on hooking. The DLL was not build with Unicode because APIHijack isn't, and I'm not interested in converting it. Feel free to do so if you want. I’ve only provided implementations for the interfaces IDirect3D9 and IDirect3DDevice9. You can implement any other interfaces if you like, provided that you modify the functions that create them to return a pointer to instances of your implementation. Keep in mind, though, that it’s a quite boring process. I nearly lost an arm and a leg writing the aforementioned implementations, even though I’ve copied the function declarators from the d3d9.h header file. You’ll understand when you see the code. [smile] The IDirect3D9 interface implementation is rather minimal, so it forwards all function calls except: 1. Release. We call IDirect3D9::Release and check its return value. If its zero, we delete the MyDirect3D9 instance. If we don’t do this, we’ll leak memory. 2. CreateDevice. We create a normal device but return our own implementation of IDirect3DDevice9, MyDirect3DDevice9. The device implementation, again, forwards all of the function calls except: a) Release, for the same reason as above. b) EndScene. This is where we can do all the rendering we want. The sample renders a colored quad to the top-left of the render-target. Limitations Applications that manually load D3D9.dll via LoadLibrary, retrieve a pointer to Direct3DCreate9 using GetProcAddress and call it will NOT be hooked. All Direct3D SDK samples do this. If you really want to hook them, you can probably do it in another way, by providing your D3D9.dll and putting it in the same folder. I might try that out later. Testing To test the sample, I used 2 applications. A build of Direct3D tutorial #2, “Vertices”, was used first. It worked fine, and it is included in the sample. To test it in a real-world scenario, though, I used the brilliant, addictive game: “Egyptian Addiction”. Yes, this is free advertising. Go give that game a try, it rocks. No, it’s not developed by Egyptians. The real-world test was useful in that it reminded me that I had to set the required render and texture stage states first. Don’t forget that there’s someone playing with the settings before you [smile]. The sample doesn’t restore the state after modifying it, assuming the hooked process sets its required states every time. This can break some applications where the application writers didn’t expect their states changing behind their back. You’ll need to cache all state changes on all the state changing calls, and revert to the cached ones after rendering if you’re dealing with such an application. License My code in this sample is public domain, do whatever you wish with it. I can’t say the same for the APIHijack library, however. The author does not mention any specific license in his code or article, so you’d probably want to contact him if you’re doing a commercial project. PICTARS!! Finally, screenshot time! 
