When I run this, my computer gets really laggy and slow, would any one know a more faster and efficient way to do this?

#1 You have a really sub par pc if it is lagging you immensely but read farther down.
#2 That command uses a windows command of getpixel which is utter shit in the speed department.
#3 In ACTool that is the only way you have.

GetDIBits is a replacement for GetPixel but it is not nearly as easy to use and in an ACTool type environment would be hideous to attempt.

In my macro I scan for about 300 pixels the length of a bar and using GetPixel (LoadRGB/ISColor/Etc... in ACTool) it is so slow that I had to skip every 8 pixels to have it semi reasonably fast but it still lagged.

Now using GetDBIbits (C++) you have to bitmap the screen then use the bitmap to scan for your colors. When done right (in your case for example) the speed gained is astronomical. I went from 4-5 secs (3-4 secs when doing +8 scanning) down to .03-.04 secs. This is not ACTool's fault but it is the Getpixel commands fault and let me explain why (for everyone and future readers who stumbled onto the horribly slow commands of LoadRGB and ISColor).

When you ISColor or LoadRGB windows allocates some memory that will hold a screenshot of the desktop then it actually takes a snapshot of the desktop and stores it. The next thing it does is calculate some weirdness math (trying to keep this explanation simple) of where the pixel is in the buffer that is holding the screenshot of the desktop. Once Windows has the true location of where your coordinate's bytes actually are it grabs them and stuffs them into a colorref then it frees the buffer that is holding the screenshot. Once the buffer is free it returns the colorref that is the RGB, and possibly A, of the colors that are at the coordinates you specified. All of the aforementioned steps is being taken each and every single time you call a color command and this is why it is horribly slow.

Now the above is exactly how GetDBIbits() works because this is just how Windows works but here is where we as programmers of C/C++/C# etc... have it better because what we can do is do all of the above steps ourselves but before we free the buffer that holds the screenshot we simply do ALL of our color checking at X,Y then, and only then, free the screenshot buffer for the next trip around. The savings in speed is truly jaw dropping.

The thing is if you are grabbing just one time (meaning you are using only one color command like LoadRGB once per trip through) each loop through there is no time savings at all. In your instance of looking up the color at three locations you would see way less lag using the above but the GetDBIbits() method is not how ACTool works so you really are SOL.

Something I am wondering is if the three places you are checking can all have that color simultaneously. Can it? I ask because your code is written as if all three places *might* have those colors and need something clicked. If one, and only one, of those three places, at any time, might have one of those colors then your logic is failing. If ALL of those locations, at any time, might have one of those colors then your code is fine (I would use a procedure) and there is nothing you can do for speed. As far as lag is concerned you are in a loop (that while 0=0) that never rests between iterations. Slap a Delay 20 before that end statement and see if that helps your computer's lag issues.

Actually, I would bet the primary problem is the lack of any DELAY, period, in the entire macro.

Your code is causing ACTool to hog all the CPU time, yielding none to whatever game process you're trying to grab the screen from.

Try a 50 millisecond DELAY before each screen grab to yield some CPU time to the game itself.

I think that as well as I noted about the delay 20 but LoadRGB is extremely slow and just googling about GetPixel shows the cries from the masses for something faster. In his situation that code needs a delay and it needs a procedure and it needs to be clarified because I see it checking all three places but not a single "skip over the follow checks if this one passed". Basically, the code, is in a horrible state but they must be a newbie so I cut them some slack for that.

btw, between you and I, Ipa, I seriously think it could be done in ACTool (I see no reason why not) but it would not be as simplistic to use for the masses. Back in our day, when this place was full of choice and adventurous people, we would have eaten such a command up but these days the script kiddies would choke and fall back in it.

This is only a piece of my bot. Suprinsgly the game I play is very very simple so it works without procedures. Currently I am working on an upgraded version of my current bot with procedures, I suppose the small "pickit" script I wrote will work alot faster when executed after a monster is killed, do a quick load for those spefic pixels and move to the next procedure. I am still new to this but I am learning pretty fast, I will post the bot I am currently working on with procedures when I get home later tonight. I have a lot of questions to ask and a lot of searching to do!

Thank you for all your help!

We never mind real questions so ask away.