​​VR нынче на рынке много, а вот AR-проектов маловато — всех потеснил MicroSoft с их Holo Lens. И тем интереснее каждый новый проект в этой области. А уж Tilt Five просто чудесный!

Сейчас проект выставлен на KickStarter, описан довольно подробно, но вот промо-видео у кампании — исключительно развлекательно-завлекательное. А интересно-то как раз "мясо"! За мясом предлагаю пройти сюда: тут вам и описание технологий от одной из создателей, и демонстрация работы, и вѝдение перспектив проекта — рекомендую к просмотру!

Из видео я лично вынес следующее. Очки работают на отражённом свете, поэтому формируют сцену только в рамках специального коврика, покрытого отражающими микросферами (я бы уголковым отражателям порадовался, но сферы сделать проще, конечно). На каждый глаз работает свой проектор. Свет идёт от очков к коврику, отражается обратно и через специальное стекло попадает в глаз — никакого короткофокусного проецирования прямо в глаза, как у Google Glasses!. До смотрящего доходит 85% света от проектора, и это при том, что сами очки довольно прозрачные и не мешают смотреть на реальность одновременно с разглядыванием дополнений к оной! При этом каждый смотрящий видит только свою картинку, хотя коврик для всех общий — отличная задумка для любителей настолочек (это основная ЦА на данный момент).

Проекторы использованы собственной разработки, сильно широкоугольные, с поляризованным светом. Первое даёт возможность видеть сцену даже боковым зрением, если вдруг отвернёшься, а ещё — масштабировать пространство за счёт дополнительных ковриков. Второе (поляризация) нужно для селективности и для фильтрации стеклом очков. Теперь о выдаваемой картинке: 720р при 180 к/с на каждый глаз — внушительно!

Спросите, как быть уверенным, что картинка с заданными характеристиками будет успевать доезжать до очков с вычислителя (любой совместимый девайс, умеющий в USB)? Отвечу: это и не нужно, ведь вся геометрия отображения сцены на плоскость с учётом положения игрока относительно коврика делается на девайсе! Да, очки получают трёхмерную модель, не учитывающую положение головы игрока, а весь трекинг делают очки, используя широкоугольную ИК-камеру с подсветкой (эта камера и даёт привязку к границам коврика). Вторая камера, подсвечиваемая и "видящая" на другой длине волны, трекает физические предметы на столе — фишки и карточки с QR-кодами, а также специальные контроллеры-волшебные палочки.

Отвязка расчёта сцены движком игры от обсчёта картинки для глаз игрока даёт возможность игре выдавать сравнительно низкий FPS, а для игрока картинка останется плавной! Это позволяет к одному компьютеру подключить столько очков, сколько он сможет обслужить в рамках конкретной игры. А ещё при "лаге" картинки не страдает зрение игроков, ведь замирание графики не приводит к замиранию рисовки сцены — можно даже зависшую игру продолжать разглядывать!

Сейчас девайс работает с Unity, но потенциально сможет работать с другими движками. Создатели уже договорились с Fantasy Grounds о портировании их виртулальных сред для игры в настолки, а это уже серьёзно! Более того, будет работать cross play с теми, у кого ещё нет очков, но есть компьютер или мобильный девайс! Не замкнутая на себя система — это отлично!

Давно такого не было и вот я опять воодушевлён! Буду следить за прокетом!

#ar #gamedev

​​Есть такой аудиочип — MOS6581, в народе SID (Sound Interface Device). Чип очень любим и комодорщиками (фанатами #retrocomputer Commodore 64), и в целом любителями #chiptune.

Микросхема содержит три управляемых генератора тона и набор фильтров. Генераторы тона умеют генерировать колебания разной формы — пила, треугольник, прямоугольник и шум. Из фильтров доступны ФНЧ, ФВЧ, ПФ и комбинации. Более того, каждый генератор поддерживает управление ADSR! Словом, SID — настоящий трёхголосый Lo-Fi синтезатор в одном Narrow-DIP корпусе!

Для #sid пишется огромное количество музыки и сейчас, да и во времена молодости Коммодора писались свои "нетленки", вроде Monty's run от Роба Хаббарда (здесь можно и послушать и посмотреть визуализацию сигналов генераторов).

Существуют и специальные модификации железа вроде 2SID, позволяющие с того же C64 управлять сразу парой SID-чипов. Вот интересное видео по теме, заодно демонстрирующее работу в специальном композиторском ПО для C64 — MSSIAH (советую вообще присмотреться к каналу автора, если вас в целом цепляют чиптюн, синтезаторы и ретро-железки. И circuit bending заодно — про это тоже расскажу как-нибудь).

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

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

Вторым может серьёзно помочь проект FPGASID. Как можно догадаться по названию, это реализация SID на #fpga. По заверениям авторов, FPGASID старается быть неотличимым от оригинала с точки зрения аналоговой части и самого звука. А ещё является "drop-in заменой" для старичка, т.е. может быть вставлен в кроватку, рассчитанную на оригинал! Более того, FPGASID умеет притворяться не только одиночным SID-чипом, но и той самой 2SID-сборкой! Теперь и у желающих "просто приобщиться", вроде меня, появилась возможность распробовать SID-чиптюн без необходимости шерстить eBay в поисках заветного "дохлого C64 с живым SID"!

В заключение добавлю ссылку на 2SID-кавер на "Space Oddity" Дэвида Боуи. Трек прям "с пылу, с жару", презентован в сентябре этого года. А тут, если не хватит одной лишь музыки, можно посмотреть на запуск FPGASID в космос под микс 2SID-версии "Space Oddity" с оригинальной песней — эпичненько!

​​Вот ещё пример #sid-музыки: шедевральный Last Ninja 2 OST, Central Park (по ссылке заодно и графику можете оценить. ИМХО, C64 в первую очередь звуком примечателен — на её фоне картинка впечатляет меньше).

У этого трека есть уйма каверов, вроде этого от Fastloaders, или этой версии от KATOD (модифицированный С64 с оригинальным SID, а ещё — электрогитара :)) и просто неплохого "метал-ремикса".

P.S. К KATOD присмотритесь, если ретромузычка подобного плана вам нравится. У них как раз недавно клип "Superkomputer" вышел тематический: PowerGlove, спектрумы, ковёр, бигуди — очень аутентично!

Я уже писал про свои эксперименты с WebAssembly/WASI, недавно даже подкаст-монолог про это дело записал. Словом, я за темой слежу, причём слежу именно за направлением "универсальных бинарников".

А тут такая новость: Mozilla, Intel, RedHat и Fastly создали Bytecode Alliance — сообщество по пилению того самого нового формата бинарников.

Суть: реализовать возможность запускать универсальны WASM-бинарники в защищённых окружениях на разных системах и при этом управлять а) зависимостями и б) доступом зависимостей к системным ресурсам. Пункт "б", ИМХО — самый интересный! Можно взять стандартную библиотеку работы со строками (ага, leftpad) и запретить ей доступ ко всему, кроме, собственно, работы со строками!

Fastly регулярно пишут про свои эксперименты с Rust/Wasmer и им очень интересна вся эта тема с управлением правами wasm-бинарников. FastlyLabs открытые проекты по теме пилят. Словом, прямой коммерческий интерес к такому применению Wasm уже есть. А это очень важно для выживания технологии!

Отдельно радует роль #rust в около'wasm'овой экосистеме: на нём и рантаймы пишутся и инструментарий вроде wascap. Не говоря уж о том, что Rust — один из первых языков, начавших прорабатывать компиляцию в Wasm.

Ждём, надеемся, держим руку на пульсе #wasm :)

​​Так уж случилось, что я тут веду очные занятия по "основам типизированного ФП", в качестве учебного языка использую, как водится, #haskell. На днях мы прошли монады и написали библиотечку парсер-комбинаторов. На очереди Transformers, robots in disguise… ой, не эти, а обычные ("monads in disguise"?).

Изначально записалось аж тридцать человек(!), десятка два начали ходить, сейчас ходят 8-10. Один ученик в своём блоге о занятиях даже заметку написал — приятно! А вот домашние задания делают не все, поэтому приходится разбирать оные на самих уроках…

Зато потихоньку нарабатываю методтички (Literate Haskell + PDF) — пригодятся для будущих сессий!

(на картинке находится акроним TFPB, от Typed Functional Programming Basics)

​​Я почему-то всегда думал, что я уже писал здесь про Propeller и саму контору Parallax. Оказалось — нет, не писал. Восполняю пропуск!

Есть такая фирма, Parallax. Занимается разработкой своих линеек микроконтроллеров, а также наборов для обучения робототехнике.

Эпоха Stamps

В 199х Parallax была известна своими BASIC Stamp — это такие микроконтроллеры, которые работают под управлением специализированной версии #BASIC. Каждый контроллер выглядел, как 24-ногая микросхема (на самом деле это была маленькая платка), которая для работы требовала только батареи на 9В. Достаточно высокоуровневый, язык PBASIC позволял управлять множеством видов периферии, код загружался в ППЗУ по последовательному порту (позже через USB2UART), а ведь до Arduino оставался ещё десяток лет! Платформа была достаточно популярна тогда, но имеет своих почитателей и сейчас.

В 1997 году Parallax запустили образовательную программу "Stamps in Class", которая знакомила учеников с микроконтроллерами, основам разработки программ и электронных схем. Ученики даже программировали роботов Boe-Bot (один из самых популярных продуктов Parallax), имеющих BASIC Stamp 2 в роли "мозга".

Что интересно, по началу BASIC Stamp и BASIC Stamp 2 делались на баже микроконтроллеров PIC, которые устанавливались на ту самую плату-сборку, имитирующую DIP-корпус. Позже Parallax начали применять свой собственный PIC-подобные контроллеры Parallax SX, и продолжали применять до 2009г, когда чипы были сняты с производства.

В 2002г Parallax сделали смелый шаг — выпустили Javelin Stamp. На этот раз "почтовые марки" предлагалось программировать на Java! Да, это была урезанная версия и языка и платформы, но всё равно это было впечатляюще!

А потом в 2006г stamps наконец перешли на Parallax Propeller и язык Spin. Об этом в следующем посте <музыка из JoJo>

​​(продолжение предыдущей записи)

Эпоха Propeller

Propeller, это уже полностью детище самой Parallax, микроконтроллер с процессором 32-битной RISC-архитектуры, имеющим восемь ядер (2006г, напомню!). Программировался контроллер на своём ассемблере, а также на отдельном языке Spin — всё это, а также IDE для Spin разработали сами Parallax!

Для чего же микроконтроллеру восемь ядер, спросите вы? Ответ на этот вопрос и делает Пропеллер таким интересным! Дело в том, что Propeller не нёс на своём борту выделенных аппаратных шин, вроде UART, SPI и i2c: вместо этого предлагалось реализовывать соответствующие шины программно и поручать их обслуживание отдельным ядрам! Даже вместо прерываний и таймеров предполагалось использовать именно отдельные ядра. Потенциальные возможности поражали, ведь получился "почти ПЛИС", только программируемый на процедурном языке: представьте, что вы можете сделать контроллер с семью последовательными портами (одно ядро будет таки выполнять вашу программу) или что-то вроде "3 SPI + 2 TWI + 2 Dallas 1-wire"!

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

Ввод-вывод был организован через один общий 32-битный порт со специальной подсистемой, защищающей от конфликтов при совместном доступе. Каждый из 32 пинов мог выдавать ШИМ!

Сам Spin был высокоуровневым языком, компилирующимся в байткод, который и выполнял Propeller на отдельных ядрах (их называли Cogs) — по интерпретатору на ядро. Язык использовал отступы для обозначения блоков, в коде допускались ассемблерные вставки.

Со временем появились компиляторы для C и PropBASIC (специальный диалект для Propeller), пара реализаций #Forth и прочие менее успешные поделки вроде подмножеств Pascal и Java.

Увы, железка получилась слишком уж специфической: для новичков она была сложна (трудно в голове уложить восемь программ), а для промышленности — слишком необычна. К 2010ым производство свернули.

В 2014 Parallax открыла под GPL 3.0 как всё ПО, так и всё "железо": код интерпретатора Spin, сред разработки, Verilog-описание процессора, HDL-файлы для обвеса. Так что Propeller 1 теперь полностью открыт. Хотя бы это радует!

Parallax тогда же объявил, что теперь они занимаются разработкой нового Propeller с производительностью 200 MIPS/Cog (вместо 20 MIPS на ядро у Propeller 1). Но я не знаю, в каком состоянии сейчас проект находится :(

Вторая жизнь Propeller 1

Так как платформа открыта, энтузиасты воплощают её в том или ином виде на FPGA. Есть и коммерческие реализации. Например, Soft Propeller от Trenz-Electronic — реализация Propeller на базе Xiliz Zinq (я как-то писал про Pynq — ПЛИС из этого же семейства, программируемый на Python). Что интересно, Soft Propeller физически совместим со старым "пропеллерным" железом: платка с ПЛИС, выполнена в том же формфакторе Narrow DIP, в котором выпускался оригинал, и может быть просто вставлена на место старого чипа! Люблю такое!

Давненько не писал. Будем считать, что был в творческом отпуске. Буду навёрстывать!

​​В прошлый раз я писал про #propeller, поделюсь ещё одной интересной штучкой с пропеллером!

К DEFCON'22' (DEFCON — это такая конференция для технарей) бейджики готовили сами Parallax. И, конечно же, бейджики были сделаны на основе Propeller! Тут можно почитать подробности. А я пройдусь "по верхам".

Каждый бейдж имел на борту помимо пропеллера ещё и ИК-трансивер (приёмник + светодиод), восемь светодиодов и четыре сенсорные кнопки. Ну и USB, конечно. При этом каждый бейдж был ещё и полноценной dev board для пропеллера: все порты были выведены на пятачки для пайки. ИК-трансивер был рассчитан на общение бейджиков между собой(!). Участники конференции обменивались таким образом контактами — забавно, правда? С эстетической точки зрения бейджи были тоже очень хороши: фигурные платы в разных цветовых схемах (фото прикреплю ниже), прям глаз радуется. Что интересно, именно на DEFCON'22 параллаксовцы официально объявили об открытии "исходников" Propeller — Verilog, схемы, вот это всё.

Но про бейдж DEFCON'22 я узнал, исследуя интернеты в поисках информации об этой прелести! Это тоже бейдж на пропеллере, но с OLED-экраном, тем же беспроводными средствами связи (ИК), и тоже представленный в нескольких цветах (разные цвета для персонала конференции, и для гостей). Пока я нашёл только эту заметку, в которой авторы делятся своим видением будущего устройства. Буду искать дальше, очень уж интересно.

​​В прошедшие выходные добрался таки до Pollen — системы для написании/программирования книг, построенной на базе #racket.

Racket я использую давно и знаю, что документация к языку и пакетам написана на отдельном диалекте Scribble, как уж это водится у "рэкетиров". И даже о Pollen я давно был наслышан — на Pollen "написана" отличная книга "Beautiful Racket" (а ещё "Practical Typography").

Pollen умеет обрабатывать Markdown и генерировать на его основе HTML, но может быть использован и в других сценариях. Самое интересное в системе, это специальный язык X-expressions — описание дерева документа, пригодное для дальнейшей обработки.

Так, все входные форматы сначала преобразуются в X-exps, а уже потом перегоняются в тот же HTML. Даже Markdown может быть преобразован в X-exps и дообработан программно перед преобразованием в HTML. И конечно же, обрабатывать X-exps и даже формировать можно с помощью Racket — Pollen является его надмножеством.

Подкину коду для демонстрации:

#lang pollen

◊(define who "World!")

◊div[#:class "content"]{
  ◊h1{
    Hello ◊|who|!
  }
  ◊strong{text}
}

"Ромбики" являются началами команд. S-exps являются Racket-кодом, а другие описывают разметку. Разметка при этом не выполняется, она просто записывается в X-exps как есть. А если учесть, что X-exps, имеет вид (div ((#:class "content")) (h1 () "Hello " who)) то вы можете догадаться, как Racket обрабатывает разметку и генерирует её сам :)

В конце итоговое X-exp скармливается шаблону, который превращает разметку в текст выходного формата. Причём выходных форматов может быть несколько! Книгу, скажем, можно преобразовать в HTML, а можно и в LaTeX/PDF.

При этом обрабатывает Pollen проекты по-взрослому — кэширует, раздаёт встроенным сервером контент (формирует контент налету).

Я на всём этом добре решил сгенерировать страничку для моей VDS с хобби-проектами. Получилось что-то такое: recursive.one. Контента, как обычно для меня, нет. Но сам "движок" писать мне понравилось :D. Как и в прошлый раз, когда я на #haskell и Shake движок написал.

Забыл написать, что этот свой Pollen generated site я запихал в #docker контейнер с lighttpd, чтобы самораздавайка получилась.

А контейнер задеплоил на VDS, на котором Dokku бегает — такой вот PaaS у меня для микропроектиков. Вот только heroku-style deploying через гит я не люблю, да и Heroku CLI мне не особо нравится. Поэтому загружаю образы целиком через docker save | ssh ... — для моих поделок на "не самых популярных стеках" самое то. Уже успешно "задоккивал" проект на #Clojure, Web-приветмир на #Racket.

Кому-то это всё покажется детскими играми. Но я не умею в этот ваш DevOps современный да и не очень-то и хочу уметь. Из современного освоил только Docker, а вся автоматизация на Makefiles сделана — не могу в k8s, зато могу в GNU m2e! И мне норм :)

Попробую новый экспериментальный формат: "Смотрите, какую дичь я писал когда-то", то есть "мои #old_projects".

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

Я, как настоящий самоучка, аж до моей второй работы варился исключительно в собственном соку. Учась в институте, я делал все свои проекты на Delphi, который изучил по его же встроенной документации, а дополнял знания из .CHM-книжек "Kuliba3000" (а может 4000, я уже и не помню) — был такой "самиздат" сборников статей из интернетов, прикладывался к дискам "сколько-то-там компонент для Delphi". Интернета у меня не было курса до третьего, так что на этом, собственно, мои источники информации и исчерпывались. Это к концу учёбы я добрался до интернета, форумов, Хабра. И узнал, что на Delphi писать зазорно. Ну да ладно, пост не об этом.

То, что я писал на QBASIC и TurboPascal в школе, увы не сохранилось — померло то ли на одном из старых "винтов", то ли на старых же дискетах. Этого вашего Git тогда ещё не было, а без интернета я бы всё равно не смог бы его использовать. Чудом сохранились лишь мои студенческие Delphi-поделки. Про одну из таких я и хочу рассказать.

​​Часть 1

Задумал я как-то написать движок для "point&click" квестов. Да, сразу движок. Потому что я откуда-то знал, что игры делают на движках, а не хардкодят каждый экран. Об анимации и визуализации персонажа я в принципе не думал. Предполагалось, что игры будут "от первого лица", как в "7th Guest" (ага, oldschool!). Был намечен абсолютный минимум: кликабельные объекты на экране, имеющие всплывающие подсказки, какой-то инвентарь, возможность изменять часть сцены (то есть наложение объектов на фон).

Нарисовал я пару экранов в XaraX, и начал думать, как бы разметить объекты сцены. В итоге выкрутился так: сделал невидимое изображение в 16-цветном .BMP, подложенное под изображение сцены. Позиция мыши "прокалывала" холст и я мог получить цвет задника. Цвет и был идентификатором объекта. 16 цветов, это 16 объектов — для одного экрана достаточно. Зато объекты могли состоять из нескольких областей и вообще иметь произвольную форму. А самое главное, я эту цветовую карту мог очень просто выгружать: я просто делал равномерную заливку в векторе, убирал сглаживание и экспортировал в .BMP. Этот формат использовался потому, что Delphi мог читать такие файлы самостоятельно и сжатие не вводило новые цвета, то есть не портило мне разметку.

Самый первый экран выглядел так:

​​Часть 2

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

Имя секции соответствовало имени файла (его базовой части) изображения фона — вот вам "convention over configuration"! Первая сцена имела фиксированное имя "begin", соответственно подгружались файлы "begin.bmp" и "begin_m.bmp" — второй, это "маска", то есть тот самый невидимый слой с выделенными цветом объектами.

В секции писалось что-то такое:

[begin]
00FF00=j{waystone}
00FF00_h=Путевой камень
FF00FF=m{Бедный Ёрик}
FF00FF_h=Череп
FF0000=j{pogost}
FF0000_h=Дорога налево
FFFF00=j{rockwall}
FFFF00_h=Дорога направо

При перемещении мыши брался текущий цвет подложки, по нему как по ключу, доставались действие по клику и hint (всплывающая подсказка) для объекта: в примере эти ключ в формате RRGGBB и он же, но с суффиксом "_h" (hint). С текстом всё понятно, а действие "j{pogost}" означает "перейти(jump) к секции pogost".

Ключи секции, имеющие префикс "#", описывали "спрайты", то есть накладываемые на подложку объекты. Имя ключа (без префикса) служило именем файла, а значение было числом, которое в формате "640 * y + x" кодировало позицию спрайта относительно верхнего левого угла. Ага, тут я поленился вводить раздельное кодирование координат ;). Если же значение было меньше нуля, то спрайт не рисовался — так можно было показывать и прятать спрайты.

Вот вам спрайт дерева, которое рисовалось поверх пенька на стартовом экране (смотрите предыдущий пост).

Часть 3

Использование координат спрайтов, а точнее — их изменение, это уже попахивает переменными! Да, таковые я тоже предусмотрел. Даже секцию "vars" завёл, которая инициализирует все переменные игры. Переменные имеют префикс "$", могут встречаться в роли значений, а в секции "vars" в роли ключей. Тут всё понятно и просто.

Но переменные нужно изменять. Для этого я прикрутил целый мини-DSL. Тот самый "j{…}", упомянутый ранее, это команда языка как раз. Изменяла переменные команда "s{$x=y}" — тут тоже всё очевидно, надеюсь.

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

Предметы кодировались цифровыми идентификаторами, но по сути могли быть любыми валидными ключами: каждый идентификатор был ещё и ключом секции "invnames", значения в которой содержали имя предмета:

[invnames]
001=Ворота (украдены на кладбище)
002=Топор (взят в Пещере Гоблинов)
003=Дубовое бревно

А вот так выглядело срубание дерева на стартовом экране:

00FFFF=i{002}g{003}s{$tree=-1}.M{Вы срубили топором дуб и сделали из него бревно}
00FFFF_h=Сухое дерево (Дуб)
#tree=$tree

- "i{002}" — если есть "топор",
- "g{003}" — дать "бревно",
- "s{$tree=-1}" — присвоить переменной $tree значение -1, то есть спрятать спрайт дерева,
- "." — перерисовать сцену (максимально лаконично!),
- "M{…}" — показать message box с указанным текстом.

"#tree=$tree" помещает спрайт дерева туда, куда указывает переменная. При перерисовке сцены переменная читается каждый раз, поэтому изменения и вступают в силу. Так на картинке первого экрана и появляется пень — просто пропадает дерево, выводимое поверх него!

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

Часть 4

Язык сценариев получился вполне себе выразительный — для данной задачи, конечно же. Можно было описать довольно сложные сценарии.

Например, в игре вы шли на кладбище, брали там ворота (дверцу калитки), шли с ней к пещере со рвом перед входом, перекидывали калитку через ров на манер моста, и попадали в пещеру. Тут вам и взятие объектов и выбрасывание ("d{id}"), условные переходы, опять же.

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

С технической стороны всё получилось максимально прямолинейно. Парсер DSL у меня был однопроходный — просто посимвольно обходил строку однократно, сразу же выполняя команды. Никаких грамматик, никакого backtracking: я и слов-то таких не знал тогда — имел то, до чего додумался сам. Зато было весело!

Игру саму я тогда не доделал, конечно. Допилил движок, и игра стала "реализуема". Дальше уже наступал черёд игрового дизайнера и сценариста, затем — художника. А вот эти роли мне были не так интересны, поэтому игра осталась в виде "proof of concept" с четырьмя игровыми экранами. Но своё удовольствие я получил. И догадался сохранить исходники, что позволило в итоге написать эту серию %^D

​​Рубрика "ссылка на видео"!

Let's Reverse: Adventures of Lomax graphics — интересный и довольно необычный скринкаст (куда уж без стримов сейчас?) разбора одной старой игры (The Adventures of Lomax от крутейших Psygnosis) на предмет того, как игра хранит графику.

Зрелище само по себе нескучное, особенно если вы интересуетесь #reverse_engineering, но в этот раз ещё и инструментарий использован примечательный: вся работа делается в IPython REPL. И не в Jupyter, а именно в текстовом режиме — текстом выводятся гистограммы, палитры, даже сама графика! Используется для всего этого фреймворк Mr.Crowbar, предоставляющий eDSL (автор вдохновлялся Django ORM, %)), с помощью которого вы жонглировать байтиками, описывать структуры и обрабатывать их так, как Web-разработчики работают с моделями ORM. Собственно это видео как раз и записано автором фреймворка как demo для "Мистера Фомки".

Сам я положу Mr.Crowbar в копилочку, а вам желаю приятного просмотра! А может быть даже и вдохновлю кого-то (менее ленивого, чем я) что-то эдакое пореверсить >;^F

#python #gamedev #video