Ускорение работы color, color требует отдельный кадр, можно ли ускорить? Опции

[KudesniK]

Было замечено, что каждый вызов функции 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.

Может кто сталкивался, подскажите как решали, или как взять цвет пикселя после фотографии экрана.

[Cockney]

Если картинка меняется, а захватывать нужно всю область, то это едва ли будет быстрей 4х color.



Использовать findcolor.

[KudesniK]

Скрипт так же успевает сделать 60 фотографий всего окна.

Идея была в том, что часть проверок на цвет сосредоточены в достаточно небольшой области: примерно 200 на 100 пикселей, если сделать скриншот этой области и изучить цвета уже в ней, это в теории могло быть быстрее чем 1/60 секунды на пиксель (ведь будет обращение к двухмерному массиву, что является крайне быстрой операцией), но как оказалось получить цвет пикселя после GetImage крайне сложно: readmem очень медленная операция, а так же часто приводит к "Client sooner dead, than alive".

[Cockney]

Само снятие(без проверки цвета) области 200х100 будет медленней 4х вызовов color(и снятие и проверка).

[cirus]

Само снятие(без проверки цвета) области 200х100 будет медленней 4х вызовов color(и снятие и проверка).

Нет. Если область небольшая, то быстрее.

readmem очень медленная операция

Быстрее, чем получение цвета.

Код

set linedelay 0
log clear
log mode compact
set %arr GetImage (0 0 1920 1080)  // получаем скрин

set #handle workwindow     // запоминаем текущее рабочее окно
set workwindow windowhandle  // рабочее окно пилот
call getcolor %arr 867, 362      // передаём массив и координаты X и Y
log $getcolor   // цвет

call getcolor %arr 863, 371      // передаём массив и координаты X и Y
log $getcolor   // цвет

set workwindow #handle   // возвращаем рабочее окно
end_script

proc getcolor %a #x #y
    set #z1 %a [1 1] + %a [1 4] * #y + #x * 3
    set #z2 %a [1 1] + %a [1 4] * #y + #x * 3 + 1
    set #z3 %a [1 1] + %a [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 $result #color
end_proc

Если скрин делать не от координат 0 0, то от передаваемых координат надо отнимать начальные x y.

[KudesniK]

Замеры производительности:
17ms (1/60s) на вызов

Код

get color #color 100 100

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]

Имеем производительность порядка 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

[cirus]

set %arr GetImage (1 1 200 200)
set #x 21
set #y 41

В этом случае надо проверять не в 21 41, а 20 40. Или скрин делать 0 0 200 200.
Неплохо бы после получения цветов устанавливать рабочее окно обратно, то, к которому была изначально привязка, иначе к пилоту будет скрипт привязан.

Код

set #handle workwindow  // запомнили рабочее окно
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

set workwindow #handle  // вернули рабочее окно, иначе привязка будет к пилоту. 

[KudesniK]

Неплохо бы после получения цветов устанавливать рабочее окно обратно, то, к которому была изначально привязка, иначе к пилоту будет скрипт привязан.

ВРоде не забыл же, перед тем как взять очередную картинку.

Код

    set workwindow #handle
    set %arr GetImage (1 1 200 200)

Про координаты спасибо, почитаю документацию.

[cirus]

ВРоде не забыл же, перед тем как взять очередную картинку.

После:

Код

set workwindow windowhandle

Все действия будут относится к пилоту. Т. е. клики, нажатия и прочее.
Лучше так:

Код

set #handle workwindow  // запомнили окно

while 1
    set %arr GetImage (1 1 200 200)
    set workwindow windowhandle
       // получили цвета
    set workwindow #handle // вернули рабочее окно
       // тут нужные действия
end_while

[DarkMaster]

В общем и целом уже достаточно давно использую findcolor вместо color. Ирония в том, что find'ы незаметно для пользователей перешли на новые алогоритмы получения изображений, а вот color, который вроде как и является частным случаем findcolor'a просто забыли перевести на новую схему работы. В общем рекомендую брать луа и использовать обертку под это дело.

[Zenogiasu]

Здравствуйте. Важный для меня вопрос возник. Потребовалась скорость работы, и стал активно изучать луа. Продвинулся в изучении, и решил проверить разницу в скорости работа пилотовского и луавского скриптов идентичных. Скорость нисколько не отличается =( Проверял на примере 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 На главной странице у вас опечатка (Простой и неворятно гибкий синтаксис.)

[kyja]

Ответ может быть не совсем верным но тут вроде что то связаное с ограничениями самой винды при проверка цветов и быстрее она быть не может
Как вариант вы можете делать это все в разных скриптах и тогда они будут идти у вас асинхроно что повысит скорость но усложнит общию логику

[DarkMaster]

таких базовых действиях как снятие цвета

У вас фундаментальное непонимание за что отвечает синтаксис. Снятие цвета к нему вообще не имеет никакого отношения. Синтаксис отвечает за парсинг параметров, математику, встроенные в луа функции. Вот это вот:
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 потоков могут не дать вообще никакой разницы.

[Zenogiasu]

У вас фундаментальное непонимание за что отвечает синтаксис. Снятие цвета к нему вообще не имеет никакого отношения. Синтаксис отвечает за парсинг параметров, математику, встроенные в луа функции. Вот это вот:
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]

1. Я бы хотел все подобные вопросы задавать с оплатой в рамках обучения, но вы куда-то дели свой дискорд. Слишком большая занятость?)

Как был в подписи так и есть. Они циферки принудительно убрали из ников.

в линейке что-то вроде около 2000 снятий цвета было в точках на языке пилота

2к вряд ли, но около 600 помню отчетливо, cirus вроде под 1к делал. Сути не меняет. На языке пилота при этом будет большая нагрузка уже из-за самого языка пилота, как синтаксиса. Луа существенно снизит затраты.

Мне известно что луа будет в 300к раз быстрее работать с ДАННЫМИ.

Если будете писать перебор массивов, то вы получите что-то подобное. Например, есть публичный скрипт который заменяет финдколор полностью написанным на луа. Если это писать на старом синтаксисе, то можно один прогон при большой области на ночь ставить.

А потом запустил скрипт в другой вкладе который был просто if 1 = 2 log 1 end_if. Тоесть просто скрипт проверял условие. И это так сильно тормознуло работу основного скрипта, что перс просто стал с задержками лютыми ходить.

Без кода сказать сложно. Скорее всего там не было ни одного вейта и linedelay равный нулю (либо в настройках выставлена задержка между строк равная нулю). Тем самым вы просто повешали поток нагрузкой.

Тоесть разделять что-то по вкладкам нет никакого смысла.

Есть, в том числе по производительности, но обычно смысл в асинхронности. Чтобы работа одного скрипта не блокировала работу другого. Например в одном скрипте у нас есть навороченный скрипт, который бегает, прыгает, бьет, торгует. Но вот незадача бывают дисконнекты. Нет смысла в каждый цикл, в каждую функцию закидывать проверку на дисконнект. Проще сделать эту проверку вторым скриптом. Однако обычно использование нескольких вкладок приводит только неоправданному усложнению написания.

любое действия сначала дожидается окончания выполнения действий в других вкладках

скорее нет, чем да. В частности очень нехватает подобного поведения для кликов(из коробки, а не самописных), т.к. скрипты могут передраться за указатель. Вся математика, логика, условия, работа с данными никак не влияют друг на друга из разных вкладок.

Что касается поиска цвета с указанием хендла - скорость вырастает с 0.4 до 0.3сек.

можно попробовать указать хэндл равным нулю, но при этом придется использовать абсолютные координаты. Не уверен насколько это корректно будет работать со встроенным финдом.

[Zenogiasu]

Как был в подписи так и есть. Они циферки принудительно убрали из ников.

Там точно раньше были 4 циферки... После Kov. А потом вы их убрали.

[DarkMaster]

Там точно раньше были 4 циферки... После Kov. А потом вы их убрали.

Ну так потому что логин сменился. Дискорд всем принудительно поменял. Логин корректный, подчеркивания часть логина.