В чем проблема...?

[Vint]

  короче, жизнь - зло.

[Hito]

короче, жизнь - зло.

Согласен ))) Я просто эмулятор PS2 поставил на комп и очень хочется пройти игру, которую я когда-то на соньке играл )) - God of War и God of War II. Очень уж игруха прикольная )) Но она ведь под джойстик заточена, а там часто нужно вовремя нужные кнопки нажимать, особенно на боссах. На джойстике это сделать трудно, а уж на клаве... Я уже молчу, когда на клаве нужно сэмитировать вращение правого, или левого тригера джойстика в определенную сторону. Это даже не просто нажимать поочередно "W" - "D" - "S" - "A", а последовательно зажать "W", потом зажать  "D", потом отпустить "W" и зажать "S", потом отпустить "D" и зажать "A" и так далее. Это попа... И на все это нужно среагировать быстро - в течении пары секунд. Но охота пройти еще раз игрушку... 

[Hito]

Как говорил Джонни, он начинает писать делфи на делфи. В чём тогда смысл?

Ну, для примера приведу тебе ситуацию...
В Clickermann-е для того, чтобы сделать скрин экрана и поместить его в буфер, нужно прописать всего лишь "GETSCREEN".
В delphi для этого нужно прописать:

bmp1 := TBitmap.Create;
bmp1.Width := Screen.Width;
bmp1.Height := Screen.Height;
BitBlt(bmp1.Canvas.Handle, 0,0, Screen.Width,
Screen.Height, GetDC(0), 0,0,SRCCOPY);

Оххх...! Я уже молчу про поиск картинки в картинке...
Джони существенно облегчил язык скрипта для пользователей Clickermann-а.

[dramster]

В общем вот программку набросал http://www.fayloobmennik.net/6636343
А вот образец картинки для работы http://www.fayloobmennik.net/6636320

я так понимаю, что должно получиться чтото типа этого

на выполнение ушло 120мс. кликерман не сильно и отстает  , всего в 5 раз дольше, 670мс (это с учетом, что SCREENSHOTFIX выполняется у меня ~100мс). значит у тебя будет гдето 350мс.

скрипт делает тоже самое, что и твоя прога.

Code: (clickermann) [Select]

$x1=135
$y1=690
$x2=222
$y2=755


$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
SCANPXL($orange, $x1, $y1, $x2, $y2, 19404)
COLORMODE(8,$x1, $y1, $x2, $y2)
PXLREPLACE($x1, $y1, $x2, $y2,16777215,0)

$size=ARRSIZE($orange)-1
FOR($a=0,$a<$size)
PXLREPLACE($orange[$a],$orange[$a+1],$orange[$a],$orange[$a+1],0,19404)
END_CYC

SCREENSHOTFIX($x1, $y1, $x2, $y2, "OutScreen.bmp", 0)
LOGWRITE ($_ms-$ms)

halt

[dramster]

PXLREPLACE скорее всего был придуман для работы с областью граф. буфера, а не для замены отдельного пиксела. и существенной  разницы по времени при замене одного пикселя или 10 000 пикс. нет. мне кажется, тут не хватает процедуры SETPXL(x,y,color), ну или чтото типа этого, чтобы независимо от цвета пикселя, кликер отрисовал в буфере нужный нам цвет.

[Oraven]

мне кажется, тут не хватает процедуры SETPXL(x,y,color), ну или чтото типа этого, чтобы независимо от цвета пикселя, кликер отрисовал в буфере нужный нам цвет.

PXLREPLACE(100,100, 100,100, -1, 255) // если в параметре -1 то любой цвет будет заменен на указанный.

[Hito]

скрипт делает тоже самое, что и твоя прога.

Если честно, то у меня за весь день опухла голова и я сейчас туго соображаю, чтобы вникнуть в ваши примеры ) А моя прога вот, что делает:

 for Y := 0 to bmp2.Height - 1 do
  for X := 0 to bmp2.Width - 1 do
  begin
      Color:=bmp2.Canvas.Pixels[x,y];
      if (Color<>19404) then
      begin
          bmp2.Canvas.Pixels[x,y]:=0
      end;
  end;

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

Вот, например
http://shot.qip.ru/00R6pv-517zmt2ziI/
Или вот
http://shot.qip.ru/00R6pv-517zmt2ziJ/
Или вот
http://shot.qip.ru/00R6pv-517zmt2ziK/

Там куча вариантов разных...

[dramster]

Я вот, что сейчас подумал... Может обрабатываемую площадь разбить на 4 части и пусть ее 4 потока обрабатывают...? 
Аааа... Тут же вроде GETSCREEN один на все потоки...
А если бы и не один, то тоже хз - как. Муть уже всякая в голову лезет )))

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

Мне просто две такие области закрашивать нужно и с поиском пяти цветов в этих областях. А потом еще сравнивать заготовленные картинки с этими областями (их больше 15-ти). И все это нужно делать быстро...

и просмотрев эти скрины

Вот, например
http://shot.qip.ru/00R6pv-517zmt2ziI/
Или вот
http://shot.qip.ru/00R6pv-517zmt2ziJ/
Или вот
http://shot.qip.ru/00R6pv-517zmt2ziK/

я начинаю подозревать, что тебе в игре дают подсказки, на какие кнопки жать, и что куда крутить.

а ты случаем не забыл, что в функции IF_PICTURE_IN есть параметр игнорируемого цвета? если использовать этот параметр, то все твои манипуляции с буфером отпадают. но даже если так, то всеравно, фрагмент такого размера будет искать оооочень долго. как по мне, тут к месту "PXLCOUNT (x, y, x2, y2, color) - числовая функция; производит подсчет количества пикселей заданного цвета в прямоугольной области буфера анализа "

хотя, возможно я ошибаюсь в поставленных задачах  . и не все так просто как мне показалось.

[Hito]

я начинаю подозревать, что тебе в игре дают подсказки, на какие кнопки жать, и что куда крутить.

Ты прям - Догада!  (Это шутка не со зла) Ты видимо в приставки не играл никогда ))
Вот джойстик для PS2 - http://shot.qip.ru/00R6pv-117zmt2ziW/
Естественно в игре дают подсказку - на какую кнопку жать, но игра подразумевает, что ты должен помнить, под каким пальцем у тебя какая кнопка. Под каким кнопка с треугольником - под каким с квадратом, и так далее. И в игре дается время на это действие столько, чтобы ты нажимал их по памяти. Там столько времени на это отпускается, что даже держа в руках джойстик, ты не успеваешь на него смотреть, чтобы визуально сориентироваться - где нужная кнопка.
А вот настройка эмулятора PS2, в которой кнопки джойстика переносятся на клавиатуру - http://shot.qip.ru/00R6pv-617zmt2ziX/
Это тебе нужно не только помнить - где на джойстике какая кнопка, но и помнить - на какую кнопку клавы ты ее воткнул )) Кнопки, что выскакивают ближе к центру экрана, еще попроще. Они хоть и на прозрачных панелях, но с помощью цветокоррекции их еще можно отловить. А вот с теми кнопками, что в левом углу экрана появляются, ситуация сложнее...
https://www.youtube.com/watch?v=vYMdZGa8nSc&feature=youtu.be
То есть, как мы видим, одну кнопку еще и в нескольких вариантах ловить нужно )) Это при том, что в этом видео я их жал в ручную и даже заранее положив палец на нужную кнопку, у меня не хватило моторики, чтобы прожимать ее с нужной скоростью, чтобы открыть проход дальше ))) И в этом варианте это еще не самые сложные кнопки выскакивают. Это не бой с боссами и все такое ))

а ты случаем не забыл, что в функции IF_PICTURE_IN есть параметр игнорируемого цвета?

Я скажу больше - я даже не знал о таком параметре )) Что он делает?

[dramster]

Я скажу больше - я даже не знал о таком параметре )) Что он делает?

пример:
будем искать фрагмент твоего скрина с использованием игнорируемого цвета. в моем примере это цвет черный "0". ищем прямо в браузере.

Code: (clickermann) [Select]

$x1=94
$y1=650
$x2=262
$y2=786
$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 0, 100) // при поиске будут игнорироваться все черные пиксели которые в "test.bmp". цвет ригнорирования можно использовать любой.
  print($_return1,"x", $_return2)
END_IF
LOGWRITE($_ms-$ms)
halt
область поиска впиши свою, чтобы ускорить поиск.
 "test.bmp" во вложении

[Hito]

О как...! Так это можно заготовить заранее таких картинок, на которых будет сохранен только нужный цвет, а потом искать его совпадение уже не закрашивая скрины "онлайн"...? Что-то в меня это надежду вселило прям... 

Code: (clickermann) [Select]

$x1=94
$y1=650
$x2=262
$y2=786
$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 0, 100) // при поиске будут игнорироваться все черные пиксели которые в "test.bmp". цвет ригнорирования можно использовать любой.
  print($_return1,"x", $_return2)
END_IF
LOGWRITE($_ms-$ms)
halt

Только я не пойму - где тут указывается параметр, при котором будет игнорироваться цвет? Я что-то не вижу его... Это нолик перед 100 что ли...? Где обычно стоит -1?

[dramster]

О как...! Так это можно заготовить заранее таких картинок, на которых будет сохранен только нужный цвет, а потом искать его совпадение уже не закрашивая скрины "онлайн"...? Что-то в меня это надежду вселило прям... 

именно так 
но все равно, поиск картинки это както долго как по мне. тут всеже  к месту был бы PXLCOUNT (x, y, x2, y2, color)

[Hito]

но все равно, поиск картинки это както долго как по мне.

Дак само сравнение разных картинок уже можно разбить на группы и запихнуть в разные потоки )) Думаю, что это уже проще и сократит время на поиск большого количества вариантов картинок )) Или я ошибаюсь...?

[dramster]

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

[dramster]

Только я не пойму - где тут указывается параметр, при котором будет игнорироваться цвет? Я что-то не вижу его... Это нолик перед 100 что ли...? Где обычно стоит -1?

да, это нолик, черный цвет. если-бы я вместо черного зарисовал к примеру красным 255, то было бы так IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 255, 100)