BACK TO THE PET - дневник разработки (часть 2/2)
Продолжение дневника разработки демо BACK TO THE PET. Весь целиком он не поместился в один пост из-за ограничений движка сайта.
Отвлекался от проекта на выходные. Тем временем возникли некоторые идеи по оптимизации эффекта волн. Однако, более эффективная оптимизация, не требующая переделок, была найдена методом тыка — оказалось, что можно отказаться от учёта младшего байта в дельте указателя внутри цикла расчёта фрагмента синусоиды, и таким образом делать 8-битное сложение вместо 16-битного. Впрочем, этого всё равно не хватает для 60 FPS в NTSC, но без ожидания обратного хода луча выглядит довольно плавно.
Провёл эксперименты с экраном логотипа в прототипе на C, чтобы оценить, работают ли задумки. Результат пока сомнительный.
Снова отвлекался, на этот раз на начало другого большого проекта, где нужно было провести подготовительные работы. Разумеется, в условиях поджимающих сроков теперь тянет заниматься им, запала на два дела не хватает, как и часов в сутках. Но пытаюсь продолжить работу. Собрал даты и начал рисовать таймлайн для второй сцены демо, перед названием.
Тем временем, до CAFe осталось две недели ровно. Учитывая, что демо готово от силы на треть, возможность поездки на пати видимо отпадает, так как это минус несколько дней до дедлайна, и само завершение проекта в срок тоже под очень большим вопросом.
Отладил эффект таймлайна в прототипе на SDL, задал анимацию таймлайна. В работу пошёл первый же вариант, так как времени на раздумывание и переделки при отсутствии критерия для определения улучшения всё равно нет. Переписал сцену на ассемблер, работает без тормозов в 60 FPS. Тормозить потенциально мог бы скролл, без развёрнутых циклов он даже в 50 FPS имел шанс не уложиться в кадр при неудачном размещении опкодов цикла (всего один лишний такт внутри цикла меняет дело). Получившаяся сцена в принципе смотрится неплохо. Плюс ещё одна зелёная строчка в списке сцен и 20 секунд к продолжительности демо. Количество готовых сцен превысило 50%, готовность же демо в целом от этой цифры пока далека.
Провёл ревизию списка всех оставшихся пяти сцен, выделил задачи для решения. Проблема в том, что среди оставшихся сцен в четырёх непонятно, что именно делать, и в двух непонятно как именно делать. Также понял, что пора в срочном порядке решать вопрос сборки разрозненных сцен в общий бинарник, а для ускорения работ делать список задач конкретно на каждый день.
Согласно списку из двух пунктов, первым делом занялся вопросом сборки. Пакет CC65 обладает огромной гибкостью, но такие простые вещи, как сборка фрагментов кода в отдельные бинарники в один и тот же адрес в нём настраивается нетривиально, а документация обширна из запутана. Так как тратить много времени на решение такой тривиальной задачи было бы неразумно, решил собирать сцены в отдельные файлы очень корявым, но рабочим методом — для каждой из сцен делается дополнительный main.s с инклюдом общего кода и кода сцены. Собрал таким образом имеющиеся сцены и оценил масштабы катастрофы. Готовые шесть сцен занимают 30125 байт, что, конечно, никак не влезет в память PET 4032. Но изначально расчёт сделан на упаковку, и сжатые по отдельности при помощи apultra сцены занимают 14210 байт, а несжатый размер самой большой из сцен — с вращающимися буквами — 7616 байт. Пока всё помещается, и даёт надежды на успешное влезание оставшихся сцен в память. Хотя, конечно, хорошо бы немного подуменьшить самые большие сцены.
Запуск упакованных сцен сходу не заработал. Похоже, что в распаковщик aplib всё-таки закралась ошибка. Чтобы не тратить время на её поиски, я решил попробовать альтернативный пакер, и быстрый поиск в Google выдал мне ZX02, свежую разработку этого года. Он даже немного эффективнее, что позволило сэкономить 374 байта на сжатых сценах, довольно быстрый, и главное — он работает.
По непонятной причине в сцене с вращающимися буквами после распаковки почему-то не работал эффект шума на картинках, хотя в версии обычной всё в порядке. После пересборок он заработал, возможно сначала что-то сползло в адресах общего для всех частей кода. В целом же система сборки заработала, но в паре сцен также нашлись проблемы при возврате из них. В сцене матрицы в одном месте была проблема в выделении byte вместо word под переменную, что портило последующий код. В сцене морфинга был потерян pla в цикле, из-за чего портился стек.
Реализовал в прототипе целочисленный вариант бампа с 16 градациями яркости. В 60 FPS смотрелось бы не так уж плохо. Сделал наивную реализацию для 6502, работает, но очень тормозит. Пока непонятно, как избавиться от нескольких моментов в вычислениях и добиться хотя бы 20 FPS.
Возникло более детальное видение, как именно должна выглядеть технически простая сцена с лабиринтом, но пока к работе над ней не приступил.
Так как времени на грамотное улучшение и оптимизацию алгоритма бампа нет, решил применить принципиальное ограничение — пятно света будет двигаться только по вертикали. Стилистически этого вполне достаточно для той роли, которую должна играть эта сцена, и это позволило существенно ускорить код. Без ожидания обратного хода луча скорость работы даже вполне неплохая. Хотелось бы немного получше, но пока можно оставить в таком виде. В целом план добиваться 60 или хотя бы 30 FPS в сценах благополучно провалился — уже в двух сценах приходится рассчитывать на компромиссное решение.
Сделал обвязку сцены, можно считать её условно готовой для включения в демо. Итого 7 из 11 сцен есть. Но всё ещё не готовы две важные части, без которых не получается полноценного демо — титульный экран и приветствия.
Выполнил рутинную часть по подготовке пустых шаблонов исходников оставшихся сцен, добавлению их в сборочный процесс, incbin'ы в main, и так далее.
Поэкспериментировал в SDL прототипе со сценой лабиринта. Не всё получается так, как представлялось, но более-менее понятно, что в ней делать. Прототип пока требует доработки.
Также поэкспериментировал со сценой титульного экрана. Придумал для него эффект плавно скроллящихся полосок кубиков, чтобы разнообразить не очень интересный эффект появления надписи PET, и в целом направление работы по этой сцене также прояснилось — что нужно сделать, чтобы она смотрелось более-менее богато и интересно при довольно простых эффектах в ней. Реализовал задуманное в прототипе, теперь надо доработать табличку рандома и переписать сцену на ассемблер.
Завершённый прототип титульного экрана сам собой подсказал идею для ещё одной короткой сценки сразу после него, для усиления сюжетной линии демо: любой вариант тоннеля, неважно какой по способу реализации, который будет символизировать собственно отправку 'назад к PET'.
Сделал SDL-прототип звёздного неба в перспективе с гашением яркости пролетающих звёзд по таблице плотности пикселей — имитация эффекта варпа. Результат мне не понравился, он не создаёт то впечатление, которое требуется. Тогда я вспомнил про одну из ранее не вошедших в сценарий идей, пол из горизонтальных полосок в перспективе. Быстро сделал прототип такого эффекта на SDL, настроил таким образом, чтобы PET смог его отобразить (только одна полоска пикселей в пределах знакоместа), потом очень быстро переписал на ассемблер. Очень простенький эффект, по сути элементарная тайловая анимация. Всего 336 байт в сжатом виде, но должен прибавить ещё один маленький процентик солидности итоговому демо.
Занялся доделкой титульного экрана. Сгенерировал таблицу рандома для появления надписи PET довольно интересным способом: создал в GIMP градиент от чёрного до белого в 256 пикселей шириной, преобразовал в два цвета с дитерингом по Флойду, результат ещё немного дорисовал вручную так, чтобы плотность включения точек постепенно нарастала, сохранил в 256-цветный BMP, и с помощью HxD скопировал 256 байт растра в табличку рандома.
После завершения прототипа титульного экрана переписал его на ассемблер. Это было довольно утомительно, пришлось поломать голову над появлением надписи PET, которое не укладывалось в 60 FPS, и в целом при объективно простом коде потребовалось довольно много отладки. Осталась небольшая визуальная странность, не совпадающая с прототипом, но на данный момент я решил оставить всё как есть и считать сцену завершённой. 1317 байт в сжатом виде, память ещё есть, но в ней становится всё теснее. Остаётся ещё три сцены и пара килобайт памяти. Есть вероятность, что придётся поломать голову над оптимизацией по размеру или над дозагрузками.
Для проходной сцены с шахматной сеткой, исполняющей функцию разогрева, уже некоторое время назад возникла идея дополнения, делающего её более сюжетно содержательной, и сейчас, когда толком нет времени и памяти, я утвердился в мысли его реализовать. Это не должно занять слишком много времени, так как по сути это простая и хорошо пакующаяся анимация. Идея заключается в том, что в конце эффекта шахматной сетки происходит зум в клетки до тех пор, пока они не станут очень крупными, небольшой скролл, и на появившихся клетках стоят крупные фигуры пешки и ферзя. Появляется надпись MY MOVE CREEP (переиначенная отсылка к Робокопу) и пешка сдвигает ферзя. Пешка символизирует PET, ферзь — другие мощные платформы.
Ещё в самом начале работы над демо была задумана сценка с формой звуковой волны, соответствующей тому, что в данный момент играет CB2 (разные битпаттерны на разных частотах) — в духе волноформовых анализаторов чиптюн-музыки на YouTube. Позже я также решил, что в ней будут показываться greets. Однако, я долгое время не решался приступить к реализации, так как был непонятен алгоритм отрисовки волны без использования огромной кучи заранее просчитанных таблиц, и при этом эффект должен быть максимально быстрым, в 60 FPS. Думаю, это самый замороченный по устройству эффект во всём демо. И вот, видимо вследствие набранного на работе над предыдущими сценами опыта, решение само по себе начало вырисовываться в голове. Написал рабочий прототип эффекта, с алгоритмом без прекалка.
Сделал анимацию зума для шахматной сценки и сразу же написал код для 6502, без прототипа. Сначала нарисовал её вручную в Gale строго по сетке 8x8 (используется только пробел и закрашенный тайл), а потом посмотрел логику изменения и составил табличку по 4 байта на кадр — цвет начальной клетки, размер клетки и начальное смещение в первой клетке. Таким образом 12 кадров эффекта зума укладываются в 48 байт описания. Правда, развёрнутые циклы вывода (для избежания сечения с лучом) занимают значительно больше. Эффект способен работать на 60 кадрах в секунду, но для того, чтобы зритель мог успеть обратить на него внимание, анимацию придётся замедлить.
Переписал эффект формы волны на ассемблер, попутно нашёл и исправил ошибку в алгоритме. Эффект укладывается в 60 FPS при высоте 15 строк, но несмотря на плавность, изначально он выглядел довольно непрезентабельно — слишком статично. Добавил плавное падение амплитуды до нуля в паузах, подмешал синусоиду к значению ширины — так стало подинамичнее, смотрится поинтереснее.
Написал сразу на ассемблере эффект начального появления шахматного поля через попиксельное закрашивание по столбцам. Первые два варианта эффекта забраковал, они смотрелись сомнительно, затянуто и статично. Третий вариант вышел поинтереснее, свою функцию он выполняет, оставляю его. Сам по себе эффект укладывается в 60 FPS, но чтобы он не проскакивал слишком быстро, видимо придётся замедлить его вдвое.
Доделал шахматную сценку с фигурами: сделал элемент с печатью надписи MY MOVE CREEP, стирание экрана сцены по знакоместам в случайном порядке, вывод спрайта с маской. Сценка задумывалась как очень простая добавочная вставка, но по факту её реализация заняла много времени и сил, и прилично памяти — 1274 байт в сжатом виде.
Поработал над прототипом сцены с приветствиями — взял эффект из сцены вращения букв и изменил, как и хотел, прикинул минималистичный эффект пролетающих звёзд для улучшения динамики сцены. После этого доделал сцену уже для самого PET: добавил появление и исчезание центральной линии анализатора формы волны со вступительной и завершающей надписями, реализовал пролёт звёзд, которые начинают лететь вместе с появлением линии и прекращают лететь во время её стирания, реализовал печать приветствий.
Таким образом, ещё одна сцена готова. Осталось сделать ещё две, чуть ли не самые простые по коду, но дело с ними застряло на уровне прототипа надолго — до сих пор непонятно, как именно они должны выглядеть. Также нужна музыка и сборка. Тем временем, до пати осталась ровно неделя.
Оптимизировал код сцены с приветствиями по размеру за счёт отказа от некоторых развёрнутых циклов — скорости для 60 FPS хватает и без них. Это позволило уменьшить размер упакованного блока с 2586 до 1517 байт, что очень кстати в условиях стремительно заканчивающейся памяти. Также немного оптимизировал по размеру сцену с вращающимися буквами — самую большую по распакованному размеру. В сжатом виде она стала меньше всего на 4 байта, но на 404 байта в обычном. Это важно, так как в ОЗУ надо оставить свободной область именно такого размера.
Сейчас остаётся в лучшем случае два килобайта свободной памяти между окном распаковки и основной частью кода со сжатыми блоками сцен. Желательно уместить код оставшихся двух сцен в эти два килобайта. Памяти может не хватить как для самих сцен, так и для музыки — она может оказаться больше, чем по начальной оценке, тем более, что предполагаемая продолжительность демо успела вырасти. На этот случай я давно подготовил решение: размещать блоки сцен таким образом, чтобы при распаковке каждой следующей можно было затирать сжатые данные уже не нужной предыдущей. При этом потеряется возможность перезапуска демо без повторной загрузки, но в данном случае это приемлемое ограничение.
Сосредоточился на доделке прототипа сцены с лабиринтом и привёл её в более-менее приемлемый вид, без дополнительных усложнений. Я изначально думал сделать ещё две градации стен лабиринта — 3 на 3 тайла и 4 на 4 без заливки, но это разогревающая сцена, и затягивать её не стоит, а нужное впечатление она создаёт и без этих дополнительных деталей. Возможно, я всё же сделал бы их, если бы сроки не поджимали.
Начал заниматься реализацией сцены с лабиринтом на ассемблере.
Решил добавить ещё одну капельку контента для повышения градуса содержательности — малипусенькую сценку из списка изначально задуманных, банальные псевдографические помехи с постепенным изменением плотности. Место им найдётся перед сбросом или стоп-экраном — пока не решил, как лучше закончить демо. Объём сжатого кода 180 байт.
По сути в том или ином виде в окончательный сценарий демо попали все сцены из предварительного списка, кроме одной, наиболее интересной — зума в псевдофрактальные псевдографические горы. Он придуман только как идея, но никаких экспериментов реализации не было сделано. Некоторые достаточно банальные идеи объединились вместе в существующих сценах — например, классический тоннель и поле в перспективе стали варпом из полосок после названия, а сцена с каким-нибудь параллаксом, видимо, будет реализована в сцене шахматного поля.
Уменьшил высоту сцены шахматного поля и сценки с фигурами до 24-х строк, чтобы скрыть неудобную половинчатую строчку внизу, делающую эффект несимметричным. Написал развёрнутые циклы вывода горизонтального и вертикального варианта сетки. Для вертикального неизбежно сечение с лучом, но на клетчатом поле оно не очень заметно. Интересно, что в эмуляторе VICE сечение видно, а в MAME нет.
Доделал реализацию сцены лабиринта на ассемблере. В упакованном виде её блок кода занял 698 байт.
Вчера возникла новая идея для сцены с шахматным полем. Мне не нравилось, что этот эффект становится слишком похожим на эффект волн — сначала я пробовал для этой сцены разные вариации смещения клеток по синусоиде. В новом варианте эффект значительно проще, но это отличает его от волн — клетки просто сдвигаются рядами и столбцами в разных направлениях, с паузами между движениями. Также задумано два одиночных всплеска по синусоиде и скролл с параллаксом — примитивный эффект, но я хотел иметь в демо параллакс хоть в каком-то виде. Переделал прототип сцены по этой задумке, что с подбором параметров и паттернов заняло часов пять. Смотрится вроде терпимо, я очень устал от этой сцены, поэтому оставляю так. Переписал её на ассемблер, что заняло ещё час-полтора, проверил работу совместно со сценой с шахматными фигурами, чтобы переход между ними был незаметен.
Для успокоения творческого зуда набросал-таки приблизительный вариант эффекта с горами в SDL-прототипе. Смотрится плохо, неизвестно, можно ли сделать лучше и сколько времени это займёт, так что эта идея с чистой совестью остаётся нереализованной в списке возможных эффектов.
Код всех сцен демо в принципе готов. Несмотря на это, можно сказать, что пока сделано около 60% работы. Предстоит сделать ещё много чего: предварительную сборку (найти память и распихать по ней блоки сцен), отрендерить референсное видео, написать музыку в Reaper по референсному видео и перемонтировать видео под музыку, интегрировать музыку с демо (снова найти память, расставить маркеры, поправить тайминги сцен), подготовить финальную сборку. На всё это есть пять дней.
Сразу же занялся вопросом предварительной сборки. При первой попытке, без нахлёста буфера распаковки, не хватило около двух килобайт для нормальной работы сцен — надеюсь, что это не станет слишком большой проблемой. Запустил сборку без данных музыки, что сдвинуло код на 4 килобайта, и впервые смог посмотреть частично собранное демо. Оно доходило до сцены приветствий и падало — упакованная сцена приветствий не работала, но с обычной версией всё было нормально. Дело оказалось в вызове подпрограмм плеера музыки, код которого был размещён в отдельном сегменте. После перемещения кода в другой сегмент демо впервые выполнилось от начала до конца. По результату первого запуска возник план, что нужно сделать для утрамбовывания демо в память, а также несколько идей для небольших улучшений.
Немного оптимизировал сцену титульного экрана по распакованному размеру. Использовал компактный вариант распаковщика ZX02. Сделал два сдвига буфера распаковки, чтобы увеличение его размера происходило позже, чем чтение данных упакованной сцены с хвоста. Эти меры не помогли, всё равно буфер распаковки успевает наползти на сцену. Возможных решений много: оптимизация размера сцен, подзагрузка с диска (в демо есть два места, где можно остановить музыку), разбивка данных музыки на блоки, чтобы можно было затирать уже прозвучавшую часть. Проблема в выборе наиболее эффективных решений по затратам времени.
В поисках возможностей для оптимизации размера проверил статистику длин RLE-сжатия в анимации вращающихся букв, где на длину отводится всего три бита. Выяснилось, что длина 5 никогда не встречается в используемых данных. Сдвиг на один код позволил сэкономить 119 байт в распакованном виде и жалкие 19 байт в запакованном. Но так как эта оптимизация по сути бесплатная, сделать её было не лишним.
Под небольшое сокращение попала сцена с говорящим компьютером — сэмпл голоса самый очевидный кандидат на уменьшение. Я снизил частоту дискретизации, что не сильно сказалось на и без того низком качестве, но сэкономил около 700 байт на запакованной сцене. Также добавил придуманную вчера шутку, обыгрывающую и невнятное качество голоса, и рефлексию на само подобное демо — сначала слово POSSIBLE в слогане печатается как PASSABLE, потом стирается и заменяется правильным.
Нашёл наконец способ заставить CA65 печатать список фактических адресов для меток, чтобы ориентироваться в расположении блоков в памяти не наугад, а по конкретным цифрам. Цифры показывают, что проблем быть не должно, зазор между буфером и упакованным блоком в четыре с небольшим килобайта, однако сцена вращающихся букв падает. Причём смещение сжатого блока в памяти пониже на пару килобайт помогает, как это было бы при наползании буфера.
Ситуация непонятная, так как при запрете процедуры распаковки RLE-данных букв код не падает, перемещение же данных в начало блока хотя и даёт визуальный глюк в анимации, падения также не происходит, и никакие прочие данные сцены (картинки) не повреждаются. Самое странное, что при запрете записи в буфер распаковки падение всё равно происходит, то есть ошибки с записью за пределы буфера, которая могла бы портить память, нет. Возникло подозрение, что это какой-то баг в самой сцене, зависящий от расположения данных или кода в памяти.
Однако, никаких проблем в коде обнаружить не удалось, зато обнаружилось, что и все последующие сцены также глючат тем или иным образом. Я попробовал поперемещать код сцены без сжатия по всей памяти, в том числе собрать её в нужном адресе, и она работает. Теперь подозрение перешло на компрессор ZX02. Вспомнил, что он использует фиксированную локацию zeropage для своих переменных, а у PET почти вся zeropage забита системными переменными. Но изменение расположения переменных декомпрессора никакого эффекта не дало.
Поиск альтернативного упаковщика в очередной раз оказался очень утомительным и неприятным процессом — по таким ключевым словам поисковики не ищут, централизированного места для подобных вещей нет, вся информация находится в давних обсуждениях на форумах, с недействительными ссылками на упаковщики и распаковщики. Удалось найти пакер и депакер предыдущей версии компрессора, ZX0. Переделал сборку под него. ZX0 оказался ничуть не хуже по эффективности — упакованные блоки имеют тот же размер или на пару байт меньше. Однако, и с ним происходит точно такой же глюк, и вместо ясности добавились только сомнения. Попробовал сохранить из монитора распакованный блок и сравнить с исходным — есть отличие в пять байт, то есть под подозрением всё же (де)пакер. Или нет? Ведь порча нескольких байт в середине при корректных остальных маловероятна, не говоря про то, что пакеры-депакеры тестируются именно сравнением, и такая проблема едва ли могла пройти мимо авторов.
В размышлениях, что, помимо депакера, может портить несколько байт, попробовал запретить звуковую систему, и всё заработало. Дальнейшее разбирательство выявило, что дело не в обработчике прерывания, а в вызове плеера музыки. Как оказалось, хотя я предусмотрел в нём защиту от выполнения логики, пока указатель не будет установлен на валидные данные, переменная указателя располагалась в секции DATA, и оставалась неинициализированной — то есть код плеера пытался читать и писать неизвестно куда. Простейшая проблема, на поиск причины которой ушло несколько часов.
Сделал референсный рендер демо в MAME, через экспорт MNG файла и конверсию в AVI посредством AEX's MNG2AVI. В предварительном варианте, где я нажимаю кнопку в моменты синхронизации с музыкой, выходит 3 минуты 50 секунд — довольно неплохая длительность. К сожалению, простая задача перетащить получившийся файл в Reaper для использования в качестве референса обернулась очередным геморроем. MAME выдаёт странное разрешение 399 на 332, которые не принимают кодеки типа x264, а Reaper'у не нравятся loseless-кодеки типа Lagarith Loseless, поэтому пришлось пропустить видео через VirtualDub, кропнуть и перекодировать, и только тогда импортировать в Reaper. Создал и разметил по сценам проект для музыки, успеть написать которую нужно за три дня.
Далее провёл ряд полирующих действий, приводящих демо к более завершённому виду.
Начал писать музыку. Пока идёт крайне туго и заставляет сомневаться в возможности успеть закончить демо в срок. Хотя ранее в этом году я делал даже более длинный трек для демо Area 5150, и уложился в аналогичные сроки, так что чисто технически я на это способен. Подобрал темп (240 BPM), наметил части, набросал заготовки музыкальных цитат, нарезал видео под такты музыки.
Решил, что музыка будет заканчиваться на сцене с бампом. Добавил дополнительные простейшие звуковые эффекты в последующие две сцены: при прорисовке говорящего компьютера и в сцену с помехами, чтобы они смотрелись повеселее. Белый шум для сцены с шумом я сначала сделал традиционным однобитным, изредка выводился случайный бит на выходной бит динамика. Потом переделал, чтобы сдвиговый регистр играл восемь бит, пока рисуются байты в экран, это позволило поднять плотность шума, чтобы он звучал более похоже на нормальный белый шум с небольшим изменением громкости — это не то, на что PET способен по умолчанию, так что тоже своего рода демоэффект.
Работа и раньше шла в разное время суток, часто начиная с ночи, а теперь идёт финальный марафон, и частота записей в сутки не успевает за изменениями в проекте. Впрочем, по музыке записывать в дневник особо нечего — обычное ковыряние аккордов и импровизаций, глядя на видео, и попытка отрафинировать наименее неудачные кусочки в хоть какую-то идею.
Переорганизовал каналы в Reaper'е более удобным образом. Сделал первый пробный экспорт трека, который на начало суток представлял собой простейшую рыбу из темпа и баса, и впал в уныние — он не конвертируется вторым методом, слишком много уникальных сочетаний питча и длительности, а первый метод выдаёт почти 9 килобайт, при том, что собственно мелодии в треке пока отсутствуют. План заранее синхронизировать демо с рыбой пока проваливается, так как в таком размере трек в память не влезет, а если заняться решением этой проблемы, не останется времени на музыку. Способы решения этой проблемы есть, но время сильно поджимает.
В связи с недостатком времени саундтрек сочиняется по принципу 'абы как', любая идея годится, даже если это очередное банальное ковыряние в Ля миноре. Тем не менее, пока более-менее пригодно к использованию только 40 секунд из необходимых 220.
К середине дня таймлайн проекта заполнился отрывками разной степени проработанности и сочетаемости, которые в целом покрывают все сцены, но сильно меняют их тайминги, а значит, к задачам сочинения музыки и впихивания её в память добавляется больше работы по синхронизации. Новый тестовый экспорт показал, что теперь трек не конвертируется вообще никаким из ранее подготовленных методов, видимо по причине использования слайдов и вибрато в треке. Придётся как-то дорабатывать конвертер.
Во второй половине дня не работал, не позволило самочувствие. Как не старался начать в этот раз работу сильно заранее, чтобы избежать марафонов и нервного перенапряжения, она всё равно растягивается до самого крайнего срока, и это тяжеловато чисто психологически.
На начало суток была условно-готова ровно половина трека и рыба без мелодий (с импровизационными набросками в записи с MIDI-клавиатуры) для второй половины. Кое-как впихал в титульном экране отсылку на Назад в Будущее — она никак не хотела ложиться в контекст мелодии. Вышло далеко не так удачно, как с Doom в Area 5150. Зато научился играть эту мелодию на гитаре.
Нарочно не придумаешь, но в самый неподходящий момент возникла неожиданная проблема. Во время работы заметил, что у компьютера не прекращает гудеть вентилятор, а любые сайты открываются очень долго. Попробовал запустить AVZ, и она сразу же закрывается. Попробовал установить Касперский, и его установка оказалась заблокирована. Стало ясно, что умудрился очень своевременно поймать вирус — такого не случалось уже много лет. Вчера таких симптомов не было, а сегодня ставил только XPadder, видимо файл был заражён. Пришлось потратить пару часов на решение проблемы путём сканирования системного раздела с ESET SysRescue Live CD, так как было непонятно, какого рода вирус и чем он грозит, да и торможение системы мешало работать. Оказалось, что это некий криптомайнер.
Вирусная проблема возникла, когда трек приближался к завершению, во время сканирования оставшиеся фрагменты устаканивались в голове, и к восьми утра, после того как продолжение работы стало возможно, саундтрек пришёл в более-менее пригодное для использования состояние, хотя и очень сомнительное. Это чистой воды мэшап, а не осмысленная композиция, сплошь построенный на стандартных ходах.
Заглянул в расписание событий, чтобы прикинуть, каковы шансы всё же успеть на конкурс. Компо начнётся вечером в субботу, таким образом есть около двух дней помимо сегодняшнего на решение двух сложных проблем: впихуемости невпихуемого (слишком большого по размеру трека) и допиливания таймингов демо. Но два дня — это без гарантий, впритык к показу. Нужно попытаться подготовить хоть какой-то результат хотя бы до утра субботы и далее держать руку на пульсе.
Исходный поток музыкальных данных имеет размер около 17 килобайт и жмётся ZX02 в 3.6 килобайта. При этом в демо зарезервировано около 4 килобайт под данные музыки, и возможно получится добавить ещё около двух. То есть возможен вариант с распаковкой фрагментов трека между сценами в буфер воспроизведения, но в текущем виде получается около 10 фрагментов, это много и неудобно.
Переписал упаковщик потока, который составляет табличку питчей (два метода: PM1 — питч и форма волны в табличке, длительность кадра хранится в потоке; PM2 — в табличке также хранится и длительность), таким образом, чтобы он заменял редко встречающиеся питчи ближайшими похожими, это позволило утрамбовать трек в 10 килобайт. Это дало оценку, какой размер получится, если дотрамбовать до PM2: 6.6 килобайт. Столько всё равно не влезет, что было проверено простой вставкой пустого блока такого размера вместо данных музыки в демо. Эксперимент показал, что без дальнейшей оптимизации сцен на музыку есть только только 5.5 килобайта. Похоже, что в любом случае придётся нарезать на фрагменты и паковать по отдельности, либо же делать дозагрузки. Также есть вариант изобрести какой-то способ потоковой упаковки, не требующий буфера под распаковку.
Провёл тесты по эффективности упаковщиков в надежде выиграть лишнюю пару сотен байт. Результаты в байтах на все 15 упакованных сцен:
В текущем варианте демо используется ZX02, и это оптимальное решение — дело в том, что у Exomizer и ZX0 распаковщики больше, и весь выигрыш от их применения сводится на нет.
Нашёл интересный компрессор — Huffmunch, который пакует Хаффманом и позволяет распаковывать поток байт за байтом, примерно за 260 тактов за байт, без необходимости в буфере для распакованных данных. Но код распаковщика занимает 330 байт, а данные музыки упаковываются либо из 17 килобайт исходного потока в 6.5 килобайт, либо из 10 килобайт сжатого PM1 потока в 5.5 килобайт плюс 256 байт таблички. То есть опять нужно 6.2-6.5 килобайта, а есть только 5.5, нужно где-то изыскать целый килобайт или более. Запомнил как возможную опцию.
Ещё немного доработал упаковщик потока, реализовал оптимизацию наиболее редко встречающихся питчей в треке до заданного порога, что позволило добиться сжатия данных методом PM2. Но для того, чтобы применение этого метода стало возможным для данного трека, порог нужно задавать очень высокий, в результате музыка звучит крайне глючно. К сожалению, это решение не подходит.
Решил попробовать вариант с паковкой музыки, предварительно сжатой PM1, в ZX02 для распаковки в буфер по кускам, в небольших паузах между сценами. Реализовал в PETCB2 экспорт трека по частям — ещё один маркер, закрывающий текущий файл экспорта и открывающий новый с тем же именем и порядковым номером блока в нём. Порезал трек на семь частей, упаковал в PM1, потом упаковал блоки в ZX02. Размер наибольшего куска в PM1 — 2082 байта, размер всех кусков в ZX02 — 3106 байт. При этом первый блок размером 421 байт (2064 байта в PM1) нужно распаковать в буфер ещё до первой сцены, что сдвигает зазор распаковки на сжатый размер блока. По цифрам вроде всё сходится, в таком виде должно влезть, но получится ли это на практике, и насколько плохо будет звучать (с паузами на распаковку, трек изначально хоть и с разбивками, но без потери темпа) — можно узнать только экспериментальным путём. По крайней мере, процесс синхронизации музыки с действиями при таком подходе должен немного упроститься, синхронизировать действие надо в пределах блока.
В целом в этот и в два предыдущих дня настроение по поводу перспектив проекта было очень упадническое. Сначала казалось, что успеть с сочинением музыки совершенно невозможно и ничего не получится, и что столько сил и времени потрачено без желаемого результата. Потом обнаружилось, что музыка уже как-то написалась, но новая проблема размера также казалась непреодолимой. Только к концу дня появились обнадёживающие цифры и определённый план действий.
Вчера дело остановилось на том, что распределённая по памяти и распаковываемая из ZX02 музыка звучит глючно. Проверил экспортированный фрагмент в плеере обычного потока, который выходит из PETCB2 — звучит нормально. Вероятно проблема в плеере или оптимизаторе редких питчей.
Изучение вопроса показало две проблемы: оптимизатор уникальных питчей глючит, портит звук, и в самом плеере есть непонятная проблема, из-за которой он не работает при расположении музыкальных данных ниже определённого адреса ($064a звука нет, $0e4a звук есть). Вторая проблема не так важна, чтобы тратить на неё время, а первая увеличивает объём данных до печальных цифр: 4.5 килобайт на все упакованные ZX02 блоки и 2.2 килобайта буфер распаковки. То есть 6.7 килобайт, либо 5.9 килобайт без учёта размера первого упакованного блока. В таком виде цифры снова не бьются.
Попробовал улучшить оптимизатор питчей, но судя по всему, не работает сама концепция: с художественной точки зрения мне важны плавные слайды в ударных, а оптимизатору они кажутся лишними, и он упрощает их настолько, что вместо удара получается просто гудок. Снова возникло ощущение, что эту проблему без внедрения дозагрузок (которые ещё надо отладить) преодолеть не удастся.
Однако, повезло: в процессе экспериментов обнаружил, что теперь, когда трек разделён на короткие фрагменты, к ним снова возможно применить метод PM2 без оптимизации питчей. Правда, цифры всё равно не сходились: все архивы 4776 байт, без первого 3982 байта, размер буфера 1638 байт, то есть нужно 5.6 килобайт. Дополнительное искривление извилин родило ещё одну оптимизацию, 4-байтная таблица для PM2 была переработана в 3-байтную, что дало другие цифры: все архивы 4667 байта, без первого 3885 байт, размер буфера 1476 байт. Это уже 5.3 килобайта, цифры снова начали биться.
В таком варианте демо собралось и отработало от начала до конца, пока с музыкой в нескольких первых частях. Правда, в сцене со вращением букв снова отвалился эффект шума — эту проблему я уже решал ранее. Вероятно, опять что-то портит память, возможно доработанный плеер музыки.
В какой-то момент в попытке разобраться с глюком в плеере и заодно оптимизировать код он полностью перестал работать, и бэкапа рабочего исходника, находящегося в активном редактировании, не сохранилось. Я потратил некоторое время, пытаясь восстановить работу, но дело оказалось не в привнесённой новой ошибке, а в старой — очередной раз двухбайтовая переменная была по ошибке объявлена однобайтовой, и в определённой конфигурации памяти это работало, но не в другой (затиралась соседняя переменная). Это решило проблему сломанной сцены с вращением букв, и демо отработало до конца с музыкой уже во всех частях — то есть проблема влезания в память вроде бы решена.
Теперь главная проблема: синхронизация действия. Также я заметил, что в сцене с приветствиями подглючивает отрисовка формы волны, но не настолько критично, чтобы нельзя было оставить как есть для party version (не рисуется левый фронт периода). Оставлю этот вопрос до момента, когда надо будет синхронизировать музыку в этой сцене — сейчас эта сцена почти вдвое короче, чем музыкальный фрагмент для неё. Тем временем, осталось шесть с половиной часов до открытия фестиваля.
Взялся за синхронизацию. В отличие от большей части разработки, где тесты велись в WinVICE за исключением критичных к скорости участков кода, синхронизация делается сразу в MAME, чтобы видеть правильную скорость (с возможным торможением) и слышать правильный звук, хотя каждый тест и требует ручного набора команды RUN для запуска, причём не в любой момент, а после паузы в несколько секунд, пока PRG-файл загружается в память эмулятора каким-то фоновым процессом.
Почему-то первой начал синхронизировать сцену лабиринта, хотя это не имеет принципиального значения. В ней обошлось без маркеров — я заранее предусмотрел настройки количества строк и длительности задержек в каждом шаге сцены. Добавил ожидание окончания фрагмента трека, чтобы переход на следующую часть не происходил до того, как доиграет текущий фрагмент.
Следующий блок сцен — шахматное поле и шахматная сцена. Поле синхронизируется по началу сцены и далее не потребовало маркеров — случайно удалось достаточно точно попасть таймингами в темп музыки. Синхронизация по маркерам начинается в шахматной сценке, по ним происходит появление и стирание надписи, ход фигуры, стирание экрана.
Во избежание глюков экспорта после добавления серии маркеров в трек приходится экспортировать его от начала до конца, что занимает столько времени, сколько он звучит (убираю звук и смотрю YouTube). Есть не очень приятный момент с тем, что после каждого экспорта размер данных слегка меняется, так как внутреннее время секвенсера привязано к эмулируемым кадрам в 1/60 секунды. Из-за этого демо иногда не работает, так как памяти впритык — пришлось на время синхронизации исключить из сборки блок сцены с говорящим компьютером. Это всё решаемо, но на это нужно время, а пока в приоритете довести демо до пригодного к показу состояния.
Далее засинхронизировал эффект матрицы и таймлайн. В матрице пришлось подкрутить длительности падения символов и подобрать начальное псевдослучайное число, чтобы на экране не оставались нестёртые буквы надписей. Титульный экран засинхронизировался по сути сам, добавил только маркер завершения эффекта варпа. Половина длительности демо на этом этапе была засинхронизирована.
Сцена с приветствиями. Глюк отрисовки удалось скрыть малой кровью, методом научного тыка, хотя выглядит странно — рисуются периоды гораздо меньшей ширины, чем разрешено в коде (запрещены, чтобы не было глюков). Однако, форма рисуемой волны в принципе выглядит странно. На этой и следующей сцене дело застряло очень надолго, пробовал разные тайминги и доработки логики отрисовки волны. Она подглючивает, но из-за скорости изменения формы это не бросается в глаза, хорошо заметно только на паузе, так что оставляю так.
Для сцены морфинга сдвинул начало фрагмента на начало слайда вверх и ускорил зарисовку экрана полосками, чтобы они успели появиться до начала маркеров смены картинки. Также поменял порядок зарисовки, сначала было сверху вниз — сделал снизу вверх, как бы застёгивающаяся молния, логично под конец демо. Так как у сцен морфинга и бампа общий фрагмент музыки, выставил тайминги и для бампа, подобрав позицию маркера завершения сцены.
Последней синхронизация делалась в сценах вращения букв и волн, которые также разделяют общий фрагмент музыки. Делалась уже хоть как-нибудь, и видимо поэтому при пробной сборке съехала на один маркер позже.
Начал пробовать собирать демо обратно в единое целое. Опять не влезает в память, есть мелкие проблемы по синхронизации в разных местах. Видимо часть из них так и останется, для лучшей синхронизации нужно больше времени и сил, и возможно больше изменений по музыке. Вырисовывается перспектива пост-патийной финальной версии.
Фестиваль открывается через десять минут, а я продолжаю сборку. По результатам очередного просмотра предварительной версии внёс ещё несколько правок в синхронизацию и в саму музыку. В том числе замедлил зум шахматной доски, так как из-за привязки к тактам музыки там образовалась длительная пауза.
Потратил около часа на попытки оптимизировать встречный горизонтальный скролл на титульном экране, он подтормаживает из-за музыки. Удалось немного ускорить код, но полностью проблему это не решило. Откладывается на потом. Поправил тайминги, чтобы звук слайда лучше совпадал с разлётом надписей вверх-вниз.
Сделал очередной прогон. Синхронизация вроде терпимая. Подкрутил ещё эффект исчезания шахматной сцены, замедлил вдвое, чтобы не был слишком долгий чёрный экран.
С места событий мне позвонил CHRV, вместе с Shuran33 представляющий меня на пати, их помощью я заручился днём ранее на случай, если работу придётся присылать вплотную к дедлайну, и спросил, под какую платформу будет работа — дему ждут и беспокоятся. Я тоже жду. Очень устал, идёт двенадцатый час работы.
Из-за удлинённого слайда объединённый фрагмент музыки для двух последних сцен стал слишком большим, и я решил разделить его на два, чтобы выиграть ещё немного места для маневра. Таким образом музыка делится на восемь частей вместо семи.
Для окончательной сборки решил натурально пошаманить — из-за нестабильного размера экспорта музыки и деления её на части есть возможность подобрать куски наименьшего размера из нескольких разных экспортов одного и того же трека. Учитывая, что счёт идёт на байты, сотня байт выигрыша не будет лишней. Собственно, после нескольких итераций такого шаманства, для сборки со всеми сценами не хватило ещё около 150 байт. Безусловно, столько и даже больше можно найти, но на данный момент стоит задача найти их максимально быстро. Поэтому решил пойти на довольно радикальные меры и ещё раз урезать качество голоса в сцене с говорящим компьютером, до совсем уже неприличного уровня, даже с запасом в сотню байт. В пост-патийной версии можно немного улучшить обратно.
Сделал очередной прогон, вроде как завершающий. Всё сработало, всё смотрится более-менее, но забыл про ожидание маркера синхронизации в новоотрезанном заключительном кусочке музыки. Поправил, сделал ещё один завешающий прогон, сразу же с рендером — вдруг прокатит нашару, и не понадобится делать ещё раз. Вроде прокатило!
Возникла новая проблема: как отрендерить видео для показа. Собственно процесс рендера был уже отработан — из MAME в MNG+WAV, из MNG+WAV через MNG2AVI в AVI, далее в VirtualDub. Однако, MAME выдаёт очень странную по пропорциям и размеру картинку, с большим бордюром и нечётными размерами. На скорую руку подобрал параметры ресайза во что-то более-менее удобоваримое. Получился такой процесс: сначала из MNG 399 на 332 в AVI с кодеком Lagarith Loseless, потом в VirtualDub кроп в 384 на 270, потом апскейл до 1536 на 1080 и леттербокс до 1920 на 1080, и уже потом энкодинг в x264. Жуть.
Следующая проблема — синхронизация звука с видео. В эмуляторе она достаточно точная, нет оснований ему не доверять, а вот в записи после перекодировок рассинхрон до секунды, что сильно портит впечатление. Подбор параметров потребовал несколько рендеров, к счастью, они идут примерно две минуты, и в видео есть места, по которым легко проверить попадание звука в видеоряд. Помогла банальная задержка звука в 500 миллисекунд.
Собрал паки — маленький без эмулятора для загрузки через events, большой с эмулятором (сборка MAME весит 600+ мегабайт) через приватное хранилище, залил копию видео на YouTube с приватным доступом, и в 15:00 (случайно совпало) отправил работу. До показа больше суток, но сил, да и свободного времени, на допиливание уже не осталось — всё равно до идеала в таком темпе не довести.
Надо ещё записать ожидания перед компо. Конечно хотелось бы победить, но объективно — платформа очень редкая, отечественному зрителю малопонятная, демо же очень олдскульное и без сложных эффектов, и третий раз в ту же реку с той же формулой наверное уже не войти. Я практически не сомневаюсь, что LowEnd (Combined) будет объединён с чем-то, скорее всего с ZX Spectrum'ом, так как едва ли будет ещё две работы для нетрадиционных для наших краёв платформ. Победа возможна при неявке соперников, если не будет сильных работ, а так, если компо объединят. а спектрумисты поднажали и выкатят что-то на уровне прошлых лет, конечно первые места уйдут им. Тогда может быть попаду в тройку или чуть ниже. Посмотрим.
По поводу мыслей о будущих работах — хотел бы я проделать что-то подобное снова? В данный момент хочется послать такие затеи куда подальше, очень уж много времени и сил на это уходит, too old for this shit и всё такое. Но через некоторое время это настроение, конечно, может измениться.
Заглянул на events — там показывается количество уже принятых работ — и увидел цифры, обнуляющие мои вчерашние предположения. В LowEnd Combined уже есть три работы, а вот в ZX Spectrum Demo пока всего одна. Так как я не один такой, кто допиливает работу до самой последней минуты, и это в принципе универсальная мировая традиция, думаю, к моменту показа работ станет побольше. Ткну пальцем в небо, назову цифру пять. Значит об объединении компо речь уже не идёт, и всё зависит только от того, насколько хорошие работы выставят конкуренты. С тремя работами в компо есть неплохой-таки шанс войти в первую тройку. Правда, этим планам угрожает платформа БК, для неё пока тоже представлено одно демо, и там шансы на пополнение категории ещё двумя работами до времени показа, как мне кажется, невелики — есть вероятность, что конкурс БК будет слит с LowEnd Combined.
Так или иначе, главное соображение в том, что если допустить, что я сделал неплохую работу, но она не возьмёт призовых мест — значит призовые места заняли работы ещё лучше моей, и значит в целом выиграла демосцена, потому что вышло много новых крутых работ, которые обязательно вдохновят авторов на новые свершения.
Начало показа работ традиционно задержалось, и даже перевыполнило традиционный план, но посмотреть трансляцию было очень интересно. Мои прогнозы об объединении несколько компо в одно не оправдались, а вот неявка соперника в каком-то смысла оправдалась — конечно, любые работы уже само по себе круто, и тем более для Вектора — я и сам своего рода Векторист (сидел на нём год в 1996). Но масштаб конкурирующих работ в LowEnd Combined был просто не тот, и к сожалению, это та победа, гордиться которой придётся с оговорками: не вырвана в тяжёлой борьбе, а начислена просто по факту явки в спортивной форме. Буду утешаться тем, что это победа над собой и сомнениями в собственных силах.
Пати в целом очень удалось. Масштаб по понятным причинам поменьше, чем в 2019, но всё равно, очень много работ, много интересного. Как минимум, были отличные демы для БК и ZX, одна дема-интра для PC мирового, я бы сказал, уровня, и компьютерные платформы были представлены разнообразно. Жаль, что не хватило сил поучаствовать в олдскул музыке, хотя бы бипером — есть ещё удивительные биты в битовницах. Жаль, что не осилил челлендж 'сделать работу' И 'приехать на пати'. Жаль, что из головы вылетело много имён, которые хотелось бы добавить в приветствия.
В завершение — немного технической информации. Демо состоит из отдельных сцен, упакованных в отдельные архивы, и также отдельно упакованы фрагменты саундтрека для соответствующих сцен. Фрагменты расположены в порядке, обратном порядку показа, и распаковываются по мере показа, перезаписывая уже не нужные упакованные данные. Для музыки в младших адресах памяти, до всех архивов, выделен буфер в 1470 байт, по размеру наибольшего распакованного фрагмента музыки. Для сцен выделяется буфер в конце памяти, его размер и расположение трижды сдвигаются для увеличения размера буфера, по размеру самой крупной сцены в группе: сначала это 2544 байта для сцен матрицы и таймлайна, потом 5120 байт для сцен от титульного экрана до шахматной сценки, и далее 7088 байт для оставшихся сцен.
Размер в байтах блоков сцен до и после упаковки (исходные сцены включают все нужные им для работы буфера, реально кода там поменьше), а также их расположение в памяти в порядке распаковки:
03.10
Отвлекался от проекта на выходные. Тем временем возникли некоторые идеи по оптимизации эффекта волн. Однако, более эффективная оптимизация, не требующая переделок, была найдена методом тыка — оказалось, что можно отказаться от учёта младшего байта в дельте указателя внутри цикла расчёта фрагмента синусоиды, и таким образом делать 8-битное сложение вместо 16-битного. Впрочем, этого всё равно не хватает для 60 FPS в NTSC, но без ожидания обратного хода луча выглядит довольно плавно.
Провёл эксперименты с экраном логотипа в прототипе на C, чтобы оценить, работают ли задумки. Результат пока сомнительный.
06.10
Снова отвлекался, на этот раз на начало другого большого проекта, где нужно было провести подготовительные работы. Разумеется, в условиях поджимающих сроков теперь тянет заниматься им, запала на два дела не хватает, как и часов в сутках. Но пытаюсь продолжить работу. Собрал даты и начал рисовать таймлайн для второй сцены демо, перед названием.
Тем временем, до CAFe осталось две недели ровно. Учитывая, что демо готово от силы на треть, возможность поездки на пати видимо отпадает, так как это минус несколько дней до дедлайна, и само завершение проекта в срок тоже под очень большим вопросом.
07.10
Отладил эффект таймлайна в прототипе на SDL, задал анимацию таймлайна. В работу пошёл первый же вариант, так как времени на раздумывание и переделки при отсутствии критерия для определения улучшения всё равно нет. Переписал сцену на ассемблер, работает без тормозов в 60 FPS. Тормозить потенциально мог бы скролл, без развёрнутых циклов он даже в 50 FPS имел шанс не уложиться в кадр при неудачном размещении опкодов цикла (всего один лишний такт внутри цикла меняет дело). Получившаяся сцена в принципе смотрится неплохо. Плюс ещё одна зелёная строчка в списке сцен и 20 секунд к продолжительности демо. Количество готовых сцен превысило 50%, готовность же демо в целом от этой цифры пока далека.
Провёл ревизию списка всех оставшихся пяти сцен, выделил задачи для решения. Проблема в том, что среди оставшихся сцен в четырёх непонятно, что именно делать, и в двух непонятно как именно делать. Также понял, что пора в срочном порядке решать вопрос сборки разрозненных сцен в общий бинарник, а для ускорения работ делать список задач конкретно на каждый день.
Согласно списку из двух пунктов, первым делом занялся вопросом сборки. Пакет CC65 обладает огромной гибкостью, но такие простые вещи, как сборка фрагментов кода в отдельные бинарники в один и тот же адрес в нём настраивается нетривиально, а документация обширна из запутана. Так как тратить много времени на решение такой тривиальной задачи было бы неразумно, решил собирать сцены в отдельные файлы очень корявым, но рабочим методом — для каждой из сцен делается дополнительный main.s с инклюдом общего кода и кода сцены. Собрал таким образом имеющиеся сцены и оценил масштабы катастрофы. Готовые шесть сцен занимают 30125 байт, что, конечно, никак не влезет в память PET 4032. Но изначально расчёт сделан на упаковку, и сжатые по отдельности при помощи apultra сцены занимают 14210 байт, а несжатый размер самой большой из сцен — с вращающимися буквами — 7616 байт. Пока всё помещается, и даёт надежды на успешное влезание оставшихся сцен в память. Хотя, конечно, хорошо бы немного подуменьшить самые большие сцены.
08.10
Запуск упакованных сцен сходу не заработал. Похоже, что в распаковщик aplib всё-таки закралась ошибка. Чтобы не тратить время на её поиски, я решил попробовать альтернативный пакер, и быстрый поиск в Google выдал мне ZX02, свежую разработку этого года. Он даже немного эффективнее, что позволило сэкономить 374 байта на сжатых сценах, довольно быстрый, и главное — он работает.
По непонятной причине в сцене с вращающимися буквами после распаковки почему-то не работал эффект шума на картинках, хотя в версии обычной всё в порядке. После пересборок он заработал, возможно сначала что-то сползло в адресах общего для всех частей кода. В целом же система сборки заработала, но в паре сцен также нашлись проблемы при возврате из них. В сцене матрицы в одном месте была проблема в выделении byte вместо word под переменную, что портило последующий код. В сцене морфинга был потерян pla в цикле, из-за чего портился стек.
Реализовал в прототипе целочисленный вариант бампа с 16 градациями яркости. В 60 FPS смотрелось бы не так уж плохо. Сделал наивную реализацию для 6502, работает, но очень тормозит. Пока непонятно, как избавиться от нескольких моментов в вычислениях и добиться хотя бы 20 FPS.
Возникло более детальное видение, как именно должна выглядеть технически простая сцена с лабиринтом, но пока к работе над ней не приступил.
09.10
Так как времени на грамотное улучшение и оптимизацию алгоритма бампа нет, решил применить принципиальное ограничение — пятно света будет двигаться только по вертикали. Стилистически этого вполне достаточно для той роли, которую должна играть эта сцена, и это позволило существенно ускорить код. Без ожидания обратного хода луча скорость работы даже вполне неплохая. Хотелось бы немного получше, но пока можно оставить в таком виде. В целом план добиваться 60 или хотя бы 30 FPS в сценах благополучно провалился — уже в двух сценах приходится рассчитывать на компромиссное решение.
Сделал обвязку сцены, можно считать её условно готовой для включения в демо. Итого 7 из 11 сцен есть. Но всё ещё не готовы две важные части, без которых не получается полноценного демо — титульный экран и приветствия.
Выполнил рутинную часть по подготовке пустых шаблонов исходников оставшихся сцен, добавлению их в сборочный процесс, incbin'ы в main, и так далее.
Поэкспериментировал в SDL прототипе со сценой лабиринта. Не всё получается так, как представлялось, но более-менее понятно, что в ней делать. Прототип пока требует доработки.
Также поэкспериментировал со сценой титульного экрана. Придумал для него эффект плавно скроллящихся полосок кубиков, чтобы разнообразить не очень интересный эффект появления надписи PET, и в целом направление работы по этой сцене также прояснилось — что нужно сделать, чтобы она смотрелось более-менее богато и интересно при довольно простых эффектах в ней. Реализовал задуманное в прототипе, теперь надо доработать табличку рандома и переписать сцену на ассемблер.
10.10
Завершённый прототип титульного экрана сам собой подсказал идею для ещё одной короткой сценки сразу после него, для усиления сюжетной линии демо: любой вариант тоннеля, неважно какой по способу реализации, который будет символизировать собственно отправку 'назад к PET'.
Сделал SDL-прототип звёздного неба в перспективе с гашением яркости пролетающих звёзд по таблице плотности пикселей — имитация эффекта варпа. Результат мне не понравился, он не создаёт то впечатление, которое требуется. Тогда я вспомнил про одну из ранее не вошедших в сценарий идей, пол из горизонтальных полосок в перспективе. Быстро сделал прототип такого эффекта на SDL, настроил таким образом, чтобы PET смог его отобразить (только одна полоска пикселей в пределах знакоместа), потом очень быстро переписал на ассемблер. Очень простенький эффект, по сути элементарная тайловая анимация. Всего 336 байт в сжатом виде, но должен прибавить ещё один маленький процентик солидности итоговому демо.
Занялся доделкой титульного экрана. Сгенерировал таблицу рандома для появления надписи PET довольно интересным способом: создал в GIMP градиент от чёрного до белого в 256 пикселей шириной, преобразовал в два цвета с дитерингом по Флойду, результат ещё немного дорисовал вручную так, чтобы плотность включения точек постепенно нарастала, сохранил в 256-цветный BMP, и с помощью HxD скопировал 256 байт растра в табличку рандома.
После завершения прототипа титульного экрана переписал его на ассемблер. Это было довольно утомительно, пришлось поломать голову над появлением надписи PET, которое не укладывалось в 60 FPS, и в целом при объективно простом коде потребовалось довольно много отладки. Осталась небольшая визуальная странность, не совпадающая с прототипом, но на данный момент я решил оставить всё как есть и считать сцену завершённой. 1317 байт в сжатом виде, память ещё есть, но в ней становится всё теснее. Остаётся ещё три сцены и пара килобайт памяти. Есть вероятность, что придётся поломать голову над оптимизацией по размеру или над дозагрузками.
Для проходной сцены с шахматной сеткой, исполняющей функцию разогрева, уже некоторое время назад возникла идея дополнения, делающего её более сюжетно содержательной, и сейчас, когда толком нет времени и памяти, я утвердился в мысли его реализовать. Это не должно занять слишком много времени, так как по сути это простая и хорошо пакующаяся анимация. Идея заключается в том, что в конце эффекта шахматной сетки происходит зум в клетки до тех пор, пока они не станут очень крупными, небольшой скролл, и на появившихся клетках стоят крупные фигуры пешки и ферзя. Появляется надпись MY MOVE CREEP (переиначенная отсылка к Робокопу) и пешка сдвигает ферзя. Пешка символизирует PET, ферзь — другие мощные платформы.
Ещё в самом начале работы над демо была задумана сценка с формой звуковой волны, соответствующей тому, что в данный момент играет CB2 (разные битпаттерны на разных частотах) — в духе волноформовых анализаторов чиптюн-музыки на YouTube. Позже я также решил, что в ней будут показываться greets. Однако, я долгое время не решался приступить к реализации, так как был непонятен алгоритм отрисовки волны без использования огромной кучи заранее просчитанных таблиц, и при этом эффект должен быть максимально быстрым, в 60 FPS. Думаю, это самый замороченный по устройству эффект во всём демо. И вот, видимо вследствие набранного на работе над предыдущими сценами опыта, решение само по себе начало вырисовываться в голове. Написал рабочий прототип эффекта, с алгоритмом без прекалка.
11.10
Сделал анимацию зума для шахматной сценки и сразу же написал код для 6502, без прототипа. Сначала нарисовал её вручную в Gale строго по сетке 8x8 (используется только пробел и закрашенный тайл), а потом посмотрел логику изменения и составил табличку по 4 байта на кадр — цвет начальной клетки, размер клетки и начальное смещение в первой клетке. Таким образом 12 кадров эффекта зума укладываются в 48 байт описания. Правда, развёрнутые циклы вывода (для избежания сечения с лучом) занимают значительно больше. Эффект способен работать на 60 кадрах в секунду, но для того, чтобы зритель мог успеть обратить на него внимание, анимацию придётся замедлить.
Переписал эффект формы волны на ассемблер, попутно нашёл и исправил ошибку в алгоритме. Эффект укладывается в 60 FPS при высоте 15 строк, но несмотря на плавность, изначально он выглядел довольно непрезентабельно — слишком статично. Добавил плавное падение амплитуды до нуля в паузах, подмешал синусоиду к значению ширины — так стало подинамичнее, смотрится поинтереснее.
Написал сразу на ассемблере эффект начального появления шахматного поля через попиксельное закрашивание по столбцам. Первые два варианта эффекта забраковал, они смотрелись сомнительно, затянуто и статично. Третий вариант вышел поинтереснее, свою функцию он выполняет, оставляю его. Сам по себе эффект укладывается в 60 FPS, но чтобы он не проскакивал слишком быстро, видимо придётся замедлить его вдвое.
12.10
Доделал шахматную сценку с фигурами: сделал элемент с печатью надписи MY MOVE CREEP, стирание экрана сцены по знакоместам в случайном порядке, вывод спрайта с маской. Сценка задумывалась как очень простая добавочная вставка, но по факту её реализация заняла много времени и сил, и прилично памяти — 1274 байт в сжатом виде.
Поработал над прототипом сцены с приветствиями — взял эффект из сцены вращения букв и изменил, как и хотел, прикинул минималистичный эффект пролетающих звёзд для улучшения динамики сцены. После этого доделал сцену уже для самого PET: добавил появление и исчезание центральной линии анализатора формы волны со вступительной и завершающей надписями, реализовал пролёт звёзд, которые начинают лететь вместе с появлением линии и прекращают лететь во время её стирания, реализовал печать приветствий.
Таким образом, ещё одна сцена готова. Осталось сделать ещё две, чуть ли не самые простые по коду, но дело с ними застряло на уровне прототипа надолго — до сих пор непонятно, как именно они должны выглядеть. Также нужна музыка и сборка. Тем временем, до пати осталась ровно неделя.
13.10
Оптимизировал код сцены с приветствиями по размеру за счёт отказа от некоторых развёрнутых циклов — скорости для 60 FPS хватает и без них. Это позволило уменьшить размер упакованного блока с 2586 до 1517 байт, что очень кстати в условиях стремительно заканчивающейся памяти. Также немного оптимизировал по размеру сцену с вращающимися буквами — самую большую по распакованному размеру. В сжатом виде она стала меньше всего на 4 байта, но на 404 байта в обычном. Это важно, так как в ОЗУ надо оставить свободной область именно такого размера.
Сейчас остаётся в лучшем случае два килобайта свободной памяти между окном распаковки и основной частью кода со сжатыми блоками сцен. Желательно уместить код оставшихся двух сцен в эти два килобайта. Памяти может не хватить как для самих сцен, так и для музыки — она может оказаться больше, чем по начальной оценке, тем более, что предполагаемая продолжительность демо успела вырасти. На этот случай я давно подготовил решение: размещать блоки сцен таким образом, чтобы при распаковке каждой следующей можно было затирать сжатые данные уже не нужной предыдущей. При этом потеряется возможность перезапуска демо без повторной загрузки, но в данном случае это приемлемое ограничение.
14.10
Сосредоточился на доделке прототипа сцены с лабиринтом и привёл её в более-менее приемлемый вид, без дополнительных усложнений. Я изначально думал сделать ещё две градации стен лабиринта — 3 на 3 тайла и 4 на 4 без заливки, но это разогревающая сцена, и затягивать её не стоит, а нужное впечатление она создаёт и без этих дополнительных деталей. Возможно, я всё же сделал бы их, если бы сроки не поджимали.
Начал заниматься реализацией сцены с лабиринтом на ассемблере.
15.10
Решил добавить ещё одну капельку контента для повышения градуса содержательности — малипусенькую сценку из списка изначально задуманных, банальные псевдографические помехи с постепенным изменением плотности. Место им найдётся перед сбросом или стоп-экраном — пока не решил, как лучше закончить демо. Объём сжатого кода 180 байт.
По сути в том или ином виде в окончательный сценарий демо попали все сцены из предварительного списка, кроме одной, наиболее интересной — зума в псевдофрактальные псевдографические горы. Он придуман только как идея, но никаких экспериментов реализации не было сделано. Некоторые достаточно банальные идеи объединились вместе в существующих сценах — например, классический тоннель и поле в перспективе стали варпом из полосок после названия, а сцена с каким-нибудь параллаксом, видимо, будет реализована в сцене шахматного поля.
Уменьшил высоту сцены шахматного поля и сценки с фигурами до 24-х строк, чтобы скрыть неудобную половинчатую строчку внизу, делающую эффект несимметричным. Написал развёрнутые циклы вывода горизонтального и вертикального варианта сетки. Для вертикального неизбежно сечение с лучом, но на клетчатом поле оно не очень заметно. Интересно, что в эмуляторе VICE сечение видно, а в MAME нет.
Доделал реализацию сцены лабиринта на ассемблере. В упакованном виде её блок кода занял 698 байт.
16.10
Вчера возникла новая идея для сцены с шахматным полем. Мне не нравилось, что этот эффект становится слишком похожим на эффект волн — сначала я пробовал для этой сцены разные вариации смещения клеток по синусоиде. В новом варианте эффект значительно проще, но это отличает его от волн — клетки просто сдвигаются рядами и столбцами в разных направлениях, с паузами между движениями. Также задумано два одиночных всплеска по синусоиде и скролл с параллаксом — примитивный эффект, но я хотел иметь в демо параллакс хоть в каком-то виде. Переделал прототип сцены по этой задумке, что с подбором параметров и паттернов заняло часов пять. Смотрится вроде терпимо, я очень устал от этой сцены, поэтому оставляю так. Переписал её на ассемблер, что заняло ещё час-полтора, проверил работу совместно со сценой с шахматными фигурами, чтобы переход между ними был незаметен.
Для успокоения творческого зуда набросал-таки приблизительный вариант эффекта с горами в SDL-прототипе. Смотрится плохо, неизвестно, можно ли сделать лучше и сколько времени это займёт, так что эта идея с чистой совестью остаётся нереализованной в списке возможных эффектов.
Код всех сцен демо в принципе готов. Несмотря на это, можно сказать, что пока сделано около 60% работы. Предстоит сделать ещё много чего: предварительную сборку (найти память и распихать по ней блоки сцен), отрендерить референсное видео, написать музыку в Reaper по референсному видео и перемонтировать видео под музыку, интегрировать музыку с демо (снова найти память, расставить маркеры, поправить тайминги сцен), подготовить финальную сборку. На всё это есть пять дней.
Сразу же занялся вопросом предварительной сборки. При первой попытке, без нахлёста буфера распаковки, не хватило около двух килобайт для нормальной работы сцен — надеюсь, что это не станет слишком большой проблемой. Запустил сборку без данных музыки, что сдвинуло код на 4 килобайта, и впервые смог посмотреть частично собранное демо. Оно доходило до сцены приветствий и падало — упакованная сцена приветствий не работала, но с обычной версией всё было нормально. Дело оказалось в вызове подпрограмм плеера музыки, код которого был размещён в отдельном сегменте. После перемещения кода в другой сегмент демо впервые выполнилось от начала до конца. По результату первого запуска возник план, что нужно сделать для утрамбовывания демо в память, а также несколько идей для небольших улучшений.
Немного оптимизировал сцену титульного экрана по распакованному размеру. Использовал компактный вариант распаковщика ZX02. Сделал два сдвига буфера распаковки, чтобы увеличение его размера происходило позже, чем чтение данных упакованной сцены с хвоста. Эти меры не помогли, всё равно буфер распаковки успевает наползти на сцену. Возможных решений много: оптимизация размера сцен, подзагрузка с диска (в демо есть два места, где можно остановить музыку), разбивка данных музыки на блоки, чтобы можно было затирать уже прозвучавшую часть. Проблема в выборе наиболее эффективных решений по затратам времени.
17.10
В поисках возможностей для оптимизации размера проверил статистику длин RLE-сжатия в анимации вращающихся букв, где на длину отводится всего три бита. Выяснилось, что длина 5 никогда не встречается в используемых данных. Сдвиг на один код позволил сэкономить 119 байт в распакованном виде и жалкие 19 байт в запакованном. Но так как эта оптимизация по сути бесплатная, сделать её было не лишним.
Под небольшое сокращение попала сцена с говорящим компьютером — сэмпл голоса самый очевидный кандидат на уменьшение. Я снизил частоту дискретизации, что не сильно сказалось на и без того низком качестве, но сэкономил около 700 байт на запакованной сцене. Также добавил придуманную вчера шутку, обыгрывающую и невнятное качество голоса, и рефлексию на само подобное демо — сначала слово POSSIBLE в слогане печатается как PASSABLE, потом стирается и заменяется правильным.
Нашёл наконец способ заставить CA65 печатать список фактических адресов для меток, чтобы ориентироваться в расположении блоков в памяти не наугад, а по конкретным цифрам. Цифры показывают, что проблем быть не должно, зазор между буфером и упакованным блоком в четыре с небольшим килобайта, однако сцена вращающихся букв падает. Причём смещение сжатого блока в памяти пониже на пару килобайт помогает, как это было бы при наползании буфера.
Ситуация непонятная, так как при запрете процедуры распаковки RLE-данных букв код не падает, перемещение же данных в начало блока хотя и даёт визуальный глюк в анимации, падения также не происходит, и никакие прочие данные сцены (картинки) не повреждаются. Самое странное, что при запрете записи в буфер распаковки падение всё равно происходит, то есть ошибки с записью за пределы буфера, которая могла бы портить память, нет. Возникло подозрение, что это какой-то баг в самой сцене, зависящий от расположения данных или кода в памяти.
Однако, никаких проблем в коде обнаружить не удалось, зато обнаружилось, что и все последующие сцены также глючат тем или иным образом. Я попробовал поперемещать код сцены без сжатия по всей памяти, в том числе собрать её в нужном адресе, и она работает. Теперь подозрение перешло на компрессор ZX02. Вспомнил, что он использует фиксированную локацию zeropage для своих переменных, а у PET почти вся zeropage забита системными переменными. Но изменение расположения переменных декомпрессора никакого эффекта не дало.
Поиск альтернативного упаковщика в очередной раз оказался очень утомительным и неприятным процессом — по таким ключевым словам поисковики не ищут, централизированного места для подобных вещей нет, вся информация находится в давних обсуждениях на форумах, с недействительными ссылками на упаковщики и распаковщики. Удалось найти пакер и депакер предыдущей версии компрессора, ZX0. Переделал сборку под него. ZX0 оказался ничуть не хуже по эффективности — упакованные блоки имеют тот же размер или на пару байт меньше. Однако, и с ним происходит точно такой же глюк, и вместо ясности добавились только сомнения. Попробовал сохранить из монитора распакованный блок и сравнить с исходным — есть отличие в пять байт, то есть под подозрением всё же (де)пакер. Или нет? Ведь порча нескольких байт в середине при корректных остальных маловероятна, не говоря про то, что пакеры-депакеры тестируются именно сравнением, и такая проблема едва ли могла пройти мимо авторов.
В размышлениях, что, помимо депакера, может портить несколько байт, попробовал запретить звуковую систему, и всё заработало. Дальнейшее разбирательство выявило, что дело не в обработчике прерывания, а в вызове плеера музыки. Как оказалось, хотя я предусмотрел в нём защиту от выполнения логики, пока указатель не будет установлен на валидные данные, переменная указателя располагалась в секции DATA, и оставалась неинициализированной — то есть код плеера пытался читать и писать неизвестно куда. Простейшая проблема, на поиск причины которой ушло несколько часов.
Сделал референсный рендер демо в MAME, через экспорт MNG файла и конверсию в AVI посредством AEX's MNG2AVI. В предварительном варианте, где я нажимаю кнопку в моменты синхронизации с музыкой, выходит 3 минуты 50 секунд — довольно неплохая длительность. К сожалению, простая задача перетащить получившийся файл в Reaper для использования в качестве референса обернулась очередным геморроем. MAME выдаёт странное разрешение 399 на 332, которые не принимают кодеки типа x264, а Reaper'у не нравятся loseless-кодеки типа Lagarith Loseless, поэтому пришлось пропустить видео через VirtualDub, кропнуть и перекодировать, и только тогда импортировать в Reaper. Создал и разметил по сценам проект для музыки, успеть написать которую нужно за три дня.
Далее провёл ряд полирующих действий, приводящих демо к более завершённому виду.
- Немного оптимизировал эффект появления надписи PET на титульном экране по скорости. Это не изменило объём упакованного блока сцены.
- Заметил, что в сцене приветствий эффект всё же работает на 30 FPS. Так как неизвестно, удастся ли его ускорить, пока сделал отрисовку волны на 30 FPS, а звёзды и приветствия на 60 FPS. Также удлинил нарастание и спадание плотности полоски и добавил паузу, чтобы можно было успеть комфортно прочитать надпись в начале и конце.
- Вместо сброса, остановки, или выхода в Бейсик (который невозможен при распаковке нахлёстом) решил закончить демо зацикливанием на финальной сцене с шумом, в связи с чем полностью её переделал, добавив эффект смутно проявляющейся в шуме надписи END. Смотрится гораздо интереснее, добавило 251 байт к сжатому блоку сцены.
- Также доработал мелкую проблему в сцене с шахматным полем и переделал эффект пропадания сцены с познакоместного, который смотрелся слишком просто, на четвертушки знакоместа, псевдографикой.
18.10
Начал писать музыку. Пока идёт крайне туго и заставляет сомневаться в возможности успеть закончить демо в срок. Хотя ранее в этом году я делал даже более длинный трек для демо Area 5150, и уложился в аналогичные сроки, так что чисто технически я на это способен. Подобрал темп (240 BPM), наметил части, набросал заготовки музыкальных цитат, нарезал видео под такты музыки.
Решил, что музыка будет заканчиваться на сцене с бампом. Добавил дополнительные простейшие звуковые эффекты в последующие две сцены: при прорисовке говорящего компьютера и в сцену с помехами, чтобы они смотрелись повеселее. Белый шум для сцены с шумом я сначала сделал традиционным однобитным, изредка выводился случайный бит на выходной бит динамика. Потом переделал, чтобы сдвиговый регистр играл восемь бит, пока рисуются байты в экран, это позволило поднять плотность шума, чтобы он звучал более похоже на нормальный белый шум с небольшим изменением громкости — это не то, на что PET способен по умолчанию, так что тоже своего рода демоэффект.
19.10
Работа и раньше шла в разное время суток, часто начиная с ночи, а теперь идёт финальный марафон, и частота записей в сутки не успевает за изменениями в проекте. Впрочем, по музыке записывать в дневник особо нечего — обычное ковыряние аккордов и импровизаций, глядя на видео, и попытка отрафинировать наименее неудачные кусочки в хоть какую-то идею.
Переорганизовал каналы в Reaper'е более удобным образом. Сделал первый пробный экспорт трека, который на начало суток представлял собой простейшую рыбу из темпа и баса, и впал в уныние — он не конвертируется вторым методом, слишком много уникальных сочетаний питча и длительности, а первый метод выдаёт почти 9 килобайт, при том, что собственно мелодии в треке пока отсутствуют. План заранее синхронизировать демо с рыбой пока проваливается, так как в таком размере трек в память не влезет, а если заняться решением этой проблемы, не останется времени на музыку. Способы решения этой проблемы есть, но время сильно поджимает.
В связи с недостатком времени саундтрек сочиняется по принципу 'абы как', любая идея годится, даже если это очередное банальное ковыряние в Ля миноре. Тем не менее, пока более-менее пригодно к использованию только 40 секунд из необходимых 220.
К середине дня таймлайн проекта заполнился отрывками разной степени проработанности и сочетаемости, которые в целом покрывают все сцены, но сильно меняют их тайминги, а значит, к задачам сочинения музыки и впихивания её в память добавляется больше работы по синхронизации. Новый тестовый экспорт показал, что теперь трек не конвертируется вообще никаким из ранее подготовленных методов, видимо по причине использования слайдов и вибрато в треке. Придётся как-то дорабатывать конвертер.
Во второй половине дня не работал, не позволило самочувствие. Как не старался начать в этот раз работу сильно заранее, чтобы избежать марафонов и нервного перенапряжения, она всё равно растягивается до самого крайнего срока, и это тяжеловато чисто психологически.
20.10
На начало суток была условно-готова ровно половина трека и рыба без мелодий (с импровизационными набросками в записи с MIDI-клавиатуры) для второй половины. Кое-как впихал в титульном экране отсылку на Назад в Будущее — она никак не хотела ложиться в контекст мелодии. Вышло далеко не так удачно, как с Doom в Area 5150. Зато научился играть эту мелодию на гитаре.
Нарочно не придумаешь, но в самый неподходящий момент возникла неожиданная проблема. Во время работы заметил, что у компьютера не прекращает гудеть вентилятор, а любые сайты открываются очень долго. Попробовал запустить AVZ, и она сразу же закрывается. Попробовал установить Касперский, и его установка оказалась заблокирована. Стало ясно, что умудрился очень своевременно поймать вирус — такого не случалось уже много лет. Вчера таких симптомов не было, а сегодня ставил только XPadder, видимо файл был заражён. Пришлось потратить пару часов на решение проблемы путём сканирования системного раздела с ESET SysRescue Live CD, так как было непонятно, какого рода вирус и чем он грозит, да и торможение системы мешало работать. Оказалось, что это некий криптомайнер.
Вирусная проблема возникла, когда трек приближался к завершению, во время сканирования оставшиеся фрагменты устаканивались в голове, и к восьми утра, после того как продолжение работы стало возможно, саундтрек пришёл в более-менее пригодное для использования состояние, хотя и очень сомнительное. Это чистой воды мэшап, а не осмысленная композиция, сплошь построенный на стандартных ходах.
Заглянул в расписание событий, чтобы прикинуть, каковы шансы всё же успеть на конкурс. Компо начнётся вечером в субботу, таким образом есть около двух дней помимо сегодняшнего на решение двух сложных проблем: впихуемости невпихуемого (слишком большого по размеру трека) и допиливания таймингов демо. Но два дня — это без гарантий, впритык к показу. Нужно попытаться подготовить хоть какой-то результат хотя бы до утра субботы и далее держать руку на пульсе.
Исходный поток музыкальных данных имеет размер около 17 килобайт и жмётся ZX02 в 3.6 килобайта. При этом в демо зарезервировано около 4 килобайт под данные музыки, и возможно получится добавить ещё около двух. То есть возможен вариант с распаковкой фрагментов трека между сценами в буфер воспроизведения, но в текущем виде получается около 10 фрагментов, это много и неудобно.
Переписал упаковщик потока, который составляет табличку питчей (два метода: PM1 — питч и форма волны в табличке, длительность кадра хранится в потоке; PM2 — в табличке также хранится и длительность), таким образом, чтобы он заменял редко встречающиеся питчи ближайшими похожими, это позволило утрамбовать трек в 10 килобайт. Это дало оценку, какой размер получится, если дотрамбовать до PM2: 6.6 килобайт. Столько всё равно не влезет, что было проверено простой вставкой пустого блока такого размера вместо данных музыки в демо. Эксперимент показал, что без дальнейшей оптимизации сцен на музыку есть только только 5.5 килобайта. Похоже, что в любом случае придётся нарезать на фрагменты и паковать по отдельности, либо же делать дозагрузки. Также есть вариант изобрести какой-то способ потоковой упаковки, не требующий буфера под распаковку.
Провёл тесты по эффективности упаковщиков в надежде выиграть лишнюю пару сотен байт. Результаты в байтах на все 15 упакованных сцен:
Exomizer 20295
ZX0 20640
ZX02 20679
ApUltra 21159
В текущем варианте демо используется ZX02, и это оптимальное решение — дело в том, что у Exomizer и ZX0 распаковщики больше, и весь выигрыш от их применения сводится на нет.
Нашёл интересный компрессор — Huffmunch, который пакует Хаффманом и позволяет распаковывать поток байт за байтом, примерно за 260 тактов за байт, без необходимости в буфере для распакованных данных. Но код распаковщика занимает 330 байт, а данные музыки упаковываются либо из 17 килобайт исходного потока в 6.5 килобайт, либо из 10 килобайт сжатого PM1 потока в 5.5 килобайт плюс 256 байт таблички. То есть опять нужно 6.2-6.5 килобайта, а есть только 5.5, нужно где-то изыскать целый килобайт или более. Запомнил как возможную опцию.
Ещё немного доработал упаковщик потока, реализовал оптимизацию наиболее редко встречающихся питчей в треке до заданного порога, что позволило добиться сжатия данных методом PM2. Но для того, чтобы применение этого метода стало возможным для данного трека, порог нужно задавать очень высокий, в результате музыка звучит крайне глючно. К сожалению, это решение не подходит.
Решил попробовать вариант с паковкой музыки, предварительно сжатой PM1, в ZX02 для распаковки в буфер по кускам, в небольших паузах между сценами. Реализовал в PETCB2 экспорт трека по частям — ещё один маркер, закрывающий текущий файл экспорта и открывающий новый с тем же именем и порядковым номером блока в нём. Порезал трек на семь частей, упаковал в PM1, потом упаковал блоки в ZX02. Размер наибольшего куска в PM1 — 2082 байта, размер всех кусков в ZX02 — 3106 байт. При этом первый блок размером 421 байт (2064 байта в PM1) нужно распаковать в буфер ещё до первой сцены, что сдвигает зазор распаковки на сжатый размер блока. По цифрам вроде всё сходится, в таком виде должно влезть, но получится ли это на практике, и насколько плохо будет звучать (с паузами на распаковку, трек изначально хоть и с разбивками, но без потери темпа) — можно узнать только экспериментальным путём. По крайней мере, процесс синхронизации музыки с действиями при таком подходе должен немного упроститься, синхронизировать действие надо в пределах блока.
В целом в этот и в два предыдущих дня настроение по поводу перспектив проекта было очень упадническое. Сначала казалось, что успеть с сочинением музыки совершенно невозможно и ничего не получится, и что столько сил и времени потрачено без желаемого результата. Потом обнаружилось, что музыка уже как-то написалась, но новая проблема размера также казалась непреодолимой. Только к концу дня появились обнадёживающие цифры и определённый план действий.
21.10
Вчера дело остановилось на том, что распределённая по памяти и распаковываемая из ZX02 музыка звучит глючно. Проверил экспортированный фрагмент в плеере обычного потока, который выходит из PETCB2 — звучит нормально. Вероятно проблема в плеере или оптимизаторе редких питчей.
Изучение вопроса показало две проблемы: оптимизатор уникальных питчей глючит, портит звук, и в самом плеере есть непонятная проблема, из-за которой он не работает при расположении музыкальных данных ниже определённого адреса ($064a звука нет, $0e4a звук есть). Вторая проблема не так важна, чтобы тратить на неё время, а первая увеличивает объём данных до печальных цифр: 4.5 килобайт на все упакованные ZX02 блоки и 2.2 килобайта буфер распаковки. То есть 6.7 килобайт, либо 5.9 килобайт без учёта размера первого упакованного блока. В таком виде цифры снова не бьются.
Попробовал улучшить оптимизатор питчей, но судя по всему, не работает сама концепция: с художественной точки зрения мне важны плавные слайды в ударных, а оптимизатору они кажутся лишними, и он упрощает их настолько, что вместо удара получается просто гудок. Снова возникло ощущение, что эту проблему без внедрения дозагрузок (которые ещё надо отладить) преодолеть не удастся.
Однако, повезло: в процессе экспериментов обнаружил, что теперь, когда трек разделён на короткие фрагменты, к ним снова возможно применить метод PM2 без оптимизации питчей. Правда, цифры всё равно не сходились: все архивы 4776 байт, без первого 3982 байта, размер буфера 1638 байт, то есть нужно 5.6 килобайт. Дополнительное искривление извилин родило ещё одну оптимизацию, 4-байтная таблица для PM2 была переработана в 3-байтную, что дало другие цифры: все архивы 4667 байта, без первого 3885 байт, размер буфера 1476 байт. Это уже 5.3 килобайта, цифры снова начали биться.
В таком варианте демо собралось и отработало от начала до конца, пока с музыкой в нескольких первых частях. Правда, в сцене со вращением букв снова отвалился эффект шума — эту проблему я уже решал ранее. Вероятно, опять что-то портит память, возможно доработанный плеер музыки.
В какой-то момент в попытке разобраться с глюком в плеере и заодно оптимизировать код он полностью перестал работать, и бэкапа рабочего исходника, находящегося в активном редактировании, не сохранилось. Я потратил некоторое время, пытаясь восстановить работу, но дело оказалось не в привнесённой новой ошибке, а в старой — очередной раз двухбайтовая переменная была по ошибке объявлена однобайтовой, и в определённой конфигурации памяти это работало, но не в другой (затиралась соседняя переменная). Это решило проблему сломанной сцены с вращением букв, и демо отработало до конца с музыкой уже во всех частях — то есть проблема влезания в память вроде бы решена.
Теперь главная проблема: синхронизация действия. Также я заметил, что в сцене с приветствиями подглючивает отрисовка формы волны, но не настолько критично, чтобы нельзя было оставить как есть для party version (не рисуется левый фронт периода). Оставлю этот вопрос до момента, когда надо будет синхронизировать музыку в этой сцене — сейчас эта сцена почти вдвое короче, чем музыкальный фрагмент для неё. Тем временем, осталось шесть с половиной часов до открытия фестиваля.
Взялся за синхронизацию. В отличие от большей части разработки, где тесты велись в WinVICE за исключением критичных к скорости участков кода, синхронизация делается сразу в MAME, чтобы видеть правильную скорость (с возможным торможением) и слышать правильный звук, хотя каждый тест и требует ручного набора команды RUN для запуска, причём не в любой момент, а после паузы в несколько секунд, пока PRG-файл загружается в память эмулятора каким-то фоновым процессом.
Почему-то первой начал синхронизировать сцену лабиринта, хотя это не имеет принципиального значения. В ней обошлось без маркеров — я заранее предусмотрел настройки количества строк и длительности задержек в каждом шаге сцены. Добавил ожидание окончания фрагмента трека, чтобы переход на следующую часть не происходил до того, как доиграет текущий фрагмент.
Следующий блок сцен — шахматное поле и шахматная сцена. Поле синхронизируется по началу сцены и далее не потребовало маркеров — случайно удалось достаточно точно попасть таймингами в темп музыки. Синхронизация по маркерам начинается в шахматной сценке, по ним происходит появление и стирание надписи, ход фигуры, стирание экрана.
Во избежание глюков экспорта после добавления серии маркеров в трек приходится экспортировать его от начала до конца, что занимает столько времени, сколько он звучит (убираю звук и смотрю YouTube). Есть не очень приятный момент с тем, что после каждого экспорта размер данных слегка меняется, так как внутреннее время секвенсера привязано к эмулируемым кадрам в 1/60 секунды. Из-за этого демо иногда не работает, так как памяти впритык — пришлось на время синхронизации исключить из сборки блок сцены с говорящим компьютером. Это всё решаемо, но на это нужно время, а пока в приоритете довести демо до пригодного к показу состояния.
Далее засинхронизировал эффект матрицы и таймлайн. В матрице пришлось подкрутить длительности падения символов и подобрать начальное псевдослучайное число, чтобы на экране не оставались нестёртые буквы надписей. Титульный экран засинхронизировался по сути сам, добавил только маркер завершения эффекта варпа. Половина длительности демо на этом этапе была засинхронизирована.
Сцена с приветствиями. Глюк отрисовки удалось скрыть малой кровью, методом научного тыка, хотя выглядит странно — рисуются периоды гораздо меньшей ширины, чем разрешено в коде (запрещены, чтобы не было глюков). Однако, форма рисуемой волны в принципе выглядит странно. На этой и следующей сцене дело застряло очень надолго, пробовал разные тайминги и доработки логики отрисовки волны. Она подглючивает, но из-за скорости изменения формы это не бросается в глаза, хорошо заметно только на паузе, так что оставляю так.
Для сцены морфинга сдвинул начало фрагмента на начало слайда вверх и ускорил зарисовку экрана полосками, чтобы они успели появиться до начала маркеров смены картинки. Также поменял порядок зарисовки, сначала было сверху вниз — сделал снизу вверх, как бы застёгивающаяся молния, логично под конец демо. Так как у сцен морфинга и бампа общий фрагмент музыки, выставил тайминги и для бампа, подобрав позицию маркера завершения сцены.
Последней синхронизация делалась в сценах вращения букв и волн, которые также разделяют общий фрагмент музыки. Делалась уже хоть как-нибудь, и видимо поэтому при пробной сборке съехала на один маркер позже.
Начал пробовать собирать демо обратно в единое целое. Опять не влезает в память, есть мелкие проблемы по синхронизации в разных местах. Видимо часть из них так и останется, для лучшей синхронизации нужно больше времени и сил, и возможно больше изменений по музыке. Вырисовывается перспектива пост-патийной финальной версии.
Фестиваль открывается через десять минут, а я продолжаю сборку. По результатам очередного просмотра предварительной версии внёс ещё несколько правок в синхронизацию и в саму музыку. В том числе замедлил зум шахматной доски, так как из-за привязки к тактам музыки там образовалась длительная пауза.
Потратил около часа на попытки оптимизировать встречный горизонтальный скролл на титульном экране, он подтормаживает из-за музыки. Удалось немного ускорить код, но полностью проблему это не решило. Откладывается на потом. Поправил тайминги, чтобы звук слайда лучше совпадал с разлётом надписей вверх-вниз.
Сделал очередной прогон. Синхронизация вроде терпимая. Подкрутил ещё эффект исчезания шахматной сцены, замедлил вдвое, чтобы не был слишком долгий чёрный экран.
С места событий мне позвонил CHRV, вместе с Shuran33 представляющий меня на пати, их помощью я заручился днём ранее на случай, если работу придётся присылать вплотную к дедлайну, и спросил, под какую платформу будет работа — дему ждут и беспокоятся. Я тоже жду. Очень устал, идёт двенадцатый час работы.
Из-за удлинённого слайда объединённый фрагмент музыки для двух последних сцен стал слишком большим, и я решил разделить его на два, чтобы выиграть ещё немного места для маневра. Таким образом музыка делится на восемь частей вместо семи.
Для окончательной сборки решил натурально пошаманить — из-за нестабильного размера экспорта музыки и деления её на части есть возможность подобрать куски наименьшего размера из нескольких разных экспортов одного и того же трека. Учитывая, что счёт идёт на байты, сотня байт выигрыша не будет лишней. Собственно, после нескольких итераций такого шаманства, для сборки со всеми сценами не хватило ещё около 150 байт. Безусловно, столько и даже больше можно найти, но на данный момент стоит задача найти их максимально быстро. Поэтому решил пойти на довольно радикальные меры и ещё раз урезать качество голоса в сцене с говорящим компьютером, до совсем уже неприличного уровня, даже с запасом в сотню байт. В пост-патийной версии можно немного улучшить обратно.
Сделал очередной прогон, вроде как завершающий. Всё сработало, всё смотрится более-менее, но забыл про ожидание маркера синхронизации в новоотрезанном заключительном кусочке музыки. Поправил, сделал ещё один завешающий прогон, сразу же с рендером — вдруг прокатит нашару, и не понадобится делать ещё раз. Вроде прокатило!
Возникла новая проблема: как отрендерить видео для показа. Собственно процесс рендера был уже отработан — из MAME в MNG+WAV, из MNG+WAV через MNG2AVI в AVI, далее в VirtualDub. Однако, MAME выдаёт очень странную по пропорциям и размеру картинку, с большим бордюром и нечётными размерами. На скорую руку подобрал параметры ресайза во что-то более-менее удобоваримое. Получился такой процесс: сначала из MNG 399 на 332 в AVI с кодеком Lagarith Loseless, потом в VirtualDub кроп в 384 на 270, потом апскейл до 1536 на 1080 и леттербокс до 1920 на 1080, и уже потом энкодинг в x264. Жуть.
Следующая проблема — синхронизация звука с видео. В эмуляторе она достаточно точная, нет оснований ему не доверять, а вот в записи после перекодировок рассинхрон до секунды, что сильно портит впечатление. Подбор параметров потребовал несколько рендеров, к счастью, они идут примерно две минуты, и в видео есть места, по которым легко проверить попадание звука в видеоряд. Помогла банальная задержка звука в 500 миллисекунд.
Собрал паки — маленький без эмулятора для загрузки через events, большой с эмулятором (сборка MAME весит 600+ мегабайт) через приватное хранилище, залил копию видео на YouTube с приватным доступом, и в 15:00 (случайно совпало) отправил работу. До показа больше суток, но сил, да и свободного времени, на допиливание уже не осталось — всё равно до идеала в таком темпе не довести.
Надо ещё записать ожидания перед компо. Конечно хотелось бы победить, но объективно — платформа очень редкая, отечественному зрителю малопонятная, демо же очень олдскульное и без сложных эффектов, и третий раз в ту же реку с той же формулой наверное уже не войти. Я практически не сомневаюсь, что LowEnd (Combined) будет объединён с чем-то, скорее всего с ZX Spectrum'ом, так как едва ли будет ещё две работы для нетрадиционных для наших краёв платформ. Победа возможна при неявке соперников, если не будет сильных работ, а так, если компо объединят. а спектрумисты поднажали и выкатят что-то на уровне прошлых лет, конечно первые места уйдут им. Тогда может быть попаду в тройку или чуть ниже. Посмотрим.
По поводу мыслей о будущих работах — хотел бы я проделать что-то подобное снова? В данный момент хочется послать такие затеи куда подальше, очень уж много времени и сил на это уходит, too old for this shit и всё такое. Но через некоторое время это настроение, конечно, может измениться.
22.10
Заглянул на events — там показывается количество уже принятых работ — и увидел цифры, обнуляющие мои вчерашние предположения. В LowEnd Combined уже есть три работы, а вот в ZX Spectrum Demo пока всего одна. Так как я не один такой, кто допиливает работу до самой последней минуты, и это в принципе универсальная мировая традиция, думаю, к моменту показа работ станет побольше. Ткну пальцем в небо, назову цифру пять. Значит об объединении компо речь уже не идёт, и всё зависит только от того, насколько хорошие работы выставят конкуренты. С тремя работами в компо есть неплохой-таки шанс войти в первую тройку. Правда, этим планам угрожает платформа БК, для неё пока тоже представлено одно демо, и там шансы на пополнение категории ещё двумя работами до времени показа, как мне кажется, невелики — есть вероятность, что конкурс БК будет слит с LowEnd Combined.
Так или иначе, главное соображение в том, что если допустить, что я сделал неплохую работу, но она не возьмёт призовых мест — значит призовые места заняли работы ещё лучше моей, и значит в целом выиграла демосцена, потому что вышло много новых крутых работ, которые обязательно вдохновят авторов на новые свершения.
23.10
Начало показа работ традиционно задержалось, и даже перевыполнило традиционный план, но посмотреть трансляцию было очень интересно. Мои прогнозы об объединении несколько компо в одно не оправдались, а вот неявка соперника в каком-то смысла оправдалась — конечно, любые работы уже само по себе круто, и тем более для Вектора — я и сам своего рода Векторист (сидел на нём год в 1996). Но масштаб конкурирующих работ в LowEnd Combined был просто не тот, и к сожалению, это та победа, гордиться которой придётся с оговорками: не вырвана в тяжёлой борьбе, а начислена просто по факту явки в спортивной форме. Буду утешаться тем, что это победа над собой и сомнениями в собственных силах.
Пати в целом очень удалось. Масштаб по понятным причинам поменьше, чем в 2019, но всё равно, очень много работ, много интересного. Как минимум, были отличные демы для БК и ZX, одна дема-интра для PC мирового, я бы сказал, уровня, и компьютерные платформы были представлены разнообразно. Жаль, что не хватило сил поучаствовать в олдскул музыке, хотя бы бипером — есть ещё удивительные биты в битовницах. Жаль, что не осилил челлендж 'сделать работу' И 'приехать на пати'. Жаль, что из головы вылетело много имён, которые хотелось бы добавить в приветствия.
В завершение — немного технической информации. Демо состоит из отдельных сцен, упакованных в отдельные архивы, и также отдельно упакованы фрагменты саундтрека для соответствующих сцен. Фрагменты расположены в порядке, обратном порядку показа, и распаковываются по мере показа, перезаписывая уже не нужные упакованные данные. Для музыки в младших адресах памяти, до всех архивов, выделен буфер в 1470 байт, по размеру наибольшего распакованного фрагмента музыки. Для сцен выделяется буфер в конце памяти, его размер и расположение трижды сдвигаются для увеличения размера буфера, по размеру самой крупной сцены в группе: сначала это 2544 байта для сцен матрицы и таймлайна, потом 5120 байт для сцен от титульного экрана до шахматной сценки, и далее 7088 байт для оставшихся сцен.
Размер в байтах блоков сцен до и после упаковки (исходные сцены включают все нужные им для работы буфера, реально кода там поменьше), а также их расположение в памяти в порядке распаковки:
исходный zx02
music_0 1468 789
e_scroll 289 94
e_matrix 1240 464
e_timeline 2528 1023
music_1 802 603
e_title 5119 1353
e_floor 1320 336
music_2 508 330
e_maze 1656 697
music_3 1297 839
e_checkers 3134 1229
e_checkmate 4664 1270
music_4 1362 783
e_petflip 7079 3753
e_waves 6488 2343
music_5 913 528
e_greets 3464 1655
music_6 1176 618
e_morph 6764 2953
music_7 530 324
e_bump 3330 619
e_voice 4259 2263
e_noise 2417 494
итого 61962 25360
17 комментариев
Единственное — не очень понимаю, почему выбрана платформа, которая недоступна живьём. Насколько я понял из статьи, ты не проверял, работает ли эта демка на компьютере, для которого написана. Это, вообще говоря, стрёмный момент. Представь, если работа занявшая первое место в oldskool, на самом деле работает только на современном PC (надеюсь, что это не так, конечно).
Да, это ценный комментарий. Дело в том, что я проворачиваю этот трюк (написание большого проекта без тестов на железе) не в первый и не в десятый раз, на самых разных платформах, уже очень много лет. У меня есть решения, которые были ранее проверены на железе, и если я не выхожу за их рамки, это даёт 99% уверенности, что всё заработает. А если всё же срабатывает неудачный процент — то это абсолютно точно можно исправить. В данном случае я изначально решил не использовать никаких трюков с перепрограммированием видеоконтроллера (народ недавно умудрился одним безумным трюком выжать больше одной градации яркости). В данной демке всюду просто перекладывание байт из одного места в другое, оно никак не может не заработать. Что могло не заработать: звук, но эту часть я отладил пару лет назад, и она была протестирована на железе (благодаря этому в свежих эмуляторах правильный звук, ранее он всюду эмулировался некорректно, что продемонстрировали мои поделки). Ещё могло не заработать: время доступа к видеопамяти, но это также было проверено моим предыдущим релизом для PET. В общем, это был хорошо осознанный и контролируемый риск, на большом опыте.
Конечно, я всё равно нервничал насчёт того возможного процента, мало ли что, железо древнее, плохо эмулируемое и с труднодоступной документацией. Правила запрещают публиковать работы до пати, и я не мог рисковать случайной утечкой, хотя мне было кого попросить провести тест. Сразу же после релиза демо проверено на железе, полёт нормальный.
Во, это радует. Было бы классно, если бы человек, который проверял, выложил бы видео на youtube. Увидеть работу на живом железе, пусть и в записи, несопоставимо интереснее, чем на PC. Даже с мерцанием и прочим.
P.S. К слову, как мне кажется, в случае утечки в такой вот ситуации, орги бы пошли навстречу и не посчитали бы это нарушением правил.
Также есть сообщения о запуске на 2001 N32K, и кусочек видео на FB — однако, демо идёт там без снега, который я ожидал увидеть.
И смотрится классно в темноте :)
Умеешь-можешь!
И спасибо, что зарелизился на CAFePARTY. Жаль, что не смог приехать лично.