|
|
|
Помогите освоить LUA |
|
|
sutra |
19.1.2019, 1:26
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Будут мысли, будет время, обязательно поделюсь. Просто сейчас решаю архисложную, нелинейную задачу, которую можно решить только индивидуальным подходом (из-за неё и перешёл на lua). Гигантский рэндом параметров (на анализ и реакцию минимум 5 параметров и всего максимум за 10-5 сотых сек. интервала анализа) не позволяет однозначно простым сравнением понять ЧТО же произошло. Плавает абсолютно всё. Начиная с момента возникновения события (пробовал всяко определять и по звуку и по тому, что творится на экране) и заканчивая попыткой анализа последствий. Теперь одновременно анализирую ну абсолютно всё, что только можно анализировать, вычисляю даже ускорение на основе полученных координат при поиске пикселей. Петля на шее хитрого алгоритма разработчиков игры затягивается неумолимо. У меня просто спортивный интерес допинать абсолютно всё. Даже квесты теперь делает IQ. В общем обленился по полной программе, интересно делать только скрипт, игра уже не интересна - всего лишь полигон для мозга.
|
|
|
|
sutra |
21.1.2019, 13:21
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Цитата Создай отдельную тему с итоговым вариантом и подробным описанием Да бог с ней с темой, поздно уже. Ну и итогового варианта у меня нет, как я говорил, я не представляю как всё поместить в одну функцию. У меня только чисто поиск более менее сделан, но там собственно всё по старому. А подготовка к поиску - для каждого случая своя примочка. Я даже пробовал создавать "виртуальные картинки" отдельным скриптом. То есть в цикле (очень долго работает), с заданной погрешностью скрипт сам пробует искать текущую картинку среди остальных картинок набора, перебирая все пиксели и увеличивая массив искомых пикселей, если находилась какая-либо картинка из набора заданных. Крайне нестандартное решение, вряд ли кому будет интересно. Но для моего случая искать среди 1000 картинок (они не самые маленькие) результат супер. Вобщем скрипт ищет уникальный набор пикселей для каждой картинки, который не повторяется больше ни в одной другой картинке, получается массив искомых пикселей для каждой картинки всего 2-4 пикселя. Поиск таких "виртуальных" картинок естественно происходит мгновенно. Вот только если будет добавление картинок в набор, всё придётся делать по новой, а это очень муторно. Теперь про deviation. Да ничего там нового я не делал. Пример. Есть пиксель RGB(200,100,50). Задаём погрешность 10%. При использовании абсолютной погрешности (как сейчас) - это +- 25 к значениям каждого канала, т.е. будут искаться пиксели с RGB(175-225, 75-125, 25-75. Это не совсем правильно. А используя относительную погрешность будет искать RGB(180-220, 90-110, 45-55). То есть RED 200+-10%=20, GREEN 100+-10%=10 ... Вот так намного эффективнее, будет искать отклонение оттенков пропорционально, а не "размазню". Вопрос в том, что если такую математику помещать в цикл поиска, то намного медленнее ищет, поэтому тут тоже нужен компромисс. Я использую пока только абсолютную погрешность, потому что у меня и так всё ищется (просто задаю бОльшую погрешность, чем была бы при использовании относительной), но если картинки "хитрые" ... ну я уже говорил на эту тему. Посмотрю попозже потом всё что я нацарапал (свалка пока), может выложу код.
|
|
|
|
sutra |
21.1.2019, 13:53
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Если же ты Дарк спрашивал про accuracy, то я не стал вообще пока этим заниматься, так как никакого практического применения этого параметра, кроме как при поиске текста, я не вижу. А поиск текста - это вообще отдельная задача, для неё однозначно лучше иметь свой отдельный алгоритм. Если не использовать набор картинок для каждого символа (а это намного быстрее и главное ТОЧНЕЕ), то всё очень неоднозначно. Лично я бы считал аккуратность учитывая полутона. Два полутона считать за один полноценный пиксель. Как уже говорил... там частенько бывает так, либо 1-на тёмная линия и одна светлая, либо 1-на почти тёмная и две ещё светлее. А ещё правильнее считать сумму RGB и сравнивать её отклонение, лично я так и делаю, только без всяких картинок. Естественно всё это делать при построчном анализе.
|
|
|
|
sutra |
21.1.2019, 16:09
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Ну вот один из вариантов внутренностей, которые крутятся во внешнем цикле. Вроде работает, но я толком почти не тестировал, не до этого пока. Обкатывал чисто идею. Ищется ОЧЕНЬ быстро. Код local function ImageCompareS(addrGet,lenGet,arrpix,scrX,scrY,fx1,fy1) -- addrGet,lenGet : начальный адрес в памяти и длина строки образа -- arrpix : массив искомых пикселей -- scrX,scrY : координаты левого верхнего угла образа (что и в getimage) -- fx1,fy1 : координаты поиска картинки в образе -- структура массива искомых пикселей arrpix {x,y,r1,r2,g1,g2,b1,b2} -- x,y координаты значимых (искомых) пикселей в картинке (0..) -- r1,r2 граничные значения поиска канала для пикселя (создаются учитывая deviation) for i=1,#arrpix do -- цикл просмотра значимых пикселей ind=addrGet + (fy1 + arrpix[i].y - scrY) * lenGet + (fx1 + arrpix[i].x - scrX) * 3 -- вычисление индекса в памяти blue=rmem("unsigned char*",ind)[0] if blue>=arrpix[i].b1 and blue<=arrpix[i].b2 then green=rmem("unsigned char*",ind)[1] if green>=arrpix[i].g1 and green<=arrpix[i].g2 then red=rmem("unsigned char*",ind)[2] if red<arrpix[i].r1 or red>arrpix[i].r2 then return false end else return false end else return false end end return true end
В общем я это уже показывал только в виде идеи. Пихаешь свой прицел в массив (хватит и десятка пикселей) и любуйся скоростью.
|
|
|
|
DarkMaster |
23.1.2019, 4:38
|
Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008 Группа: Супермодераторы Наличность: 27707
Пользователь №: 11.279
|
Цитата Вместо одного байта нарисует ДВА, с символом 13. Никогда не понимал смысл подобных реализаций сишных записи в файл. Они всегда пишут кривые переносы строк. Используй не текстовый режим, а бинарынй: f=io.open([[set.txt]],"w b") Цитата Ну хорошо, следущий пост по финдам будет в новой теме. Разрабатывать лучше здесь, но должно быть место для каких-то релизов и обсуждения именно использования. Сейчас в данной теме если захочешь взять код и использовать и появятся вопросы, то шансов разобраться нет =) Тут рабочий беспорядок (IMG: style_emoticons/default/wink.gif)
--------------------
Скрипты UOPilot под заказ. Консультации по UOpilot 15$/час. Услуги Lua разработчика (не пилот, проекты, постоянка) Disсоrd: Kov____
|
|
|
|
sutra |
23.1.2019, 16:02
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Дарк, у меня пока более менее нормальный код не готов, чтобы его выкладывать. Всё ещё думаю над мелочами. Вот к примеру, на мой взгляд, вообще не вижу смысла делать поиск более одной картинки. Однозначно будет медленнее работать, а смысла особого нет. Если картинки лежат в известных местах, ничто не мешает их там и искать. А если например собирать монетки, как показывал Cirus, то тоже особого выигрыша не будет. Ну нашёл я 40 монеток, получил их координаты, а дальше что? Между кликами на монетки всё равно придётся делать паузы, так не проще сделать так - нашёл ... кликнул, нашёл ... кликнул, по времени поиск будет выполняться не намного медленнее чем ожидания между кликами. Опять же, если адекватно задавать и уменьшать по ходу дела зону поиска, то запросто ещё и быстрее получится. В общем лично я этой хренью заниматься не стану, ну не вижу для себя никакого смысла, даже на перспективу.
|
|
|
|
DarkMaster |
23.1.2019, 22:52
|
Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008 Группа: Супермодераторы Наличность: 27707
Пользователь №: 11.279
|
Цитата Дарк, у меня пока более менее нормальный код не готов, чтобы его выкладывать. Какой-то промежуточный вариант наболее рабочий, значит надо выкладывать. Цитата вообще не вижу смысла делать поиск более одной картинки. Однозначно будет медленнее Код fi.name = function (,,,path,,,) if type(path) == 'table' then for i = 1, #path do здесь вызов обчный функции на 1 изображение end else здесь вызов обчный функции на 1 изображение end end Таким образом мы не модифицируем саму функцию, просто при необходимости мы ее вызываем несколько раз. Подобная обертка _очень_ нужна.
--------------------
Скрипты UOPilot под заказ. Консультации по UOpilot 15$/час. Услуги Lua разработчика (не пилот, проекты, постоянка) Disсоrd: Kov____
|
|
|
|
sutra |
24.1.2019, 3:44
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Цитата Таким образом мы не модифицируем саму функцию, просто при необходимости мы ее вызываем несколько раз Ха, ты просто экстрасенс, ты читаешь мои мысли, вот хоть верь, хоть нет, ну просто аналог моего прототипа кода. Точно так же определял тип .. таблица или нет. Вот только там не всё так просто. Я такую штуку хотел прикрутить для поиска НАБОРА картинок. А при поиске нескольких картинок запросто может возникнуть коллизия пересечения координат поиска. Если конечно тупо просматривать от первого до последнего пикселя, то вроде должно всё быть нормально (хотя не анализировал на 100% ситуацию). Но такой поиск будет не быстр. Если же использовать "кишки", которые я в последний (крайний) раз выкладывал, ну если искать "избранные" пиксели, то запросто может найти одну и ту же картинку дважды. Ну вот стоят 2 домика у Сайруса один под другим, а следующие 2 домика с монетками, чуть ниже, а следующие 2 опять выше. Смещая поиск на 1 пиксель ниже, я легко найду по новой те монетки, что уже найдены. Выход один, увеличивать виртуальную картинку поиска и всё равно придётся запоминать зоны экрана, на которых уже обнаружена искомая картинка. Наверное сложная получилась трактовка. Может потом попробую подробнее про эту коллизию объяснить. НО, способ поиска не всех, а только нужных пикселей - это прорыв по скорости. Задавать фон (пиксели исключаемые вообще из поиска) и задавать искомые пиксели, нужно таблицами. То есть в теории, мы можем задать любое количество фонов и любое количество цветов искомых пикселей. Например для монеток, мне понадобится задание 2-х цветов - светлого (полупрозрачного фона "капельки") и жёлтого (центр первой монетки), всё остальное в ФОН. ТРЁХ пикселей будет достаточно для идентификации картинки монетки. Скорость поиска оправдает всё. Но может возникнуть коллизия пересечения координат поиска, если не отсекать (в произвольных координатах) зоны поиска, в которых уже найдена монетка. Ну реально нет времени заниматься этой логикой. Будет время - сделаю. Хочу в течении месяца "расправиться" со своими хитрыми задачами, потом ради интереса займусь и этим. Как программер вряд ли что смогу изобразить, а вот поделиться идеями и как тебе нравится реальным кодом смогу. НО ПОПОЗЖЕ. Реальный свой текущий код поиска, ну хорошо, посмотрю ещё повнимательнее и выложу на обозрение, только там ничего выдающегося и нового нет.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|