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

[cirus]

не знаю как там получить список файлов

Код

--lua
log "clear"  log "mode compact"
resultarray, count = dir ([[C:\Windows]], "*.exe", "norecursion")
log ("Найдено файлов: " .. count)
if count > 0 then
    for i=1, count do
        log(resultarray[i][1])
    end
end

[DarkMaster]

В данном случае я бы рекомендовал для начала забыть про jpg. Не стоит создавать проблемы там, где их можно легко избежать. Не тот размер у бмп/пнг, чтобы ловить развлечения с jpg.

[sutra]

resultarray, count = dir ([[C:\Windows]], "*.exe", "norecursion")

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


Спасибо за совет, надо конечно эксперементировать.

забыть про jpg

Дарк, так я для себя сделал, файлов эталонов будет наверное около 1500 штук, но это не скажется на быстродействии, в любом случае мой метод намного быстрее и практичнее. Я его делал, когда не было поиска в памяти, но думаю и поиск в памяти будет медленнее и НАМНОГО.


Хотя вариант с dir сопоставим по скорости, сравнение и циклы в lua тоже без тормозов. Спасибо Cirus. Но lua тоже не было раньше, а переделывать мне лень.

У меня одна проблема, мне нужен быстрый колор, хотя я практически доделал свой, сопоставимый по скорости, если по вертикали не более 70 пикселей, то всё работает хорошо, ну а больше мне наверное и не понадобится.

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

[sutra]

resultarray, count = dir ([[C:\Windows]], "*.exe", "norecursion")

Сорри, не доглядел, действительно, я не знал синтаксиса этой команды. Ещё раз спасибо.

[DarkMaster]

Очень неплохо поднимается производительность, если буферизировать изображения под имидж, если их нужно перебирать достаточно большое количество.
Loadimage()
Тем не менее нужно понимать, что для некоторых случаев колор действительно предпочтительнее, когда можно описать одной формулой несколько изображений, а то и десяток.

[sutra]

Так в том то и фишка, что колор в памяти только-только начал свой путь в большую жизнь. Колором я бы ещё мог ускорить распознавание. Вызов printscreen и getimage по скорости абсолютно одинаков (у меня 27 тысячных), а обработка колором (в теории) быстрее тех 2-х сотых, которые кушает моя программа.

Конечно я имею ввиду lua, а его я начал осваивать без году неделя.

[cirus]

Код

--lua
-- сделать привязку Ctrl+A
local h = workwindow()
local t, addr=os.clock()
for i=1, 100 do  -- для теста 100 скринов
    addr = getimage (0, 0, 500, 500)
end
log(os.clock()-t)

t=os.clock()
for i=1, 100 do  -- для теста 100 скринов
    addr = getimage (0, 0, 500, 500, h)    -- так быстрее чем вызов без указания хендла
end
log(os.clock()-t)

Разница по времени зависит от приложения.

[sutra]

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

Спасибо большое. Век живи и век учись. Я просто плохо пока понимаю принципы работы, но потихоньку учусь.


А где ещё можно указывать хендл? В каких операторах?

[cirus]

А где ещё можно указывать хендл?

Color, findimage, findcolor, getimage, move, left, readmem, writemem.

[sutra]

ОК.

[sutra]

Теперь про борьбу с рендерингом. Может кому пригодится. Даже используя стандартный Пилотовский findimage соблюдая два нехитрых правила результат поиска становится стабильнее и точнее.
1) На рендеринг (прорисовку) любой картинки влияют соседние с ней ИЗМЕНЯЮЩИЕСЯ объекты. Поэтому захват нужной картинки надо производить по возможности дальше от таких объектов.
Например, есть текст, который надо захватить для сравнения с неким оригиналом, и над этим текстом вверху постоянно меняющееся изображение каких-либо объектов.
Предположим, что высота символов 12 пикселей. Осуществляйте захват не по всей высоте текста, а сместите верхнюю границу зону захвата на 2-3 (а возможно и больше) пикселя ниже.
Грубо говоря скрин будет размером не 40х12, а скажем 40х10. Картинка конечно смотрится неприглядно, но идентифицировать её будет проще, так как подверженные влиянию верхние пиксели мы отбросим, кстати границы объектов всегда наиболее подвержены рендерингу.
2) Сильно может влиять положение рабочего окна, поэтому лучше чтобы рабочее окно всегда находилось на "своём привычном месте", я его устанавливаю при помощи set windowpos ...

Мне на 100% избежать влияния рендеринга удаётся не всегда, но в таких случаях у меня есть 2-3 (ничто не мешает сделать и больше) эталонных файла картинки. Имена файлов эталонов содержат номер события, поэтому все они легко распознаются в соответствии с событием (0001.jpg; 0002-a.jpg; 0002-b.jpg; и т.д.). Размеры файлов варьируются очень сильно, поэтому в подавляющем большинстве случаев, опознание производится по размеру файлов не прибегая к открытию файлов и их сравнению.

Кстати можно хранить содержимое файлов эталонов в памяти, да и сам список файлов тоже. Никаких тормозов в принципе быть не должно, хотя у меня и внешняя программа пашет на ура.

[sutra]

Конечно если картинки очень сложные, то спасёт только deviation Пилотовского имиджа, тут без вариантов. Ну или надо напрячь серое вещество и работать колором.

[sutra]

Код

function FindRGB(addr,len,scrX1,scrY1,fx1,fy1,fx2,fy2,usl,numf,h)
  -- addr,len : адрес в памяти и длина строки в памяти (то, что даёт getimage)
  -- scrX1,scrY1 : координаты скрина, аналогичны координатам getimage (конечные X и Y не требуются)
  -- fx1,fy1,fx2,fy2 : координаты поиска, абсолютные относительно рабочего окна (мне так удобнее). Должны быть внутри диапазона скрина.
  -- usl : условие поиска "R(10-255) G(70-100) B(50) R-G[50 200] R-B[-40 -20] G-B[15]"
  -- условие ОДНО, по принципу ужесточения параметров поиска. R-G - разность между каналами с возможностью интервала
  -- G-B[15] идентично G-B[15 255]
  -- никакой проверки лексики естественно нет
  -- numf : количество искомых пикселей
  -- h : хендл пилота
  local _,_,r1,r2 = usl:find("R%((%d+)%-*(%d*)")
  local _,_,g1,g2 = usl:find("G%((%d+)%-*(%d*)")
  local _,_,b1,b2 = usl:find("B%((%d+)%-*(%d*)")
  local _,_,RG1,RG2 = usl:find("R%-G%[(%-*%d+)%s*(%-*%d*)")
  local _,_,RB1,RB2 = usl:find("R%-B%[(%-*%d+)%s*(%-*%d*)")
  local _,_,GB1,GB2 = usl:find("G%-B%[(%-*%d+)%s*(%-*%d*)")
  r1=tonumber(r1)  r2=tonumber(r2)
  g1=tonumber(g1)  g2=tonumber(g2)
  b1=tonumber(b1)  b2=tonumber(b2)
  RG1=tonumber(RG1)  RG2=tonumber(RG2)
  RB1=tonumber(RB1)  RB2=tonumber(RB2)
  GB1=tonumber(GB1)  GB2=tonumber(GB2)
  if r1==nil then  r1,r2=0,255  else  if r2==nil then  r2=r1  end  end
  if g1==nil then  g1,g2=0,255  else  if g2==nil then  g2=g1  end  end
  if b1==nil then  b1,b2=0,255  else  if b2==nil then  b2=b1  end  end
  if RG1==nil then  RG1,RG2=-255,255  else  if RG2==nil then  RG2=255  end  end
  if RB1==nil then  RB1,RB2=-255,255  else  if RB2==nil then  RB2=255  end  end
  if GB1==nil then  GB1,GB2=-255,255  else  if GB2==nil then  GB2=255  end  end
  local r,g,b=0,0,0
  local arr,ss,k,numbyte,pos={},"",0,255,(fx1-scrX1)*3                   -- pos -  количество первых байтов в строке памяти не требующих анализа
  if len<253 then
    local rgb=1
    local ind=addr+(fy1-scrY1)*len+pos                                   -- начальный индекс в памяти для считывания данных
    local maxind=addr+(fy2-scrY1)*len+(fx2-scrX1+1)*3-1                  -- конечный индекс в памяти для считывания данных
    local x,y,j=fx1,fy1,1
    while ind<=maxind do
      numbyte=math.min(255,maxind-ind+1)                                   -- количество байт для очередной итерации считывания из памяти
      ss=readmem(ind,"s",numbyte,h)
      ind,j=ind+numbyte,1
      while j<=numbyte do
        if x>=fx1 and x<=fx2 then
          if rgb==1 then  b=string.byte(ss,j)  end
          if rgb==2 then  g=string.byte(ss,j)  end
          if rgb==3 then
            r=string.byte(ss,j)
            if r>=r1 and r<=r2 and g>=g1 and g<=g2 and b>=b1 and b<=b2 and r-g>=RG1 and r-g<=RG2 and r-b>=RB1 and r-b<=RB2 and g-b>=GB1 and g-b<=GB2 then
              k=k+1  arr[k]={}  arr[k][1]=x  arr[k][2]=y  arr[k][3]=r  arr[k][4]=g  arr[k][5]=b
              if numf<=k then  return arr  end
            end
          end
        end
        j,pos=j+1,pos+1
        if rgb<3 then  rgb=rgb+1  else  rgb,x=1,x+1  end
        if pos==len then  pos,y,rgb,x=0,y+1,1,scrX1  end
      end
    end
  else
    local numreed=math.ceil((fx2-fx1+1)*3/255)
    local ost=math.fmod((fx2-fx1+1)*3,255)
    for i=fy1,fy2 do
      local ind=addr+(i-scrY1)*len+pos
      local x=fx1
      for s=1,numreed do
        if s==numreed then numbyte=ost  else  numbyte=255  end
        ss=readmem(ind,"s",numbyte,h)
        for j=1,numbyte,3 do
          b=string.byte(ss,j)
          g=string.byte(ss,j+1)
          r=string.byte(ss,j+2)
          if r>=r1 and r<=r2 and g>=g1 and g<=g2 and b>=b1 and b<=b2 and r-g>=RG1 and r-g<=RG2 and r-b>=RB1 and r-b<=RB2 and g-b>=GB1 and g-b<=GB2 then
            k=k+1  arr[k]={}  arr[k][1]=x  arr[k][2]=i  arr[k][3]=r  arr[k][4]=g  arr[k][5]=b
            if numf<=k then  return arr  end
          end
          x=x+1
        end
        ind=ind+numbyte
      end
    end
  end
  return arr
end

log "clear"  log "mode compact"
local x1,y1,x2,y2=49,100,551,941
local address, w, h, len = getimage (x1, y1, x2, y2)
local handle = windowhandle()
local bmp={}
bmp=FindRGB (address, len, x1, y1, 49,700,51,901,"R(0-255)",20000,handle)
deleteimage(address)
for i=1, #bmp do
    log(table.concat(bmp[i], "  "))     -- вывод массива в лог
end

Наваял тут, может ткнут носом что совсем не так делаю. И вопрос, а как сделать, чтобы сохраняя формат в отдельном окошке код помещать?

Сообщение отредактировал sutra - 14.11.2018, 13:56

[sutra]

Круто, я так не умею, не знаю как.

[sutra]

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

А может Кнайт всё-таки сделает колор инструментом №1.

[DarkMaster]

len

Может быть рассчитан на основе кооридант. Т.е. его передача по сути не требуется.

local _,_,r1,r2 = usl:find("R%((%d+)%-*(%d*)")
local _,_,g1,g2 = usl:find("G%((%d+)%-*(%d*)")
local _,_,b1,b2 = usl:find("B%((%d+)%-*(%d*)")
local _,_,RG1,RG2 = usl:find("R%-G%[(%-*%d+)%s*(%-*%d*)")
local _,_,RB1,RB2 = usl:find("R%-B%[(%-*%d+)%s*(%-*%d*)")
local _,_,GB1,GB2 = usl:find("G%-B%[(%-*%d+)%s*(%-*%d*)")
r1=tonumber(r1) r2=tonumber(r2)
g1=tonumber(g1) g2=tonumber(g2)
b1=tonumber(b1) b2=tonumber(b2)
RG1=tonumber(RG1) RG2=tonumber(RG2)
RB1=tonumber(RB1) RB2=tonumber(RB2)
GB1=tonumber(GB1) GB2=tonumber(GB2)

Можно избавиться передавая вместо стринга массив. Что-то врод:
{r={0, 255}, g={100, 200}}
При этом парсинг, как таковой не очень нужен, читаемость едва ли шибко хуже, но при этом уже полностью стандартизирована и чистый луа в который можно и переменной задать какие-то куски.
Обращаю внимание на то, что избавиться можно именно от парсинга, но вот таблицу привести к массиву ради скорости работы все же нужно. Задание переменными по сути структуры не очень хорошо - массивы как-то логичнее (навсякий случай проверить скорость работы).

function FindRGB

local опять уплыл.

for

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

[sutra]

Спасибо Дарк. Я не знал про переменные. В Паскале это вроде влияло только на размер дебуггера. Хотя всё равно тормоз - reedmem.

При этом парсинг, как таковой не очень нужен

Да я вообще в этом почти ничего не понимаю. Я самоучка, методом тыка на примерах. Нет у меня образования. Ты объясняешь, я примерно пытаюсь понять.

Я сегодня 3 часа убил только на изучение шаблонов при обработке строк, а ты говоришь таблицей. Нигде "у нас" не сказано, что * - это нуль и более или что () - возвращают результат. Тыкался наугад как слепой котёнок. А была бы путная справка (например которую бы нарисовал я) 10 минут и чел, имеющий хоть малейшее понятие, всё бы понял.

Хотя конечно, по себе знаю, написание хелпа, самая нудная и неблагодарная задача. Раньше Петя Нортон был корифей в этом, а теперь всем некогда.

[DarkMaster]

Я сегодня 3 часа убил только на изучение шаблонов при обработке строк, а ты говоришь таблицей. Нигде "у нас" не сказано, что * - это нуль и более или что () - возвращают результат.

Это регэкспы. Можно почтиать в regex, но в луа они специфические, поэтому рекомендую все-таки или буржуйскую справку или какие-то общие статьи. Тема на самом деле достаточно объемная и не самая простая для восприятия. Там очень много подводных камней с оптимизацией. Я хоть и очень люблю регэкспы, но стараюсь руководствоваться правилом: чем меньше, тем лучше. В понятие "меньше" входит частота вызова участка кода. Регэксп быстр в описании и медленный в работе, нужно это учитывать при написании, хотя конкретно в текущем коде он не критичен, но просто там и не нужен (IMG:style_emoticons/default/smile.gif) Тем не менее не смотря на его тормознутость при выполнении когда-то мной был написан конвертор параметров мобов сервера уо в c#. Так просто было быстрее в плане написания, а код этот по сути должен отработать был только один раз.
Поверьте потраченные 3 часа на регэкспы - это мелочь и они вам точно еще пригодятся в жизни.

[sutra]

Спасибо на добром слове Дарк. Примерно я понимаю. Это раньше за каждый байт и даже бит "бились". Я работал на Искре-1030 (512 кб оперативки, 10 МБ разбитый на 5 лог. дисков винт) приходилось некоторые участки кода на ассемблере писать. А сейчас ... кто на чём будет экономить? Памяти - дохренища, винт - солид + РАМ гиг на 16. Прогресс не умолим, я отстал от него неотвратимо. Помню теоретические выкладки о пороге частоты в 1 гигагерц, вот смешно сейчас.

Да ещё и в очередь, 286 машинка стоила тогда более 50 000, не один жигуль можно было купить. Помню как кто-то сказал ... а Нортон то синий, на монохроме мы сидели. Но тогда было интереснее, сейчас все "зажрались".

Да и игры заточены только на выманивание денег - интеллекта - нуль целых, хрен десятых. Вот мы и будем кликать Кнайтовским Пилотом.

[sutra]

и они вам точно еще пригодятся в жизни

А вот это не факт. Каркать не стану, но сдаётся мне, не так уж много мне осталось.