Автокликер Clickermann :: Форум
Основной раздел => Общие вопросы => Topic started by: АНТИКЛАН on February 03, 2015, 12:14:15 AM
-
Всем привет!
Интересуют именно механизмы по которым происходит поиск. Если можно поподробнее кто знает :)
-
с лева на право и с верху в низ
-
с лева на право и с верху в низ
А еще подробнее? :D
-
ещё подробнее специально, персонально и только для вас всё очень-очень подробно описано в встроеной справке.
может вам, там нехватает Шрифта Брайля 8) 8) 8), ну для полного щястя?
Ну данных в справке достаточно только для того чтобы использовать функцию. Мне же интересно больше. Например как происходит сравнение образца с буфером анализа. Как функция узнает что нужно начать сравнивать. Может она ищет первый пиксель и потом выхватывает область равную размеру образца и потом сравнивает ее на основе контрольных сумм или как то по другому? Хочется знать вот это. :)
-
думаю поиск картинок происходит так же, как поиск пикселей, только после нахождения первого пикселя картинки - ищется второй, если совпадает - третий и так далее, если не совпадает - идем дальше, если включен % совпадения, то некоторое количество ошибок игнорируется
-
ну в принципе как Луций написал, так оно и делается.
идея с контрольными суммами интересная, но в нее не впихивается ни здававаемая погрешность, ни возможность игнорировать фон.
способ крайне топорный, но изза высокой скорости, реализованной на всяких хитрых механизмах (иногда вызывающих интерес http://zhyk.ru/forum/showthread.php?t=495376) в принципе вполне приемлем как рабочий. суть в том чтобы минимизировать операции, учитывая что приходится раз за разом работать с тысячами пикселей. поэтому всякие подсчеты - это лишние милисекунды.
если кто-то придумает еще какие нибудь хитрые алгоритмы - буду рад почитать.
-
если кто-то придумает еще какие нибудь хитрые алгоритмы - буду рад почитать.
Помимо каких? Мы же не знаем какие оптимизации уже применены.
А что если два варианта? Если параметры прозрачности/процента не заданы попробовать считать контрольную сумму области. Хотя наверное быстрей не будет. Для образца то считается 1 раз, а для области - много.
Читал ещё на Ai народ пытается загонять в строковую переменную и искать подстроки. Ещё в массив и искать вхождение. Но там встроенных средств мало. Для картинок вообще нет, только пользовательские библиотеки. Вот и мудрят.
-
А что сравнивается? Значения цветов? Про взятие области равной образцу я правильно подумал?
-
А что сравнивается? Значения цветов?
Да.
Про взятие области равной образцу я правильно подумал?
Не совсем, сравнивается последовательно образцу. Да в пределах области, но в любой момент при несовпадении всё прервётся.
-
Не совсем, сравнивается последовательно образцу. Да в пределах области, но в любой момент при несовпадении всё прервётся.
То есть он находит первый совпавший пиксель и начинает сравнивать последовательно дальше без локализации области для сравнения. Но так он легко же может выйти за пределы размеров образца а там уж точно будет отрицательный результат...
-
Ну конечно построчно образцу. Ничто никуда не выходит.
-
Ну конечно построчно образцу. Ничто никуда не выходит.
То есть найдя совпадение с первым пикселем образца выхватывает область равную по размеру образцу и уже в ней сравнивает пиксели так?
-
Не знаю так или не так. Но логично предположить: зачем что-то "выхватывать". Расчёт позиции следующего сравниваемого пиксела производить на лету.
Берём пиксел образца. Берём пиксел экрана. Сравнили.
Если совпадает или количество допустимых несовпавших (%) не превысил...
Берём следующий пиксел в ряду и экрана нарастив X.
Если привысили ширину образца переходим на следующий ряд наращивая Y и там и там и возвращая начальные X.
Не понятно зачем ты это спрашиваешь? Чем это поможет?
-
Не знаю так или не так. Но логично предположить: зачем что-то "выхватывать". Расчёт позиции следующего сравниваемого пиксела производить на лету.
Берём пиксел образца. Берём пиксел экрана. Сравнили.
Если совпадает или количество допустимых несовпавших (%) не превысил...
Берём следующий пиксел в ряду и экрана нарастив X.
Если привысили ширину образца переходим на следующий ряд наращивая Y и там и там и возвращая начальные X.
Не понятно зачем ты это спрашиваешь? Чем это поможет?
Это нужно при создании образцов. Программа не всесильна и поэтому для более стабильной работы нужно облегчать работу ей.
-
Это нужно при создании образцов. Программа не всесильна и поэтому для более стабильной работы нужно облегчать работу ей.
не нужно кликер может сам создать "оразец" стабильность зависит от конкретного применения. ну или прямоты рук... впрочем есть у меня на практике пример когда игра специально вносила изменения в изображение. на практике все решилось не через IF_PICTURE_IN т.к получалось медленно.
-
С образцами давно всё понятно. Размер - небольшой. Стараться чтоб не попадали шрифты, сглаженные края и фон. Для ускорения не увлекаться процентом совпадения и стараться чтобы начальные пикселы образца были поуникальней.
Например черный градиентный шарик на белом экране. Вырезать следует часть шарика, чтобы вверху- слева и вверх не было пикселов фона. Лучше правую нижнюю четверть для понятности.
Очень хороши в некоторых случаях тонкие длинные полоски толщиной в 1-3 пиксела. Особенно на текстах. Вместо всей строки по высоте. И начало должно начинаться с цвета текста.
-
а может, к примеру, IF_PIXEL_IN искать в обратном направлении?
-
а может, к примеру, IF_PIXEL_IN искать в обратном направлении?
Нет. Но можно воспользоваться scanpxl, она соберет все найденные координаты в массив а нам нужно только кликнуть по последней координате.
getscreen
// поиск всех красных (255) пикселей в области 0,0 - 1250,959
scanpxl($var, 0,0, 1250,959, 255)
// вывод массива, содержащего результаты поиска
$size = arrsize($var)
while ($size > 0)
$y = arrpop($var)
$x = arrpop($var)
LCLICK($x,$y) // кликаем по последней координате
WAITMS(50)
$size = 0 // и прерываем цикл
end_cyc