Pixel Scanning Develpoment

[LiX]

Many threads here mention that their method of pixel scanning is slow. I would just like to know how long it takes your method of pixelscanning to scan the entire screen pixel by pixel?

I have created a method that takes about 3 seconds (roughly) to scan a 1024x768 window.

I have an idea that would increase the scan speed, making it scan the whole window in less than 500 miliseconds. In theory, my idea should work.

[roundknot]

And what is your idea? For some reason, it takes me 15 seconds to scan a 1024x768 area, so mine is slower than other systems.

[LiX]

Well, it's more likely to be the method.

Explain how your Pixel Scanning method works.

What I am doing is taking a snapshot of the window and then scaning it from the memory using GetPixel.

However I have an idea that would work better.

[weakbarb]

I haven't try scanning the full screen yet. What are you benchmarking it against? The time to read all 1024x768 pixels? Or grabbing and comparing against some values before going to the next? Let me know and I will do a test on mine.

[LiX]

Read all 1024x768 pixels.

[roundknot]

Well I am only using AutoIt, so I think that is the problem, what scripting are you using?

[LiX]

I code in C++.

[weakbarb]

Will let you know about my test.. Coding in vb though, not very low lvl

[LiX]

Ah VB, it's bound to be slower in VB than it would be in C++.

[Ultima]

why does it take so long to scan for you?

i scan multiple times per second^^

[LiX]

Well it also depends on the power of your computer, I am running a 2.80ghz Intel Pentium 4 Processor.

Ultima are you using GetPixel or GetDIBits. Using GetDIBits I could scan a shitload faster than I currently am. :P

[Ultima]

Originally posted by LiX@Jun 19 2005, 20:24
Well it also depends on the power of your computer, I am running a 2.80ghz Intel Pentium 4 Processor.

Ultima are you using GetPixel or GetDIBits. Using GetDIBits I could scan a shitload faster than I currently am. :P

i have just poor 1.4 GHz ^^

and i use delphi so maybe my way to check is just faster

cause i reduce the amount that is scanned cause i dont need the whole screen

[S.O]

it takes about 2 secs to do a 2 for-loops to read all pixels
(colorfinder method)

when it takes a second or so to do actual screenie

problem is, in 3 secons - the crappy mosnters move!

so when i find them and try attacking - they're not there anymore

2 ways out of that one

A. scan REALLY fast (and the whole screen!)
B. read from memory the coords of the monsters and you and tilt of the screen - calucalte and voila! attack in less than 0.01 seconds (but, i donno how to do that!)

some data: Pentium 4 1.5GHz, 1256MB RDRAM 800Mhz, AGPx2 GeForce MX 200 (****), programming in C# v2003 (might make things slower!)

if you can create a com function in C++/ASM to find a color real fast, i'd appreciate it very much (should have the box within to check, coords of where is "center" - to find closest first, and the color)

thanks a bundle

[roundknot]

Hmmmm, well if there is something in our memory that has the postions of all the monsters on our screens, that would be the best. Could someone do a TSearch for that when the servers get back up?

[w0rf]

Not to forget to mention the greatest issue, lag/ping. But basically, I don't see how it would differ much with you clicking on it, or having something search for it.

From what I've done with various types of Pixel Searching (C++, some Delphi, and some scripting engines like AutoIt or even SCAR) they all seem to work fine. I really doubt a 3 second delay would really be that much, especially when dealing with monsters. If you were talking about PvP, it would be different, but then again, system specifications and also internet connection, etc. would affect it all.

You could have 300 ping on a server (my average ) and someone else might have 475 ping at the time, and so it would basically make no difference whether it's a 3 second pixel search delay or a 500 millisecond, it's still going to suck.

Also, I doubt anybody would really be training on anything higher than what they know they can handle, so a 3 second delay or less wouldn't really matter, unless you can't stand taking 1 damage from a Bandit :P

There are various things out already such as Conquer Partner which seem to do just fine, and I doubt that is very advanced in the whole Pixel Searching methods.

If this was some other game such as Counter-Strike and you were doing a color 'aimbot', which I know LiX has, then I guess it would need to be more technical, but as a fact, Conquer is just like, a point and clicker.

It doesn't take any skills except a strong finger and eyesight...not even good coordination

So what I'm saying, is 300 ping and 500 Milliseconds against 300 ping and 3 seconds of a pixel search delay, isn't really going to matter.

You also have to look at the fact that on average, there is around 3-5 monsters on your screen at the same time, if you're hunting anywhere...especially Elfapes or somewhere like that. You're bound to find one of them in less time than 3 seconds, which really isn't that much at all.

It's not like making a Pixel Searching hunter for you is going to be much different than just clicking a monster yourself, it's doing the same thing, but...faster. So that means, we all know we can click a monster right now if we were playing and we'd go attack it, even if it did move, we'd go to where it moved...the bot would be doing the same thing at the same speed if not faster...