|
|
|
Ускорение работы color, color требует отдельный кадр, можно ли ускорить? |
|
|
KudesniK |
10.7.2018, 9:09
|
Registred
Сообщений: 6
Регистрация: 10.7.2018 Группа: Пользователи Наличность: 0
Пользователь №: 18.992
|
Было замечено, что каждый вызов функции color требует отдельный кадр, рассмотрим пример (отключено слежение, задержка 0ms): Код set #counter 0 set timer while 1 if timer > 1000 hint #counter set timer set #counter 0 end_if
set #counter #counter + 1 set #color color (53, 144) end_while end_script в окнах, где используется vsync количество вызовов color будет ограничено частотой экрана, в моем случае 60, в остальных окнах количество вызовов color может доходить до нескольких тысяч. Таким образом при необходимости анализа шести разных пикселей на цвет, мы получаем падение производительности скрипта до десяти проверок в секунду, при необходимости контролировать десять пикселей, уже шесть операций в секунду. Например, заменив одну операцию color на (как пример): Код if 255, 380 16777215 and 200, 300 15588051 and 12, 27 5621216 and 33, 33 13743257 send {f1} end_if мы получаем падение производительности в четыре раза (четыре вызова color), т.е. до 15 проверок в секунду, пример выше использован для демонстрации. Соответственно при пяти таких блоках производительность уже будет около трех проверок в секунду. Альтернативный вариант сделать один снимок экрана и в нем искать нужные цвета в нужных пикселях, но я не нашел как взять цвет пикселя в результате работы GetImage. Может кто сталкивался, подскажите как решали, или как взять цвет пикселя после фотографии экрана.
|
|
|
|
KudesniK |
10.7.2018, 13:50
|
Registred
Сообщений: 6
Регистрация: 10.7.2018 Группа: Пользователи Наличность: 0
Пользователь №: 18.992
|
Замеры производительности: 17ms (1/60s) на вызов Код 1-2ms на вызов Код set %arr GetImage (0 0 200 200) 9-17ms на вызов Код call getcolor %arr 100, 100 Код for #i 1 25 set #t timer set %arr GetImage (0 0 300 300) set #t timer - #t log get-image tooks #t ms, timer end_for Код for #i 1 25 set #t timer call getcolor %arr 100, 100 set #t timer - #t
log get-color tooks #t ms, timer end_for Но, уберем затраты на вызов процедур: Код set #x 100 set #y 100 for #i 1 25 set #t timer
set #z1 %arr [1 1] + %arr [1 4] * #y + #x * 3 set #z2 %arr [1 1] + %arr [1 4] * #y + #x * 3 + 1 set #z3 %arr [1 1] + %arr [1 4] * #y + #x * 3 + 2 readmem #b #z1 b readmem #g #z2 b readmem #r #z3 b set #color #r + #g * 256 + #b * 65536
set #t timer - #t
log get-color tooks #t ms, timer end_for получаем 1ms на вызов.
|
|
|
|
KudesniK |
10.7.2018, 14:15
|
Registred
Сообщений: 6
Регистрация: 10.7.2018 Группа: Пользователи Наличность: 0
Пользователь №: 18.992
|
Имеем производительность порядка 1100 пикселей в секунду по сравнению с 60 у get color. При увеличении области до 800х600 производительность падает до 600 в секунду. Область 1920х1080 - 400 пикселей в секунду. "Фотография" экрана происходит для анализа 20 пикселей. Всем спасибо, с большего меня это решение устраивает, может в будущем что-то переработают, пока живу с вот этим. Код set #handle workwindow
set timer
while 1 if timer > 1000 hint #counter log #counter set timer set #counter 0 end_if
set #counter #counter + 1
set workwindow #handle set %arr GetImage (1 1 200 200)
set workwindow windowhandle
for #i 1 20 set #x random(200) set #y random(200) // set #x 21 // set #y 41 gosub fast_color // log #color end_for end_while
:fast_color set #z1 %arr [1 1] + %arr [1 4] * (#y - 1) + (#x - 1) * 3 set #z2 %arr [1 1] + %arr [1 4] * (#y - 1) + (#x - 1) * 3 + 1 set #z3 %arr [1 1] + %arr [1 4] * (#y - 1) + (#x - 1) * 3 + 2 readmem #b #z1 b readmem #g #z2 b readmem #r #z3 b set #color #b * 256 * 256 + #g * 256 + #r return
|
|
|
|
KudesniK |
10.7.2018, 15:01
|
Registred
Сообщений: 6
Регистрация: 10.7.2018 Группа: Пользователи Наличность: 0
Пользователь №: 18.992
|
Цитата(cirus @ 10.7.2018, 14:41) Неплохо бы после получения цветов устанавливать рабочее окно обратно, то, к которому была изначально привязка, иначе к пилоту будет скрипт привязан.
ВРоде не забыл же, перед тем как взять очередную картинку. Код set workwindow #handle set %arr GetImage (1 1 200 200) Про координаты спасибо, почитаю документацию.
|
|
|
|
Zenogiasu |
1.5.2024, 3:59
|
Neophyte
Сообщений: 45
Регистрация: 3.12.2022 Группа: Пользователи Наличность: 0
Пользователь №: 20.434
Возраст: 28
|
Здравствуйте. Важный для меня вопрос возник. Потребовалась скорость работы, и стал активно изучать луа. Продвинулся в изучении, и решил проверить разницу в скорости работа пилотовского и луавского скриптов идентичных. Скорость нисколько не отличается =( Проверял на примере color/get color Персонаж в игре двигается, перед шагом я снимаю 5 цветов с 5 точке гет колором, делаю шаг, затем проверка снова тех-же точек - должны измениться, если нет - значит застопали. Делать это приходится часто, мозные компы успевают все действия между шагами проверять а слабые нет. Сейчас в предвкушении перехода на луа сделал 2 проверочных скрипта: 25 гетколоров на пилоте и 25 колоров на луа. Проверил скорость там и там. Она идентична... Также проверил 25 финдколоров на луа, скорость такая-же. Включение/отключение вертикальной синхронизации, снижение/увеличение фпс 60-200 на скорости никак не влияют. Сначала 25 гетов та ми там занимало 800 мс. потом отошел на 10 мин, вернулся, снова тесты и почему-то вдруг стали занимать 400мс, ничего нигде не менял. Черная магия в общем. Скажите подалуйста, в чем тогда заключается скорость луа, если не в таких базовых действиях как снятие цвета? Вот код можете проверить у себя, спасибо. Скрипты привязаны к игре. Код get color #q 1148, 148 get color #q1 1200, 76 get color #q2 1192, 145 get color #q3 1224, 100 get color #q4 1175, 118 get color #q 1148, 148 get color #q1 1200, 76 get color #q2 1192, 145 get color #q3 1224, 100 get color #q4 1175, 118 get color #q 1148, 146 get color #q1 1200, 77 get color #q2 1192, 148 get color #q3 1224, 108 get color #q4 1175, 117 get color #q 1148, 145 get color #q1 1200, 74 get color #q2 1192, 141 get color #q3 1224, 102 get color #q4 1175, 113 get color #q 1148, 142 get color #q1 1200, 73 get color #q2 1192, 144 get color #q3 1224, 105 get color #q4 1175, 115 log timer end_script
Код --lua timer2 = os.clock() local q = color (1148, 148) local q1 = color (1200, 76) local q2 = color (1192, 145) local q3 = color (1224, 100) local q4 = color (1175, 118) local q5 = color (1141, 148) local q6 = color (1201, 76) local q7 = color (1191, 145) local q8 = color (1221, 100) local q9 = color (1171, 118) local q10 = color (1142, 148) local q11 = color (1202, 76) local q12 = color (1193, 145) local q13 = color (1222, 100) local q14 = color (1172, 118) local q15 = color (1144, 148) local q16 = color (1204, 76) local q17 = color (1194, 145) local q18 = color (1225, 100) local q19 = color (1174, 118) local q20 = color (1145, 148) local q21 = color (1205, 76) local q22 = color (1195, 145) local q23 = color (1225, 100) local q24 = color (1174, 118) timer3 = os.clock() - timer2 log (timer3)
p.s На главной странице у вас опечатка (Простой и неворятно гибкий синтаксис.)
|
|
|
|
DarkMaster |
1.5.2024, 11:59
|
Модератор UOPilot
Сообщений: 9.573
Регистрация: 2.12.2008 Группа: Супермодераторы Наличность: 28548
Пользователь №: 11.279
|
Цитата таких базовых действиях как снятие цвета У вас фундаментальное непонимание за что отвечает синтаксис. Снятие цвета к нему вообще не имеет никакого отношения. Синтаксис отвечает за парсинг параметров, математику, встроенные в луа функции. Вот это вот: https://www.lua.org/manual/5.1/https://luajit.org/color и финды это, наверное, самое далекое в пилоте, что только можно вообразить от базовых действий луа. Есть функции пилота, а есть склейка этих функций, работа с переменными, циклами, еще раз математику упомяну. Представьте тот же финд в виде отдельной дллки. Какая разница чем вы ее загрузите, если работает дллка? Разница лишь на стыке сред, когда дллка что-то вернет, а луа получит результат и вы с ним работать начнете. Конкретно по вашему случаю: там все время тратится на захват изображения, а не на поиск, возврат значений и т.д. Еще большой кусок времени улетает на выделение памяти под захваченное изображение. Сам вызов функции выделения памяти жрет много. Используйте color с указанеим хэндла окна внутри параметров функции - это изменит метод захвата изображения и существенно ускорит работу. Не все приложения позволяют так делать. Как альтернатива можно вызывать getimage и проверять внутри полученного изображения конкретные пиксели. Код local ffi=require "ffi" -- в шапку local ext = {} -- img - это адрес ext.get_pix = function(img, x, y) local r, g, b, dec, bright local pix = ffi.cast("unsigned char*", img[1]) b = pix[ img[4]*y + x*3 ] g = pix[ img[4]*y + x*3+1] r = pix[ img[4]*y + x*3+2] dec = b*255*255 + g*255 + r bright = b + g + r return {r, g, b, dec, bright} end
Цитата Как вариант вы можете делать это все в разных скриптах и тогда они будут идти у вас асинхроно А вот это надо тестить. Раньше вся работа с захватом изображений была в одном потоке независимо от количества вкладок. Вроде что-то менялось, но точно не скажу. Так же там очень вероятно окажется узким местом сама винда и даже 100 потоков могут не дать вообще никакой разницы.
--------------------
Скрипты UOPilot под заказ. Консультации по UOpilot 15$/час. Услуги Lua разработчика (не пилот, проекты, постоянка) Disсоrd: Kov____
|
|
|
|
Zenogiasu |
2.5.2024, 3:49
|
Neophyte
Сообщений: 45
Регистрация: 3.12.2022 Группа: Пользователи Наличность: 0
Пользователь №: 20.434
Возраст: 28
|
Цитата(DarkMaster @ 1.5.2024, 11:59) У вас фундаментальное непонимание за что отвечает синтаксис. Снятие цвета к нему вообще не имеет никакого отношения. Синтаксис отвечает за парсинг параметров, математику, встроенные в луа функции. Вот это вот: https://www.lua.org/manual/5.1/https://luajit.org/color и финды это, наверное, самое далекое в пилоте, что только можно вообразить от базовых действий луа. Есть функции пилота, а есть склейка этих функций, работа с переменными, циклами, еще раз математику упомяну. Представьте тот же финд в виде отдельной дллки. Какая разница чем вы ее загрузите, если работает дллка? Разница лишь на стыке сред, когда дллка что-то вернет, а луа получит результат и вы с ним работать начнете. Конкретно по вашему случаю: там все время тратится на захват изображения, а не на поиск, возврат значений и т.д. Еще большой кусок времени улетает на выделение памяти под захваченное изображение. Сам вызов функции выделения памяти жрет много. Используйте color с указанеим хэндла окна внутри параметров функции - это изменит метод захвата изображения и существенно ускорит работу. Не все приложения позволяют так делать. Как альтернатива можно вызывать getimage и проверять внутри полученного изображения конкретные пиксели. Код local ffi=require "ffi" -- в шапку local ext = {} -- img - это адрес ext.get_pix = function(img, x, y) local r, g, b, dec, bright local pix = ffi.cast("unsigned char*", img[1]) b = pix[ img[4]*y + x*3 ] g = pix[ img[4]*y + x*3+1] r = pix[ img[4]*y + x*3+2] dec = b*255*255 + g*255 + r bright = b + g + r return {r, g, b, dec, bright} end
А вот это надо тестить. Раньше вся работа с захватом изображений была в одном потоке независимо от количества вкладок. Вроде что-то менялось, но точно не скажу. Так же там очень вероятно окажется узким местом сама винда и даже 100 потоков могут не дать вообще никакой разницы. 1. Я бы хотел все подобные вопросы задавать с оплатой в рамках обучения, но вы куда-то дели свой дискорд. Слишком большая занятость?) 2. Далее, я где-то раньше читал в старых темах, что вы говорилии что лично видели как у человека в линейке что-то вроде около 2000 снятий цвета было в точках на языке пилота, а речь шла вроде как о разнице в скорости между пилотом и луа. Найти снова не смог этого. А в то время мне такое не нужно было. Мне известно что луа будет в 300к раз быстрее работать с ДАННЫМИ. Но в рамках написания ботов, наверно еще нубас, но пользу вижу сомнительную. Например я прописываю маршрут в удобном для себя виде, а затем происходит блок где бот перерабатывает его в удобный для него вид и ходит по нему. На языке пилота на эту переработку данных уходит секунд 10 в зависимости от длины маршрута, а на луа меньше секунды. Покачто вся видимая польза. Также мне понятно что чтобы реализовать поиск цвета для пользователей пилота всего одной строкой - вам пришлось написать много много строчек кода где-то там закулисами. 3. Я пробовал разделить действия по разным вкладкам. Вышло что-то такое Неприятное, что возник вообще вопрос, а какой тогда смысл во вкладках. Дело состояло в том что я просто запустил основной скрипт передвижения с чеком 5 точек, хп, чата и еще всякой фигни, и прожиманием кнопки движения - работало норм. А потом запустил скрипт в другой вкладе который был просто if 1 = 2 log 1 end_if. Тоесть просто скрипт проверял условие. И это так сильно тормознуло работу основного скрипта, что перс просто стал с задержками лютыми ходить. Вывод таков - у пилота общая производительность во всех вкладках... Тоесть разделять что-то по вкладкам нет никакого смысла. Я пробовал и просто так сделать, чтобы кнопку таб прожимал в отдельной вкладке, чтобы взять моба в таргет если таковой появится. Но это тоже было не быстрее нисколько. Как в одной вкладке он не может одновременно выполнить больше 1 действия в момент времени, так словно и в других вкладках любое действия сначала дожидается окончания выполнения действий в других вкладках. 4. Гет имаге изучу, спасибо. Что касается поиска цвета с указанием хендла - скорость вырастает с 0.4 до 0.3сек. Но в моей игре почему-то при указании хендла и снятии цвета - начинает люто моргать игра белым цветом. Что есть невыносимо. Возможно связано с тем что игла толи на java толи на lua написана. Либо одновременно. Чтож, тогда даже не знаю... Чем более бот как мне кажется, тем больше в геометрической прогрессии увеличивается количество финдов/снятий цветов, которые нужно выполнить в момент времени и как можно скорее. А я уже взял и так глупо уперся в потолок из всего-лишь 5-10ти возможных снятий колоров между шагами перса, чтобы он двигался без рывков и не запалил что он бот. Кстати когда решил сендекс_довн, вайт 20 + рандом 20) сенсекс_ап заменить на просто сендекс - кнопка движения, тк оно прожимается в разы быстрее - полетели баны) так что не стоит едооценивать рандом промежутки даже при нажатии-отпускании клавиши)
|
|
|
|
DarkMaster |
2.5.2024, 6:11
|
Модератор UOPilot
Сообщений: 9.573
Регистрация: 2.12.2008 Группа: Супермодераторы Наличность: 28548
Пользователь №: 11.279
|
Цитата 1. Я бы хотел все подобные вопросы задавать с оплатой в рамках обучения, но вы куда-то дели свой дискорд. Слишком большая занятость?) Как был в подписи так и есть. Они циферки принудительно убрали из ников. Цитата в линейке что-то вроде около 2000 снятий цвета было в точках на языке пилота 2к вряд ли, но около 600 помню отчетливо, cirus вроде под 1к делал. Сути не меняет. На языке пилота при этом будет большая нагрузка уже из-за самого языка пилота, как синтаксиса. Луа существенно снизит затраты. Цитата Мне известно что луа будет в 300к раз быстрее работать с ДАННЫМИ. Если будете писать перебор массивов, то вы получите что-то подобное. Например, есть публичный скрипт который заменяет финдколор полностью написанным на луа. Если это писать на старом синтаксисе, то можно один прогон при большой области на ночь ставить. Цитата А потом запустил скрипт в другой вкладе который был просто if 1 = 2 log 1 end_if. Тоесть просто скрипт проверял условие. И это так сильно тормознуло работу основного скрипта, что перс просто стал с задержками лютыми ходить. Без кода сказать сложно. Скорее всего там не было ни одного вейта и linedelay равный нулю (либо в настройках выставлена задержка между строк равная нулю). Тем самым вы просто повешали поток нагрузкой. Цитата Тоесть разделять что-то по вкладкам нет никакого смысла. Есть, в том числе по производительности, но обычно смысл в асинхронности. Чтобы работа одного скрипта не блокировала работу другого. Например в одном скрипте у нас есть навороченный скрипт, который бегает, прыгает, бьет, торгует. Но вот незадача бывают дисконнекты. Нет смысла в каждый цикл, в каждую функцию закидывать проверку на дисконнект. Проще сделать эту проверку вторым скриптом. Однако обычно использование нескольких вкладок приводит только неоправданному усложнению написания. Цитата любое действия сначала дожидается окончания выполнения действий в других вкладках скорее нет, чем да. В частности очень нехватает подобного поведения для кликов(из коробки, а не самописных), т.к. скрипты могут передраться за указатель. Вся математика, логика, условия, работа с данными никак не влияют друг на друга из разных вкладок. Цитата Что касается поиска цвета с указанием хендла - скорость вырастает с 0.4 до 0.3сек. можно попробовать указать хэндл равным нулю, но при этом придется использовать абсолютные координаты. Не уверен насколько это корректно будет работать со встроенным финдом.
--------------------
Скрипты UOPilot под заказ. Консультации по UOpilot 15$/час. Услуги Lua разработчика (не пилот, проекты, постоянка) Disсоrd: Kov____
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|