Флудилка:)

[RUSL]

Зате гарно як зробили)

Всередині зробили гарно .

а зовні пофарбували у якесь торобало .

[Dmytro]

А тим часом на X box Serious S можна грати Starfield  хоч і в 30 fps.

Он неинтересный.

[aNGeL]

а зовні пофарбували у якесь торобало .

Щоб злодіїв не приманювати)

[aNGeL]

Он неинтересный.

Він цікавий.

[Edd.Dragon]

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

Потоки по ядрам гуляют.
Нет таких ААА игр, чтобы имели скажем 8 потоков и ни один из них не работал по максимуму, т.е. даже важный(ые) уходили в спячку половину времени. В игровом мире всегда есть что пересчитать и хотелось бы пересчитывать в 10 раз чаще.

[Vlad]

Потоки по ядрам гуляют.
Нет таких ААА игр, чтобы имели скажем 8 потоков и ни один из них не работал по максимуму, т.е. даже важный(ые) уходили в спячку половину времени. В игровом мире всегда есть что пересчитать и хотелось бы пересчитывать в 10 раз чаще.

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

[Dmytro]

Він цікавий.

Ну там же ИИ никакой. Плюс локации где кроме мобов ничего нет.

[Edd.Dragon]

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

нет

управление процессором гоняет тяжелые потоки по ядрам. это нормально. но ты из-за этого НЕ видишь картинки "одно ядро постоянно перегружено, а несколько - вообще спят"

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

[Vlad1]

[Dmytro]

Ага, круто. Причем там даже 2Д-стили на 1 лвл. прогрессии неплохие. Уже начал проходить.

Итого у меня БП в трех играх...

[aNGeL]

[graved1gger]

це спінофф бойс?

[Edd.Dragon]

управление процессором гоняет тяжелые потоки по ядрам. это нормально. но ты из-за этого НЕ видишь картинки "одно ядро постоянно перегружено, а несколько - вообще спят"

Если попытаться простыми словами объяснить - два подхода: студенческий и промышленный.

1) Студенческий:
Пишем программу в чем угодно. Потоками вообще не интересуемся, не лезем в эти дебри. В итоге у тебя от начала до конца работы программы существует единственный поток.

Твой поток. Потому как среда разработки может все-таки быть немножко умнее и по-умолчанию создавать два потока: для ГУЯ и очереди сообщений (т.е. - себе) и для твоего кода (т.е. для твоих бесконечных циклов), но это усложняет взаимодействие с ГУЕМ, т.к. программист все же должен отдавать себе отчет, что ГУЙ в другом потоке.

Ну не суть. Пусть будет как в старом Дельфи - один единственный поток. В котором и обработка очереди сообщений, и обработка ГУЯ, и твоя писанина. И вот ты шлепаешь кнопку на форму и пишешь обработчик на ее нажатие - бесконечный цикл, в котором счетчик (переменная в памяти) приращивается на единичку. Т.е. "выполнять N = N + 1 бесконечно!". Никаких пауз. Тупо максимальная нагрузка на процессор (ядро). Ну как максимальная... Максимальная с логической точки зрения. Т.е. он будет нагружен 100% времени выполнением одной и той же команды. Ничего другого он делать не в состоянии. Ни капли времени не простаивал. Но по факту почти весь сложнейший кристал ядра ничего не делает. Для такой простейшей команды не нужно много кеша, не нужен длинный конвеер. Не нужны блоки векторных операций и т.д. Т.е. ядро греется умеренно. И что немаловажно, твой поток как при старте программы создался, так до ее конца он и работает. Всё - в этом потоке. Т.е. у тебя цикл фигачит 100% нагрузки, окно зависло нахрен, потому что к обработке очереди сообщений мы из цикла не выходим. Снять задачу разве что для прекращения.

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

Если же мы сделаем умнее и не будем рассчеты проводить в основном потоке, а создадим отдельный поток. Но тоже такой, что никогда не делает паузы, а молотит без остановки. Тогда конечно же картина не изменится - будет нагружено одно ядро. Создадим два таких потока - будет нагружено два ядра. При этом основной поток у нас ничерта не делает, кроме перерисовки формы с кнопкой. В ожидании твоих действий. Зато не висит. Можешь спокойно закрыть приложение (при этом надо форсировать убиение потоков, т.к. они не отвечают (мы не предусмотрели в них паузы на обработку очереди сообщений). А то так при закрытии приложение будет ждать прекращения потоков, а они в свою очередь даже не думают узнавать о том, что им пора закругляться... Такой вариант логики приложения не годится никуда.

2) Поэтому к управлению потоков надо подходить иначе. Чаще всего используют принцип "задач". Т.е. если мы желам накручивать счетчик бесконечно и максимально много (ну типа проверяем сколько ядро арифметических операций способно выполнить), то стоит это делать порциями. Скажем создавать поток, который нарастит счетчик миллион раз и закончит на том. Следом запустим точно такую же задачу. И т.д. Т.е. у нас хотя бы раз в миллион итераций будет пауза и возможность поуправлять потоками. Если такая задача выполняется долговато (например, целую секунду), то и в процессе ее выполнения поток помимо вычислений должен прерываться на обработку очереди сообщений, чтобы оперативнее реагировать на команды от основного пока (типа, прекратить и выйти).

Точно так же и в игре. Можно, например, создавать поток с задачей "пересчитать мир" (т.е. выполнить одну итерацию по изменениям в мире, зависящим от твоих действий и от действий мобов). Такая задача в идеале должна выполняться не дольше 0.01 сек, чтобы обеспечивать рефреш мира и картинки 100 раз в секунду. В идеале! А на деле, чем говнянее движок  выполнения скриптов для мобов и жизни мира, чем говнянее сами скрипты (которые стажеры понаписали), чем сложнее логика и масштабнее мир (в градостроительном симуляторе следует пересчитать тысячи домов, огромный транспортный граф, обработать светофоры, машинки, людишек-пешеходов, экономику и т.д.), тем печальнее рефреш.

В итоге, что мы имеем:
- основной поток (А) курит бамбук, раздавая задачи; например, запускает поток пересчета мира.
- поток пересчета мира (Б) нагружает одно ядро на 100% и выполняется, допустим 0.05 сек. При этом он выполняет не одну и ту же примитивную операцию, а довольно разнообразный код и обрабатывает приличный массив данных, описывающих состояние всех объектов в мире. Т.е. в течении 0.05 секунды у тебя одно ядро точно нагружено на 100%. А в менеджере график обновляется раз в секунду или даже в две.
- основной поток получает результат от потока Б и во-первых, запускает пересчет мира заново (следующая итерация), а во-вторых, запускает потокИ для подготовки кадра по данным предыдущей итерации (какой-то поток что-то графическое подгружает, конвертирует, выгружает, другие потоки физику обсчитывают, и т.д.)
- что происходит? Критический поток Б, который новый, вовсе не обязан лечь на то же ядро, на котором был предыдущий поток Б. Т.е. следующие 0.05 секунд на 100% у тебя может быть загружено другое ядро. И так 20 раз в секунду критический поток может запускаться поочеродно на разных ядрах (где холоднее, туда и попадет). А остальные потоки вовсе не обязательно выполняются так же долго, как поток Б. Всеони конечно же тоже нагрузят ядра на 100%, но допустим отработают минимум в 5 раз быстрее. А то и в 10 раз! И дальше все ядра курят бамбук, пока управляющему потоку не поступит свежая порция данных для вывода. И это все повторяется десятки раз в секунду! А график обновляется один раз в секнду...

И в итоге:
- пересчет мира у нас работает по максимуму, с микропиздической паузой на перезапуск. Но этот пересчет мира не привязан к какому-то ядру, поэтому прыгает. Ну и 100% ядра - это 12.5% процессора (если 8 ядер). А остальное барахло обрабатывается быстрее пересчета мира и добавляет к общей нагрузке еще 30-40%. В каждый момент времени минимум одно ядро занято на 100%. В среднем на 100% занята половина ядер. Часто все ядра заняты на 100%. Так же часто - как и не заняты ничем...

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

Проблема не в том, что программисты не смогли нагрузить проц. Проблема в том, что пересчет мира (или может какая-то другая критическая задача) выполняется всего 20 раз в секунду, а все иные действия зависят от ее результатов и ждут ее завершения. Как можно улучшить?
а) Проанализировать, что тянет это время. Попробовать оптимизировать код в тех местах, которые занимают большую часть из этого времени.
б) Попробовать хотя бы частично распаралелить процесс. Т.е. в алгоритме пересчета найти возможность разделить его на несколько независимых друг от друга частей.
Разумеется, оба варианта трудозатратны. Обычно, чрезмерно трудозатратны. Т.к. речь об обработке логики, запутанной и зависимой друг от дружки. И если времени не осталось, приходится как-то выкручиваться. А там, где это дегко делается - уже давно сделано на уровне покупных движков (та же физика или работа с текстурами). Т.е. выненесено от конечных программистов под капот и вылизано разрабами движков.


Ну и разумеется, как ты предположил - возможны проблемы транспорта данных. Например, кеша процессора не хватает и один и тот же код, то выгружается, то загружается. А проц при этом "загружен" на 100% выполнением операции, большую часть времени ожидая для нее данных. Либо же через зад в памяти работа с данными и т.д. Между оперативкой и видеопамятью (но тогда бы полной загрузки видеокарты не было бы) и т.д.

[aNGeL]

це спінофф бойс?

так

[graved1gger]

9700к маслає всіма ядрами на максимум
відяха 1070ті ледь нагружена
фпс ледь 30
всім пох. проблем з перформансом нема

запускаєш те саме на 5600х та 6800хт - фпс дійсно трошки більше, 5600х не так сильно навантажений, а 6800хт взагалі думає що їй 2д показують)

[Edd.Dragon]

відяха 1070ті ледь нагружена

Как я раньше любил говорить: сглаживание вруби! 

[Edd.Dragon]

Можно даже в командном процессоре єксперимен провести. Батничек, в котором в бесконечном цикле очищается экран и выводится дерево папок небольшое (я вывожу дерево папок с изошки с виндой). Поскольку "команда" вывода дерева tree - это по сути запуск отдельного экзешника в отдельном от cmd.exe потоке. Выполняется она быстро и много раз в секунду. Управление потоками раскидывает ее то на 3-ий, то на 4-ый логический процессор. В итоге нагрузка в 25% распределена по двум ядрам. Но по факту задача одна в каждый момент времени. Выполняется на одном ядре в каждый момент времени. Ничего не ожидает (ну почти, паузы на перезапуск, отрисовку не дают уверенно 25% нагрузки показать).

[graved1gger]

Как я раньше любил говорить: сглаживание вруби! 

не допомагає
тупо нема різниці налаштування, розрішення, і оце все - адін пенис)
6800хт взагалі скидає частоти ледь не в нуль)

[Vlad]

Если попытаться простыми словами объяснить - два подхода: студенческий и промышленный.

Спасибо. Доходчиво и интересно.
В это объяснение хорошо укладываются и фризы, появляющиеся при 60-80 FPS на счётчике.

[Edd.Dragon]

Зрада!

Ілон Маск таємно наказав своїм інженерам відключити мережу супутникового зв'язку Starlink поблизу узбережжя Криму минулого року, щоб зірвати прихований напад України на російський військово-морський флот, згідно з уривком з біографії Маска від Уолтера Айзексона. Як пише Айзексон, коли українські морські дрони, начинені вибухівкою, наблизилися до російського флоту, вони "втратили зв'язок і нешкідливо викинулися на берег", буквально подарувавши росіянам цю технологію. Як повідомляється в книзі, зі змістом якої ознайомилися в CNN, "Маск злякався, що росіяни почнуть ядерну війну". А саму атаку на чорноморський флот рф він нібито називав "міні-Перл-Харбор". Реліз біографії відбудеться 12 вересня.

[aNGeL]

Зрада!

Ілон Маск таємно наказав своїм інженерам відключити мережу супутникового зв'язку Starlink поблизу узбережжя Криму минулого року, щоб зірвати прихований напад України на російський військово-морський флот, згідно з уривком з біографії Маска від Уолтера Айзексона. Як пише Айзексон, коли українські морські дрони, начинені вибухівкою, наблизилися до російського флоту, вони "втратили зв'язок і нешкідливо викинулися на берег", буквально подарувавши росіянам цю технологію. Як повідомляється в книзі, зі змістом якої ознайомилися в CNN, "Маск злякався, що росіяни почнуть ядерну війну". А саму атаку на чорноморський флот рф він нібито називав "міні-Перл-Харбор". Реліз біографії відбудеться 12 вересня.

Розстріляти!

[aNGeL]

[Xella]

Если попытаться простыми словами объяснить - два подхода: студенческий и промышленный.

1) Студенческий:
Пишем программу в чем угодно. Потоками вообще не интересуемся, не лезем в эти дебри. В итоге у тебя от начала до конца работы программы существует единственный поток.

Твой поток. Потому как среда разработки может все-таки быть немножко умнее и по-умолчанию создавать два потока: для ГУЯ и очереди сообщений (т.е. - себе) и для твоего кода (т.е. для твоих бесконечных циклов), но это усложняет взаимодействие с ГУЕМ, т.к. программист все же должен отдавать себе отчет, что ГУЙ в другом потоке.

Ну не суть. Пусть будет как в старом Дельфи - один единственный поток. В котором и обработка очереди сообщений, и обработка ГУЯ, и твоя писанина. И вот ты шлепаешь кнопку на форму и пишешь обработчик на ее нажатие - бесконечный цикл, в котором счетчик (переменная в памяти) приращивается на единичку. Т.е. "выполнять N = N + 1 бесконечно!". Никаких пауз. Тупо максимальная нагрузка на процессор (ядро). Ну как максимальная... Максимальная с логической точки зрения. Т.е. он будет нагружен 100% времени выполнением одной и той же команды. Ничего другого он делать не в состоянии. Ни капли времени не простаивал. Но по факту почти весь сложнейший кристал ядра ничего не делает. Для такой простейшей команды не нужно много кеша, не нужен длинный конвеер. Не нужны блоки векторных операций и т.д. Т.е. ядро греется умеренно. И что немаловажно, твой поток как при старте программы создался, так до ее конца он и работает. Всё - в этом потоке. Т.е. у тебя цикл фигачит 100% нагрузки, окно зависло нахрен, потому что к обработке очереди сообщений мы из цикла не выходим. Снять задачу разве что для прекращения.

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

Если же мы сделаем умнее и не будем рассчеты проводить в основном потоке, а создадим отдельный поток. Но тоже такой, что никогда не делает паузы, а молотит без остановки. Тогда конечно же картина не изменится - будет нагружено одно ядро. Создадим два таких потока - будет нагружено два ядра. При этом основной поток у нас ничерта не делает, кроме перерисовки формы с кнопкой. В ожидании твоих действий. Зато не висит. Можешь спокойно закрыть приложение (при этом надо форсировать убиение потоков, т.к. они не отвечают (мы не предусмотрели в них паузы на обработку очереди сообщений). А то так при закрытии приложение будет ждать прекращения потоков, а они в свою очередь даже не думают узнавать о том, что им пора закругляться... Такой вариант логики приложения не годится никуда.

2) Поэтому к управлению потоков надо подходить иначе. Чаще всего используют принцип "задач". Т.е. если мы желам накручивать счетчик бесконечно и максимально много (ну типа проверяем сколько ядро арифметических операций способно выполнить), то стоит это делать порциями. Скажем создавать поток, который нарастит счетчик миллион раз и закончит на том. Следом запустим точно такую же задачу. И т.д. Т.е. у нас хотя бы раз в миллион итераций будет пауза и возможность поуправлять потоками. Если такая задача выполняется долговато (например, целую секунду), то и в процессе ее выполнения поток помимо вычислений должен прерываться на обработку очереди сообщений, чтобы оперативнее реагировать на команды от основного пока (типа, прекратить и выйти).

Точно так же и в игре. Можно, например, создавать поток с задачей "пересчитать мир" (т.е. выполнить одну итерацию по изменениям в мире, зависящим от твоих действий и от действий мобов). Такая задача в идеале должна выполняться не дольше 0.01 сек, чтобы обеспечивать рефреш мира и картинки 100 раз в секунду. В идеале! А на деле, чем говнянее движок  выполнения скриптов для мобов и жизни мира, чем говнянее сами скрипты (которые стажеры понаписали), чем сложнее логика и масштабнее мир (в градостроительном симуляторе следует пересчитать тысячи домов, огромный транспортный граф, обработать светофоры, машинки, людишек-пешеходов, экономику и т.д.), тем печальнее рефреш.

В итоге, что мы имеем:
- основной поток (А) курит бамбук, раздавая задачи; например, запускает поток пересчета мира.
- поток пересчета мира (Б) нагружает одно ядро на 100% и выполняется, допустим 0.05 сек. При этом он выполняет не одну и ту же примитивную операцию, а довольно разнообразный код и обрабатывает приличный массив данных, описывающих состояние всех объектов в мире. Т.е. в течении 0.05 секунды у тебя одно ядро точно нагружено на 100%. А в менеджере график обновляется раз в секунду или даже в две.
- основной поток получает результат от потока Б и во-первых, запускает пересчет мира заново (следующая итерация), а во-вторых, запускает потокИ для подготовки кадра по данным предыдущей итерации (какой-то поток что-то графическое подгружает, конвертирует, выгружает, другие потоки физику обсчитывают, и т.д.)
- что происходит? Критический поток Б, который новый, вовсе не обязан лечь на то же ядро, на котором был предыдущий поток Б. Т.е. следующие 0.05 секунд на 100% у тебя может быть загружено другое ядро. И так 20 раз в секунду критический поток может запускаться поочеродно на разных ядрах (где холоднее, туда и попадет). А остальные потоки вовсе не обязательно выполняются так же долго, как поток Б. Всеони конечно же тоже нагрузят ядра на 100%, но допустим отработают минимум в 5 раз быстрее. А то и в 10 раз! И дальше все ядра курят бамбук, пока управляющему потоку не поступит свежая порция данных для вывода. И это все повторяется десятки раз в секунду! А график обновляется один раз в секнду...

И в итоге:
- пересчет мира у нас работает по максимуму, с микропиздической паузой на перезапуск. Но этот пересчет мира не привязан к какому-то ядру, поэтому прыгает. Ну и 100% ядра - это 12.5% процессора (если 8 ядер). А остальное барахло обрабатывается быстрее пересчета мира и добавляет к общей нагрузке еще 30-40%. В каждый момент времени минимум одно ядро занято на 100%. В среднем на 100% занята половина ядер. Часто все ядра заняты на 100%. Так же часто - как и не заняты ничем...

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

Проблема не в том, что программисты не смогли нагрузить проц. Проблема в том, что пересчет мира (или может какая-то другая критическая задача) выполняется всего 20 раз в секунду, а все иные действия зависят от ее результатов и ждут ее завершения. Как можно улучшить?
а) Проанализировать, что тянет это время. Попробовать оптимизировать код в тех местах, которые занимают большую часть из этого времени.
б) Попробовать хотя бы частично распаралелить процесс. Т.е. в алгоритме пересчета найти возможность разделить его на несколько независимых друг от друга частей.
Разумеется, оба варианта трудозатратны. Обычно, чрезмерно трудозатратны. Т.к. речь об обработке логики, запутанной и зависимой друг от дружки. И если времени не осталось, приходится как-то выкручиваться. А там, где это дегко делается - уже давно сделано на уровне покупных движков (та же физика или работа с текстурами). Т.е. выненесено от конечных программистов под капот и вылизано разрабами движков.


Ну и разумеется, как ты предположил - возможны проблемы транспорта данных. Например, кеша процессора не хватает и один и тот же код, то выгружается, то загружается. А проц при этом "загружен" на 100% выполнением операции, большую часть времени ожидая для нее данных. Либо же через зад в памяти работа с данными и т.д. Между оперативкой и видеопамятью (но тогда бы полной загрузки видеокарты не было бы) и т.д.

як у старі добрі часи простиня.
Але я спочатку запідозрив що це ШІ писав ))

[aNGeL]

МКС переходить на новий рівень зв'язку на швидкості 1 Гбіт/с
https://universemagazine.com/mks-perehodyt-na-novyj-riven-zvyazku-na-shvydkosti-1-gbit-s/

[Dmytro]

Как же я хочу работу без всего этого...

[Миха]

МКС переходить на новий рівень зв'язку на швидкості 1 Гбіт/с
https://universemagazine.com/mks-perehodyt-na-novyj-riven-zvyazku-na-shvydkosti-1-gbit-s/

Тепер на МКС буде інтернет краще ніж в більшій частині америки та європи.

[Edd.Dragon]

як у старі добрі часи простиня.
Але я спочатку запідозрив що це ШІ писав ))

ну я не далеко від нього відкотився 

[aNGeL]

Тепер на МКС буде інтернет краще ніж в більшій частині америки та європи.

Порнуха стала ближче до зірок!

[aNGeL]

 

[aNGeL]

[Dmytro]

[Dachnik]

One piece netflix кто смотрел, как вам? Хочу вот с девушкой косплей замутить оттуда, каких персонажей выбрать интересно. А то первый опыт был с магазине, вот https://aaaa.in.ua/odezhda-dlya-seksa/kostyumy-eroticheskie/ костюмы для ролевых игр , но хочется чего то нового!

[graved1gger]

всі?

[aNGeL]

всі?

це ж серіал он випустили по аніме

[graved1gger]

це ж серіал он випустили по аніме

ну да. вже всі подивились)

[aNGeL]

ну да. вже всі подивились)

А я скачав і не дивився

[Mantikor]

А я скачав і не дивився

Я подивився, нормальне.
Аніме сцу починати, там наклепали дуже дофіга серій.

[Dmytro]

ну да. вже всі подивились)

А я аниме посмотрел и на аватарку поставил! (с)

[Wolf256]

Тепер на МКС буде інтернет краще ніж в більшій частині америки та європи.

upload навіть показувати не буду, там вже зовсім соромно 

[aNGeL]

upload навіть показувати не буду, там вже зовсім соромно 

Сором'язливий ти наш!

[aNGeL]

Схоже що у японців на заводах нема моніторінгу серваків 

Усі заводи Toyota Motor у Японії припинили роботу на добу через нестачу вільного місця на сервері
https://mezha.media/2023/09/08/toyota-free-space/

[aNGeL]

[aNGeL]

[aNGeL]

[T1000]

Це косплей. Справжня актриса так не виглядає.  
 там де вундервумен

[Mantikor]

Це косплей. Справжня актриса так не виглядає.  
 там де вундервумен

Хочеш сказати що Ґаль Ґадот не хоче просто так свою жопу інтернету показати? Та бути не може!

[aNGeL]

Це косплей. Справжня актриса так не виглядає.  
 там де вундервумен

[T1000]

Думаю просто дівка схожа сфоткалась і все. Це як Кіану Рівз на ютубі, начебто схожий, але якийсь молодий!
 Є ще ідея що це взагалі АІ намалював...

[Edd.Dragon]

Думаю просто дівка схожа сфоткалась і все. Це як Кіану Рівз на ютубі, начебто схожий, але якийсь молодий!
 Є ще ідея що це взагалі АІ намалював...

я так розумію, що праця живих людей в фотошопі нині взагалі не вважається як варіант?! 

[T1000]

Це ти намалював?