Первая половина статьи была опубликована в последнем номере замечательного журнала ЗаРулём, а вторая написана по следам свежего релиза нашей новой игры GLUF. Но т.к. они дополняют друг друга я решил их объединить в одну. В ней нет ничего нового для мастеров кода и гуру из 90-х годов, это скорее поток мыслей на тему мультиколора, скрола и попытки их объединения который может быть будет кому-то интересен :)

После того как вышла наша новая игрушка Old Tower мне почти сразу же посыпались просьбы рассказать, как же удалось добиться такой плавной и яркой картинки на нашем старичке Speccy. Ну что же, берите чай и печенки и вперёд!



Прежде всего надо ещё раз напомнить, что же такое мультиколор и с чем его едят. Поэтому я процитирую свою старую статью 2016 года, где я сделал обзор существующих на тот момент мультиколорных движков. «Общеизвестно, что стандартный видеорежим спектрума не позволяет отображать более 2-х цветов в одном знакоместе экрана. Однако существует различные программные трюки, позволяющие обойти это ограничение. Один из них — это так называемый «Мультиколор», или «Rainbow Graphics». Он позволяет, уменьшит высоту знакоместа до блоков 8x1, 8x2, 8х4 с помощью идеальной синхронизации вывода атрибутов и луча, формирующего картинку на экране» Грубо говоря, микросхема ULA, отвечающая за формирование изображения на экране, читает значения цвета из атрибутов не один раз на блок 8 пикселей высотой, а каждую экранную линию, потому нужно только успеть поменять значение в памяти на новые и удача ваша. Это в теории. На практике ширина области мультиколора ограниченна и для блоков 8х1 так и не удалось сделать картинку шире 20 знакомест.

Стоит отметить что ещё в 1988 году в игре Action Force 2 применятся точно такая же технология что и в нашей игре, просто взгляните на картинку, и вы всё поймёте. Почему же они не пошли дальше и не сделали полноценную игру в таком режиме? Увы, нам остаётся только догадываться и сожалеть.

Но постойте, скажет внимательный читатель. Ограничение в ширину и куча цветов — это же идеальная среда чтобы перенести на спектрум какую-нибудь механику с мобилок! Да, именно так я и подумал, и решил, взяв за основу великолепную Tomb Of The Mask перенести её в свои традиционные головоломные уровни. Осталось просто добавить скролинг и дело в шляпе. Но не тут-то было.

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

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

После нескольких зарисовок на бумаге, нескольких часов поисков оптимальных размеров областей и двойной работы по подгонке мультиколора в двух кадрах, у меня получилась такая схема:

Итак, первый кадр. Начнём с момента, когда луч дошёл до места обозначенного зелёной линией. Это самый критичный момент в моём рендере. Как только луч оказался тут мы начинаем формировать новый для кадр нашей игры. Первым делом рисуем 50 нижних линий нашей пиксельной области, на схеме это белый прямоугольник поменьше. После этого у нас остаётся очень-очень мало времени до конца кадра, но нам нужно успеть ещё обновить мультиколор для наших врагов, это единственное место где можно это сделать безопасно и без глюков потому что чуть раньше, в области обозначенной «A» мы их уже отрисовали в пиксельный буфер и прямо сейчас уже нарисовали 50 линий с него.

Второй кадр, сразу же, без долгих раздумий начинаем рисовать 110 оставшихся линий нашего пиксельного буфера (белый прямоугольник побольше) пока луч не добежал до нашей игровой области. После их отрисовки у нас в экранной памяти получается законченная картинка, которая складывается из 50 линий нарисованных в прошлом кадре уже после луча и 110 линий, нарисованных перед лучом, которому ничего не остаётся как нарисовать полный буфер на экран. Так мы избежали подёргиваний и сечений лучом отрисовав линии таким хитрым образом. Количество этих линий рассчитано так что сразу после того как мы их отрисовали начинаются пляски с мультиколором, которые продолжаются всю область, обозначенную буквой «B», причём в обоих кадрах в этой области происходит одно и то же — рисуется мультиколор. А так как область мультиколора всего 12 знакомест шириной, то осталось ещё время нарисовать и стены башни одновременно с мультиколором.

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

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

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



После релиза Old Tower можно было и остановиться, но хотелось увеличить ширину игрового поля и увеличить размер тайлов и спрайтов. Поэтому я стал думать, как можно развить рендер с прошлой игры в нечто большее. Итак, нужно увеличить ширину мультиколорной области и максимально оптимизировать пиксельный и мультиколорный скроллинги. Так начинался GLUF.

За основу я взял рендер из Old Tower. Первым делом берёмся за мультиколор, чтобы он стал приемлемой ширины пришлось перейти в режим атрибутов 8х2 что тоже весьма красочно, тем более размеры спрайтов и тайлов тоже подрастут до 16х16, так что такой переход не критичен. Здесь не было никаких сложностей, в наше время написать мультиколор 8х2 это достаточно легко, нужно просто немного побегать с лучём наперегонки. Были заморочки с тем чтобы сделать вывод мультиколора из линейного буфера, ведь в таком случае можно его скролить лёгким движением руки, а ещё я немного заморочился и свернул мультиколор в цикл сэкономив приличный кусок памяти. Во время разработки OldTower меня дико раздражало ограничение на количество обновляемых областей мультиколора при восстановлении фона под динамическими элементами, поэтому я решил сделать двойной буфер для мультиколора и обновлять цвета в том буфере, который сейчас не виден на экране. В качестве бонуса получилось сделать эффект заливки красным цветом при смерти героя просто подменив мультиколорный буфер на другой – весь заполненный красным.

А дальше нужно было ускорить вывод пикселей с сохранением возможностью их лёгкого скролинга. После всех экспериментов я остановился на оптимальном размере игровой область в 24*16 знакомест. Отрисовка пикселей это достаточно затратно, поэтому я решил взять самый быстрый метод вывода изображения из буфера в простонародье известный как «лдпуш» он основан на постоянном повторении комбинации команд ld и push. Мы отводим огромный кусок памяти в который генерируем такой код

;у нас будет 320 линий

dup 320

;код для вывода одной линии

ld sp, адрес конца линии экрана 

dup 12 : ld de, 2 байта данных : push de : edup

edup

Это и будет наш пиксельный экран, он статичен. Он просто выводит данные на экран которые в нём же и хранятся. Причем выводит он их задом наперёд, т.к. команда push уменьшает указатель стека, который в нашем случае является адресом куда мы кидаем данные. Таким образом, вместо того чтобы рисовать напрямую в экран мы, будем рисовать прямо в код! Т.е. нам нужно будет каким то образом преобразовывать реальные игровые координаты в адрес нужного нам байта в этом куске кода. К тому же нужно учитывать, что всё будет зеркально, т.к. рисуется задом наперёд и вдобавок ко всему, чтобы двигать горизонтально плавно спрайты шириной 16 пикселей по экрану нам необходимо перерисовывать 3 знакоместа в ширину, а значит вычисление соседнего знакоместе будет совсем не тривиальным. Не стоит забывать, что под спрайтами ещё нужно сохранять и восстанавливать фон. К тому же нужно как-то скролить это всё прыгая на нужную строчку кода и выпрыгивать с неё и ещё обновлять адреса линий куда всё будет выводится. Список проблем рискует перерасти критическую массу, после которой уже опускаются руки.

Но засучив рукава и разбив задачу на более мелкие удалось всё победить. Всё оказалось не столь страшным как казалось изначально.

Начал я с простого, скролинг делается тривиально – начало строки вычислить легко, к тому же каждая «линия» экрана занимает 51 байт кода что облегчает нам все вычисления. Итак, на экране показывается 128 пиксельных линий, точка входа в этот могучий кусок кода вычисляется простым умножением на 51 номера линии, с которой мы хотим вывести картинку, а выход вычисляется прибавлением 128*51. Чтобы сделать выход мы просто патчим код и вклиниваем команду jp (hl) в нужное нам место, не забыв при вызове поместить в hl адрес куда нам нужно вернуться, а после возврата вернуть туда что там было до этого. Всё это старый и всем известный трюк. Потом нам ещё надо обновить все адреса 128-ми линий которые мы будем выводит и дело в шляпе.

Я в принципе не очень хороший кодер, а на z80 и подавно. Поэтому процедуры, которые выводят 5 динамических спрайтов с фиксированным числом тактов в верхнем бордюре второго фрейма и запоминают адреса в «буферах донорах» для восстановления фона дались мне слишком тяжело. И уже сейчас, спустя месяц как я их написал я, смотрю на них и нечего почти там не помню. Поэтому детально описать что там происходит уже не получится. Единственное что могу сказать, что я пожертвовал ещё одним куском памяти в последней быстрой странице чтобы хранить в ней пиксели для восстановления фона. Хранятся они там столбцами и не строками, чтобы максимально быстро их восстанавливать, т.к. вся отрисовка спрайтов построена на выводе столбцами из-за нетривиального перехода к соседнему столбцу.

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

Вот собственно и всё, дальше было просто дело техники.



Если вы вдруг ещё не играли в наши новые игры, то хочу вам напомнить — скачать и даже поиграть онлайн можно на нашем сайте www.retrosouls.net

Играйте в спектрум, смотрите демки, поддерживайте авторов, пытайтесь сами что-нибудь делать и просто получайте удовольствие от любимого хобби!

Пока!