Lytus

I've adjusted things to decrease processing time and increase functionality. Here's a sampling: Dim $result While $xwidth <= $width - 1 Select Case $column[$xwidth] = 3 AND $column[$xwidth+1] = 3 AND $column[$xwidth+2] = 9 AND $column[$xwidth+3] = 3 AND $column[$xwidth+4] = 4 $result &= "$" $xwidth += 4 . . . Case Else $xwidth += 1 WEnd ;_OCRrow: Handles collisions in the column pixel counting function by evaluating the rectangle that contains the letter by row ; rather than column, increasing detection. To use, just call this function in the above case statements where there are two ; different letters with the same column pixel count. ;Parameters: The width of the CURRENT letter (not the width of the entire segment), the height of the segment, the char array ; that contains the bitmap in hex format, the current color of the numbers/letters you're looking for in hex, and ; the particular case you're dealing with (p v. b; q v. d; etc.) Func _OCRrow($width, $height, $char, $charColor, $case) $p = 1 Dim $row[$width] For $xheight = 0 To $height - 1 For $xwidth = 0 To $width - 1 If $char[$xwidth][$xheight] = $charColor Then If $p = 1 Then $div = $xwidth $p += 2 EndIf $x = $xwidth - $div $row[$x] +=1 EndIf Next Next Select Case $case = 1 ;etc. Case $case = 2 ;. Case $case = 3 EndFunc Keep in mind that I just wrote this quickly and haven't tested it, but I hope folks get the idea. The Case block will keep the CPU from checking every single If statement, and I also made it skip over areas once it's determined that the space is occupied by a character. The old version would start looking for a new character in the middle of an old character, and it's safe to assume that characters do not start in the middle of other characters. Thanks a ton for the original code. I hope this helps.

Yea, he has row and column backwards. I have a suggestion on augmenting this code to allow for more accurate character identification: 1) Expand the function to _OCR($Ax, $Ay, $Dx, $Dy, $CharColor), where $CharColor is the hex value of the color, and replace the "000000" with $CharColor (could make it optional, too, and have it default to black) 2) You know the width of the characters that are giving you trouble are the same, so just use that width and count pixel colors by row instead of column. Hence, "b" and "p" will look the same by column but not by row. Keep in mind this still won't work with some cases, such as / v. \, but I'm sure there's a way to do some more CPU intensive algorithms to tell these 2 apart. It's just an idea right now cuz it's late for me. Hopefully I'll have some code samples up in a few days.

That should work! My last question: I am unfamiliar with window's process priority. Will setting it to realtime be guaranteed to prevent it from switching to any other program with normal(default) priority?

Oh, my 1% chance is Train Wreck!

Thank you for the response, Valik. I was hoping there was a code version of this in AutoIT rather than physically going to the task manager and increasing the process's priority, because I'd like a particular segment of the code to be atomic and not the whole program. If I would have to write my own C or C++ code to do this then it may be easier to just change the priority and adjust my program accordingly. My apologies if some folks didn't understand what I meant in the question. Valik gave a great response. For anybody interested, you can read about it here: http://en.wikipedia.org/wiki/Context_switch. This is useful if you have an event-driven program, where the environment is changing (like a bot for a game GUI), and the program does the right thing 99% of the time and a seriously wrong thing 1% of the time. This occurs because your program could be finished processing the GUI and starting on your program's response, when a context switch happens and the game changes state. Your program will execute based on the erroneus game state, and the affects can range from not noticable to train wreck.

Is there a way with AutoIT to prevent context switches in windows?? I've looked around a bit and cant find one.

You're missing a parameter for MouseClick(). You can look it up here: http://www.autoitscript.com/autoit3/docs/f.../MouseClick.htm ----- My apologies if bumping this topic causes grief, and my gratitude to the original supplier of this DLL. When used in a loop, "image_in_clipscreen_rects" causes a memory leak that will eventually crash the program. If you want to see for yourself, just run an infinite loop with the single function call "image_in_clipscreen_rects" and watch the memory usage climb, eventually crashing. I'd like to know the following: 1) Could this get fixed? 2) If this DLL has gone to the graveyard, is there a DLL that does the same thing w/o a leak? It would be a pity to have to dump the use of this library because the garbage isn't cleared.