Разработка findcolor, findimage, Pure lua Опции

[sutra]

А чем пилотный не подходит?

А что-то у меня не получалось это совместить с новым getimage.

Потестил старый финд. При малых deviation он делает нам "козью рожу". Наш алгоритм пропуска действительно неэффективен. Мы лопатим каждую позицию, прежде чем понять, удовлетворяет нас результат или нет. Это неверный подход. Есть у меня идея. В двух словах, скорее всего, надо искать попиксельно, а не целиком всю картинку, сначала сверяем 1-ый пиксель по всей зоне, потом 2-ой и т.д. Во всяком случае - это первое, что мне пришло в голову.

Вопрос только в том, что мне пока непонятно, либо весь алгоритм сразу переделывать, либо возможно требуется компромисс. То есть, например, если погрешность задана ну скажем менее 25% - новый алгоритм, если больше оставить старый. Надо пробовать и смотреть.

Грубо говоря, в моём алгоритме цикл 3-го уровня, делать циклом первого. Примерно так. Возможно я ошибаюсь - это спонтанное решение.

Уверен, у Кнайта именно такая реализация. И именно поэтому тормоза начинаются и увеличиваются именно с увеличением погрешности, т.к. растут циклы 2-го и 3-го уровня, а 1-й цикл (количество искомых пикселей неизменен). Я почти уверен, что я прав. В чудеса и сверхспособности я не верю.

Запросто переделаю, прямо сейчас. Всё именно так, как я думаю. Если не трогать погрешность, и менять процент accurace - это никак не влияет на скорость у Кнайта. Вывод очевиден, всё очень даже просто.

[sutra]

Дарк, переделал алгоритм. Скорость поиска - нуль. Чем больше % пропуска, тем даже быстрее. Сейчас некогда, через часик освобожусь, слегка подправлю код и выложу результаты. Пока ясно одно, наши алгоритмы работают.

[sutra]

Поторопился я, всё не так просто. Да, если искать только одну картинку, то вроде всё понятно, а вот если несколько, тут у меня пока не получается. Надо думать, но наверное уже не сегодня.

[sutra]

Прошу прощения, я ОЧЕНЬ сильно затупил. Думаю что в поставленной задаче ничего ускорить нельзя. Я вспомнил. Я даже вроде об этом спрашивал в теме про Пилот. Я нашёл в своё время косяки у стандартного финда и вроде (точно уж не помню) это и было как раз при поиске нескольких картинок, когда они накладывались друг на друга. В общем чего-то он не находил. Я не знаю какой там алгоритм, возможно какие-то методы исключения зон из последующих проверок. Короче господа, вы уж как хотите, а я буду использовать свой алгоритм, проверенный, абсолютно понятный, с предсказуемым результатом. А пропускать 250 пикселей на тестируемой картинке, я не вижу этому никакого практического применения. Ещё раз сорри за дезинформацию.

[DarkMaster]

Прикручена функция
-- ext.image_copy
-- Копирует часть изображения.
-- Допустимый синтаксис:
-- <address>,<x1>,<y1>,<x2>,<y2> -- если изображение загружено новым getimage
-- <{address, width}>,<x1>,<y1>,<x2>,<y2>
-- <{address=val, width=val}>,<x1>,<y1>,<x2>,<y2>
-- <{a=val, w=val}>,<x1>,<y1>,<x2>,<y2>

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

Важно понимать, что image_copy создает копию части битовой маски, соответственно - это полноценный кусок памяти загнанный в буфер. Необходимо удалять изображения из памяти (deleteimage), если они более не использются. В случае если происходит вызов saveimage с сохранением части изображения, то image_copy и deleteimage будут вызваны скрыто, дополнительного удаления не потребуется.

Что не так с loadimage и что ты от него хочешь? Просто альтернативу на луа?

[sutra]

Спасибо. Да я сам не знаю чего я хочу. Сам дотункаю, так что не парьтесь. Надо будет наверное просто глянуть чем отличается write от read. Я же для себя ковыряю. Всё переделал. Мне больше чем ХД не нужно. Сделал 2 глобальных массива CI[1] и CI[2], сразу выделил им по ХД, в функцию даю параметр в какой массив битовую маску получать и всех делов. Я так подумал, десятки раз в секунду у меня происходит захват экрана, зачем мне абсолютно ненужные действия, кроме тормозов никаких плюсов. Почесал конечно репу, пока не вспомнил про твой минус высоты, а то всё с задницы начиналось. Я ведь по факту и получал по адресу этот самый массив, короче убрал лишнее действие.

[sutra]

Вот только пока не определился с чем лучше работать с 32 битами или по старинке с 24.
И думаю всё про Кнайтовский алгоритм. Прямо даже зацепило. Наверное как-то построчно идёт анализ, уж очень хитро. Хотя, как и говорил, есть у меня подозрения на косяки. Я давно экспериментировал с ним, могу конечно ошибаться, как говорится не в первой. Но вроде как финд косячил именно на смешении картинок. Помню я нарисовал что-то типа забора, ну в общем, куча повторяющихся элементов, получалось как бы картинка на картинке. И на этом большом заборе искал его куски, естественно их находится много, и вроде как он неверные координаты выдавал. Хотя конечно интересно бы глянуть на алгоритм.
НО. Зацикливаться на нём точно не надо. Минусов в старом в разы больше. По моему опыту, мне вот как раз не надо делать пропуски. Всё с точностью до наоборот. Мне надо распознавать объекты в разных состояниях. А пропуски будут игнорить эти различия. Повторюсь, не вижу никакого применения, кроме наложения объектов, но как правило - это небольшие объекты и всё работает быстро. Во всяком случае я не видел особых тормозов, когда распознал ВСЕ твои мишени, всё равно, с новым имиджем получается однозначно быстрее старого финда.

[sutra]

Спасибо вам друзья огромное!! Лично мне всего хватает и скорости и функционала. Вспоминаю, как извращался с Пилотом на родном ему языке - ужас. А нынешние технологии, для меня это просто прорыв.

А тебе Дарк, как раз стоит подумать про забор. Очень интересные там могут получаться комбинации. Почему я и говорил про шаг поиска и при поиске картинок. И хоть у меня пока таких проблем не возникало, но, во всяком случае практическое применение этому я вижу.

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

[sutra]

У меня остался один вопрос, может подскажете. Как резвенько скопировать часть СИ-шного массива в другой СИ-шный массив. В Паскале была функция move, которая позволяла это делать. Выделять память как я понимаю надо использовать malloc , удалять free.

[cirus]

Как резвенько скопировать часть СИ-шного массива в другой СИ-шный массив.

Код

--lua
local ffi = require("ffi")
ffi.cdef[[
    void RtlMoveMemory(void*  Destination, void const *Source, unsigned int Length);
]]

log 'clear' log 'mode compact'

local array = ffi.new('int[10]', {0, 10, 20, 30, 40, 50, 60, 70, 80, 90})   -- массив на 10 элементов

local array2 = ffi.new('int[5]')  -- массив на 5 элементов
ffi.C.RtlMoveMemory(array2, array+2, 20)  -- скопировать 20 байт, начиная с 3го элемента

log(array2[0])
log(array2[1])

[sutra]

Спасибо Cirus! Скоро буду СИ-шником. (IMG:style_emoticons/default/biggrin.gif)

[Cockney]

Это не Си. Смотрите memcpy() функцию.

[sutra]

Смотрите memcpy() функцию

Посмотрел, спасибо. А как к скрипту присобачить?
И вообще я вроде затупил. Привык по-старинке ... выделил память ... освободил память.
А тут я так понял само всё чистится, как только выходишь из зоны видимости?

Код

    void memcpy(void*  Destination, void const *Source, unsigned int Length);
 

Правильно объявил? Вроде работает.

[Cockney]

Посмотрел, спасибо. А как к скрипту присобачить?
И вообще я вроде затупил. Привык по-старинке ... выделил память ... освободил память.
А тут я так понял само всё чистится, как только выходишь из зоны видимости?

Ну если явно вызывается malloc(), то нужно вызывать free(), если просто происходит ffi.cast, то ничего делать не требуется.

[sutra]

Не, malloc - это указатель делает, нахрен не нужен. Делаю new

[Cockney]

Код

    void memcpy(void*  Destination, void const *Source, unsigned int Length);
 

Правильно объявил? Вроде работает.

Да.

[sutra]

Код

if true then
  local arr={}
  for i=1,10 do
    arr[i]=ffi.new('unsigned char[?]',100000)
    ffi.C.memcpy(arr[i],CI[1],4)
--    ffi.C.RtlMoveMemory(arr[i],CI[1],4)
    log(arr[i][0])
    wait(1000)
  end
  log(arr[3][1])
end 

То есть по окончании оператора if память будет очищена? Всё верно понимаю? Специально по 100 кило выделял, смотрел загрузку памяти, вроде всё почистилось само.

Как я понял memcpy самый быстрый способ, так как нет никакого контроля границ диапазонов, по сравнению скажем с memmove.

[Cockney]

Память освободится при завершении работы скрипта (из контекста не понятно - это часть или весь скрипт) либо если память будет забита и в игру вступит сборщик мусора. Но тогда и скрипт подвиснуть должен.

Вот тут ребята вроде сделали быстрее

[sutra]

Точно, не чистится, сделал задержку после ифа , посмотрел на память - не очистило. Тогда так нельзя. Тогда что? только через malloc?

Инглиш не для меня. Я в советское время учился и мы считали, что этот буржуйский язык нам никогда не пригодится.

Мне просто показалось, что rmem всё-таки подтормаживает процесс, почему я и использую СИ-шные массивы. Как то всё уж больно хитро. Вот раньше, как просто у меня было. getmem p-адрес p^[25] указатель на конкретные данные freemem - свободен. А тут кругом препятствия.

Задача то простая. В цикле (скажем 1 сек.) ... Сканирую экран ... поиск объектов ... хотелось бы получить копию битовой маски (небольшая) ... если всё штатно освободить память, если нет сохранить все кадры в файлы и освободить память и это всё в одном большом глобальном (почти вечном) цикле.

[DarkMaster]

только через malloc?

Во первых если ты будешь использовать указатели, то только malloc иначе сборщик мусора просто уничтожит данные. Он не сопоставляет указатели. Т.е. если были какие-то данные local и больше к ним не планируется доступ напрямую, то сборщику будет глубоко пофиг на то, что где-то висит указатель и через этот указатель ты будешь дергать данные.
Выделять память настоятельно рекоменду через gc.
local bitmap_address = ffi.gc(C.malloc(bitmap_size), C.free)
чтобы сборщик знал, как прибить.
Если память используешь активно, то придется либо явно вызывать free либо collectgarbage() - иначе можешь обожраться памяти (временно).

bitmap_address = nil
дальше сборщик сделает свое дело