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

В этой статье мы хотели поговорить о моделировании волн в открытом море и представить алгоритм, который позволил достичь достаточно интересные результаты при приемлемых 25-30Fps на среднем китайфоне.

Зачем?

В эпоху Arduino UNO и Atmega328 я вполне обходился без программатора, прошивая микроконтроллер сначала загрузчиком Arduino через другую Arduino (Arduino as ISP), а потом через обычный последовательный порт, и лишь после появления поддержки Arduino для модулей на основе Nordic Semiconductor nrf51822 и nrf52832 для меня впервые стало актуальным наличие swd-программатора, ибо никаким другим способом прошивку в голый китайский модуль не зальешь.

Стандартом де-факто в данной области являются программаторы Jlink немецкой компании Segger Microcontroller System, известные не только своими прекрасными ТТХ, но и заоблачной ценой (около $500-600). Надо отдать должное компании Segger, для некоммерческого использования выпускается EDU версия, полностью идентичная Jlink Base, но даже она стоит в России в районе 3000 руб. Любимый Aliexpress полон китайских клонов, однако и они относительно недешевы, не говоря уж о прочем.

Есть еще ST-LINK/V2 от ST Microelectronics, правда, под вопросом их совместимость с микроконтроллерами производства не самой STMicro.

В итоге, мой взгляд неминуемо пал на JTAG/SWD программатор Black Magic Probe (BMP), собравший на Kickstarter более $47,000 при заявленной цели в $10,000.

Данный текст будет являться новой главой для учебного пособия по защите информации кафедры радиотехники и систем управления МФТИ (ГУ). Полностью учебник доступен на github. На хабре я же планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

Когда у вас есть знания о том, что такое криптографически стойкая хеш-функция, понять, что такое blockchain («цепочка блоков») очень просто. Blockchain – это последовательный набор блоков (или же, в более общем случае, ориентированный граф), каждый следующий блок в котором включает в качестве хешируемой информации значение хеш-функции от предыдущего блока.

Технология blockchain используется для организации журналов транзакций, при этом под транзакцией может пониматься что угодно: финансовая транзакция (перевод между счетами), аудит событий аутентификации и авторизации, записи о выполненных ТО и ТУ автомобилей. При этом событие считается случившимся, если запись о нём включена в журнал.

В таких системах есть три группы действующих лиц:

• источники событий (транзакций)
• источники блоков (фиксаторы транзакций)
• получатели (читатели) блоков и зафиксированных транзакций.

В зависимости от реализации эти группы могут пересекаться. В системах типа BitCoin, например, все участники распределённой системы могут выполнять все три функции. Хотя за создание блоков (фиксацию транзакций) обычно отвечают выделенные вычислительные мощности, а управляющими их участников называют майнерами (см. раздел про децентрализованный blockchain далее).

Основное требование к таким журналам таково:

• Невозможность модификации журнала: после добавления транзакции в журнал должно быть невозможно её оттуда удалить или изменить.

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



И приготовим себе задачу — попасть в таблицу лидеров. Однако задача будет решаться еще интереснее, если поставим жесткое ограничение — ресурсы искусственный интеллект будет черпать не от нашего, несомненно, мощного компьютера, а от одноплатника на архитектуре ARM! Заодно получим не только опыт работы с портативными устройствами, но и возможность держать бота включенным 24/7 без какого-либо ущерба для основного компьютера!

Часть 2
Часть 3
Приступим!

Для проверки безопасности вводимых паролей через KeePass я решил написать простейший кейлоггер с дополнительным захватом данных из буфера обмена. Весь код занял несколько строчек на FreePascal.

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

Умоляю перестань мне сниться
Я люблю тебя моя невеста
Белый иней на твоих ресницах
Поцелуй на теле бессловесном

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

Вернее, нейронная сеть нужна лишь для первого этапа — расстановки слов в правильном порядке. С рифмовкой справляются правила, применяемые поверх предсказаний нейронной сети. Хотите узнать подробнее, как мы это реализовывали? Тогда добро пожаловать под кат.

В комментариях к моим постам об ограничении калорий (1, 2) пару раз прозвучала мысль, что было б неплохо, если бы я привел данные по исследованиям и многдневного полного голодания. Что ж, попытаюсь.

Скажу сразу, что в сети очень много восторженных отзывов о том, как кому-то помогло длительное голодание (1, 2, 3). Отрицательных же (или хотя бы нейтральных) в разы меньше. Думаю, тут дело не только в мега-полезности голодания, но и в reporting bias — те, кому от голодания стало хуже, не особо горят желанием делиться опытом: ведь мало того, что неприятно рассказывать о своих неудачах, так еще и есть риск оскорбить религиозные чувства адептов голодания, которые расскажут, что ты всё делал неправильно, и вообще врёшь.

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

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

От создания нового проекта в Юнити до публикации бета-версии в Стиме прошло 10 месяцев. 90% времени ушло на создание, оптимизацию и вылизывание физической модели, остальное — на геймплей.

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

Сделал всё из взаимодействующих частиц: землю, здания, танки игроков, врагов, снаряды и бонусы — всё. Взаимодействия между частицами реализовал на видеокарте, поскольку для параллельных вычислений она в 50-100 раз производительней процессора.

Получившаяся из частиц материя сначала выглядела странно, и напоминала то ли жидкость, то ли газ:



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

Хочу рассказать сообществу о проведённом мной эксперименте.

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

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

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

Или ещё замечательный пример — Kerbal Space Program. Там физика уже является непосредственым источником геймплея.

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

Я давно мечтал сделать именно такой, до предела физически реалистичный римейк Scorched Earth. Но все мои эксперименты с моделированием физических систем упирались в неумолимо медленные процессоры. Тысяча-две частиц были пределом для real-time симуляции.

Но недавнее моё «открытие» изменило ситуацию.

Введение

Почему псевдо-3d?

Зачем кому-то захочется создавать дороги в олдскульном стиле сегодня, когда каждый компьютер может на лету отрисовывать графику, состоящую из миллионов полигонов? Разве полигоны — не то же самое, только лучше? На самом деле нет. Полигоны действительно создают меньше искажений, но именно деформации в старых игровых движках дают такое сюрреалистическое, головокружительное чувство скорости, ощущаемое во многих дополигональных играх. Представьте, что область видимости управляется камерой. При движении по кривой в игре, использующей один из таких движков, похоже, что она заглядывает на кривую. Затем, когда дорога становится прямой, вид тоже выпрямляется. При движении в повороте с плохим обзором камера как будто заглядывает за выступ. И поскольку в таких играх не используется традиционный формат трасс с точными пространственными соотношениями, то можно без проблем создавать трассы, на которых игрок будет ездить с захватывающей дух скоростью. При этом не нужно беспокоиться о том, что объекты появляются на трассе быстрее, чем может среагировать игрок, потому что физическую реальность игры можно легко изменять в соответствии со стилем геймплея.

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

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

Приветствую тебя, %username%!



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

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

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

Здравствуйте, меня зовут Саша, я написал самый быстрый ресайз изображений для современных х86 процессоров. Я так утверждаю, поскольку все остальные библиотеки, которые я сумел найти и протестировать, оказались медленнее. Я занялся этой задачей, когда работал над оптимизацией ресайза картинок на лету в Uploadcare. Мы решили открыть код и в результате появился проект Pillow-SIMD. Любой желающий с легкостью может использовать его в приложении на языке Python.

Любой код выполняется на конкретном железе и хорошей оптимизации можно добиться, только понимая его архитектуру. Всего я планирую выпустить 4 или 5 статей, в которых расскажу как применять знание архитектуры железа для оптимизации реальной задачи. Своим примером я хочу побудить вас оптимизировать другие прикладные задачи. Первые две статьи выйдут в течение недели, остальные — по мере готовности.

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

Традиционно, приложение, запускающееся даже с правами пользователя, имеет полный доступ в сеть. Оно может использовать любой сетевой адрес, существующий в системе для отправки пакетов.

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

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

Привет, Geektimes! Этот пост я пишу в соавторстве с Лобановым Виталием (hdablin) по следам его публикации «Когнитивные стимуляторы и другая психофарма: можно ли стать умнее», посвящённой фармакологическим аспектам проблемы «разгона» мышления. В нём я хочу рассказать о патопсихологии, о том, как проверяют людей на адекватность в психиатрической больнице, о том, какими бывают нарушения мышления, как их выявляют, о том, где проходит разница между гиком и психически больным человеком, о том, можно ли диагностировать у себя психическое заболевание самостоятельно, и о многом другом, имеющем отношение к теме.

Немного о себе: меня зовут Кристина, я медицинский психолог (именно медицинский, окончивший медицинский же университет по специальности «Клиническая психология», это важно), три года проработала в психиатрической больнице, сейчас ушла в частную практику, но осталась в психиатрии как в индустрии. Имею специализацию в нейропсихологии. За время работы мне приходилось сталкиваться с самыми разными категориями пациентов — шизофрениками, БАРщиками, депрессивными, органиками; часть из них обращалась добровольно, часть была госпитализирована в остром состоянии, часть вообще была «принудчиками» (это люди, совершившие преступление, но направленные судом не в тюрьму, а к нам в психушку на принудительное лечение).

tl;dr: В статье рассказано о том, как, зачем и почему проводится диагностика нарушений работы психики.

Предисловие

На написание статьи меня сподвигло практически полное отсутствие материалов на русском языке про алгоритмы генерации лабиринтов. На Хабре, из того, что вообще есть по теме, можно отметить две статьи: раз и два. Ценность и пользу из которых несет лишь вторая. В первой – просто перевод формального алгоритма и небольшое его пояснение. Что, конечно, неплохо, но очень скудно и не вызывает желания изучать тему дальше.

Если моя статья Вам понравится, я продолжу писать о различных алгоритмах. Мы рассмотрим два самых примитивных и простых случая – генерация двоичного дерева и Сайдвиндер, который, по своей сути, просто чуть измененная версия двоичного дерева с одним заметным плюсом. ОСТОРОЖНО ТРАФИК.

Уже не раз замечал интерес к новой плате-клону всем известной Raspberry Pi от китайских энтузиастов из компании Xunlong под звучным названием Orange Pi PC. Прославилась она, в основном, своим неплохим «железом» (4-ядерный процессор Allwinner H3, 1Gb RAM и GPU Mali-400MP2 600MHz), наличием неплохого функционала (HDMI, AV, Ethernet, 3 USB, microUSB-OTG, инфракрасный порт для управления с пульта и GPIO-гребенка, по словам разработчиков, якобы «100% совместимая с Raspberry Pi), а главное — ЦЕНА. Создатели оценили свой девайс всего лишь в $15, ПЯТНАДЦАТЬ долларов, Карл! (скоро мы увидим, что это на самом деле весьма лукавое заявление, и конечный девайс стоит дороже).

Итак, давайте рассмотрим данную плату повнимательнее.

В рунете уже есть на нее обзоры, но все они представляли из себя нечто вида „установил андроид и подключил к телеку на кухне“. Я предлагаю взглянуть на плату с другой стороны, а именно — установить туда линукс, поюзать её как настоящий ПК, и даже немного поиграть.

Для тех, кому лень читать полностью, прорезюмирую:

Интересная штука, на данный момент вполне юзабельная, но имеется огромное количество огрехов и косяков, требующих допиливания напильником. Покупать только на свой страх и риск! Простому пользователю, рассчитывающему иметь готовое решение „из коробки“, я бы посоветовал обратить внимание на ТВ-боксы на базе Android или Windows. Продвинутому пользователю, знакомому с Linux, который не боится неизведанных челенджей в сыром продукте, и которому хотелось бы иметь неттоп для интернет-серфинга, работы с документами, программирования и скромных игр — must have! Особенно с учетом цены.

Запуск Raspberry Pi с полной поддержкой графики на microSD, навсегда остающейся в режиме read-only после установки системы. Отсутствие какой-либо записи данных на флэш-память повышает надёжность устройства, приближая его к промышленному классу изделий. Пошаговая инструкция. Небольшой театр инженерного абсурда для развлечения аудитории.

Мне понадобилось сетевое устройство с открытым кодом и выходом HDMI, и я решил попробовать Малиновый Прог. Да, я именно так предлагаю переводить Pi: Прог. Понятное дело, даже одноплатнику нужна операционка. И вот, захожу я на официальный сайт, ожидая встретить там подробное руководство по созданию суровой, неломаемой Вещи à la turnkey box. Но народ, как ни в чём не бывало, устанавливает Ubuntu (т.е. Raspbian Jessie) прямо на microSD, размещая и swap там же. Как обычный десктоп, face palm.

Но то цветочки. Малиновые ягодки — это проекты фоторамок из МалинПрога, требующие обязательного выключения кнопкой. Иначе фоторамка после сбоя питания может не заработать, вместо картинок предлагая воспользоваться fsck. Но и это не предел, под катом читателя ждёт настоящий шедевр инженерного абсурда, найденный автором на просторах сети.

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

Хорошо размахнувшись, инженер производил мощный удар кулаком сверху монитора. Раздавался треск и… монитор оживал! Тогда, 30 лет назад, когда в свои десять лет я посещал вечерние занятия школы юных программистов в университете, только инженер имел право так чинить мониторы. Только он знал, в какое место и с какой силой приложить компьютерную технику, чтобы она ожила и мы, дети, которым повезло попасть в школу программистов, продолжили, счастливые, писать свои строчки кода.

Как же нам не любить аниматронику? Отогните силиконовую кожу любой куклы, и вам откроется скопление мехатронной магии, дающей ей жизнь на большом экране. Я искал в интернете хорошие вводные материалы на эту тему, но нашёл лишь один – обучающие видео от Стэна Уинстона. Уже через 30 секунд я почувствовал, как щупальца пробуждают мои самые низменные позывы к постройке осязаемых вещей. Я запал, я просто обязан был построить одну такую штучку… или несколько. И вот, как можно создать вполне реальное аниматронное щупальце.

Давайте поговорим о физике транспортных средств

Физика транспортных средств в видеоиграх не очень сильно обсуждается. Статьи в Интернете о физике транспорта в видеоиграх немногочисленны и поверхностны; обычно они посвящены самым основам. Программист транспорта для видеоигр ощущает себя сегодня в относительном вакууме. Возможно, такая ситуация возникла, потому что эту тему довольно сложно объяснить, а может быть, мы просто стыдимся признаваться в использовании хаков, упрощений и хитростей, которые мы вносим по сравнению с «правильной», реалистичной симуляцией физики. Как бы ни обстояло дело, видеоигры имеют уникальные проблемы в симуляции транспорта, а значит, об этом стоит писать. Это захватывающая тема, относящаяся к физике, работе с камерой, звуку, спецэффектам, а также к восприятию и психологии человека.

Я решил сначала поговорить о судах, потому что недавно работал с ними; ещё я обнаружил, что их динамика не совсем понимается даже на уровне исследований (хотя многое и понятно). Модели и теории формулируются таким образом, что их становится сложно применить непосредственно в видеоиграх. Или же они требуют очень ресурсоёмких методов симуляции, которые практически невозможно контролировать и адаптировать под причудливые потребности разработчиков и игроков. Но можно написать упрощённую модель, которая учитывает важные параметры судна. В этом определённо есть доля искусства, «прыжка веры» и небольшая доля «творческой» физики, которая заставит Кельвина и Стокса перевернуться в могилах.