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!

I've never had the time to look into API hooking in much detail, but I've always been curious how it actually worked. I shall be sure to have a look through your code as/when I get some time [smile]

Cheers!
Jack

Niiiiiice, this is quality work. If I only had a dollar for each time I answered a "hooking" question, I would be a BAZILIONIONAIRE!!! Gotta love the tediousness of inheriting IDirect3DDevice9...there are only like 14 trillion member functions.

Quote:Original post by circlesoft
Niiiiiice, this is quality work. If I only had a dollar for each time I answered a "hooking" question, I would be a BAZILIONIONAIRE!!!

No need to be modest, we all know you already are!

Quote:Gotta love the tediousness of inheriting IDirect3DDevice9...there are only like 14 trillion member functions.

Yes, seriously. I almost broke my fingers on this one.

Wow, this is awesome. I intend to have some fun with this. I enjoyed hooking OpenGL and writing wallhacks for HL1 and its mods*. Let's see what I can do with this. And, kudos for typing out all those functions. There sure are a lot...

* Of course I don't play publically with the hacks. I rather happen to enjoy writing them, is all.

I'm wondering if there is some sort of image-analysis tool that can be built on top of this sort of technology.

If you could hook a commercial game and count the number of shaders used, number of passes, overdraw complexity and so on... would be an interesting thing to mess with if nothing else.

Make it work well and the hardware-nuts would love it - they spend enough time talking about clockspeeds and megahurtz that I'm sure they'll have good fun with a screenshot of the shader-complexity of a commercial game [lol]

Jack

Quote:Original post by jollyjeffers
I'm wondering if there is some sort of image-analysis tool that can be built on top of this sort of technology.

If you could hook a commercial game and count the number of shaders used, number of passes, overdraw complexity and so on... would be an interesting thing to mess with if nothing else.

Make it work well and the hardware-nuts would love it - they spend enough time talking about clockspeeds and megahurtz that I'm sure they'll have good fun with a screenshot of the shader-complexity of a commercial game [lol]

Jack

That would be quite easy...just hook into IDirect3DDevice9::SetVertexShader() and IDirect3DDevice9::SetPixelShader(). Then count up how many changes you have per frame. You can do *all* kinds of performance analysis like that.

p.s. IIRC the effect framework still uses Set*Shader() in its underlying implementation

Maybe I'm missing something here, but isn't that exactly what PIX does?