Здравствуйте, гость ( Вход | Регистрация )

35 страниц V « < 19 20 21 22 23 > »   
Ответить в эту темуОткрыть новую тему
> Помогите освоить LUA
sutra
сообщение 11.1.2019, 7:42
Сообщение #401


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Цитата
Что касается windowfrompoint, она возвращает строку с хендлами вместо массива.

Спасибо, да, я понял. Просто как обычно, не зная толком синтаксиса, да ещё и ни хрена не понимая, обязательно наступаю на грабли. Просто ТО, на чём проверял (потом уже на разных окнах пробовал) работает только с параметром "child", на остальных возвращало пустую строку, вот я и затупил. Конечно на мой взгляд надо делать универсально, чтобы обе функции работали одинаково. По логике алгоритм то вроде не должен сильно отличаться. А то, что нет массива, так и в windowfromcursor тоже нет. Но там числом возвращает.

Цитата
она возвращает строку с хендлами вместо массива

А у меня вроде только хендл первого окна возвращает, также как и windowfromcursor.


Ну меня устраивает такой расклад. Мышку трогать не хочется, может испортить работу других скриптов. А так смотрю хендл, если отличается от того, который мне нужен, то минимизирую размер этого окна. И так пока не появится нужное мне окно. Вот таким вот долгим путём получилось решить проблему с выводом на передний план нужного мне окна. Хотя конечно интересно, почему в первый заход окно активируется, а потом нет. Кстати, не засекал, но с какого-то N-го цикла окно всё-таки активируется. В общем - загадка.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 16.1.2019, 16:21
Сообщение #402


***********

Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 27708
Пользователь №: 11.279



http://luajit.org/dynasm_examples.html


--------------------
Скрипты UOPilot под заказ.
Консультации по UOpilot 15$/час.
Услуги Lua разработчика (не пилот, проекты, постоянка)
Disсоrd:
Kov____
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 16.1.2019, 17:35
Сообщение #403


***********

Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 27708
Пользователь №: 11.279



Еще пара интересных ссылок по производительности.
http://wiki.luajit.org/NYI
http://wiki.luajit.org/Numerical-Computing-Performance-Guide


--------------------
Скрипты UOPilot под заказ.
Консультации по UOpilot 15$/час.
Услуги Lua разработчика (не пилот, проекты, постоянка)
Disсоrd:
Kov____
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 17.1.2019, 14:32
Сообщение #404


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Цитата
Еще пара интересных ссылок по производительности

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

Что-то ещё ускорять в функциях смысла нет. 90-99% скорости потр<вырезано анти-матом>ет getimage. А как ускорить его я естественно не знаю, но наверное сам по себе доступ к экрану требует времени вне зависимости как это выполняется.

Какой убогий анти-мат, даже не знаю каким словом заменить, - "требует времени".
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 17.1.2019, 14:37
Сообщение #405


***********

Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 27708
Пользователь №: 11.279



Цитата
getimage

А какой метод используется? В приложении фпс ограничен? Если забирать по хендлу, то ограничение вроде только в фпс.

Верю, что летает. Но там можно сделать вставки на асме)


--------------------
Скрипты UOPilot под заказ.
Консультации по UOpilot 15$/час.
Услуги Lua разработчика (не пилот, проекты, постоянка)
Disсоrd:
Kov____
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 17.1.2019, 14:54
Сообщение #406


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



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

Так я и говорю ... можно конечно на АСМе нарисовать, но у меня всё упирается в getimage. Поиск намного быстрее 1 тысячной, так что вроде смысла нет.

Ну вот помнишь Cirus давал картинку с монетками? Там реально их можно искать даже всего по 4-м пикселям, 3 белых с разбросом координат (светлый фон) и 1-ин жёлтый (в центре монетки). Такая комбинация однозначно принадлежит только монеткам и всё найдётся очень быстро.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 17.1.2019, 15:22
Сообщение #407


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Опять же твой статус - ты мастер, ты теорию лопатишь, чтобы работало на все случаи жизни. Мне до твоих знаний, как до Парижа. Я - практик, привык лопатой и ломом, но так, чтобы и экскаватор не мог угнаться. Так сказать надо-то всего ткнуть пару раз лопатой и пока экскаватор заведётся, пока прицелится, я уже и лопатой управлюсь.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 17.1.2019, 15:57
Сообщение #408


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Ну вот простейший утрированный пример как не надо делать. Предположим, что на экране есть 100 красных, 100 зелёных и 100 синих квадратов размером 10х10. В 2-х красных, 2-х зелёных и 2-х синих квадратах внутри находится белый квадрат размером 2х2, который определяет их особый статус. И белого цвета на экране больше не встречается нигде. Надо найти красный квадрат с белым внутри. Если искать по порядку, как и делается в стандартной функции, придётся напрасно лопатить уйму красных пикселей, пока дойдёт очередь до белых. А вот если правильно задать массив искомых пикселей и на первые позиции искомого массива поставить белые пиксели, то поиск выполнится в разы быстрее и никакая математика не угонится за обычной логикой. Вот такие у меня подходы к решению возникающих задач.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 18.1.2019, 15:24
Сообщение #409


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Цитата
Если забирать по хендлу, то ограничение вроде только в фпс

Каюсь, был не прав. Уж не помню почему я так решил, что типа тормозит вызов функции. Вот такие у меня получились результаты.
Код
local p={}
ok[1][1] -- ОКНО которое пытыют!!!
tmc=os.clock()
for i=1,1000 do  p[i]=getimage(0,0,9,9,ok[1][1])  end
tmc=os.clock()-tmc  log("Время загрузки: ",tmc)   -- 1.796  1.909  1.707
-- среднее время выполнения: 0,0018
tmc=os.clock()
for i=1,1000 do  deleteimage(p[i])  end
tmc=os.clock()-tmc  log("Время удаления: ",tmc)   -- 0.193  0.196  0.195

tmc=os.clock()
for i=1,100 do  p[i]=getimage(0,0,899,899,ok[1][1])  end
tmc=os.clock()-tmc  log("Время загрузки: ",tmc)   -- 1,511  1,585  1,37
-- среднее время выполнения: 0,0149
tmc=os.clock()
for i=1,100 do  deleteimage(p[i])  end
tmc=os.clock()-tmc  log("Время удаления: ",tmc)   -- 0,036  0,038  0,037
-- при тесте на 1000 ошибка нехватки памяти

Так что лучше вызывать чаще, но при меньшей зоне захвата. Придётся кое-что переделать. И ассемблер конечно же даст прирост (при правильном подходе). Вот только я его наглухо забыл, да и знал то тоже
на церковно-приходском уровне.

И ещё раз про погрешность. Ну лично я сколько репу не чесал, так и не мог придумать когда есть толк при применении абсолютной погрешности, ничего, кроме ухудшения поиска не происходит. Однозначно надо задавать относительную погрешность. Единственный минус - падает скорость, поэтому там где не нужен точный поиск, а нужна скорость, то нужна абсолютная погрешность, я бы назвал этот параметр не погрешность, а отклонение (дельта). Я использую оба эти параметра по мере необходимости.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 18.1.2019, 15:38
Сообщение #410


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Те же монетки, если искать с относительной погрешностью, для однозначного результата поиска достаточно нескольких пикселей, а вот если использовать абсолютную, то надо уже внимательно всё проверять, могут быть ложные срабатывания.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
cirus
сообщение 18.1.2019, 15:43
Сообщение #411


**********

Elder
Сообщений: 3.480
Регистрация: 18.8.2014
Группа: Пользователи
Наличность: 26540
Пользователь №: 16.971
Возраст: 29



Цитата
for i=1,1000 do p[i]=getimage(0,0,9,9,ok[1][1]) end
for i=1,100 do p[i]=getimage(0,0,899,899,ok[1][1]) end

10 * 10 * 1000 это не тоже самое что 900 * 900 * 100.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 18.1.2019, 16:15
Сообщение #412


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Поскольку я делаю для себя, то иногда просто делаю частные случаи поиска, чтобы не городить огород и не замедлять скрипт. Ну вот надо мне например искать картинку затенённую на 20%, добавил функцию, в которой изменил всего лишь одну строку, меня это не сильно напрягает.
Код
raz=rmem("unsigned char*",pg)[x]-rmem("unsigned char*",pl)[x]+rmem("unsigned char*",pl)[x]/5

И всех делов.

Цитата
10 * 10 * 1000 это не тоже самое что 900 * 900 * 100.

Я это понимаю, комментарии соответствующие были. Скорость считалась деля результат на 1000 и 100 соответственно.


И выводы были даны соответствующие - на скорость СИЛЬНО влияет зона захвата. Гораздо СИЛЬНЕЕ, чем собственно вызов функции.

Я к чему это всё озвучил ... Раньше в Пилоте, у меня были тормоза при вызове финдов. Собственно почему тогда я и попросил Кнайта сделать поиск в памяти и findcolor-ом. В lua, как я только что выяснил всё не так. Раньше я делал один захват и проводил в нём поиск например 3-х объектов и так было быстрее. Сейчас, как я понимаю, так делать не надо. Лучше делать захват для каждого объекта отдельно, так будет быстрее. Просто поделился СВОИМ опытом, ни на что не претендуя.

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

Хотя всё равно у меня всё делается быстро. Было мгновенно, будет молниеносно.

Универсальный поиск у меня красиво сделать не получилось. Я разделил это на 2 этапа. 1) Подготовка таблицы координат и RGB искомых пикселей. 2) Собственно поиск в памяти. Да, это некрасиво, но эффективно.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 18.1.2019, 17:04
Сообщение #413


***********

Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 27708
Пользователь №: 11.279



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

Есть сомнения. Мне кажется, как раз наоборот будет.
Цитата
И выводы были даны соответствующие - на скорость СИЛЬНО влияет зона захвата. Гораздо СИЛЬНЕЕ, чем собственно вызов функции.

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

Цитата
Я разделил это на 2 этапа. 1) Подготовка таблицы координат и RGB искомых пикселей. 2) Собственно поиск в памяти. Да, это некрасиво, но эффективно.

Путешествие по таблице и захваченному изображению не в линейном чтении может существенно снижать скорость. Нужно присмотреться. В частности, если я не ошибаюсь, сейчас камни считывают минимум 10 байт памяти, соответственно, если нормально работает прогнозирование ветвлений, то 7 байт авансом остаются в кэше проца.


--------------------
Скрипты UOPilot под заказ.
Консультации по UOpilot 15$/час.
Услуги Lua разработчика (не пилот, проекты, постоянка)
Disсоrd:
Kov____
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 18.1.2019, 17:06
Сообщение #414


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Конечно я реально затупил, как я сразу не понял про getimage. Ведь был у меня тест, а я даже не вник в результаты.
Код
tmc=os.clock()
for i=1,100 do         -- ищем чёрный пиксель
    tmp = findcolor("100 30 100 30 1 1 (0),ok[1][1]")
end
tmc=os.clock()-tmc  log("Время поиска: ",tmc) -- 5,345 сек.

tmc=os.clock()
for i=1,100 do
    b=f.FindPix(1,1,"R(0)G(0)B(0)",ok[1][1])
end
tmc=os.clock()-tmc  log("Время поиска: ",tmc) -- 0,132 сек.


FindPix - сам нарисовал.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 18.1.2019, 17:41
Сообщение #415


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Цитата
Я подозреваю это происходит из-за копирования участка памяти внутри пилота
Я не знаю тонкостей, просто тупо пробую всяко. Подготовка таблицы ничего не занимает. Составить для монеток таблицу для 4-х пикселей - мгновенно. А вот искаться будут только они. Причём первым пикселем в таблице является "белый" (фон капельки), при относительной погрешности (потому что он сильно плавает на полупрозрачном фоне) на первом же сравнении всё становится понятным. Там нет иных таких. Быстрее сам господь вряд ли найдёт.


А вот если задавать абсолютную погрешность ... там на каждой крыше свой фон, плавает СИЛЬНО. Словить ложное срабатывание - легко. Получается найти если исследовать досконально влияние погрешности. А если учесть, что дан всего лишь маленький фрагмент игрового экрана ... не факт, что там нет подводных камней.

Смысл таблицы в чём?? В том, что внутри функции поиска я ничего не меняю, там нет никакой лишней математики. Сравнение идёт уже с "подготовленными" параметрами (RED1 - RED2 и т.д.)

Разница в том, что при обычном поиске индекс в памяти модифицируется только при переходе на новую строку (но за то выполняется инкремент на смещение в памяти). А при использовании таблицы, для каждого сравниваемого пикселя считается индекс в памяти (по координатам пикселя), но нет операции инкремента смещения. Так что потери по скорости мизерные, а результат работы логики ... даже не о чем говорить.

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

Я делаю так. Сначала отдельным скриптом сканирую экран, выясняю чего там есть, а чего нет (граничные значения RGB), а потом на основании этих данных леплю таблицу.

Я различаю 2 аспекта: найти быстро и найти хитрую картинку. Если быстро и картинка простая - то использую примитивнейшую функцию (там всё понятно). Если "хитро" - однозначно относительная погрешность. Если "хитро" и недолго - использовать таблицу искомых пикселей. Иных вариантов не знаю.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 18.1.2019, 17:54
Сообщение #416


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Конечно если подключить потоки и искать одновременно в разных частях экрана, если впихнуть ассемблер, добавить логики, то можно наверное сделать универсально и быстро. Но это явно не мой уровень, ты Дарк, конечно это сделаешь. Я в лучшем случае гожусь на роль тестера, да и то как выяснилось и тестер то из меня хреновый.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 18.1.2019, 18:25
Сообщение #417


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Ещё раз про таблицу. Её можно создать и автоматически, только надо задавать не фон, а цвет (а частенько и цвета). Для прицела хватит и одного цвета. Разница с ныне действующим алгоритмом Кнайта такова. Сейчас фоном считается один цвет. У меня не так, ВСЁ что не нужно считается фоном и ВООБЩЕ не анализируется, то есть даже не определяется что это фон.

Иначе говоря имеем опять 2 аспекта: или стабильный фон или стабильный цвет. Ну и возможен конечно случай когда всё не стабильно. Для такого случая, ну никак вы не сделаете универсально. Тут однозначно нужен индивидуальный подход через создание таблицы искомых пикселей - это может быть достаточно сложная задача, но по-другому никак.

А при поиске текста, тут вообще использование таблицы - самое простое решение (или как угодно обзовите, опорные точки, реперные ...), поскольку всё ещё вдобавок ОЧЕНЬ СИЛЬНО может плавать, но эти самые точки у каждого символа ЕСТЬ. Есть или однозначный фон или однозначный "не фон". Ковыряться только с этим надо, если плюнуть на скорость (что в большинстве случаев и нужно делать), то тогда использовать параметр аккуратности, только на мой взгляд с "построковым" анализом.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 18.1.2019, 19:29
Сообщение #418


***********

Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 27708
Пользователь №: 11.279



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

Асм я вообще не знаю (операторы, стили).
А вот потоки скорее всего в скором будущем понадобятся, причем там же и cuda. С потоками на самом деле все достаточно просто.


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

Сообщение отредактировал DarkMaster - 18.1.2019, 19:30


--------------------
Скрипты UOPilot под заказ.
Консультации по UOpilot 15$/час.
Услуги Lua разработчика (не пилот, проекты, постоянка)
Disсоrd:
Kov____
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 18.1.2019, 23:05
Сообщение #419


*******

Adept
Сообщений: 923
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 19.007



Цитата
Но если сотворим, то будет реально пуля

В любом случае, в 10-ый раз скажу тебе Дарк спасибо. Пусть у меня всё криво, пусть некрасиво. Но ты дал инструмент, а уж применить его - дело техники. Абсолютно уверен в одном, пусть даже нестандартно, но за то я теперь могу решить практически любую задачу. На данный момент не вижу ничего, чего нельзя бы было реализовать. И Кнайту тоже ещё раз спасибо, он дал глобальный инструмент, всё остальное в наших руках. Он не обязан за всех думать, тем более что инструмент условно бесплатный. Будет время - усовершенствует. Всем успехов и здоровья!


У остальных участников форума, прошу прощения, что тема про lua как-то изначально превратилась в тему про финды, но думаю что не только мне это было интересно.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 19.1.2019, 0:21
Сообщение #420


***********

Модератор UOPilot
Сообщений: 9.460
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 27708
Пользователь №: 11.279



Цитата
В любом случае

Допиливать надо в любом случае =)

Цитата
тема про lua

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


--------------------
Скрипты UOPilot под заказ.
Консультации по UOpilot 15$/час.
Услуги Lua разработчика (не пилот, проекты, постоянка)
Disсоrd:
Kov____
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения

35 страниц V « < 19 20 21 22 23 > » 
Ответить в эту темуОткрыть новую тему
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 

- Текстовая версия | Версия для КПК Сейчас: 29.3.2024, 1:29
Designed by Nickostyle