Автокликер Clickermann :: Форум
Основной раздел => Предложения => Topic started by: Vint on February 11, 2016, 08:59:51 AM
-
Предлагаю вернуть если была или добавить функцию
IF_NOT_PIXEL_IN (x, y, x2, y2, color1, ...) - производит поиск пикселя НЕ СОВПАДАЮЩЕГО с заданными цветами в прямоугольной области буфера анализа.
Параметры
x, y - числовые координаты левого верхнего угла области поиска
x2, y2 - числовые координаты правого нижнего угла области поиска
color1, ... - цвета, игнорируемые фунуцией (цвета фона).
Часто очень нужна, без этого приходится городить трёхэтажные огороды по разбиванию поля на зоны с последовательной проверкой или другие извращения, медленные и неудобные.
-
иии,ии,иии, и дополнительный пораметр в ифпикселин (и в ифнотпикселин) - оначающий начальный угол сканирования экрана. 1, 2, 3 или 4 - с верхнего левого угла, с верх.правого, ниж.левого и нижнего правого соответственно. ну и тоже самое с ифпиктуреин :D.
конечно можно и все 8 вариация сканирования добавить, было бы вообще мегакруто.
наглядно
(http://i.imgur.com/wGNHOsl.png)
-
и позвольте спросить начерта? в чем практический смысл искать пиксель не совпадающий?
про направления - туда же. если вы знаете ожидаемое место появления - подгоняйте области.
-
про направления - туда же. если вы знаете ожидаемое место появления - подгоняйте области.
самое очевидное - определение границ обьекта. ну и возможно ще гденибудь поможет :D.
-
таким образом можно определить только границы идеального объекта - прямоугольника. а вот простой ромб уже поставит в тупик данный подход.
-
Он и имел ввиду габариты.
Сейчас для этого приходится много раз искать одно пиксельной строкой или столбцом.
В принципе это всё ещё решаемо через поиск в массив и сортировку массива как нужно. Но сортировка у нас долгая. Тем более по массиву X,Y
и позвольте спросить начерта? в чем практический смысл искать пиксель не совпадающий?
Это же не сложно в отличии от направлений. Почти копи-паст.
А начерта? Часто нужно найти объекты произвольного цвета на равномерном фоне. Иногда можно выкрутится через колормод. Но бывают цвета близкие к фону и колормод их сжирает.
А уменьшать номер колормода... даже на 7 уровне уже 7 поисков.
И всё равно остаётся проблема если цвет отстоит от цвета фона < 0.5 расстояния между цветами в колормоде.
6 режим вообще не реальный с его 64 цветами.
-
не хочу плодить костыли, которые выбиваются из общего стройного синтаксиса. вот это if_четотам с регистрами $_return - смотрится просто дико. теперь.
и все равно считаю что фон можно упростить через cmode до однородного да и пиксели этого вашего объекта все равно известны заранее.
давай пример фона с объектом, посмотрю эту нерешаему без введения очередного костыля задачу
-
Нет сейчас рабочих примеров.
Ну что то типа этого... Только переливов много. Это не реальный проект.
-
Весь в меня. Я тоже долго сопротивляюсь и отказываюсь от непонятных мне доработок :D
Иногда до неприличия, аж самому стыдно.
-
Может проще добавить функцию обработки графики?!
Скажем задаем какие то цвета фона для исключения, а все остальные цвета функция перекрасит в заданный цвет. Таким образом останется только фон а все неизвестные цвета станут одним известным.
Дальше ищем его обычными функциями.
-
Можно и так, но чем это лучше?
Во первых дольше. Два раза нужно обработать графику.
А NOT это в условии чуть поменять и всё.
Можно и то и то сделать. Давно функционал не расширялся.
-
Лучше тем что потребуется создать лишь одну функцию подобную PXLREPLACE. Можно визуально вывести полученное в скриншот. Оценить что мы ищем. Можно даже искать одноцветную картинку по форме объекта.
Как твоя функция будет работать? Находить первый не совпадающий с фоном пиксел? А если надо найти все объекты то нужна уже NOT_SCANPXL что ли?
Во первых дольше. Два раза нужно обработать графику.
Да ладно, несколько дополнительных миллисекунд ничего не решат.
-
насчет обработки графики поддерживаю. бывает часто, что колормода мало, а в paint.net при коррекции можно вывести нужные зоны в нужные цвета.. конечно не знаю как это должно выглядеть, но если бы была обработка примерно как в paint.net - меню коррекция. инвертация, кривые, огрубление(тотже колормод), оттенок и насыщенность, чернобелый, сипея, уровни, яркость и контраст.
конечно это я загнул, прям редактор какойто получится. но если так разобраться, вроде ничего сложного. вся эта коррекция сводится через определенные математические действия с цветами. даже можно их самому написать и менять в буфере через тотже PXLREPLACE, но скорость...... . каждый пиксель менять придется.
во, я даже набросал по быстрому коррекцию в чернобелый:
$x1=578
$y1=962
$x2=718
$y2=1080
print("start")
GETSCREEN($x1,$y1,$x2,$y2)
SCREENSHOTEX($x1,$y1,$x2,$y2)
FOR($y=$y1,$y<$y2+1)
FOR($x=$x1,$x<$x2+1)
$c= pxl($x,$y)
$gray=int((0.299*colorr($c))+(0.587*colorg($c))+(0.114*colorb($c)))
PXLREPLACE($x,$y,$x,$y,$c,COLORGEN($gray,$gray,$gray))
END_CYC
END_CYC
print("fin")
SCREENSHOTEX($x1,$y1,$x2,$y2)
haltбыло
(http://i.imgur.com/tRWRb9A.png)
стало
(http://i.imgur.com/qVNuQBF.png)
на выполнение ушло 16 сек.
-
Пришли отсюда:
http://crapware.aidf.org/forum/index.php?topic=2134.msg23102#msg23102
Для начала замерил у себя перевод в градации серого через PIXELREPLACE на образце 100х100 pxl.
// PXLREPLACE 100х100 10000 pxl
// 8100 ms 0.81 ms/pxl
После попробовал через редактирование буфера.
Код такой:
STRSEPARATE("A:B:C:D:E:F", ":", $arr16) //=== перевод числа в HEX. Выход $HEX =
SUB(toHEX, $DEC)
$HEX = ""
WHILE($DEC > 0)
$cel = INT($DEC/16)
$ost = $DEC - $cel*16
IF($ost > 9)
$ost = $arr16[$ost - 10]
END_IF
$HEX = STRCONCAT($ost, $HEX)
$DEC = $cel
END_CYC
//LOGWRITE($HEX)
END_SUB
SUB(GREYSCALE, $x1, $y1, $x2, $y2)
GETSCREEN($x1, $y1, $x2, $y2)
READMEM($pid, "004E20FC", 4) // читаем адрес начала буфера в указателе
$startbufwr = $_return1 + ($y1*($xmax+1)*4) + ($x1*4) // с этой ячейки начнем
//LOGWRITE($_return1," $startbuf = ", $startbufwr)
FOR($y=0, $y < ($y2 - $y1 + 1))
$adrDECwr = $startbufwr + ($y*($xmax+1)*4)
FOR($x=0, $x < ($x2 - $x1 + 1))
$c = PXL($x1+$x, $y1+$y)
$gray_canal = INT((0.299*COLORR($c)) + (0.587*COLORG($c)) + (0.114*COLORB($c)))
$gray = COLORGEN($gray_canal, $gray_canal, $gray_canal)
//LOGWRITE("$gray_canal = ", $gray_canal, " ", $gray)
toHEX($adrDECwr + $x)
WRITEMEM($pid, $HEX, $gray, 4)
$adrDECwr = $adrDECwr + 3
END_CYC
END_CYC
END_SUB
К сожалению выходит намного медленней, даже с учётом оптимизации
// GREYSCALE = 5.25 ms/pxl
// 10х10 ~555 мс, ~552 мс 5.52 ms/pxl
//GREYSCALE(70, 75, 79, 84)
// 20х20 400 pxl ~2167 мс 5.42 ms/pxl
//GREYSCALE(772, 432, 791, 451)
// 100х100 10000 pxl ~53956 мс, 52431 5.25 ms/pxl
//GREYSCALE(750, 426, 849, 525)
Не просто медленней, а в 6.5 раз медленней. Я надеялся, что запись в память будет намного быстрее, чем не предназначенная для записи одного пикселя PXLREPLACE. Досадно.
Но движемся дальше, ради чего всё это затевалось.
Реализовал на AutoIt алгоритм из SCREENin3 и получил на 100х100 10000 pxl...
// 100х100 10000 pxl ~1400 мс 0.14 ms/pxl
Всего в 6 раз быстрее кликера и PXLREPLACE. Ожидал большего.
Чуть оптимизировал и переделав структуру из DWORD (4 байта) в структуру равную длине строки пикселов стал читать и писать построчно по X.
Но ускорил всего на 9.2%
// 100х100 10000 pxl ~1270 мс 0.127 ms/pxl
Дальше пока ничего не придумал. Позамеряв скорость разных этапов, выяснилось, сто чтение и обработка занимает примерно 400 мс и остальные 870 мс занимает запись. Как ускорить пока не знаю.
В любом случае пока итог:
100х100 10000 pxl
// PXLREPLACE 8100 ms 0.810 ms/pxl
// +AutiIt 1270 ms 0.127 ms/pxl
Для области 100х100 1.27 секунды вроде и ничего.
Но для 300х300 уже 11.43 секунды. Это медленно.
А не дай бог 1000х1000, то это уже 127 секунд. 2 минуты Карл!
Жду помощи, прежде чем браться за перевод "яркость-контраст".
-
http://crapware.aidf.org/forum/index.php?topic=2134.msg23102#msg23102
http://crapware.aidf.org/forum/index.php?topic=2390.msg23103#msg23103
да уж, у тебя пруха :D.... у меня тоже такое бывает :D .
конечно идеи изредка проскакивают, но, как оказывается - бредовые и не реализуемые. :-\ но ведь кликер же может почти мгновенно править графический буфер тем же colormode!!! странно что автоит показал такие слабые результаты :-\ .
будем надеяться, что джонни всеже прислушается к идее контраста. спрос на такую коррекцию, как видно, присутствует.
P.S.
да, контраст это здорово, но вот если бы максимально ускорить в кликере попиксельную запись в графический буфер ::), так это бы вообще была сказка. каждый творил бы что хотел с этим буфером. жаль, что это скорее всего не так просто :(
-
colormode потому быстрый, что там обработка минимальна. Битовый сдвиг вправо на N бит.
Любая другая обработка намного медленней.
Да и colormode быстрый только сейчас. Как я писал на моём старом компе colormode была самая медленная команда. Использовал только на ограниченных областях. На весь экран уходило неприлично много времени для нормального, не тормозного скрипта.
-
хотел проверить твой вариант записи в память отсюда http://crapware.aidf.org/forum/index.php?topic=2390.msg23103#msg23103
ты бы точную версию к-мана написал, ато пришлось капаться в памяти для поиска указателя в памяти. ну да ладно, нашел. и, не работает почемуто, меняет только первую строку по Y . следил за памятью - поочередно меняет только первую строку. пока времени нет разбираться, гляну вечером, врядли проблема на моей стороне. перепроверь.
хотел проверить одну из бредовых идей по ускорению данного действия :D, но не вышло даже запустить твой вариант :(.
-
Кликер 4.11. Забыл написать.
Всё работает. Я же по скринам проверял.
Ты там не забыл системные переменные в обычные занести, это как оказалось тоже оптимизирует.
$xmax = $_xmax
$ymax = $_ymaxК обычным переменным доступ быстрей.
К коду выше запуск такой:
//не забываем вписывать PID кликера после каждого запуска кликера
$pid = 4120
$xmax = $_xmax
$ymax = $_ymax
GETSCREEN
//GREYSCALE(772, 432, 791, 451)
GREYSCALE(750, 426, 849, 525)
SCREENSHOTEX(700,400, 900,550, "Gray_", 0)
HALT
(http://savepic.net/9654850.png)
Я бы хотел ускорить запись в AutoIt/ Всё таки он сейчас быстрей в 6.5 раз
-
Полез в автоит код переделать, хотел одну идею проверить и увидел как я облажался ;D :-[
Я там начудил и при переделке на запись строками, чтение вынес за цикл, а запись осталась внутри.
И вместо записи 1 раз на строку оно писало 'длина строки в пикселах' раз, т.е. $x2-$x1 раз :o
Поправил и получил результат
100х100 10000 pxl
// PXLREPLACE 8100 ms 0.810 ms/pxl
// +AutiIt 130 ms 0.013 ms/pxl
1600х900 = 15000 ms
В 62 раза быстрее PXLREPLACE! И чем длинее строка, тем разница должна быть больше.
Появился смысл делать контраст.
Попробую ещё один вариант, может ещё ускорю.
P.S. ещё один:
~118 мс 0.0118 ms/pxl
1600х900 = 11971 ms
Уже разница 68.6 раза.
Вот проект на битбакете https://bitbucket.org/Vintets/cmextend/commits/all присоединяйся
-
Ты там не забыл системные переменные в обычные занести, это как оказалось тоже оптимизирует.
$xmax = $_xmax
$ymax = $_ymax
именно в них и была причина.
ну чтож, с автоитом все вышло, здорово, и скорость мега. жаль что я в автоите не силен :'(, изредка использую в случаях где нужны быстрые вычисления. и при написании в нем - из ушей мозг вытекает. тут еще нужно учитывать, что для каждой версии кликера свой указатель адреса. а так, переписать GREYSCALE на контраст я думаю не составит труда... тебе :D
вернемся к моим бредовым идеям. удалось только лишь используя кликер ускорится почти в 3 раза ;D . да, этот результат и рядом не стоит с автоитовским.
суть идеи такова. один кликер использует наши мега компьютеры с дюжинами камней лишь на малый процент всей мощности. у меня вариант GREYSCALE с записью в память нагружает проц всего на 12-14%. при этом участок 100х100 обрабатывается 52-55сек. попробовал разделить нагрузку на несколько экземпляров программы. тоесть один исполняемый кликерман делает скрин и запускает на выполнение определенное количество кликерманов.
GETSCREEN(0,0,100,100)
INIWRITE ("speed.ini", "n_win",0)
INIWRITE ("speed.ini","pid",4992)
waitms(10)
$time = $_ms
FOR($a=0,$a<5)
EXECUTE("speed.cms")
waitms(120)
END_CYC
WHILE(WNDFIND ("speed")>0)
waitms(100)
END_CYC
print($_ms - $time,"ms.")
SCREENSHOTEX(0,0, 100,100, "Image_", 0)
haltа они редактируют память первого.
#autorun
$n_win = INIREAD("speed.ini","n_win")+1
INIWRITE ("speed.ini", "n_win",$n_win)
$xmax = $_xmax
$ymax = $_ymax
$pid = INIREAD("speed.ini","pid")
GETSCREEN(($n_win-1)*20,0,($n_win-1)*20+20,100)
GREYSCALE(($n_win-1)*20,0,($n_win-1)*20+20,100)
halt(1) первый ожидает окончания работы до последнего.... и готово. пару часиков наладки и тестов - и в итоге стало ясно, что если запустить кучу процессов, то все это начинает жутко тупить, и работа замедляется. но, тесты показали, что оптимальное количество к-манов - пять штук. пять процессов (плюс один во главе) смогли нагрузить процессор почти до 80%. время выполнения участка 100х100 уменьшилось до 18-19сек.
-
ну чтож, с автоитом все вышло, здорово, и скорость мега. жаль что я в автоите не силен :'(, изредка использую в случаях где нужны быстрые вычисления. и при написании в нем - из ушей мозг вытекает.
Ерунда, я тоже не силён. А писать удобней. Но не так удобно как на питоне.
тут еще нужно учитывать, что для каждой версии кликера свой указатель адреса.
Это я упустил. Сам адрес определять не умею до сих пор.
Нужно доработать, сделать автоопределение версии кликера и использовать для каждой свои адреса. В памяти можно найти версию? или она тоже в разных местах?
-
Я не вникал особо в код, но не может ли утилитка командной строки NConvert для работы с графикой тут помочь? Батчевый консоль всё-таки рулед. Эт кнешна было б прикольно иметь возможность одним параметром иметь возможность задавать направление сканирование (или же начальную точку, зюйд-вест-ост-норд в форме пар вида sw-ne, для этого понадобится ещё один параметр)).
Почему собсна и предлагают превратить кликер в фотошоп, т. к. в таких заданиях много рутины и их не плохо б автоматизировать. Кстати, краем ухо помню наличие в фотошопе неких капель :) автоматизации и прочих ускоряющих инструментов.
-
Вот проект на битбакете https://bitbucket.org/Vintets/cmextend/commits/all присоединяйся
глянул одним глазком вчера, заинтриговал. сегодня уделил немного времени, так запустить и не удалось ;D . наличие "settings_cme.ini" обязательно? где его взять? или самому писать? очень много информации, дохера чего не понятно, сразу все усвоить не реально.
кстати для работы с памятью всегда использовал библиотеку RMemory.au3 (у меня она так называется, не помню откуда я ее нарыл), на все случаи для работы с памятью.
тут еще нужно учитывать, что для каждой версии кликера свой указатель адреса.
Это я упустил. Сам адрес определять не умею до сих пор.
Нужно доработать, сделать автоопределение версии кликера и использовать для каждой свои адреса. В памяти можно найти версию? или она тоже в разных местах?
перекапал все кликеры которые у меня есть. так и не нашел закономерности в адресах с версией. пока никаких идей нет по определению версии :'( .
-
settings_cme.ini там же лежит.
Библиотеку я использую встроенную WinAPI
Много встречал ещё NomadMemory, но посмотрел, она внутри так же вызывает 'kernel32.dll', только структуру каждый раз новую создаёт внутри. 100% будет медленней. NomadMemory - для простоты.
кстати для работы с памятью всегда использовал библиотеку RMemory.au3 (у меня она так называется, не помню откуда я ее нарыл), на все случаи для работы с памятью.
Может здесь http://autoit-script.ru/index.php?topic=20769.msg122696#msg122696
-
Ещё вариант. Быстрее
+На всём экране ускорился на 1.1 секунду (отдельная обработка).
Всё итог. Выжал всё что мог. Последний вариант внизу
// PXLREPLACE 100х100 10000 pxl
// 8100 ms 0.81 ms/pxl
// 100х100 10000 pxl ~130 мс 0.013 ms/pxl
// 1600х900 15000 мс
// 100х100 10000 pxl ~118 мс 0.0118 ms/pxl
// 1600х900 11971 мс
// 100х100 10000 pxl ~110 мс 0.0110 ms/pxl
// 1600х900 10823 мс
// 100х100 10000 pxl ~100 мс 0.0100 ms/pxl
// 1600х900 10823 мс
Теперь обработка куска 300х300 должна занимать ~900 ms
-
Контраст добавлен.
Наверно добавлю и второй вариант, который красивый контраст делает.
Может для примеров есть наработки? Паттерны значений для облегчения последующего поиска.
-
тест в новой версии.
SUB(GREYSCALE_1, $x1, $y1, $x2, $y2)
FOR($y=$y1,$y<$y2+1)
FOR($x=$x1,$x<$x2+1)
$c= pxl($x,$y)
$gray=int((0.299*colorr($c))+(0.587*colorg($c))+(0.114*colorb($c)))
PXLREPLACE($x,$y,$x,$y,$c,COLORGEN($gray,$gray,$gray))
END_CYC
END_CYC
END_SUB
SUB(GREYSCALE_2, $x1, $y1, $x2, $y2)
$startbufwr = 0x085D0400 //адрес меняется при запуске
$place = $x + $x1*4 - $y1*($xmax+1)*4 //сдвиг в нужное место
FOR($y=0, $y < ($y2 - $y1 + 1))
$adrDECwr = $startbufwr - $y*($xmax+1)*4
FOR($x=0, $x < ($x2 - $x1 + 1))
$c = PXL($x1+$x, $y1+$y)
$gray_canal = INT((0.299*COLORR($c)) + (0.587*COLORG($c)) + (0.114*COLORB($c)))
$gray = COLORGEN($gray_canal, $gray_canal, $gray_canal)
WRITEMEM($pid, $adrDECwr + $place, $gray, 4)
$adrDECwr = $adrDECwr + 3
END_CYC
END_CYC
END_SUB
////////////////////////////////////////
$pid = HGETPID (WNDFIND ("Clickermann"))
$xmax = $_xmax
GETSCREEN(100,100,200,200)
wait(1)
$t = $_ms
GREYSCALE_1(100,100,200,200)
print("PXLREPLACE - ", $_ms - $t," ms")
SCREENSHOTEX(0,0, 300,300, "Image_", 0)
wait(1)
$t = $_ms
GREYSCALE_1(100,100,200,200)
print("WRITEMEM - ", $_ms - $t," ms")
SCREENSHOTEX(0,0, 300,300, "Image_", 0)
halt
0:53:01 PXLREPLACE - 3743 ms
0:53:06 WRITEMEM - 3632 ms
с буфером какаято неразбериха в новой версии кликера, указателя на него в памяти не нашел. строки в памяти идут с низу в верх (- $y*($xmax+1)*4). и пришлось добавить сдвиг при записи $place . результат WRITEMEM немного даже опередил PXLREPLACE :D . да и в сравнении с версией 4.12 более чем в 2 раза быстрее.
не по теме:
без параметров GETSCREEN, как то даже неохота тестить вот это "+ Доработка функций граф поиска, небольшое ускорение поиска". особенно если разрешение экрана большое, и изза этого GETSCREEN отрабатывает очень долго. но уже видно, что PXLREPLACE стал значительно быстрее.