Sign in to follow this  
vanHell

Ingame overlay like Fraps

Recommended Posts

Simply put, this is very difficult. You can overlay stuff on top of other DirectX applications (for example a sprite or something of that nature), but it is *very* in-depth, and is no easy undertaking.

First, you must make your own D3D dll by inheriting the IDirect3D and IDirect3DDevice9 interfaces, placing your own custom code where necessary. For example, if you wanted to render your own stuff, you would put it in your definition of EndScene(), before calling the base EndScene().

Then, you have to hook into the application, and make sure your specific D3D device is created. It's quite tricky, and this is only a (very) high-level overview.

Share this post


Link to post
Share on other sites
I haven't actually done this yet, but I understand what you need to do...

Like circlesoft said, the first part is writing pass-through classes for all of the DirectX (I haven't looked at how OpenGL works, but it's probably similar) interfaces.

The hard part comes when you need to get the game to use your interface. You have to modify the game so that it will create YOUR classes rather than the standard classes.

So, when a program is loaded, the system looks at a certain place in the program and finds out what .DLLs it needs, and which functions from those .DLLs it calls. There are usually two hardcoded tables, one of which is where the loader will write in the address of each DLL imported function. For DirectX, there is ONE function that the program will have in this table per DirectX subsystem that you use: Direct3DCreate8 is the only function in the table for Direct3D 8. Once the program calls that function, it receives an interface that it can use to get access to all the other interfaces (IDirect3DDevice8, IDirect3DSurface8, etc). All you need to do is load your .DLL and replace the old Direct3DCreate8 function pointer with YOUR version of the Direct3DCreate8 function.

When the program wants to call Direct3DCreate8, the program goes to the function table, grabs the address that the loader put in there, and calls that address. So you don't have to go in and rewrite any assembly code like I've seen in some tutorials on this.

As for actually being able to get access to the game's memory before it calls that function, I think there are two options: You can create a global windows hook in which you should be able to handle a function call each time a process launches, or you can create a loader program that starts the game in a suspended state, makes the required changes, and then resumes the game.

You'll have to search around to find the neccessary documentation to do all of this, since I don't remember all of the structures and functions to do all of this.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this