Прошлым летом меня пригласили на тусовку в Саннивейле. Оказалось, что у хозяев в гараже есть аркадный автомат NBA JAM Tournament Edition на четверых игроков. Несмотря на то, что игре уже больше 25 лет (она была выпущена в 1993 году), в неё по-прежнему очень интересно играть, особенно для увлечённых любителей.

Меня удивил список игроков Chicago Bulls, в котором не было Майкла Джордана. Согласно источникам, ^[1], Эм-Джей получил собственную лицензию и не был частью сделки, которую Midway заключила с NBA.

Расспросив владельца автомата, я узнал, что хакеры выпустили мод игры для SNES «NBA Jam 2K17», позволяющий играть новыми игроками и Эм-Джеем, но никто не занимался разбором того, как работала аркадная версия. Поэтому мне обязательно нужно было заглянуть внутрь.

Начав писать про стратегии обработки, я понял что творю «обезьяний набор» — пошаговое руководство даже не для чайников, а для идиотов, мои шаги повторить можно, сделать свои по образцу тоже, но понимания не добавляется. В свое время, когда я внезапно решил стать фрезеровщиком, имея в бэкграунде высшее медицинское, МБА и 10 лет компьютерного ритейла, мне было очень сложно продираться через терминологию и абсолютно новый понятийный аппарат.

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



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

Battle Prime — первый проект нашей студии. Несмотря на то, что многие члены команды имеют приличный опыт в разработке игр, мы, естественно, сталкивались с разными сложностями во время работы над ним. Они возникали как в процессе работы над движком, так и в процессе разработки самой игры.

В геймдев индустрии огромное количество разработчиков, которые охотно делятся своими историями, наработками, архитектурными решениями — в том или ином виде. Этот опыт, выложенный в публичное пространство в виде статей, презентаций и докладов, является отличным источником идей и вдохновения. Например, доклады команды разработки из Overwatch были для нас очень полезны при работе над движком. Как и сама игра, они очень талантливо сделаны, и я советую посмотреть их всем интересующимся. Доступны в GDC vault и на YouTube.

Это одна из причин, по которой мы также хотим вносить вклад в общее дело — и эта статья одна из первых, посвященная техническим деталям разработки движка Blitz Engine и игры на нем — Battle Prime.

Статья будет поделена на две части:

• ECS: имплементация Entity-Component-System паттерна внутри Blitz Engine. Этот раздел важен для понимания примеров кода в статье, и сам по себе является отдельной интересной темой.
• Неткод и геймплей: все, что касается высокоуровневой сетевой части и ее использования внутри игры — клиент-серверная архитектура, клиентские предсказания, репликация. Одной из важнейших вещей в шутере является стрельба, так что ей будет уделено большее количество времени.

Под катом много мегабайт гифок!

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

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

В dungeon crawler'е Unexplored использован фундаментально иной подход (см. рисунок 1). Вместо линейных путей в качестве самой базовой структуры он изначально использует циклы. Разница оказывается поразительной: при старом подходе хорошие и интересные циклы могли возникать случайно, а в Unexplored они являются запланированной особенностью результата работы генератора.

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

Представляю вашему вниманию библиотеку microrl (on github), предназначенную для организации консольного интерфейса в разного рода встраиваемых железках на микроконтроллерах.

Зачем нам консоль в МК?

Текстовый консольный интерфейс обладает рядом преимуществ для встраиваемых систем, при всей своей мощи и простоте (ведь текст, в отличие от светодиода, говорит сам за себя!):

• Требует относительно мало ресурсов МК, и минимум аппаратных затрат — последовательный интерфейс типа UART или любой другой имеющийся в МК, это может быть встроенный USB или внешний USB-Com адаптер или даже TCP если ваше микроконтроллер достаточно серьезный.
• Удобно подключаться — достаточно терминала поддерживающего Com-port (putty для Windows или minicom для linux).
• Удобно использовать — цветной вывод в терминал, поддержка авто-дополнений, горячих клавиш и истории ввода.

Привет, Хабр. В этом посте мы хотим рассказать о том, как и почему мы в IPONWEB используем язык программирования с красивым названием Lua.

Lua — скриптовый встраиваемый язык программирования со свободно распространяемым интерпретатором и открытыми исходными текстами на C. Он был разработан в 1993 году в Бразилии, в подразделении Tecgraf Католического университета Рио-де-Жанейро, а его прародителями были DEL (Data-Entry Language) и SOL (Simple Object Language), разработанные там же ранее. Один из прародителей, язык SOL, косвенно поучаствовал и в «крещении» новорожденного — «Sol» переводится с португальского как «солнце», а новый язык получил имя «Lua», «луна».

Легкость встраивания Lua в написанные на “системных” языках движки сделала его популярным скриптовым языком видеоигр. На Lua написаны, к примеру, скрипты в Grim Fandango и Baldur's Gate. Те, кто играет в World of Warcraft, тоже наверняка слышали о Lua не раз и не два — именно на нем пишут аддоны к игре, облегчающие жизнь хардкорщикам, казуалам, любителям помериться эффективностью и прочим обитателям игрового мира. Вне геймдева Lua используется как скриптовый язык встроенных систем (телевизоров, принтеров, автомобильных панелей), а также приложений, например, медиаплеера VLC Media Player. Lua используют в качестве встроенного языка такие инструменты, как Tarantool, Redis и OpenResty. А еще Lua был использован как язык расширения для расчетных кодов на языке Фортран, моделирующих термомеханическое поведение ядерного топлива.

Почему Lua?

Я всегда начинаю с того, что задаю много вопросов и провожу активные исследования. За свою карьеру я успел поработать над множеством сиквелов уже существовавших франшиз. Лучшее, что ты можешь сделать в этом случае — полностью освоить жанр игры и изучить мир. Среди прочих проектов, мне приходилось с головой нырять в Halo, StarWars, Hellboy и Division. Хорошие гейм-дизайнеры — это хорошие исследователи.

Naughty Dog мастерски реализовала The Last of Us: Left Behind, и прежде чем браться за этот проект, мне нужно было хорошо подготовиться. Если вы не играли в Last of Us, то сыграйте! Это одна из самых потрясающих историй и несравненный пример развития персонажей. Другие разработчики очень многому могут научиться у создателей этой игры. Из-за сильного упора на повествование Naughty Dog называет свои дизайн-документы миссий «набросками глав». Мне кажется, это очень милый штрих. Это заставляет больше думать о повествовании при создании контента и придавать дизайну более сюжетную структуру.

Предупреждение — в статье содержатся спойлеры Last of US и Last of Us DLC.

Существует множество поклонников старых игр. И они не прочь пустить скупую ностальгическую слезу и нет-нет, да сыграть в «Арканоид», «Пакмана» или «Принца Персии», как двадцать, тридцать, сорок или — подставьте нужное число — лет назад. DOS-box и эмуляторы — им в помощь. Да, что там, я недавно смотрел стрим самого первого 2D «Принца Персии» на Ютьюбе, где довольно молодой «стример» после прохождения очередного смертельного препятствия, смахнув со лба пот рукой, изрек: «Мне еще никогда не было так страшно в компьютерной игре». То есть, даже молодежь способна оценить хардкорность и крутизну старых игр.


Я подумал, а почему бы не создать новую игру в подобном стиле? Да, существуют различные ремейки и клоны. Также, радуют современные игры в стиле пиксель-арт. Однако, все они, как правило, повторяют квесты, механики и иногда вообще полностью левел-дизайн старых игр, по мотивам которых они сделаны. Ну либо, наоборот, предлагают совершенно новый сюжет и локации, являя собой просто визуальную стилизацию «под старину». А что, если представить, какой была бы новая часть старой игры, выйди она следом за последней из серии? Я решил такую создать.

Редактирование снимка экрана для этой статьи — в Haiku

TL;DR: Производительность намного лучше, чем изначально. Виноват был ACPI. Запуск в виртуальной машине работает прекрасно для показа экрана. Git и менеджер пакетов встроены в файловый менеджер. Публичные беспроводные сети не работают. Разочарование с python.

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



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

Прототипирование — значимый этап в веб-разработке, который позволяет определить и сформировать ДНК проекта на ранних стадиях. В последние годы количество онлайн-сервисов и инструментов для прототипирования ощутимо возросло. В этом обзоре представлены 10 сервисов для создания визуальных сайтмэпов.

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

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

Почти все игровые ретроконсоли генерируют цвета в каком-нибудь из вариантов RGB-кодирования.

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

Самым распространённым сегодня видом дисплеев являются ЖК-панели (LCD). Они известны тем, что имеют очень плохие уровни чёрного. Различия между TN, PVA и IPS не слишком на это влияют.

Отдельные фанаты играют на ЭЛТ-мониторах, и всё большую популярность набирают OLED-экраны, особенно на телефонах и планшетах. Но в этой статье мы в основном будем рассматривать ЖК-экраны, хотя данная методика важна для дисплеев любого типа.

Точность цвета

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

Например, Sega Genesis кодирует 9-битные цвета, что даёт по 3 бита на канал.

Самым наивным решением было бы поместить 3 бита в самые старшие 3 бита вывода, а младшие 5 бит оставить пустыми, но при этом белый цвет становится немного серым.

[Примечание переводчика: перевод первой части этой статьи уже есть на Хабре, но её автор почему-то не завершил работу.]

Рендерер Quake III

Рендерер Quake III стал эволюционным развитием рендерера Quake II с аппаратным ускорением: классическая часть построена на архитектуре «двоичного разбиения»/«потенциально видимых наборов», но добавлены два новых заметных ключевых аспекта:

• Система шейдеров, построенная поверх фиксированного конвейера OpenGL 1.X. Это было большим достижением для 1999 года. Она обеспечивала большое пространство для инноваций в эру до повсеместно распространённых сегодня вершинных, геометрических и фрагментных шейдеров.
  
• Поддержка многоядерной архитектуры: клиент-серверная модель OpenGL блокирует некоторые методы и система потоков частично решает эту проблему.

(с)

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

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

Обновившись в конце апреля на новые драйвера AMD 16.4.2, я обнаружил, что все DirectX12-приложения перестали работать. Ничуть не удивившись, я решил подождать устранения проблемы и отложил DirectX12 в сторону. Но месяцы шли, а с новыми драйверами ситуация не менялась.

Сколько процессорных ядер Intel в вашем компьютере? Если вы пользуетесь системой на базе Intel, то в абсолютном большинстве случаев к вашему ответу надо будет прибавить единицу. В состав почти всех процессоров Intel — от Atom и до Xeon E3, естественно, не пропуская Core, уже много лет входит интегрированное графическое ядро Intel Graphics, являющееся по сути полноценным процессором, и соответственно, способное не только показывать на экране картинки и ускорять видео, но и выполнять «обычные» вычисления общего назначения. Как это можно эффективно использовать? Смотрите под катом.

Введение

(Ссылки на исходный код и проект KiCAD приведены в конце статьи.)

Хотя мы родились в 8-битную эпоху, нашим первым компьютером был Amiga 500. Это великолепная 16-битная машина, обладавшая потрясающими графикой и звуком, благодаря чему она отлично подходила для игр. Очень популярным игровым жанром на этом компьютере стали платформеры. Многие из них были очень цветастыми и обладали очень плавным параллаксным скроллингом. Это стало возможно благодаря талантливым программистам, гениально использовавшим сопроцессоры Amiga для увеличения количества экранных цветов. Взгляните, например на LionHeart!


Lionheart на Amiga. Это статичное изображение не передаёт всю красоту графики.

С 90-х электроника сильно поменялась, и теперь есть множество маленьких микроконтроллеров, позволяющих создавать удивительные вещи.

Мы всегда любили платформенные игры, а сегодня всего за несколько долларов можно купить Raspberry Zero, установить Linux и «довольно легко» написать красочный платформер.

Но это задача не по нам — мы не хотим палить из пушки по воробьям!

Мы хотим использовать микроконтроллеры с ограниченной памятью, а не мощную систему на чипе со встроенным GPU! Другими словами, мы хотим трудностей!

В 1985 году Алексей Пажитнов и Вадим Герасимов выпустили в свет Tetris. Эта увлекательная и вызывающая сильное привыкание игра требовала от игроков соединять фигуры, появлявшиеся в случайном порядке. С того времени было выпущено более 150 лицензионных версий «Тетриса». Отличаясь игровыми режимами, правилами и реализацией, все они игрались слегка (или очень) по-разному. Рандомизатор «Тетриса» — это функция, возвращающая случайно выбранную фигуру. На протяжении многих лет правила выбора фигур эволюционировали, оказывая влияние на геймплей и саму случайность. Некоторые из этих алгоритмов были подвергнуты реверс-инжинирингу и задокументированы. Я составил список рандомизаторов, которые считаю важными, и покажу в статье, как с годами менялось внутреннее устройство «Тетриса».

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

Инструменты отладки

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


Отладчик эмулятора FCEUX

Стоит заметить, что этот способ больше подходит для продвинутых программистов, работающих с языком ассемблера. Но мы новички, поэтому будем писать на языке C (cc65). Разумеется, компилятор станет играть по своим собственным правилам, и нам будет трудно разбираться с машинным кодом, скомпилированным из кода на C.