UoKit.com Форумы > Кликер > UO Pilot
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59
DarkMaster
Собственно обсуждение багов, фич, функционала, тесты и прочее.
Вверх
sutra
Я в теме. Я давно отказался от передачи массивов. Делаю сразу глобальный массив (достаточно большой) через ffi , который использует и финдколор и все кому надо, и никаких тормозов. Если данные требуются позже (что крайне редко) ничто не мешает запомнить их отдельно. Понятно что это не эстетично, но совершенно нет потерь времени, необходимое при выделении памяти на массивы. По факту, при адекватных зонах поиска, время поиска - НУЛЬ.

Мне очень удобно. Грубо говоря вызываю if findcolor(... и данные поиска уже лежат в глобальном массиве и ими пользуешься напрямую в любых следующих действиях .

Сейчас буду пробовать твой вариант, если получится, то проблема будет решена для всех случаев жизни - спасибо!

Кстати, вот ещё замечание. От мощности видюхи зависит скорость доступа к данным, остальное от камня. Я успел до кризиса поменять на RTX 2070 - как чувствовал, что подорожают. Небольшой прирост в скорости всё-таки получил.
Вверх
DarkMaster
Цитата
Я в теме.

Ловлю на слове. Пока хочу допилить, то, что есть, чтобы понять, как оно вообще работает, на чем сыпит скорость и т.д. У меня на данный момент финдколор на фул хд отрабатывает за 0.02 секунды, ирония в том что из этого 0.015 занимает парсинг параметров. Нужно допиливать. Код уже переписан раз на 10.

Цитата
Что-то у меня не получилось, выдаёт три нуля. Адрес присваивал шестнадцатиричное число из первого скрипта.

Можно в коде увидеть?
Вверх
sutra
Не помню сколько у меня на фул хд. Я же сказал при "адекватных". Искать совсем не зная что и где - наверное тут и нет таких требований к скорости. Если искать мишени по всему экрану, то двух сотых вполне достаточно, чтобы потом всех их пристрелить, за полсекунды.

Всё ОК. Спасибо.
Вверх
DarkMaster
Цитата
Не помню сколько у меня на фул хд. Я же сказал при "адекватных".

Ты где тут нашел адекватного?) Ну а вообще тесты то нужно как-то делать. На меньшем размере и вовсе на фоне парсинга хрен поймешь сколько времени занимает. На то они и тесты чтобы давать нагрузку.
Вверх
sutra
Да я понял, но у меня в основном нагрузка на файндимидж. Поиск конечно идёт по локальным позициям, а не по всему экрану. Ищутся все кнопки, все цифры, все наименования. Один getimage и потом мгновенно всё распознаётся. Ищу как и говорил ранее, не картинки а силуэты!! Например силуэты цифр состоят из 2-х ... 5-ти пикселей, которые и анализируются. Сначала создаются готовые наборы таких силуэтов, от 3-х, до 6-ти на каждый символ. И этого хватает для однозначного поиска. Главное ручками (и головой) правильно создать эти силуэты. Я делаю для себя. А ты ставишь суперзадачу. Сделать алгоритм, работающий за тупого юзера. Будет время потестю, поделюсь результатами.

Конечно всё зависит от конкретной задачи, главное правильно определять где фон (его надо игнорировать) и где значимые пиксели (вот их и надо искать).
Вверх
DarkMaster
По поводу создания изображений и помощи валенкам у меня тоже есть идеи, но это после поисковиков. По крайней мере нужно довести до ума. Обязательно хочу прилепить буфер из findString'а моего. Буфер изображений, чтобы они не дергались с винта это реально хорошая весч. Прикрутить возможность задать папку, а не конкретное изображение, дать возможность оверрайдить параметры поиска (если ищет всю папку) исходя из имени файла. Все это оптимизировать и вылизывать. Работы вагон. Но чет меня прет) Сижу с удовольствием неспешно тесты гоняю, переписываю все.
Вверх
DarkMaster
Из забавного. Речь пойдет о чтении из памяти данных, которые уже существуют, их размер известен. Т.е. сознательно двигаются указатели, в т.ч. происходит выход за пределы массива (мы уверены, что за пределами массива все так же находятся данные). При тестах инициализация массивов, присвоение начальных адресов были вынесены за пределы бенчмарка. Т.е. непосредственно время обращения в if'ов.

local p = ffi.new("unsigned char[3]") - тормоз.
Гораздо эфективнее использовать конструкцию:
local p = ffi.new("unsigned char[1]")
двигая указатель на массив.

еще шустрее использовать:
ffi.cast("unsigned char*",address)
при этом если объявить:
local rmem = ffi.cast
rmem("unsigned char*",address)
то дополнительно выиграем в скорости.

rmem ("unsigned char*",i)[0],rmem ("unsigned char*",i+1)[0],rmem ("unsigned char*",i+2)[0]
проигрывает в скорости:
rmem ("unsigned char*",i)[0],rmem ("unsigned char*",i)[1],rmem ("unsigned char*",i)[2]
при этом вполне очевидно, что полей [1], [2] не существует, но все прекрасно работает - проверок на выходы за пределы массивов в ffi нет.
Вверх
sutra
Ну вот, зачем спрашивается лопатить фул хд. Разбил на 4 зоны, запустил 4 скрипта и собирай урожай.
Вверх
DarkMaster
ну вообще типа да, но типа нет. Поуму нужно делать потоки. Пока не берусь. Хотя бы потому, что не очень хорошо представляю сам для себя, как все это должно собираться. На данный момент есть четкое правило - все найденные результаты упорядочены слева-направо и сверху вниз, так же есть ограничение на количество найденных результатов. При разбиении на части может получиться путаница, если делать сортировку, то нужно дожидаться окончания обработки до некоторой позиции N в которой собрано необходимое количество изображений и т.д. Пока я для себя в голове не решил, как это будет выглядеть правильно и какое поведение будет наиболее востребовано и наиболее нативно ожидаемо для пользователя.
// Cirus подогнал getimage нормальный для работы через хендл.
Вверх
Invision Power Board © 2001-2024 Invision Power Services, Inc.
Version for Pocket PC © 2006-2024, IPBest Studio.