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

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

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

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

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

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

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

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

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

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

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

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

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

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

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