|
|
|
Помогите освоить LUA |
|
|
sutra |
11.1.2019, 7:42
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Цитата Что касается windowfrompoint, она возвращает строку с хендлами вместо массива. Спасибо, да, я понял. Просто как обычно, не зная толком синтаксиса, да ещё и ни хрена не понимая, обязательно наступаю на грабли. Просто ТО, на чём проверял (потом уже на разных окнах пробовал) работает только с параметром "child", на остальных возвращало пустую строку, вот я и затупил. Конечно на мой взгляд надо делать универсально, чтобы обе функции работали одинаково. По логике алгоритм то вроде не должен сильно отличаться. А то, что нет массива, так и в windowfromcursor тоже нет. Но там числом возвращает. Цитата она возвращает строку с хендлами вместо массива А у меня вроде только хендл первого окна возвращает, также как и windowfromcursor. Ну меня устраивает такой расклад. Мышку трогать не хочется, может испортить работу других скриптов. А так смотрю хендл, если отличается от того, который мне нужен, то минимизирую размер этого окна. И так пока не появится нужное мне окно. Вот таким вот долгим путём получилось решить проблему с выводом на передний план нужного мне окна. Хотя конечно интересно, почему в первый заход окно активируется, а потом нет. Кстати, не засекал, но с какого-то N-го цикла окно всё-таки активируется. В общем - загадка.
|
|
|
|
sutra |
17.1.2019, 14:32
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Цитата Еще пара интересных ссылок по производительности Спасибо Дарк. Конечно с моим английским разбираться приходится всё равно методом тыка. В принципе, когда у меня возникает альтернатива написания кода, я тупо пробую разные варианты и сравниваю результат. А вообще, спасибо тебе огромное! Я не поленился, полностью переписал весь код, используя пакет собственных функций, ВСЁ ЛЕТАЕТ. Скорости хватает с большим запасом. По картинкам ... главное правильно определить ЧТО (минимизировать количество искомых пикселей) и ГДЕ (не шерстить весь экран) искать и тогда всё ищется мгновенно. Что-то ещё ускорять в функциях смысла нет. 90-99% скорости потр<вырезано анти-матом>ет getimage. А как ускорить его я естественно не знаю, но наверное сам по себе доступ к экрану требует времени вне зависимости как это выполняется. Какой убогий анти-мат, даже не знаю каким словом заменить, - "требует времени".
|
|
|
|
sutra |
18.1.2019, 15:24
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Цитата Если забирать по хендлу, то ограничение вроде только в фпс Каюсь, был не прав. Уж не помню почему я так решил, что типа тормозит вызов функции. Вот такие у меня получились результаты. Код local p={} ok[1][1] -- ОКНО которое пытыют!!! tmc=os.clock() for i=1,1000 do p[i]=getimage(0,0,9,9,ok[1][1]) end tmc=os.clock()-tmc log("Время загрузки: ",tmc) -- 1.796 1.909 1.707 -- среднее время выполнения: 0,0018 tmc=os.clock() for i=1,1000 do deleteimage(p[i]) end tmc=os.clock()-tmc log("Время удаления: ",tmc) -- 0.193 0.196 0.195
tmc=os.clock() for i=1,100 do p[i]=getimage(0,0,899,899,ok[1][1]) end tmc=os.clock()-tmc log("Время загрузки: ",tmc) -- 1,511 1,585 1,37 -- среднее время выполнения: 0,0149 tmc=os.clock() for i=1,100 do deleteimage(p[i]) end tmc=os.clock()-tmc log("Время удаления: ",tmc) -- 0,036 0,038 0,037 -- при тесте на 1000 ошибка нехватки памяти Так что лучше вызывать чаще, но при меньшей зоне захвата. Придётся кое-что переделать. И ассемблер конечно же даст прирост (при правильном подходе). Вот только я его наглухо забыл, да и знал то тоже на церковно-приходском уровне. И ещё раз про погрешность. Ну лично я сколько репу не чесал, так и не мог придумать когда есть толк при применении абсолютной погрешности, ничего, кроме ухудшения поиска не происходит. Однозначно надо задавать относительную погрешность. Единственный минус - падает скорость, поэтому там где не нужен точный поиск, а нужна скорость, то нужна абсолютная погрешность, я бы назвал этот параметр не погрешность, а отклонение (дельта). Я использую оба эти параметра по мере необходимости.
|
|
|
|
cirus |
18.1.2019, 15:43
|
Elder
Сообщений: 3.480
Регистрация: 18.8.2014 Группа: Пользователи Наличность: 26540
Пользователь №: 16.971
Возраст: 29
|
Цитата for i=1,1000 do p[i]=getimage(0,0,9,9,ok[1][1]) end for i=1,100 do p[i]=getimage(0,0,899,899,ok[1][1]) end 10 * 10 * 1000 это не тоже самое что 900 * 900 * 100.
|
|
|
|
sutra |
18.1.2019, 16:15
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Поскольку я делаю для себя, то иногда просто делаю частные случаи поиска, чтобы не городить огород и не замедлять скрипт. Ну вот надо мне например искать картинку затенённую на 20%, добавил функцию, в которой изменил всего лишь одну строку, меня это не сильно напрягает. Код raz=rmem("unsigned char*",pg)[x]-rmem("unsigned char*",pl)[x]+rmem("unsigned char*",pl)[x]/5 И всех делов. Цитата 10 * 10 * 1000 это не тоже самое что 900 * 900 * 100. Я это понимаю, комментарии соответствующие были. Скорость считалась деля результат на 1000 и 100 соответственно. И выводы были даны соответствующие - на скорость СИЛЬНО влияет зона захвата. Гораздо СИЛЬНЕЕ, чем собственно вызов функции. Я к чему это всё озвучил ... Раньше в Пилоте, у меня были тормоза при вызове финдов. Собственно почему тогда я и попросил Кнайта сделать поиск в памяти и findcolor-ом. В lua, как я только что выяснил всё не так. Раньше я делал один захват и проводил в нём поиск например 3-х объектов и так было быстрее. Сейчас, как я понимаю, так делать не надо. Лучше делать захват для каждого объекта отдельно, так будет быстрее. Просто поделился СВОИМ опытом, ни на что не претендуя. Надо в общем внимательно смотреть в каждом конкретном случае. Понятно одно, при большой зоне захвата, выигрыша в скорости скорее всего не будет. Хотя всё равно у меня всё делается быстро. Было мгновенно, будет молниеносно. Универсальный поиск у меня красиво сделать не получилось. Я разделил это на 2 этапа. 1) Подготовка таблицы координат и RGB искомых пикселей. 2) Собственно поиск в памяти. Да, это некрасиво, но эффективно.
|
|
|
|
DarkMaster |
18.1.2019, 17:04
|
Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008 Группа: Супермодераторы Наличность: 27708
Пользователь №: 11.279
|
Цитата Те же монетки, если искать с относительной погрешностью, для однозначного результата поиска достаточно нескольких пикселей, а вот если использовать абсолютную, то надо уже внимательно всё проверять, могут быть ложные срабатывания. Есть сомнения. Мне кажется, как раз наоборот будет. Цитата И выводы были даны соответствующие - на скорость СИЛЬНО влияет зона захвата. Гораздо СИЛЬНЕЕ, чем собственно вызов функции. Я подозреваю это происходит из-за копирования участка памяти внутри пилота, но тут очень большой вопрос как именно релизован захват. Если там идет захват всего изображения, а потом вырезается кусок, то возможно имеет смысл ничего не вырезать, а непосредственно модифицировать поиск, чтобы он просчитывал смещения. Выигрыш может быть существенный, но тут нужно кнайта пытать, что именно и как там происходит. Цитата Я разделил это на 2 этапа. 1) Подготовка таблицы координат и RGB искомых пикселей. 2) Собственно поиск в памяти. Да, это некрасиво, но эффективно. Путешествие по таблице и захваченному изображению не в линейном чтении может существенно снижать скорость. Нужно присмотреться. В частности, если я не ошибаюсь, сейчас камни считывают минимум 10 байт памяти, соответственно, если нормально работает прогнозирование ветвлений, то 7 байт авансом остаются в кэше проца.
--------------------
Скрипты UOPilot под заказ. Консультации по UOpilot 15$/час. Услуги Lua разработчика (не пилот, проекты, постоянка) Disсоrd: Kov____
|
|
|
|
sutra |
18.1.2019, 17:06
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Конечно я реально затупил, как я сразу не понял про getimage. Ведь был у меня тест, а я даже не вник в результаты. Код tmc=os.clock() for i=1,100 do -- ищем чёрный пиксель tmp = findcolor("100 30 100 30 1 1 (0),ok[1][1]") end tmc=os.clock()-tmc log("Время поиска: ",tmc) -- 5,345 сек.
tmc=os.clock() for i=1,100 do b=f.FindPix(1,1,"R(0)G(0)B(0)",ok[1][1]) end tmc=os.clock()-tmc log("Время поиска: ",tmc) -- 0,132 сек.
FindPix - сам нарисовал.
|
|
|
|
sutra |
18.1.2019, 17:41
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Цитата Я подозреваю это происходит из-за копирования участка памяти внутри пилота Я не знаю тонкостей, просто тупо пробую всяко. Подготовка таблицы ничего не занимает. Составить для монеток таблицу для 4-х пикселей - мгновенно. А вот искаться будут только они. Причём первым пикселем в таблице является "белый" (фон капельки), при относительной погрешности (потому что он сильно плавает на полупрозрачном фоне) на первом же сравнении всё становится понятным. Там нет иных таких. Быстрее сам господь вряд ли найдёт. А вот если задавать абсолютную погрешность ... там на каждой крыше свой фон, плавает СИЛЬНО. Словить ложное срабатывание - легко. Получается найти если исследовать досконально влияние погрешности. А если учесть, что дан всего лишь маленький фрагмент игрового экрана ... не факт, что там нет подводных камней. Смысл таблицы в чём?? В том, что внутри функции поиска я ничего не меняю, там нет никакой лишней математики. Сравнение идёт уже с "подготовленными" параметрами (RED1 - RED2 и т.д.) Разница в том, что при обычном поиске индекс в памяти модифицируется только при переходе на новую строку (но за то выполняется инкремент на смещение в памяти). А при использовании таблицы, для каждого сравниваемого пикселя считается индекс в памяти (по координатам пикселя), но нет операции инкремента смещения. Так что потери по скорости мизерные, а результат работы логики ... даже не о чем говорить. Проблема одна - подготавливать таблицу - надо напрягать мозги, конечно проще тупо доверить это стандартной процедуре, вот она тупо и будет работать в 100 раз дольше. Я делаю так. Сначала отдельным скриптом сканирую экран, выясняю чего там есть, а чего нет (граничные значения RGB), а потом на основании этих данных леплю таблицу. Я различаю 2 аспекта: найти быстро и найти хитрую картинку. Если быстро и картинка простая - то использую примитивнейшую функцию (там всё понятно). Если "хитро" - однозначно относительная погрешность. Если "хитро" и недолго - использовать таблицу искомых пикселей. Иных вариантов не знаю.
|
|
|
|
sutra |
18.1.2019, 18:25
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Ещё раз про таблицу. Её можно создать и автоматически, только надо задавать не фон, а цвет (а частенько и цвета). Для прицела хватит и одного цвета. Разница с ныне действующим алгоритмом Кнайта такова. Сейчас фоном считается один цвет. У меня не так, ВСЁ что не нужно считается фоном и ВООБЩЕ не анализируется, то есть даже не определяется что это фон.
Иначе говоря имеем опять 2 аспекта: или стабильный фон или стабильный цвет. Ну и возможен конечно случай когда всё не стабильно. Для такого случая, ну никак вы не сделаете универсально. Тут однозначно нужен индивидуальный подход через создание таблицы искомых пикселей - это может быть достаточно сложная задача, но по-другому никак.
А при поиске текста, тут вообще использование таблицы - самое простое решение (или как угодно обзовите, опорные точки, реперные ...), поскольку всё ещё вдобавок ОЧЕНЬ СИЛЬНО может плавать, но эти самые точки у каждого символа ЕСТЬ. Есть или однозначный фон или однозначный "не фон". Ковыряться только с этим надо, если плюнуть на скорость (что в большинстве случаев и нужно делать), то тогда использовать параметр аккуратности, только на мой взгляд с "построковым" анализом.
|
|
|
|
DarkMaster |
18.1.2019, 19:29
|
Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008 Группа: Супермодераторы Наличность: 27708
Пользователь №: 11.279
|
Цитата Конечно если подключить потоки и искать одновременно в разных частях экрана, если впихнуть ассемблер, добавить логики, то можно наверное сделать универсально и быстро. Но это явно не мой уровень, ты Дарк, конечно это сделаешь. Я в лучшем случае гожусь на роль тестера, да и то как выяснилось и тестер то из меня хреновый. Асм я вообще не знаю (операторы, стили). А вот потоки скорее всего в скором будущем понадобятся, причем там же и cuda. С потоками на самом деле все достаточно просто. Асм там ксати какой-то специфический. Насколько я понял он компилируется в Си. Хотя подозреваю, что на подобных примитивных ифах и циклах компилирование это происходит без потери производительности ибо там элементраная задача для компилятора(он же и оптимизирует). Но если сотворим, то будет реально пуля. Надо время выкроить. Пока тяжеловато. Сообщение отредактировал DarkMaster - 18.1.2019, 19:30
--------------------
Скрипты UOPilot под заказ. Консультации по UOpilot 15$/час. Услуги Lua разработчика (не пилот, проекты, постоянка) Disсоrd: Kov____
|
|
|
|
sutra |
18.1.2019, 23:05
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Цитата Но если сотворим, то будет реально пуля В любом случае, в 10-ый раз скажу тебе Дарк спасибо. Пусть у меня всё криво, пусть некрасиво. Но ты дал инструмент, а уж применить его - дело техники. Абсолютно уверен в одном, пусть даже нестандартно, но за то я теперь могу решить практически любую задачу. На данный момент не вижу ничего, чего нельзя бы было реализовать. И Кнайту тоже ещё раз спасибо, он дал глобальный инструмент, всё остальное в наших руках. Он не обязан за всех думать, тем более что инструмент условно бесплатный. Будет время - усовершенствует. Всем успехов и здоровья! У остальных участников форума, прошу прощения, что тема про lua как-то изначально превратилась в тему про финды, но думаю что не только мне это было интересно.
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|