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

Этой весной мы в лаборатории экспериментировали с самыми разными данными: характеристиками танков в игре World of Tanks, статистикой правильных и неправильных ответов на тренажёре ПДД, температурными рекордами в городах России, нарушениями в работе маршрутных такси Нижнего Новгорода, историей изменения цен на авиабилеты. Результатом экспериментов стали 5 наглядных интерактивных визуализаций:



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

Традиционно в последнюю пятницу месяца состоялся Python Meetup. В мартовском митапе с приглашенными спикерами мы разобрались в следующих темах:

• Машинное обучение на Python
• Как устроен Python AST и какие интересные факты есть у диалекта Ну
• Как при помощи Requests, Asyncio и Aiohttp перестать использовать многопоточный код

Видео и ссылки на презентации смотрите под катом. Приятного просмотра!

Часть первая: инструментарий мелкосерийного изобретения велосипедов

Почему и зачем: длинная и необязательная преамбула

Хорошо, что опыта игрового модостроительства у меня было немного — так, пару кастомных прицелов для Deer Hunter 2005 и «нелицензионный» недоклиент VATSIM/FSD с сопутствущим «взломом» протокола последнего. Ещё лучше, что ни разу не приходилось с головой погружаться в сколь-нибудь трудоёмкую и длительную отладку и дизассемблирование. То есть, с IDA и OllyDBG я поверхностно знаком, но не как с ежедневными рабочими инструментами.

В WOT играю с начала 2011 года. Не запоем, а, скорее, набегами — по 5-6 боёв вечером. Было время 2 года назад, наш клан состоял в Красном Альянсе, ходил на глобалку по ночам, выполнял какие-то тактические задачи на европейском ТВД, устраивал тренировки и спарринги, вовсю бурлили внутриигровые политические страсти, отпочковывались учебные кланы. Сейчас всего этого уже нет, и наш золотой ёжик превратился в табличку над «Домом Ветеранов».

Впадать в ересь сравнения танков с другими MMO не буду, так как хорошо знаком только с танками. Тем более не знаком ни с одним другим проектом, использующим BigWorld, поэтому искренне верю WarGaming'у на слово, что существуют и (не)тривиально (не)преодолеваются различные техномагические ограничения движка — на размер карты, на максимальную скорость юнита, на численность команд и прочее. Оставаясь в рамках внутренней критики, я также понимаю, что, с точки зрения целевой аудитории танков вообще, и их активного игрового коммьюнити в частности, каждое нововведение из очередного патча, безусловно, гораздо более востребовано и обосновано, сколь бы малым оно ни было. И что оптимизировать Motion Blur на несколько процентов это, безусловно, важнее, чем отменить принципиальную неизменяемость привязки действий на кнопки мыши для тех, кто привык на них ставить движение вперёд-назад (DOOM-стайл, да).

Итак, я уверен, что в обозримом будущем никаких планов по введению полноценного режима спектатора в WOT нет и не будет. Под полноценным режимом спектатора я понимаю множественные подключения игроков в сеанс боя изначально как невзаимодействующих на игру «привидений»-наблюдателей, а не на технике. Это тот самый режим, из-за отсутствия которого комментаторы на чемпионатах WOT вынуждены заходить в бой 15-м танком, убиваемым своими на базе. Это тот самый режим, из-за которого появились моды «командирского zoom» и «кинематографической камеры» — по сути, просто костыли. А нужен такой режим затем, чтобы командир роты занимался командованием, а не скакал впереди на лихом танке по-чапаевски, чтобы он видел ситуацию на карте в целом непрерывно, а не отвлекался на неё в пылу нападения из засады. В идеале, командиру даже не нужны красоты трёхмерного мира — достаточно одной большой карты на весь монитор с игровой ситуацией в реальном времени — HP, повреждениями модулей, членов экипажа, направлениями стволов и прицелов союзной техники, засвеченных в каждый момент вражеских юнитов и прочей вспомогательной информации.

WOT предоставляет широкие возможности модостроительства, но такая идея выходит за рамки классического «заменить пару swf-файлов на свои». Потребуется перехват и разбор самого игрового протокола для того, чтобы иметь возможность передать на командирский планшет своё видение игровой ситуации.

Ведущий разработчик Яндекс.Деньги Андрей Мелихов (также редактор/переводчик сообщества devSchacht) на примере движка V8 рассказывает о том, как и через какие стадии проходит программа, прежде чем превращается в машинный код, и зачем на самом деле нужен новый компилятор.



Материал подготовлен на основе доклада автора на конференции HolyJS 2017, которая проходила в Санкт-Петербурге 2-3 июня. Презентацию в pdf можно найти по этой ссылке.

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

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

Анализ статистики GitHub показывает, что по показателям активных репозиториев и push-запросов, JavaScript находится на первом месте, да и в других категориях он показывает довольно высокие позиции.


Статистические сведения по JavaScript с GitHub

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

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

Как ни странно, существует множество разработчиков, которые регулярно пишут на JavaScript, но не знают, что происходит в его недрах. Пришло время это исправить: этот материал посвящён обзору JS-движка на примере V8, механизмов времени выполнения, и стека вызовов.

V8 — это движок JavaScript от Google, который используется в браузере Chrome. Он быстрый и доступен в исходных кодах (С++) для Linux (точнее для gcc) и под Windows.

В свете роста популярности использования V8 я решил поделиться своим (годичным) опытом его использования на платформе Windows в качестве серверного скриптового движка.

Часть 1. Введение и простейшая программа, использующая V8.

Сегодня вечером был выпущен финальный ISO-образ Windows 10 2004 (20H1). Им стал билд за номером 19041.208.vb_release_svc_im.200416-2050. Образы для разработчиков уже доступны на MSDN как вскоре и сами знаете где.

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

Началось все, как водится, с ошибки. Я первый раз работал с Java Native Interface и делал в C++ части обертку над функцией, создающей Java объект. Эта функция — CallVoidMethod — вариативна, т.е. помимо указателя на среду JNI, указателя на тип создаваемого объекта и идентификатора вызываемого метода (в данном случае конструктора), она принимает произвольное число других аргументов. Что логично, т.к. эти другие аргументы передаются вызываемому методу на стороне Java, а методы могут быть разные, с разным числом аргументов любых типов.

Соответственно и свою обертку я тоже сделал вариативной. Для передачи произвольного числа аргументов в CallVoidMethod использовал va_list, потому что по-другому в данном случае никак. Да, так и отправил va_list в CallVoidMethod. И уронил JVM банальным segmentation fault.

За 2 часа я успел перепробовать несколько версий JVM, от 8-ой до 11-ой, потому что: во-первых это мой первый опыт с JVM, и в этом вопросе я StackOverflow доверял больше, чем себе, а во-вторых кто-то на StackOverflow посоветовал в таком случае использовать не OpenJDK, а OracleJDK, и не 8, а 10. И лишь потом я наконец заметил, что помимо вариативной CallVoidMethod есть CallVoidMethodV, которая произвольное число аргументов принимает через va_list.

Что мне больше всего не понравилось в этой истории, так это то, что я не сразу заметил разницу между эллипсисом (многоточием) и va_list. А заметив, не смог объяснить себе, в чем принципиальное отличие. Значит, надо разобраться и с эллипсисом, и с va_list, и (поскольку речь все-таки о C++) с вариативными шаблонами.

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

• Безопасный вызов метода
• Неиспользуемые переменные
• Превращение в строку
• Запятая в аргументе макроса
• Бесконечный цикл

Заранее предупреждаю: если Вы думаете увидеть под катом что-то крутое, головоломное и сногсшибательное, то ничего такого в статье нет. Статья про светлую сторону макросов.

Вступление

Мне кажется, что нам надо использовать меньше тригонометрии в компьютерной графике. Хорошее понимание проекций, отражений и векторных операций (как в истинном значении скалярного (dot) и векторного (cross) произведений векторов) обычно приходит с растущим чувством беспокойства при использовании тригонометрии. Точнее, я считаю, что тригонометрия хороша для ввода данных в алгоритм (для понятия углов это интуитивно понятный способ измерения ориентации), я чувствую, что что-то не так, когда вижу тригонометрию, находящуюся в глубинах какого-нибудь алгоритма 3D-рендеринга. На самом деле, я думаю, что где-то умирает котенок, когда туда закрадывается тригонометрия. И я не так беспокоюсь о скорости или точности, но с концептуальной элегантностью я считаю… Сейчас объясню.

В середине 1980-х Nintendo Entertainment System (NES) была обязательной к покупке консолью. Лучший звук, лучшая графика и лучшие игры среди всех консолей того времени — приставка расширяла границы возможного. До сих пор такие проекты, как Super Mario Bros., The Legend of Zelda и Metroid считаются одними из лучших игр всех времён.

Прошло более 30 лет после выпуска NES, а классические игры чувствуют себя прекрасно, чего нельзя сказать о железе, на котором они работали. Имея разрешение всего 256x240, консоль NES не могла предоставить играм достаточно пространства. Тем не менее, бесстрашным разработчикам удалось уместить в играх NES потрясающие, незабываемые миры: лабиринтоподобные подземелья The Legend of Zelda, обширные пространства планеты в Metroid, яркие уровни Super Mario Bros.. Однако из-за аппаратных ограничений NES игроки никогда не могли выйти за пределы разрешения 256x240…

До недавнего времени.

Представляю вашему вниманию проект wideNES — новый способ сыграть в классику NES!

Сегодняшняя тема — надежность World of Tanks Server — достаточно скользкая. Надежность игры — это trade off, потому в разработке игр все нужно делать быстро и быстро изменяться. Нагрузка на серверы большая, а пользователи склонны что-нибудь поломать просто из интереса. Левон Авакян на РИТ++ рассказал, что в Wargaming делают для обеспечения надежности.

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

О спикере: Левон Авакян работает в компании Wargaming в должности Head of WoT Game Services and Reliability и занимается проблемами надежности танкового сервера.

Части первая и вторая.

Эмулятор процессора 8080

Оболочка эмулятора

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

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

Для начала я создам структуру памяти, которая будет содержать поля для всего, что показалось мне необходимым при написании дизассемблера. Также там будет место для буфера памяти, который будет представлять собой ОЗУ.

Первая часть здесь.

Дизассемблер процессора 8080

Знакомство

Нам понадобится информация об опкодах и соответствующих им командах. Когда вы будете искать информацию в Интернете, то заметите, что есть много перемешанных сведений о 8080 и Z80. Процессор Z80 был последователем 8080 — он выполняет все инструкции 8080 с теми же hex-кодами, но также имеет и дополнительные инструкции. Думаю, пока вам стоит избегать информации о Z80, чтобы не запутаться. Я создал таблицу опкодов для нашей работы, она находится здесь.

У каждого процессора есть написанное изготовителем справочное руководство. Обычно оно называется как-то наподобие «Programmer's Environment Manual». Руководство для 8080 называется «Intel 8080 Microcomputer Systems User's Manual». Его всегда называли «справочником» («data book»), поэтому я тоже буду так его называть. Мне удалось скачать справочник по 8080 с http://www.datasheetarchive.com/. Эта PDF представляет собой некачественный скан, так что если найдёте версию получше, то используйте её.

Написание эмулятора аркадного автомата — это замечательный учебный проект, и в этом туториале мы очень подробно рассмотрим весь процесс разработки. Хотите по-настоящему разобраться в работе процессора? Тогда создание эмулятора — наилучший способ его изучения.

Вам потребуется знание C, а также пригодится знание ассемблера. Если вы не знаете язык ассемблера, то написание эмулятора — лучший способ освоить его. Также вам нужно будет освоить шестнадцатеричную математику (также известную как base 16 или просто «hex»). Я расскажу и об этой теме.

Я решил выбрать эмулятор автомата Space Invaders, в котором используется процессор 8080. Эта игра и этот процессор очень популярны, потому в Интернете можно найти о них кучу информации. Для завершения проекта она вам понадобится.

Весь исходный код туториала выложен на github. Если вы не освоили работу с git, то на странице github есть кнопка «Download ZIP», позволяющая скачать архив со всем кодом.

Введение

Для нового проекта мне понадобилось извлечь данные уровней из классической видеоигры 1985 года Super Mario Bros (SMB). Если конкретнее, то я хотел извлечь фоновую графику каждого уровня игры без интерфейса, подвижных спрайтов и т.п.

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

На первом этапе проекта мы изучим язык ассемблера 6502 и написанный на Python эмулятор. Полный исходный код выложен здесь.