Ingame overlay like Fraps
Author
Hi,
Anyone knows how to make a ingame overlay like Fraps FPS counter or XFire ingame chat??
Somthing which looks like a OSD in Games.
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.
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.
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.
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.
You might want to check out Microsoft Research's Detours library.
There's also a whitepaper describing what it does and some possible uses.
There's also a whitepaper describing what it does and some possible uses.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
