Dank Tier VIP
- Jul 15, 2018
Game: Prototype 2
Version: Steam Latest (as of 11/07/2020)
Is it just me or do game developers fucking hate windowed mode? Yes it's annoying to handle reset events on Direct X but windowed mode is mandatory if you tend to use your PC for multiple things (like its designed for) such as streaming games. So after picking up the Prototype games on Steam on the cheap during a sale I naturally tried to play it windowed mode. It worked for about two seconds until my cursor left the and dragged a bunch of files into the trash. Nice.
So anyone who's written applications for DirectX will know there's two primary modes dedicated full screen and shared (windowed) mode. In dedicated mode you don't need to worry about anything you have guaranteed full access rendering and keyboard / mouse input. However with windowed mode you have to share your toys with the rest of the applications on the operating system. You need to handle things like ALT+TAB or even a desktop switch without breaking anything.
The mouse in particularly is a pain when you're trying to control it for game input but the user moves the mouse outside your window essentially flipping you off and sending the input to the window next to it. Luckily Microsoft provides two functions to assist with this: ClipCursor and ShowCursor. ClipCursor defines a region of the screen to "lock" the mouse cursor like the game window and ShowCursor simply hides/shows the cursor as required.
So it should be pretty simple a patch right? Inject a DLL take over the window procedure and handle all these events ourselves.
Well not quite:
You see they decided to subclass their window procedure to DInput. This had the delightful side effect of causing a WndProc hook to completely tank the framerate. Why this happens I do not know all I know is the game code is exceptionally fragile you can actually see later after the subclass they pass it off the default handler:
This creates an interesting problem our code needs to execute at exactly the right time. If we steal the procedure at the wrong time we bork the engine code and tank the framerate. Now I COULD have done this the smart way and and installed hooks and had everything call in the correct order and what not but I have my own problems: that is lack of time. The reason I haven't been active much on GH is I have very few minutes per day to dedicate to this type of thing.
Enter the jank:
So, I did what any good hacker does: I improvised. That is to say I wrote garbage hack code until I got it to work most of the time:
AND IT WORKED! Sort of. The capture routines held and hid the mouse on injection but ALT+TABBING caused the window to get shy and hide in the taskbar. No amount of clicking would get it to restore so thinking back to Frostbite I assumed there was some type of routine wrecking up the place.
"I'll give you one guess which routine is causing this".
The prototype devs for whatever reason decided their engine was hot fire and they weren't going to use runtime linking like some scrubs they were going to hide their stuff in their super secret GPA routine.
"Except you know I have a debugger..."
The patch was simple enough:
"Ah 0xE9 how many times have you saved my ass"
And that's it game fully patched and working as expected with windowed mode.
How to use:
Because you're all lovely people I've bundled the patch with a launcher that makes it simple and easy to use (just follow the steps below):
1. Configure the launch options for the game:
2. Extract the files somewhere and run the exe.
3. Launch the game.
- The launcher needs to be running FIRST before you start the game: this is due to the issue I mentioned earlier. If you don't do it this way weird things happen.
- You can you use +/- on your keyboard to manually hide / show the cursor and lock it to the screen. If you're ALT+TABBING a lot sometimes it will get out of sync.
337.3 KB Views: 4