Ускорение работы 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.

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

[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) сенсекс_ап заменить на просто сендекс - кнопка движения, тк оно прожимается в разы быстрее - полетели баны) так что не стоит едооценивать рандом промежутки даже при нажатии-отпускании клавиши)