- #MOUNT AND BLADE WARBAND KEYS REGISTRY KEY APPEARS DRIVERS#
- #MOUNT AND BLADE WARBAND KEYS REGISTRY KEY APPEARS PATCH#
- #MOUNT AND BLADE WARBAND KEYS REGISTRY KEY APPEARS CODE#
- #MOUNT AND BLADE WARBAND KEYS REGISTRY KEY APPEARS WINDOWS#
#MOUNT AND BLADE WARBAND KEYS REGISTRY KEY APPEARS DRIVERS#
Perhaps there are other circumstances involving drivers and or specific system configurations.
Why this causes flickering is unknown, and why ignoring the setCursor fixes it is also unknown.īy setting it to 01, it should completely negate the SetCursor as SetCursor expects a HCURSOR object, and 01 is not a valid HCURSOR object.
SetCursor will always hide it, but D3D can show it again.ĮDIT: - I'd like to point out that after further research the above is actually valid and usual way of handling this according to the Microsoft documentation. This is I believe the heart of the issue. The D3D9::ShowCursor call can be either a true or a false depending on the internal state of the game (eg, FPS mode), but the SetCursor call is ALWAYS set to zero, this is the byte 00 above. There are two operations that occur in the game message pump.Ģ. The cursor is hidden in FPS modes as well. Works perfectly fine for me, completely eliminates all flickering and FPS issues. So strange, it must be some kind of windows/nvidia/something bug.
#MOUNT AND BLADE WARBAND KEYS REGISTRY KEY APPEARS PATCH#
And the method 2 cursor patch "FIXED" it again. So, after playing for an hour, the FPS drops re-appeared. You can always revalidate the steam files to revert any changes anyway. Maybe it'll work for you, maybe not, I dunno. I've updated the exe to NOP out the bytes as suggested, but made it optional as a "method 2".
#MOUNT AND BLADE WARBAND KEYS REGISTRY KEY APPEARS WINDOWS#
There is something here, maybe some kind of conflict between NVIDIA and Windows causing FPS issues in multiple games (I have seen similar reports of lag when the window is focused by the mouse for Star Citizen) that's a bit beyond my ability to understand right now. But can't reverse the FPS gain, I can't un-reproduce what I did to fix my FPS. Eventually I got FS2020 to an acceptable level, and now Mount and Blade Warband no longer has an issue. So, I went to test out a new version that nopped out the command as suggested, but now it no longer flickers, and no longer drops FPS even when it's NOT PATCHED.īetween then and now I was trying to diagnose a low FPS issue in Flight Sim 2020, where, when the mouse was in the window it was stuttering, and outside it didn't at all, so I was messing with a bunch of settings, nvidia graphics settings, Program vs Background services, turning off XBOX DVR and making sure NVIDIA overlay was disabled. Linux and Microsoft have been doing live byte patching for years. I think I'm trustworthy, but I doubt anything I can say will convince you.įinally, on the topic of byte patching to fix a bug. The problem though is if you don't trust my program, how would you trust any program I linked you to now to perform the patching? How would you trust the bytes I have given? Here is a perfectly capable hex editor if you really want: įor reference, the MD5 of the patched program (using method2) should be 7192E798BF9A6C4D27648E9C689BA88F (010 editor can calculate the MD5 for you), so you can know you did it right. If you want to do this yourself, you need to patch those bytes above into the executable. If I had JMP or CALL instructions in there, that would be cause for concern since that implies some kind of trampoline, and could cause jumps out to other parts of the system. It's really hard to pinpoint though as not everyone experiences it and I don't have the Warband sourcecode.Īnyway, the nops and pop are pretty basic X86 instruction code, but if you don't have experience in X86 assembly, it may look a bit strange. I suspect this is a bug somewhere in either Windows UI code, or in the graphics drivers.
#MOUNT AND BLADE WARBAND KEYS REGISTRY KEY APPEARS CODE#
I want to make it clear this is a workaround, and the original code is actually doing what the Microsoft documentation recommends. I suspected it might be something to do with the setcursor being called too many times, so the byte patching removes that part of the code that calls the setcursor. The rationale behind this attempt is that there appears to be some relation between cursor and LOW fps. The 0x5f is a POP EDI instruction (to clean up the stack), the rest (0x90) are NOPs (x86 for "no instruction"). The second one comments out the setcursor entirely. In the first case it changes a register to always force the mouse cursor to a specific handle, which isn't the best solution. I've explained what it attempts to do but I'll do so again. It's not a virus, but you don't have to take my word for it.Ĭhange the bytes at 0x216fa8 to 0x5f, 0x90, 0x90, 0x90, 0x90, 0x90
0 kommentar(er)
