Quote (Muted @ Dec 19 2009 03:07am)
I get you all mixed up, but anyways, your post was extremely childish.
Because that's pretty much how you talk?
Quote (Muted @ Dec 19 2009 03:07am)
Aren't you the one who cares so much about optimization, that's why you use OOP over structural?
OOP and structural paradigms make no implication for efficiency. Protip: A working, inefficient algorithm is better than a non-existent one.
Quote (Muted @ Dec 19 2009 03:07am)
There's more than one way to do what I want, and what I want, isn't hard to do.
I just haven't learned enough to be able to wing it on my own, like I usually do.
That's why I offered a solution for you. However, you just decided to take the usual "I DON'T UNDERSTAND SO YOU'RE AN IDIOT" route that you take in every single topic.
Quote (Muted @ Dec 19 2009 03:07am)
If that's hard for you to accept, sorry. But anyways, if I really wanted to, I would do it the way you're saying.
I was just trying to be more 'efficient,' for a change.
Like Minkomonster said -- my solution is linear with the size of the image. I highly doubt you can beat that. In non-Big-O terms, you might be able to shave off a few cycles by avoiding the checks for function calls (and only a few cycles -- all the values will be in the L1 cache), but it is going to be safer to let the Windows API do the checking for you. It will also be more extensible, if you wanted to do comparison at beyond the bit-level, although you would probably be better off with OpenCV (as I've suggested before). Since you've been completely unclear as to what you actually want, I really can't help you.