   game cameras with D3DXMATRIXLookAtLH
  I'm trying to create a hook that will move the camera around in a game (this is for 3d stereo vision). I was thinking that maybe I could hook the D3DXMATRIXLookAtLH and D3DXMATRIXLookAtRH functions. This has to work on most modern games so my question is this.. Do most modern games use these functions to calculate the camera matrix? Also, if anyone knows another way to do this or flaws in this theory please let me know.Thanks,Lance   
Quote:Original post by chavez98I'm trying to create a hook that will move the camera around in a game (this is for 3d stereo vision). I was thinking that maybe I could hook the D3DXMATRIXLookAtLH and D3DXMATRIXLookAtRH functions. This has to work on most modern games so my question is this.. Do most modern games use these functions to calculate the camera matrix? Also, if anyone knows another way to do this or flaws in this theory please let me know.Thanks,LanceUnlikely to be a flawless method unfortunately. Issues:- Some games use earlier versions of D3DX that were provided as static libraries rather than DLLs. For the static libraries, those functions will be linked in, so there's nothing you could easily hook (i.e. no D3DX functions in the imports section of the PE).- LookAt matrix computation is the kind of thing that a company will have in its own proprietary maths libraries since it's not a high frequency operation that benefits from CPU-specific optimisation.- If the company who developed the game also develops for other platforms, then it's even more likely they'll be using proprietary libraries for most of their maths since D3DX isn't available on non-MS platforms and most people prefer not to write the same code multiple times...- Screwing with someone's view matrix could have implications for any view dependent things like specular lighting and environment mapping.Thoughts:- If you know the game(s) you want to hook are using the old D3D fixed function pipeline, you could hook the SetTransform() call instead and intercept any D3DTS_VIEW matrices; most game view matrices will be nice and orthonormal so no nasty decomposition woes.- If the game(s) use vertex shaders, 'some' space positions as input and homogeneous clip space positions out is about all you can rely on as known from the shader-pipeline black-box. - If I were really forced to (I really wouldn't want to) get some view information from that black box, off the top of my head, I'd probably 'attack' the vertex shader first. e.g. maybe duplicate any created vertex shader bytecode/microcode and constant setting calls, then make my own software shader parser to work back from oPos to get the transformations that happen to get to HCLIP; or maybe something using ProcessVertices() and a SWVP clone of the shader. All ugly, nasty, and far from foolproof - urgh!   ;  So do you think it's pretty much impossible to create a reliable hack of this kind that would work for most modern games?