Помогите освоить LUA Опции

[sutra]

Разницы между структурой и неструктурой я тоже не выявил. У меня даже со структурой получилось чуть медленнее. Хрен знает, чего там lua сам про себя делает, может всё равно какое-то преобразование типов выполняет. Грубо говоря, осязаемого прироста я добиться не смог. И наверное овчинка выделки не стоит. От тормозов надо избавляться всё-таки оптимизацией математики, но опять же если юзер будет искать всегда в диапазоне 1920х1080, да ещё и 1000 картинок, ну кто ему поможет??

По уму конечно, целиком бы всё делать на СИ. Но это уже не мой уровень, да и вопрос опять всё тот же, А НАДО??

[sutra]

Может ещё попробую использовать вместо таблиц СИ-шные массивы, но уж больно не читаемо получается, а если делать двойную (повторную) инициализацию (массив[0]=таблица.r1) внутри функций, то же вопрос. При малых зонах поиска и при частых вызовах запросто может получиться даже медленнее. Будет время, потестирую и так и так.

В общем закономерность очевидная. Либо красиво и читаемо, но медленнее, либо чуток быстрее, но код будет полная абракадабра, через год сам не поймёшь чего наваял. Этак можно действительно и до АСМа "докатиться". Ну тестану ещё разок, поделюсь результатами, хотя уверен, ничего нового и революционного не открою.

[DarkMaster]

Я не знаю, как в lua напрямую работать с битами.

С битами никак, а с байтами уже работаешь. Создавая массив через ffi - ты создаешь непрервный набор байтов к которому и обращаешься.
Вход в любом случае должен быть бмпшником. Его можно как угодно конвертировать на начальном этапе, но вход должен быть адекватен. Хотя я не очень согласен с тем, что должно быть привидение к некоторой странной структуре самодельной. Я считаю оба формата (скрин и искомое) должны быть стандартным бмпшником, а вот для пользователей можно сделать упрощенное создание бмп конвертацией некоторого массива байт в битовую маску корркетную.

[DarkMaster]

Про биты наврал. В luajit есть bitop правда мне он никогда не был нужен.

[sutra]

Да самопальным методом можно всё вытащить и биты и всё, что угодно. Интересно с вами господа. А вот скажите-ка мне, какое принципиальное отличие в сценарии (скажем изначально задуманное) известнейшего фильма "Ирония судьбы или с лёгким паром" между двумя персонажами, которых играют Андрей Мягков и Юрий Яковлев? Понимаю, что никто не ответит, но для меня и молчание будет ответом и про себя буду думать, а кому "великое по плечу"? То, что эту тему читают, я не сомневаюсь. Вот вам логический вопрос.

Я считаю оба формата (скрин и искомое) должны быть стандартным бмпшником

Да, но вот тебе Дарк, великое точно по плечу. Только великое не создать стандартным подходом. Не надо замыкаться на догмах!


Я даже для себя составил психологические портреты многих участников форума. Тебе Дарк, на мой взгляд, не хватает ну какой-то свободы мысли. У тебя мощная база, но ты пытаешься всегда решить все вопросы по принципу - это возможно ... я обязательно что-нибудь придумаю ... вот я уже нащупал нить идеи и т.д. И обязательно, чтобы это было приемлемо для всех. Эх! Огорчу, всем ну никак не угодить.

Дарк - это моя лучшая интерпретация психологического портрета. Ты - действительно мастер своего дела. Кнайт? Тоже мастер, но он очень интересный человек, я пока только в частностях его понимаю, на нём большой груз ответственности за начатое им дело, а оно не может не лежать грузом ...

[sutra]

Сайрус, только не обижайся пожалуйста, для меня ты кардинал Ришелье, рука всегда на пульсе событий, всё про всех и обо всём знать. Твоё личное мнение, твои мысли знать не должен никто.

[sutra]

Я считаю оба формата (скрин и искомое) должны быть стандартным бмпшником

Ну тут хоть считай, хоть не считай, скрин точно БМПшник. Искомое? Искомое должно быть найдено, какая разница как я это сделаю? Если нашлось и при этом на порядок быстрее, то почему же это должно быть обязательно БМПшником?

[sutra]

Ну вот, даже явный и очевидный бит различия, между Мягковым и Яковлевым, никто не хочет найти, а собрались символы чата искать !! А подсказок не будет! И чат значит будете искать сами!

[sutra]

Дарк, а что мы скажем юзерам, которые играют в игру "Найди 5 отличий", ну или не знаю как там она называется. Смысл там такой, наоборот, найти различия в картинках. Надо тогда задавать и такой параметр поиска, ну что бы уж все были довольны. В общем, концепция распознавания чата у меня есть, но только функция поиска картинок будет иметь косвенное применение, а если точнее, нужно "рисовать" специализированную вещь, со своим алгоритмом. Стандартным подходом распознать будет явно проблематично, хотя у меня слишком мало данных, чтобы делать однозначные выводы, ну если сотворишь, как и говорил - сниму шляпу.

[sutra]

Я вот просто поглядел, как отрисовывает символы винда на рабочем столе, вот уж где действительно может быть ЛЮБОЙ фон, но в нашем случае всё намного кривее, тем не менее найти можно, если как раз уйти от стандартного мышления. И на мой взгляд, простым анализом хоть контрастности, хоть чего-либо подобного тут не отделаешься.

[FREEON]

раз вы занимаетесь разглагольствованием а не делом, то поделюсь секретом, как быстро искать отличия без всяких скрыптов и за тры секунды. Сохраняем две картинки в новую пустую папку, открываем просмотр, зажимаем стрелку влево или вправо и обона отличия мигают словно анимация (IMG:style_emoticons/default/smile.gif)

[sutra]

как быстро искать отличия без всяких скрыптов и за тры секунды

Согласен, конечно можно, правда 3 сек. - это Вы явно преувеличили. Без скрипта за 3 сек. не получится. Так я без всякого скрипта и чат читаю, вот уж действительно не совру секунд за 5 несколько строк сразу. А про разгалагольствования, Вы правы, бывает люблю потрепаться. Ну а про дело? Делом занимается Кнайт. Дарк тоже занимается в своей стезе. Остальные - разглагольствуют (я больше всех). Правда, что-то я кроме своих выкладок здесь пока ещё не видел, чтобы кто-то, чего-то, более менее стабильно искал. Своё дело - я делаю и уверяю Вас вполне неплохо. Просто появляются мысли, вот и делюсь ими типа пожеланий на будущие реализации. И я просто не согласен с Дарком, по поводу ОДНОЗНАЧНЫХ БМПшников, вот и выражаю своё мнение в нестандартном виде. Иногда сухой сленг просто утомляет мозг.


И ещё про дело. Мне вот две задачки подкинули - я дал нестандартное решение. Хотя, даже если всегда подсовывать даже БМПшник прицела, всё равно он будет искаться во-первых 100%, а во вторых НАМНОГО быстрее. Будет желание и время кину сюда готовый скрипт как всё это просто делается.

[sutra]

Про "хитрый" чат я тоже своё мнение высказал предельно ясно. Без анализа фона снимка экрана - дело "тёмное". Только вопрос, А КАК Я ОПРЕДЕЛЮ ЭТОТ ФОН? Какой пиксель смотреть? В любом месте может находиться пиксель не фона (это если попытаться стандартно всё запихать в одну функцию). Для меня слишком мало данных, чтобы что-то конкретно рабочее предложить, специально играть в разные игры для решения НЕ МОИХ задач я не стану.

[sutra]

Дарк, я потестил с массивом, вместо структуры. Да, получается быстрее, но я ни хрена не понимаю как правильно объявить такой массив. Вот так (от балды для теста ткнул 100) работает: local arr=ffi.new("uint16_t[100][5]"). А вот так не хочет:

Код

  local n=math.min(numf,(fx2-fx1+1)*(fy2-fy1+1))
  local arr=ffi.new("uint16_t[n][5]")

[sutra]

arr=ffi.new("uint16_t[100][5]")

Да и так конечно очень дефективно, при увеличении массива - жуткие тормоза при выделении памяти. Короче я не дотункал, как правильно объявлять массив. Понятно, что одномерные массивы, понятно, что указатель на указатель, но на этом моё понятие закончилось. Это вам не getmem - тут без образования нечего делать.

[cirus]

local arr=ffi.new("uint16_t[n][5]")

Код

local arr=ffi.new("uint16_t[" .. n .."]")

arr=ffi.new("uint16_t[100][5]")

Объявить массив на 500 элементов.

Код

arr=ffi.new("uint16_t[500]")

Допустим массив arr[100][5], те же 500 элементов одномерного.
Обратиться к элементу arr[40][2]
arr[100*2+40]

[sutra]

local arr=ffi.new("uint16_t[" .. n .."]")

Сайрус, извини, не въезжаю я что-то, как такая штука будет работать. Вариант одномерного массива тоже не устраивает. Массив (пока таблица) нужен для возврата параметров найденных пикселей. Было вот так:

Код

arr[k]={x=j,y=i,red=r,green=g,blue=b}

А надо, чтобы было так:

Код

arr[k]={j,i,r,g,b}

Что меня бесит, что задача то плёвая (ну не бывает проще, мозгов вообще не требует), а такие у меня вызывает трудности.

Инициализация структуры выполнялась так:

Код

ffi.cdef[[typedef struct{uint16_t x,y; uint8_t red,green,blue;}xyrgb]]
local arr=ffi.new("xyrgb[?]",math.min(numf,(fx2-fx1+1)*(fy2-fy1+1)))

Мне надо тоже самое сделать с обычным массивом.

[DarkMaster]

local arr=ffi.new("xyrgb[?][3]",math.min(numf,(fx2-fx1+1)*(fy2-fy1+1)))
Пальцем в небо, но по логике как-то так.


Вообще new сишный не предполагает создания многомерных массивов. Если нужен многомерный - создавай одномерный и его элементам присваивай массивы. В стандарте С++ 11 появились инструменты, но тут все консервативно, стандарт 98 года. Вообще в данном случае я не вижу смысла в создании двумерного массива. Сделай один большой, ползай по нему да и все.

[sutra]

Вообще new сишный не предполагает создания многомерных массивов. Если нужен многомерный - создавай одномерный и его элементам присваивай массивы

Спасибо, Дарк. Я так и понял, потому что всяко перепробовал. Сильно был удивлён, что такая элементарщина образца прошлого века не имеет нормальной реализации. Нет никакого смысла делать одномерный, так как нужно возвращать адекватно читаемый результат поиска. Значит оставим структуру. Да и так всё быстро ищется. Пора прекращать фигнёй заниматься. Лучше алгоритмом заниматься.

[DarkMaster]

Нет никакого смысла делать одномерный, так как нужно возвращать адекватно читаемый результат поиска.

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