1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Как повесить идеальный хэдшот если у тебя пинг 2 секунды? Вы узнаете в этой статье.

Текущий алгоритм работы мультиплеера

• Сервер получает команды с клиентов и времена их отправления
  
• Сервер обновляет состояние мира
  
• Сервер с некоторой частотой отправляет свое состояние всем клиентам
  
• Клиент отправляет команды и локально воспроизводит их результат
  
• Клиент получает обновленные состояния мира и:
  • Применяет состояние от сервера
  • Заново применяет все свои команды, которые сервер не успел применить.
  • Интерполирует предыдущие состояния других игроков
• С точки зрения игрока, есть два серьезных последствия:
  • Игрок видит себя в настоящем
  • Игрок видит других в прошлом.

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

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Введение

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

В этой статье мы рассмотрим последствия одновременного подключения нескольких игроков к одному серверу.

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

Разработка игры — само по себе непростое занятие. Но мультиплеерные игры создают совершенно новые проблемы, требующие разрешения. Забавно, что у наших проблем всего две причины: человеческая натура и законы физики. Законы физики привнесут проблемы из области теории относительности, а человеческая натура не даст нам доверять сообщениям с клиента.

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

Немного истории

С начала основания компании "Мультиклет" в 2010 велась разработка нескольких типов компиляторов для мультиклеточной архитектуры:

1. С первым процессором Multiclet P1 в 2012 году был разработан в составе программного обеспечения компилятор С89 на базе LCC. Одновременно велась разработка первого варианта собственного компилятора, приостановленная ввиду изначально сложного нереализуемого замысла.
   Как уже неоднократно указывалось во многих статьях на данную тему, а также признавалось самими разработчиками компании, компилятор на базе LCC имеет ряд существенных недостатков: поддержка лишь языка С89, отсутствие каких-либо оптимизаций.
   Впоследствии данный компилятор был адаптирован для поддержки нового процессора Multiclet R1 (2015 г.), система команд которого была значительно расширена, но компилятор этого не учитывал.
   Принимая во внимание эти недостатки, руководство компании в 2012 году собрало группу программистов, которым была поставлена задача разработать новый компилятор С99, лишённый указанных недостатков.

Многие слышали о мультиклеточной архитектуре, процессорах и даже первых устройствах на них. Особенно продвинутые пользователи опробовали свои алгоритмы. Были проведены первые простые тесты производительности, а также пользователь Barsmonster, вытравил кристалл процессора Р1. Сейчас уже проходит первые проверки процессор R1 и скоро будет доступен всем. Но ответ на вопрос о том, как работает мультиклеточная архитектура и в чём её отличие, знают не все. Попытаемся сейчас ввести в курс дела.

Предисловие

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

Учитывая все вышесказанное, а также тот "незначительный" факт, что заказчик в ТЗ прописал необходимость автоматического тестирования указанных в том же ТЗ функциональных требований, при старте очередного проекта стал актуальным вопрос выбора инструмента для автоматизации тестирования GUI. Проект был на Qt, и требовалась кроссплатформенность (Windows, Linux).

Какой в итоге opensource инструмент появился, смотрите по катом.

Эта очень короткая заметка на примере активации ключей в Steam описывает процесс автоматизации операций, выполняемых при помощи мыши и клавиатуры.

Допустим, вы купили несколько наборов игр Humble Bundle. Теперь у вас есть, например, 5 ключей для активации в Steam. А может быть 15 или даже 25. Вы очень не хотите активировать их вручную, потому что это слишком муторно: в клиенте Steam нужно каждый раз наводить курсор на меню «Games», щёлкать, потом наводить курсор на пункт меню «Activate a Product on Steam…», опять щёлкать, потом нажимать Enter, потом ещё раз Enter, и только затем наконец-то вводить ключ (а потом нужно подождать, ещё раз нажать Enter, затем Escape). А потом повторять то же самое для каждого последующего ключа. Как писал Леонид Каганов, стоило ли вообще ради такого «прогресса» спускаться с пальмы и брать в руки каменный топор?

В общем, вы решили этот процесс автоматизировать — тем более, что задача-то, на самом деле, очень простая. Для её решения нам потребуются консольные утилиты xdotool и xclip — убедитесь, что они установлены у вас в системе.

Большинство создают внешние ссылки через target="_blank" и не знают одного интересного нюанса — страница, на которую мы попадем таким образом, получит частичный контроль над ссылающейся на нее страницей через js свойство window.opener.

Через window.opener.location мы сможем сделать редирект на, к примеру, фишинговую страницу. Это своего рода tabnabbing, только более продвинутый. Так как жертва меньше всего ожидает подмены страницы, в открытой ранее, доверенной вкладке браузера.

Доброго времени суток, харбачитатель.

В этой статье мне хотелось бы рассказать об одном придуманном когда-то алгоритме (или скорее всего — переизобретённом велосипеде) построения плавного графика по заданным точкам, используя кривые Безье. Статья была написана под влиянием вот этой статьи и очень полезного комментария товарища lany, за что им отдельное спасибо.

Постановка задачи
Есть массив Y-ков точек, расположенных равномерно по оси X. Нужно получить плавный график, который проходит через все заданные точки. Пример на рисунке ниже:



Всех, кому интересно, прошу под кат.

Здравствуйте, уважаемые читатели! С наступающими вас праздниками.

В последней апрельской публикации мы хотели бы рассказать вам о замечательной книге Майкла Керриска «Linux Programming Interface», которая в очередной раз вернулась в наше поле зрения благодаря превосходным продажам другой литературы по Linux:



Конечно, сложная книга о системном программировании объемом 1500+ страниц — литература, прямо скажем, на любителя. Но, поскольку отзывы о ней до сих пор восторженные, а нам потратиться на Linux завсегда не жалко предлагаем почитать ее обзор, опубликованный в далеком 2011 году.

С ростом компании меняются люди и проекты. Не так давно в блоге GitHub появилась интересная статья, в которой автор рассказывает, как делать, а как лучше не делать Pull Request’ы. Перевод, традиционно, спрятан под катом.

В прошлый раз мы рассказали об Intel Management Engine (ME) — подсистеме, которая встроена во все современные компьютерные платформы (десктопы, лэптопы, серверы, планшеты) с чипсетами компании Intel. Эта технология многими воспринимается как аппаратная «закладка», и на то есть причины. Достаточно сказать, что Intel ME является единственной средой исполнения, которая:

• работает даже тогда, когда компьютер выключен (но электропитание подаётся);
• имеет доступ ко всему содержимому оперативной памяти компьютера;
• имеет внеполосный доступ к сетевому интерфейсу.

Ошарашенный присутствием такого компонента в компьютере, пользователь (получается, что именно «пользователь», а не «владелец») наверняка задавался вопросом: можно ли выключить Intel ME?

Эта статья целиком посвящена этому вопросу.

В моей статье полугодичной давности о длинной арифметике есть замеры скорости (throughput в тактах) очень коротких фрагментов кода — всего по несколько инструкций. Методика измерения была кривовата, но давала правдоподобные результаты. Потом выяснилось, что результаты таки неверные — поверхностный подход всегда сказывается.

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

Представляем электронную версию статьи из номера №2 за 2016 год журнала Компоненты и технологии. Автор Курниц Андрей.

В статье описан процесс развертывания экосистемы разработки приложений для микроконтроллеров Atmel серии SAM4S в среде операционной системы Linux. Читатель познакомится также с оценочной платой SAM4S-EK и семейством ARM Cortex-M4 микроконтроллеров фирмы Atmel. Приведены рекомендации по работе с адаптером отладки SAM-ICE (он же J-LINK) и программой OpenOCD.

Введение

Выбор операционной системы Linux в качестве среды для программирования микроконтроллеров ARM Cortex-M4 фирмы Atmel сложно назвать общепринятой практикой. Напротив, для разработки под свои микроконтроллеры Atmel свободно распространяет среду Atmel Studio 7, предназначенную исключительно для операционных систем Windows. Не будет секретом и тот факт, что разворачивание и настройка среды Atmel Studio 7 для новичка окажется куда проще, чем выбранный автором путь.
Автор предлагает использовать среду разработки Qt Creator в связке с инструментарием для кросс-компиляции GCC и с пакетом OpenOCD для отладки. В качестве операционной системы автор выбрал Linux Lubuntu 14.04 LTS (выполняющуюся на виртуальной машине, но это не существенно). Такой подход позволяет с легкостью переходить на другие ARM (и не только) микроконтроллеры, не меняя при этом привычный комплект инструментов. Например, в [1] приводится пример разработки для микроконтроллеров STM32F4 фирмы ST microelectronics с применением такого же комплекта инструментов.
Несколько слов об используемой терминологии. Аппаратное устройство, которое подключается к целевому микроконтроллеру и к рабочей станции, далее называется отладочным адаптером. Отладчиком же будет называться компьютерная программа, служащая для пошагового выполнения программы, просмотра значений ячеек памяти и т.д.

Аппаратная платформа

Рис. 1. Внешний вид платы SAM4S-EK с подключенным отладочным адаптером.

В прошлых статьях (Основы, Редактор: Часть 1 и Редактор: Часть 2) мы создавали небольшие приложения на языке AngelScript. На этот раз я хочу показать, что благодаря продуманной структуре движка писать игры на таком страшном языке, как C++, так же легко, как и на скриптовом языке. И чтобы вам не было слишком скучно читать, я подготовил небольшую игру (клон Flappy Bird), которую можно скачать здесь: github.com/1vanK/FlappyUrho. Кстати, исходный код игры можно читать как самостоятельную статью, потому что он очень подробно прокомментирован.

Как известно, в современных архитектурах x86(_64) и ARM виртуальная память процесса линейна и непрерывна, ибо, к счастью, прошли времена char near* и int huge*. Виртуальная память поделена на страницы, типичный размер которых 4 KiB, и по умолчанию они не отображены на физическую память (mapping), так что работать с ними не получится. Чтобы посмотреть текущие отображённые интервалы адресов у процесса, в Linux смотрим /proc/<pid>/maps, в OS X vmmap <pid>. У каждого интервала адресов есть три вида защиты: от исполнения, от записи и от чтения. Как видно, самый первый интервал, начинающийся с load address (соответствующий сегменту .text у ELF в Linux, __TEXT у Mach-O в OS X), доступен на чтение и исполнение — очень логично. Ещё можно увидеть, что стек по сути ничем не отличается от других интервалов, и можно быстро вычислить его размер, вычтя из конечного адреса начальный. Отображение страниц выполняется с помощью mmap/munmap, а защита меняется с помощью mprotect. Ещё существуют brk/sbrk, deprecated древние пережитки прошлого, которые изменяют размер одного-единственного интервала «данных» и в современных системах эмулируются mmap’ом.

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

• оптимально управляет уже выделенной памятью;
• значительно уменьшает количество обращений к ядру (ведь mmap / sbrk — это syscall);
• вообще абстрагирует программиста от виртуальной памяти, так что многие пользуются malloc’ом, вообще не подозревая о существовании страниц, таблиц трансляции и т. п.

Довольно теории! Будем щупать malloc на практике. Проведём три эксперимента. Работа будет возможна на POSIX-совместимых операционках, в частности была проверена работа на Linux и на OS X.

В процессе разработки приложения на Qt, может понадобиться добавить в данное приложение веб-интерфейс, что особенно может быть актуально при разработке встраиваемых систем с использованием Qt. Для решения данной задачи можно либо написать собственное решение, либо воспользоваться готовыми решениями. Например, библиотекой QtWebApp, которая предоставляет необходимый функционал для создания web-интерфейса.

К достоинствам данной библиотеки можно отнести:

1. формирование страниц с динамическим содержанием по шаблонам;
2. формирование полностью динамических страниц;
3. работу с Cookie, что позволит добавить авторизацию на приложении;
4. работу со статическими файлами, например, style.css или изображения;
5. реализацию загрузки файлов.

Предлагаю подробно рассмотреть один из вариантов запуска небольшого приложения на Qt, которое будет иметь несколько web-страниц, работающих с применением библиотеки QtWebApp.

На момент написания статьи изначально использовалась библиотека QtWebApp 1.6.3 и Qt 5.6. Проект успешно был запущен с комплектами сборки MSVC2013 и MinGW. В процессе отладки был замечен баг в классе Template библиотеки QtWebApp. После исправления бага и связи с разработчиком версия библиотеки была повышена до 1.6.4. Исходя из этого, можно отметить также плюс библиотеки, что разработчик ответил в течение суток на информацию о баге, и в тот же день версия библиотеки была повышена. Окончательный вариант примера приложения был подготовлен на версии 1.6.4.

Как-то так незаметно получилось, что программист, который разрабатывал нам прошивку для микроконтроллера, стал банально не успевать и в некоторые моменты я начинал перехватывать инициативу и самостоятельно браться за исправление ошибок.
Разработка велась в среде IAR, и многие согласятся со мной, что по сравнению с разработкой в QtCreator'е это боль и страдание.
В какой-то момент мы решили, что быстрее нанять нового программиста и вместе с ним заново переписать прошивку контроллера stm32, так, как я к этому моменту уже немного сам смыслил в их программировании и к тому же обнаружил, что QtCreator умеет отладку на голом железе (плагин BareMetal), я решил принять в этом активное участие.
Здесь я хочу поделиться шаблоном проекта для stm32f407 от Terra Electronica и рассказать об особенностях его настройки.

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

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

Кроме того, стоит также заметить, что практически все программы снятия рипов в Linux на самом деле являются просто обёрткой над cdparanoia. Поэтому я лично предпочитаю использовать эту утилиту напрямую, благо консоль у меня не вызывает негативных эмоций.