I can't for the life of me figure out what exactly causes the problem.
My ingame FPS drops to 60 from 120 after a second or two delay of having players physically close to me (it seems) or having many ESPs on my screen at once. Upon certain conditions, there's another second or two delay and my fps goes back up to 120. It's a very dramatic change.

The problem doesn't seem to happen when I prevent the ESP from getting X/Y screen coordinates and just having the ESPs draw in the upper left hand corner. This is unrelated to the actual fetching of the coordinates, apparently.

Edit: added in your line functionalityhttps://imageshack.us/scaled/landing/707/lineze.png
With only lines, it's significantly less laggy. I only get screen lag when a player gets close, not dependent on how many lines are on the screen. The problem persists even if the overlay isn't over MW3, just sitting in the background.

Edit: Added in a really shitty "radar" http://i50.tinypic.com/120m9sj.png.. Now, if only I knew how to find the map sizes so I could scale things on a radar image.
Another problem with the overlay is when you click, it creates lag because mouse clicks focus the overlay. The workaround is to set your fire/ironsights buttons to keyboard keys.

@Naka, no idea sorry. Strange though how moving the values into a local variable fixes the problem. It could be that the compiler optimises the code better that way. Also declaring the current player as a temporary variable might improve performance instead of fetching it each time using the index.

Also for the mouse issue, try setting the IsHitTestVisible property of the Window in the XAML code to False.

Great to know that someone actually knows what they are doing. Keep up the good work.

Last edited by master131; 10-29-2012 at 01:45 AM.

Donate:BTC: 1GEny3y5tsYfw8E8A45upK6PKVAEcUDNv9

Handy Tools/Hacks:Extreme Injector v3.6.1*NEW* Windows 10 compatible!
A powerful and advanced injector in a simple GUI.
Can scramble DLLs on injection making them harder to detect and even make detected hacks work again!

@Naka, no idea sorry. Strange though how moving the values into a local variable fixes the problem. It could be that the compiler optimises the code better that way. Also declaring the current player as a temporary variable might improve performance instead of fetching it each time using the index.

Also for the mouse issue, try setting the IsHitTestVisible property of the Window in the XAML code to False.

Great to know that someone actually knows what they are doing. Keep up the good work.

I wouldn't go so far as to say I know what I'm doing.
I think you may have misread though, nothing stops the issue besides preventing the rendering of text/lines/boxes. Though it was already obvious, having the local variables populated with the positions just showed that it's the canvas.setleft/canvas.settop causing the issue. Having lines (no canvas.setleft/canvas.settop, just line start and end positions) shows that it's not just a problem with setleft/settop. I'm thinking you should have similar issues to me, have you tested it much?

I wouldn't go so far as to say I know what I'm doing.
I think you may have misread though, nothing stops the issue besides preventing the rendering of text/lines/boxes. Though it was already obvious, having the local variables populated with the positions just showed that it's the canvas.setleft/canvas.settop causing the issue. Having lines (no canvas.setleft/canvas.settop, just line start and end positions) shows that it's not just a problem with setleft/settop. I'm thinking you should have similar issues to me, have you tested it much?

No, not anymore, just in-case VAC does something dodgy. There is an alternate method to move objects, and it's using the RenderTransform properties. Something like this:

Handy Tools/Hacks:Extreme Injector v3.6.1*NEW* Windows 10 compatible!
A powerful and advanced injector in a simple GUI.
Can scramble DLLs on injection making them harder to detect and even make detected hacks work again!