[HELP] Scan for a certain pixel

Yay i did C++

Code:

HDC umad = ::GetDC(NULL); int screenX = GetSystemMetrics( SM_CXFULLSCREEN ); int screenY = GetSystemMetrics( SM_CYFULLSCREEN ); COLORREF rgb; int red; int blue; int green; for(int x = 0; x < screenX; x++) { for(int y = 0; y < screenY; y++) { rgb = GetPixel(umad, x, y); red = GetRValue(rgb); blue = GetBValue(rgb); green = GetGValue(rgb); if(red == 37 && blue == 159 && green == 90) { MessageBoxA(NULL, "Found", "LOL", NULL); } } }

Worked for me /

wow, guys u might get pissed when i say this but it did work after all, it was just so slow at scanning i didn't even realize it was working. Thanks so much guys.

Yeah, maybe consider multiple threads to scan the whole screen, configure each thread to it's own section of the screen, and make each thread scan its section, will be faster. Also, you could consider stepping your for statement by 2 or more instead of 1 pixel at a time, as generally an object will contain the same color in a 2 pixel radius, it wont just be an infinitesimally small dot of color on your screen. Try stepping it by 5 pixels in either direction and if the results are too vague/don't work, then reduce the amount it steps.

Perhaps you could use the GPU in some way. Not sure. Seems the fastest way.
It is built to sample textures and react.
Perhaps a downscaled framebuffer 1/4 of the screen size, sample and render into a 1px framebuffer if your conditions are met, then read from that framebuffer using the CPU and continue with your hack.
yayaya?

Mind you, he did say that it wasn't made to be fast.

Transfering data between the GPU and CPU is a bad idea, it would likely reduce performance quite a bit unless there is some method I don't know of.

Using multiple threads isn't too bad of an idea, and as suggested, you can skip some pixels to find places where the image may potentially be, and then rescan them more closely pixel by pixel.

Pixel scanning aimbots is a really bad idea, esp in 3D games. The idea behind an aim-bot is, you find where all the player data-structs are and use their x, y, z members to locate where the potential targets are. Then take the distance of the closest player and use basic trig functions to find theta(the angle) between yourself and the target, and then aim according to that angle. You'll probably use inverse tan(y/x).

You can use the same thing along the x and z axis for 3D space.

Originally Posted by FknBobNegro

Mind you, he did say that it wasn't made to be fast.

Transfering data between the GPU and CPU is a bad idea, it would likely reduce performance quite a bit unless there is some method I don't know of.

Using multiple threads isn't too bad of an idea, and as suggested, you can skip some pixels to find places where the image may potentially be, and then rescan them more closely pixel by pixel.

Pixel scanning aimbots is a really bad idea, esp in 3D games. The idea behind an aim-bot is, you find where all the player data-structs are and use their x, y, z members to locate where the potential targets are. Then take the distance of the closest player and use basic trig functions to find theta(the angle) between yourself and the target, and then aim according to that angle. You'll probably use inverse tan(y/x).

You can use the same thing along the x and z axis for 3D space.

Yeah, the ideal aimbot is of course to reverse the structs around an enemy player...and all that jazz you were talking about. However, he didn't say it was necessarily for a game, there are a few uses I could think of for a simple color scanner onscreen (not many, but some) that this would work fine for. Another problem with a scan on a pixel to pixel basis is the fact that with such high quality colors nowadays, you're bound to find 1 stray pixel containing your color somewhere you don't expect.

If you really want to go colour I've heard good things about GetDIBits() as a faster function.

ya that's what i am doing now, thanks guys.

Post a Reply

Similar Threads

Tags for this Thread