Snusmumriken
Ловка не умеет лезть в чужие окна, только в своё.
Алёша
1. Не ругайся без нужды. Исправляй словечки а то удолю. 2. 777 / 20 = ~38-39 проверок цвета.
В целом можно красный бар искать с шагом в 20 пикселей, а синий по конкретному цвету шагом поменьше, чтобы точно не потерять
Алёша
19 пикселей.
21, чтобы целое кол-во шагов было
Snusmumriken
Померяй точные размеры синего бара. Если сделать шаг в его размер-1 то ты никак его не пропустишь. Ну воткнёшься в краешек, невелика потеря.
Михаил
Понимать бы ещё что это
ну - вешаешь на функцию дополнительный байткод чтобы удостовериться что типы совпадают
Михаил
if not __type_string(arg1) then error(); end
Михаил
в начале
Михаил
и на каждый return еще проверка
Михаил
или просто __type_string(arg1); __type_custom1(arg2);
Алёша
Померяй точные размеры синего бара. Если сделать шаг в его размер-1 то ты никак его не пропустишь. Ну воткнёшься в краешек, невелика потеря.
Надо будет, но даже при условии шага для краного бара - 21 и синего бара - 7, количество проверок в самом худшем варианте снижается в 15 раз, вместо 3885 всего 259
Snusmumriken
А красный бар какого размера?
Snusmumriken
Зачем синему бару шаг в 7 пикселей когда он гораздо больше?
Snusmumriken
Ты можешь сократить гораздо сильнее, до ~40-80 проверок.
Алёша
А красный бар какого размера?
Он может немного меняться в размере, но в целом он довольно большой, что то в районе 250 с гаком
Алёша
Но в идеале +- определять его центр
Snusmumriken
Зачем?
Алёша
Зачем?
Чтобы стремиться удерживать центр на синей метке
Алёша
Зачем синему бару шаг в 7 пикселей когда он гораздо больше?
Я не знаю точно его размер, да и к тому же после 7 сразу 21 идёт чтобы целое число шагов получить. Хотя в целом можно подрезать пару пикселей с краёв, вместо 777 например сделать 770
Snusmumriken
А давай я тебе расскажу как легко определить его центр в минимум проверок. Вот мы такие гуляем с шагом минимального его размера, например, предположим что это 249 пикселей. Находим первое вхождение. И идём такие от точки вхождения, например, влево, с шагом, например, в 50 пикселей, в поисках выхода из красного бара. Максимум 4 проверки. Делай с этой информацией что хочешь, её достаточно для определения центра.
Snusmumriken
Между шагами 3-4 мы такие нашли левую границу красного бара. Ура. Значит его центр — примерно посередине между ними, плюс 125 пикселей.
Snusmumriken
Погрешность есть? Ну есть. И чо? Зато сколько проверок пикселей?
Алёша
Погрешность есть? Ну есть. И чо? Зато сколько проверок пикселей?
Ну она в целом не шибко критичная, 50 пикселей в данном случае. Хм, если топать с шагом 249 то будет 4 шага, плюс 4 максимум шага назад, итого 8. Очень демократично
Snusmumriken
Алёша
Так
Snusmumriken
А ты такой спрашиваешь "что можно оптимизировать".
Snusmumriken
Вкратце: если мы относительно толерантны к ошибкам и нам не нужна абсолютная точность, то всё.
Алёша
А теперь вопрос есть. А что если наткнёмся шагом в 249 на синюю метку? С одной стороны можно проверить на цвет, с другой стороны во первых синяя метка может быть на красном баре, а во вторых по краям синей метки пара пикселей другого цвета
Snusmumriken
Ничего страшного.
Snusmumriken
Хотя надо подумоть
Snusmumriken
Ладно, возможно стоит уменьшить шаг в ~2.1 раза. Если тыкать каждые 100 пикселей (меньше половины размера красного бара минус размеры синего бара), то мы точно не промахнёмся, и даже если попадём в синий то на следующем шаге точно попадём в красный. Ок, ~10 проверок в худшем случае.
Алёша
Хотя, после нахождения красного бара одинг фиг надо топать искать синюю метку, но вот только в случае обсёра придётся цикл заново повторить
Snusmumriken
Ещё. Синяя метка рандомно перемещается каждый кадр?
Алёша
Хм, есть вариант после попадания топнуть влево пикселей на 20 и вправо, если и там и там попадём то точно красный бар
Snusmumriken
Или она ползает?
Алёша
Ещё. Синяя метка рандомно перемещается каждый кадр?
Не каждый кадр, но через случайное время
Snusmumriken
Не каждый кадр, но через случайное время
Но просто мгновенно перемещается, так?
Алёша
Или она ползает?
Ну считай ползает, и бывает очень быстро, почти что моментально
Алёша
Но не в 1 кадр
Snusmumriken
Ну значит, быстрая проверка на синюю метку — уточнить, что она всё ещё находится в той же точке. И искать её только когда она перемещается. Мы же можем запоминать переменные?
Snusmumriken
И ещё, чтобы не попадать в синюю метку при поиске красного бара, мы можем такие проверять точку поиска "не слишком ли она близко к бару", и если да — сместить на 20 пикс в любую сторону. Вариант с топаньем вправо-влево после втыкания в синий бар тоже сойдёт.
Алёша
Ну значит, быстрая проверка на синюю метку — уточнить, что она всё ещё находится в той же точке. И искать её только когда она перемещается. Мы же можем запоминать переменные?
То есть идём искать синюю метку, нашли, запомнили, потом проверяем её там где запомнили и если нет то идём искать заново?
Snusmumriken
Да.
Snusmumriken
С красным баром та же история. Если он не телепортируется — ты один раз нашёл его границу, а дальше можешь только актуализировать данные, притом, если он перемещается только под контролем кликера, то мы даже знаем в какую сторону актуализировать эту границу.
Алёша
Хм, вариант пока такой, топаем с шагом 249, попадаем в точку, начинаем топать по 50 пикселей влево, если после первого топа улетели, то делаем контрольный топ от первоначальной точки но на 50 вправо. Если вправо ткнулись то всё ок. Если нет то идём дальше с шагом 249. Единственный закос может случиться если синий бар будет очень близко слева от красного, но всё же скрипт будет стремить к синему центр красного, так что окей я думаю
Snusmumriken
Зато количество проверок сдувается до 3-5 на всё время пока синий бар не двигается, и ~20 когда двигается.
Snusmumriken
Ну ты понял.
Алёша
В кликермане блин нельзя функцию создать. Хотя по сути там есть нечто подобное именуемое sub, но это просто как подпрограмма, из которой нереально получить вывод. Ибо ретурна нету, а все переменные использованные в теле саба считаются его собственными локальными и после завершения саба убиваются
Алёша
Ну ты понял.
Ну я понял
Snusmumriken
Добро пожаловать в basic 1964 гогда. Тогда подобное активно использовалось. Вместе с goto func1.
Алёша
Просто как будто если в сабе использовать какую либо переменную, даже объявленную заранее, то оно создаст всё равно свою собственную локальную с таким же именем. Ибо на ранних стадиях тестирования и гребли с кликерманом я использовал в самом скрипте и в сабе переменные с одним именем, и они друг другу не мешали
Snusmumriken
Печальбеда
Алёша
Я пытался как то выудить из него хоть что нибудь путём функции записи и чтения в память данных, но как то не срослось
Алёша
Ох снусик, по итогу вышло так, удалось ускорить процесс до 10-15 выполнений в секунду, но шедеврокликерман почему то останавливает скрипт спустя секунды 4
Алёша
Хотя показывает что скрип запущен, но по сути скрипт не работает ибо в лог перестаёт писаться инфа
Алёша
По итогу ширина красного бара 210, а нужного цвета на синей метке всего 4 пикселя. Как итог - снижение юзания функции определения цвета пикселя примерно в 12 раз, вместо 3885 получилось немного меньше 300
Алёша
В шедевральном и очень "удобном". Цвет приходит одним числом, например красный это 255, а белый 16777215
Алёша
Я хз как это шедеврокодировка называется
Михаил
битовыми сдвигами получаешь каждый цвет
Алёша
Кто это придумал вообще
Михаил
гений
Алёша
В чём проблема обычного ргб
Михаил
а что для тебя обычный ргб
Михаил
он взял 3 байта из буфера и дал тебе их числом, в чем проблема
Алёша
В понимании
Михаил
битовые операции это база require "bit" так в луажит можно
Алёша
Мне проще понять когда у меня отдельно 3 цвета от 0 до 255 а не рандомное число по типу 4533245
Михаил
Алёша
Да ну их куда подальше
Igor
Да ну их куда подальше
Ну тогда лучше и не лезть в эту тему вообще, раз уж на то пошло. Не было бы побитовых операций и прочей упаковки, программы бы рассирались по оперативной памяти только в путь.