gta2patch.exe (7 kb)

Please bear in mind that this patch is VERY ghetto. It doesn't even check if you are patching the right version, so USE AT YOU OWN RISK!
For the details, the source code and the alternate methods (if you don't feel like downloading and launching an executable from an unknown source), hit the jump.

I won't go into big details but it seems at some point the code to detect whether or not your graphic card is capable of handling high resolution screws up decides that it can't and falls back into "safe mode" by setting a flag. For another weird reason, the flag is not set when a registry key is.
Try to set the DWORD key skip_frontend to 1 under HKEY_LOCAL_MACHINE\SOFTWARE\DMA Design Ltd\GTA2\Debug and it should launch the game at high resolution. The problem is, the game fails telling you that it can't open some file. Whatever.
So what did I do, well, I simply patched the fail-safe code, by forcing high-res.

If you want to patch it yourself, take you favorite hex editor and open gta2.exe. Go at offset 0x000CB2C9, and replace 74 1D by EB 1D (forced jmp ftw).

Finally, if you want to compile the patch yourself (some people do I guess!), here is the code! I told you it was ghetto!

• Creating a new 3D object (not CWindow3D)
• Tying it to the original 2D CVisual Window
• Creating the 3D viewport
• Setting the 3D viewport view matrices

What's missing is the command to tell MIL to display the viewport. And of course everytime I test I have to restart the DWM because it crashes (hence the 2nd computer).
Anyway, I'll keep you guys informed of how everything falls into place, and release a DWMaxx demo pretty soon.

Anyway, you can now find everything on the DWMaxx Google Code project page.

On a side note, I've been working pretty hard to get 3D window rotations working. I think I'm on something, but it might be trickier than I thought (because theses things are quite hard-wired inside the DWM). I'll keep you guys posted.

Once again, pardon my AGP card for the slow capture framerate

DWM uses timing magic to minimize the number of scene rendering is has to do! When idle, for instance, my desktop runs at 2 fps (according to Fraps). And indeed, when I change the size of the my window, the scene doesn't get redrawn. But thankfully, the DWM has also the less known DWM Frame Timing API. Basically, this API allows you to control the rendering frame-rate of the screen, according mostly to "refreshes" (V-Sync) signals. So, indeed, I requested my frame to get redrawn after I change a window size.

Also, I've added the possibility to change the window's position (regardless of it's real position, it's only graphic).

And here's what it looks like, running inside Sinapse (which is being rewritten):

Everything you see is running on a P4E 3.0 GHz with a GeForce 7600 GS (it's an AGP card, hence the 15-20 FPS only).

So, here we go, first demo: True Zooming

Jump for the (quite long I admit) story

Last year (Oct. 2006) I started playing with the Windows Vista's Destkop Window Manager (DWM) API. Like a lot of people, I was really disappointed by the library. The only thing it permits you to do is to have your own live thumbnails... Come on Microsoft! The DWM uses freaking Direct3D, why don't you let us mess around with that!
I knew there a way to extract the window texture (since DWM uses Direct3D9Ex and its marvelous shared resources), so I started a thread on AeroXP.org to expose my progress on this.

I started of by disassembling dwmapi.dll, and it paid off. Here it was, in front of me: DwmpDxGetWindowSharedSurface()! ...and its 32 bytes signature! Damn, that's 8 parameters maximum to reverse! Arg.
But after spending almost 2 months reverse engineering, it eventually paid off. I had a (almost) complete function signature, and even a way to use it.

int __stdcall DwmpDxGetWindowSharedSurface(HWND hWnd,
                                           LUID adapterLuid,
                                           LUID someLuid,
                                           DWORD *pD3DFormat,
                                           HANDLE *pSharedHandle,
                                           unsigned __int64 *arg7);

But there is a "but", the function would return me a correct texture handle but to a black texture! After weeks of trying to tweak the code, I was facing a dead end.
So, taking my courage, I mailed the WPF Architect, Greg Schechter to ask him for help, without much hope about a response. But he did reply (and that was very kind of him to do so), thanking me for my interest into the DWM, but that he couldn't comment on such things (and it's understandable).

And here I was, lonely, facing a dead end. Eventually the project was forgotten on my hard drive (as many others).

But after some months, Jeremiah Morrill followed by work, and scratched some more dust, finding that the texture wasn't black when the window used a Direct3D device, like WPF. And after all, it makes perfect sense. Direct3D applications render to a shared texture given by the DWM, as stated in Greg Schechter's blog:

DirectX window redirection is handled by having the DirectX system, when it's determining what surface to provide the app with to render to, make calls to the DWM in order to share a surface between the DirectX client application process, and the DWM process. This "shared surface" support is unique to DirectX atop the WDDM, and is another key reason why WDDM is an absolute requirement for running the DWM.

But there we were facing the same problem: how the f*ck do we extract the window texture, for all windows?

A few months later, I started talking to Andreas Verhoeven about this (he was doing some reverse on other parts of DWM on his own), and eventually, I revived the project. After a few nights of work, there it was:

The texture relies on hooking IDirect3D9::CreateTexture() to watch out for newly created textures by the DWM, and mark them as shared (GDI texture are not

However, the technique is flawed. The main problem is that the render loop is done asynchronously of windows creation (synchronous with v-sync), there was no direct way to establish a HWND <-> TextureHandle relationship. More importantly, the rendering is done though MIL (milcore.dll), and MIL doesn't have any clue of windows objects, that are handled by uDWM.dll. Pseudo dead end again.

But I didn't stop here, and thank to Andreas, I dug deeper into the DWM. And the results, you saw them at the top of the post
I won't expose exactly what's involved (yet), but it's a combination of internal calls, and API hooking

And for those of you who wonder, yes, I'm working on a library to do all this!