2009-10-02, 09:43 PM
I was up late last night inadvertently taking a stab at this.
Basically I started working from the "game trainer" angle, but soon realized there was no real way (I know of yet) to debug this from a traditional debugger pov. So I thought it might be a good idea to take a detour into ways to integrate graphical debugging tools directly into the SoM runtime's execution (which beats the hell out of debugging via logs anyway) ...So in order to get (intercept) some basic info about the SOM process, I had to replicate the first level of the DX API. I looked into how many functions that would be, then decided I could live with it, and so I did...
The first problem is not even a message box seems to work in fullscreen mode. Having a message box being the child of the SOM process seems to make the screen go black and basically Vista at least completely useless short of taskmanager. I guess this means message boxes and fullscreen mode are a no no.
So anyway, I also felt like trying to get SOM out of fullscreen mode. Doing this wasn't too tough, but for reasons I don't yet know, this forces SOM to go into software "RGB emulation" mode. Furthermore I can't get SOM to play nice with a normal captioned/border window. I think this is because even though in fullscreen mode SOM is requesting the device context for the entire window and not just the client area (the box inside the window where the application goes) ...since SOM's "window" is technically undecorated this seems like overkill, but anyway, this mean SOM draws over the caption/border. There is no way by this technique to change this behavior since it's not part of the DX api. The only possible way might be to proxy the WindowProc, but that might be a little dangerous (if even possible... though if possible, doing so would let us know when SOM calls the DX API within it's control flow)
One way that might be possible, is to try to spawn a window, and then try to make SOM's window its child (go inside the new window) ...however that would still force SOM into software (non-accelerated) mode at present. Still something I will definitely look into at least for debugging purposes.
Interceding in SOM's graphical routines might require further replicating the API. I'm not sure. It might also be safe to just draw shit whenever... I don't know enough about DirectX personally. It's my last graphics API of choice in the whole wide world. I've even learned a lot more than I cared to know about the Windows API fooling around with this stuff.
Anyway, I think I've experimented enough for now (and frankly worn myself out) ...so I will just get back to blindly developing that multi-threaded memory mapper. Or maybe try harder to find a way to properly debug it (probably depending on how things go)
Basically I started working from the "game trainer" angle, but soon realized there was no real way (I know of yet) to debug this from a traditional debugger pov. So I thought it might be a good idea to take a detour into ways to integrate graphical debugging tools directly into the SoM runtime's execution (which beats the hell out of debugging via logs anyway) ...So in order to get (intercept) some basic info about the SOM process, I had to replicate the first level of the DX API. I looked into how many functions that would be, then decided I could live with it, and so I did...
The first problem is not even a message box seems to work in fullscreen mode. Having a message box being the child of the SOM process seems to make the screen go black and basically Vista at least completely useless short of taskmanager. I guess this means message boxes and fullscreen mode are a no no.
So anyway, I also felt like trying to get SOM out of fullscreen mode. Doing this wasn't too tough, but for reasons I don't yet know, this forces SOM to go into software "RGB emulation" mode. Furthermore I can't get SOM to play nice with a normal captioned/border window. I think this is because even though in fullscreen mode SOM is requesting the device context for the entire window and not just the client area (the box inside the window where the application goes) ...since SOM's "window" is technically undecorated this seems like overkill, but anyway, this mean SOM draws over the caption/border. There is no way by this technique to change this behavior since it's not part of the DX api. The only possible way might be to proxy the WindowProc, but that might be a little dangerous (if even possible... though if possible, doing so would let us know when SOM calls the DX API within it's control flow)
One way that might be possible, is to try to spawn a window, and then try to make SOM's window its child (go inside the new window) ...however that would still force SOM into software (non-accelerated) mode at present. Still something I will definitely look into at least for debugging purposes.
Interceding in SOM's graphical routines might require further replicating the API. I'm not sure. It might also be safe to just draw shit whenever... I don't know enough about DirectX personally. It's my last graphics API of choice in the whole wide world. I've even learned a lot more than I cared to know about the Windows API fooling around with this stuff.
Anyway, I think I've experimented enough for now (and frankly worn myself out) ...so I will just get back to blindly developing that multi-threaded memory mapper. Or maybe try harder to find a way to properly debug it (probably depending on how things go)