суббота, 13 июня 2026 г.

Забытый мультиколор (часть 4)

Программный vs Аппаратный Полное руководство по аппаратному мультиколору. 
Преимущества и недостатки, прототип игры, перспективы



  
См. также первую, вторую и третью части.



Аппаратный vs Программный

Аппаратный мультиколор

Всем был бы очень нужен

Программные мультиколоры

Обязаны сидеть в луже!

Эта часть могла бы быть первой (и единственной). Тем не менее в силу незнакомства широких масс с аппаратным мультиколором и/или поверхностного понимания особенностей его программирования потребовались предыдущие три части для понятного (надеюсь) разъяснения: насколько это просто, широко доступно и практически бесплатно. Satisfaction Megademo (Code Busters)

Будем предельно откровенны: с самого начала мультиколор представлял собой перформанс. На вопрос «Зачем нужен мультиколор?» никогда не было ясного ответа, но бытовало представление, что это просто «круто». 

Демо, имевшее мультиколорную часть, считалось более технологичным и стоящим на ступень выше других, мультиколор поднимал статусность авторов.

Вопрос «Зачем?» не задавался: мониторы спектрумистов были обклеены бумажками, на которых они мерили INT, отмечая его карандашом. Ответ на этот вопрос мог звучать так: «Потому что Code Busters!»

Долгое-долгое время мультиколор применялся исключительно в целях демостроения. Программный мультиколор реализуется через перезапись атрибутов синхронно с лучом развёртки. Однако из-за различий в синхронизации и таймингах прерываний демо, созданные для одного клона Спектрума, на других клонах будут работать либо некорректно, либо требовать адаптации.

Shock Megademo (ESI) Это значит, что разработчику приходится либо решать заведомо нереализуемую задачу подстройки под весь существующий зоопарк клонов Спектрума, либо предоставлять пользователю ограниченный ручной выбор.

Тотальная несовместимость — это фундаментальная проблема программного мультиколора, с которой все смирились.

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

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

В 2018 году появилась игра «Старая башня» от Retro Souls, с которой многие связывают переход от применения программного мультиколора исключительно в демостроении к использованию его в геймдизайне. На следующий год Денис Грачёв опубликовал историческую статью «Мультиколор будет побеждён», обосновавшую дальнейшее увеличение игрового пространства. 

Сложно не заметить, что на эту победу ушло больше четверти века, т. е. 35 лет (если считать с 1983 года). Всё это время рядом находился копеечный, но неизвестный и поэтому нераспространённый аппаратный мультиколор, вообще не требующий, чтобы его «побеждали». 

С точки зрения потерянного времени дела в демостроении обстоят не лучше. Для написания чанковой цветной демки в разрешении 64×48 не надо писать ещё один мультиколорный движок с именем шумерского бога. Достаточно заполнить область изображения числом #33 или #CC и выводить чанки расширенными атрибутами. Никакого пафоса и минимальные трудозатраты. Подытожим:

 
МультиколорПрограммныйАппаратный
Порог вхожденияВысокийНизкий
Доступность1) Любой ZX Spectrum
2) Фиксация на INT		1) Простая доработка
2) Встроен во многих клонах ZX Spectrum
СовместимостьТотальная несовместимостьЛюбой клон с поддержкой режима Hi-Color
Графический редакторmultiArtist (ограниченно)ZX-Paintbrush (универсально)
Создание графикиПлохо стандартизировано
Изобретение форматов удобных
для вывода и хранения		Стандартные форматы
Элементарно, но требует привычки
Динамичные игры
и демонстрации		Через вывод чанковТакже, как в стандартном режиме
Адаптация ПО1) Сложно и времяёмко
2) М.б. невозможной		1) Обычно не требуется
2) Добавление значений в стандартные порты
Мультигигаскрин128×192 (16×24 знакоместа)Полный экран 256×192

Прискорбно, но многие спектрумисты-разработчики сегодня переориентировались на поддержку зарубежных коллекционеров, разворачиваясь пердимоноклем к пользователям отечественных клонов. Новые релизы всё чаще ориентированы на оригинальный ZX Spectrum 128 и формат TAP (иначе зарубежные коллекционеры и пользователи FPGA-клонов не смогут это запустить и не захотят покупать).

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

 

Речной рейд

Спектрумизм в целом неизлечим.

Вот зачем — ты пойди спроси.

Пишут демки ассемблерные,

Мультиколорные россыпи!

Одной из важных вех развития программного мультиколора считается вышедшая в 2009 году техническая демонстрация «River Raid» от британского разработчика Джейсона Дж. Рейлтона. Она пародирует одноимённую классическую игру от Activision, существующую на Спектруме, но в худшем (по сравнению с Commodore 64, Atari и т. д.) качестве.

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

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

  RiverRaid на разных клонах 

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

Иллюзия движения в оригинальной демке создаётся синхронной прокруткой изображений мультиколора, атрибутов и бордюрных полос сверху вниз. При этом сам крохотный самолётик стоит на месте. В режиме Hi-Color мы не ограничены мультиколорной областью и можем нарисовать кукурузник размером хоть во весь экран. Хотя из скромности предлагаю ограничиться изображением советского истребителя МиГ-29.

МиГ-29 Ландшафт логично рисовать расширенными атрибутами, и детализации вполне хватает для изображения такой игры. С точки зрения художника, мы должны отрисовать самолёт цветом тона (чернила), а весь ландшафт — цветом фона (бумага). С точки зрения кодера, мы имеем область изображения (куда заранее впечатан самолёт) и область расширенных атрибутов (6144 байта), которую необходимо прокручивать сверху вниз.

Аппаратный мультиколор может выводить атрибутную картинку в разрешении 32×192. Стандартная программная прокрутка: запоминаем в буфер 32 байта расширенных атрибутов из нижней 191-й строки, прокручиваем расширенные атрибуты на пиксель вниз и выводим буфер в верхнюю (нулевую) строку. Повторяем в цикле.

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

Не скажу, что сильно перетрудился, но итоговая техническая демонстрация «Речной рейд» (с музыкой, печатью текстов и другими добавлениями для выполнения требования об отсутствии сплошной анимации) под аппаратный мультиколор будет отправлена на фестиваль DiHalt 2026 Summer. Попробуйте, может быть, у вас выйдет лучше (самолёт меняется на звездолёт, вертолёт, и т.д.)?

К вопросу о «жирных» 12К картинках (этот вопрос уже частично затрагивался в предыдущей части руководства): графику в современных программах для Спектрума принято (де)компрессировать. Для компрессии можно использовать zx7mini, пример для данной программы:

$ zx7mini.exe res/Landscape.C res/Landscape.Z
Optimal LZ77/LZSS compression by Einar Saukas
File converted from 12288 to 592 bytes! 

Конечно, компрессия сильно зависит от характера графики, но надо отметить, что расширенные атрибуты обычно имеют значительные однотонные области и сжимаются гораздо лучше изображений. Можете себе представить, сколько такой графики можно поместить в 4 Мб современного клона типа ZX Evolution? Посчитайте)

 

Ошибка Зонова

Все за и против взвесив,

Дело осталось за малым:

Добавь своему Спектруму,

Аппаратный живой мультиколор!

На легендарном фестивале Enlight’97 фирма «Скорпион» показала предсерийный образец платы GMX (Grafic Memory eXtension). По сути, это была видеокарта для Scorpion ZS 256, обладавшая следующими характеристиками:

 
  • 512 КБ ОЗУ
  • Графический режим 640x200 @4
  • Текстовый режим 80x25
  • Аппаратная прокрутка экрана вверх-вниз
  • Стоимость эквивалентная $35-$40

Что с ней было не так?


GMX никогда не предназначался для вывода графики. Графический режим был задуман для вывода текста с символьным разрешением 80×25, хорошо подходящем для адаптированной Андреем Ларченко версии CP/M 2.2. Если текст был цветным, то этот видеорежим потреблял все 512 КБ.

Видеокарта не работала при установленной звуковой карте General Sound. Пользователь должен был выбирать между видео и звуком. Кто-то говорил, что Зонов устраняет конкурентов, а из ларька Scorpion на радиорынке доносилось что-то про MIDI-контроллер.

Официально инфляция за 1997 год составила 11% при официальном же курсе 5600–5960 руб. за доллар. Средняя зарплата была эквивалентна $159, поэтому приобретение платы GMX выглядело как выбор между едой и Спектрумом.

В действительности фирма «Скорпион» проводила опросы пользователей, а Сергей Юрьевич внимательно слушал критику, просто трактовал её по-своему. После эпичной осады пользователями на фестивале Enlight’96 в рамках проекта GMX должен был появиться режим совместимости (позволяющий смотреть мультиколорные демо для Pentagon без адаптации).

Когда GMX был показан «вживую», пользователи стали требовать уменьшить разрешение до 320×200 и предоставить видеорежим с цветом на точку. По коллективной мысли пользователей, это должно было привести к удешевлению (в 2 раза меньше памяти) и появлению видеорежима для вывода именно графики, а не текста.

Зонов трактовал это пожелание как добавление нового видеорежима в существующий концепт, требующее доработки и изменений ПЗУ. Пользователи пожали плечами и массово начали дорабатывать свои Scorpion для видеорежима Timex Hi-Res (начавшийся в 1997 году в Санкт-Петербурге тренд докатился к 1999 году до Саранска). Разрешения 512×192 хватало для работы с текстовыми редакторами и почтовыми программами. То есть ровно для той ниши, в которую был нацелен GMX. Себестоимость добавления видеорежима 512×192 составляла какие-то десятые доли доллара.

Если Клайв Синклер продвигал свой ZX Spectrum по принципу «лучше хуже, но больше», то бизнес-логика Сергея Зонова, наблюдавшего стремительное сокращение популяции спектрумистов, лежала в плоскости «лучше меньше, но дороже». Более развёрнуто: «Лучше получить с каждого пользователя больше денег сейчас, потому что потом они всё равно все будут на PC».

Предположим, что копеечные режимы Timex были бы добавлены Сергеем в 1993 году при запуске производства Scorpion. Это никак не повлияло бы на совместимость с ПО и стоимость, но закрыло бы вопрос с мультиколором (1996) и разрешением для почтового ПО (1997). Пользователи не корябали бы красивые зелёные платы. Такое решение неузнаваемо изменило бы ландшафт ПО для всего ZX Spectrum.

Возможно, кто-то составит впечатление: «Ну вот, во всём виноват Зонов». Это не так. Сергей Юрьевич действовал в конкретную и непростую историческую эпоху, исходя из своих представлений о предпринимательской деятельности, и был во многих отношениях первопроходцем.

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

Казалось бы, после популяризации шин ZXBUS и NemoBUS, что могло бы быть более эффективным, чем небольшая платка изменяющая логику работы ULA и добавляющая режимы Timex любому клону Спектрума? Ровно эти два нативных режима, и ничего более, то есть никаких GMX, никаких HRC, HAM, EGA, VGA и прочего.

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

Проблема вот в чём. Разработчикам железа было (и есть) гораздо интересней:
  1. Реализовать нестандартный и ни с чем не совместимый видеорежим, который не будет иметь никакой поддержки;
  2. Провести работы по реверс-инжинирингу и переизданию какого-нибудь мертворожденного железа (например, GMX);
  3. Провести работы по синхронизации с экраном Спектрума чего-нибудь совершенно чужеродного (например, Dendy);
  4. Подключить видеопроцессор в неожиданный разъём (например, VDAC2 для порта IDE);
  5. Создать видеокарту на базе чипа выпаянного из фоторамки и закрыть проект в связи с недоступностью фоторамок на AliExpress.
Список можно продолжить.

Если пользователю нужен Dendy, то он пойдёт и купит Dendy. Спектрум ему для этого не нужен. 

Если пользователю будет нужен режим HAM, то он пойдёт и купит Амигу. Ему не нужен этот режим на Спектруме. Хотя бы потому, что весь инструментарий для режима HAM — на Амигах. Он даже не сможет этим нормально пользоваться без покупки Амиги.

Точно так же пользователь говорит: «Зачем мне GMX "за много денег", если, припаяв пять проводов, я получу почти то же самое в существующих условиях?». И на этом заканчиваются продажи.

Как мы знаем хотя бы из опыта создания GMX фирмой «Скорпион», построение замкнутых экосистем для полутора пользователей, имеющих возможность покупать железо по цене крыла самолёта, — путь в никуда.

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

Тестирование новой видеокарты для ZX Spectrum

Тестирование новой видеокарты для ZX Spectrum

Конец

на 1 комментарий:

среда, 3 июня 2026 г.

Забытый мультиколор (часть 3)

Примеры мультиколорных иллюстраций Полное руководство по аппаратному мультиколору. 
Совместимость, алгоритмы, эффекты и градиенты



 
Начало здесь, вторая часть здесь.


Философия мультиколора


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

Теперь стоит поговорить о некоторых (не)очевидных вещах. Расширенные атрибуты имеют тот же размер — 6144 байта, что и область данных изображения. Причём что наиболее важно — они имеют точно такую же нелинейную структуру. Мне приходилось слышать следующие (неверные) выводы из этого факта:
 
  • Нет смысла писать программы для аппаратного мультиколора, т. к. они будут показывать на обычном Спектруме чёрный экран;
  • Надо изменять в 2 раза больше данных, а графических акселераторов не завезли;
  • Писать эффекты с расширенными атрибутами сложно.

Рассмотрим эти возражения.

Чёрный экран


Не встречал настолько злых авторов, которые зануляли бы область атрибутов. Гипотетически такое возможно, и тогда пользователь Спектрума действительно сидел бы перед чёрным экраном, из-за которого (может быть) доносились бы какие-то звуки деятельности программы. Однако типично атрибуты заполняются байтом 04 (зелёный) или 07 (белый), что при отсутствии режима Hi-Color даёт монохромное изображение.

На Спектруме огромное количество программ с монохромной графикой, поэтому спектрумисты могут по крайней мере сложить представление о том, что делает эта программа, хотя и без цвета. Это даёт явное преимущество перед программами, написанными для видеорежимов разнообразных FPGA-эмуляторов.

Игра NEXTipede

Можно даже совместить раскраску атрибутов.

Демонстрация Timex Color

Надо заметить, что расширенные атрибуты удобно использовать наравне с данными изображения, поэтому какие-то элементы в монохромном режиме могут быть не видны. Например, в игре Hi-Color Hero выстрелы звездолёта сделаны через расширенные атрибуты — это быстро и удобно (красим 8 пикселей одним байтом), но такое решение оставляет игрока на оригинальном Спектруме с «пиу-пиу» без визуализации выстрелов.

Отсюда следует, что разработчик, использующий расширенные атрибуты, должен помнить о Спектрумах без такого режима. Природа атрибутов позволяет использовать для подобной заботы т. н. «скрытые пиксели». Именно так выводится заставка игры Hi-Color Hero+: в нижней строчке изображения есть надпись «МУЛЬТИКОЛОР НЕ НАЙДЕН», закрашенная расширенными атрибутами, но видимая на нерасширенном Спектруме.

Заставка при запуске с вкл. мультиколором и без
Загрузка игры Hi-Color Hero+
   
Похожим образом поступили авторы демонстрации Timmy, выводя на нерасширенных Спектрумах простую атрибутную картинку.

Загрузка демонстрации Timmy

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

Вывод графики


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

Если разработчик выводит статическую картинку в стандартном режиме, то он может сначала занулить область атрибутов (#5800), затем заполнить область изображения (#4000) и, наконец, скопировать реальные атрибуты. Это даёт «моментальное» появление картинки на экране. Но если графика динамическая, то алгоритм меняется: сначала заполняется область атрибутов, а затем «под ней» выводится графика в область изображения.

Возьмём эффект «шторки» (англ. blind), в котором полноэкранная картинка отрисовывается по линиям сверху вниз. В стандартном режиме можно сначала заполнить атрибуты, а затем в цикле (с задержкой) копировать на экран 192 линии изображения сверху вниз (рассчитывая адреса нижеследующих строк). Важным является отсутствие атрибутов, в которых фон (бумага) отличался бы от фона экрана (обычно чёрного). Иначе пользователь будет видеть атрибутные квадраты до тех пор, пока линии картинки не дорисуются до них.

Расширенные атрибуты имеют высоту ряда в 1 пиксель. Это делает вывод данных изображения взаимозаменяемым с выводом атрибутов. Можно сначала занулить расширенные атрибуты (#6000), затем заполнить данные изображения (#4000), а затем копировать 192 линии расширенных атрибутов сверху вниз (рассчитывая адреса нижеследующих строк). Фон в копируемых атрибутах при этом может не совпадать с фоном экрана. В стандартном режиме так не делается, потому что изображение в этом случае появлялось бы по знакоместам 8×8, что некрасиво.

Вопрос вывода графики сводится к решению задачи «что выводить первым»: изображение или (расширенные) атрибуты? Вопроса вывода 12288 байт (изображение + расширенные атрибуты) вместо 6144 байт изображения обычно не стоит. Если же необходимость возникла, то надо понимать, что байты расширенных атрибутов имеют те же смещения от начала их области, что и байты изображения, а значит, рассчитывать эти смещения надо по-прежнему один раз. Не надо писать отдельные процедуры для расчёта адресов в области атрибутов и в области изображения.


Адаптация эффектов


Разработчик имеет два подхода: 1) использование процедурных библиотек, в т. ч. процедур ПЗУ, для визуализации графики и печати текстов без изменений (с заполнением расширенных атрибутов) и 2) переписывание вывода байтов изображения на вывод байтов расширенных атрибутов в существующих эффектах.

В любом случае, ему не приходится иметь дело с terra incognita, изобретать велосипеды и судорожно искать примеры кода от тех, кто уже «раскурил» этот «новый» видеорежим. Ничего нового в нём нет, всё хорошо известно, а существующие базы статей на ZXPress и ZXDN точно так же применимы к режиму Hi-Color, как и к стандартному режиму.

В стандартном режиме цветные шрифты могут быть выведены либо печатью шрифтов 8×8 «между знакоместами», либо их увеличением по высоте. Для печати текста в режиме Hi-Color можно использовать стандартный вызов RST #10 с заранее подготовленными расширенными атрибутами. Это можно делать даже из Бейсика, как демонстрирует программа ColorPRINT (в версии для Hi-Color).
 
Печать мультиколора из ColorPRINT
 
Раскраска каждого знакоместа описывается 8 байтами расширенных атрибутов, называемых мультиколорным градиентом (для краткости — просто градиентом). Одни градиенты больше подходят для раскраски заголовков, другие — для текста, третьи — для подписей. Чтобы читатели не ломали над этим голову, поделюсь своей коллекцией:

BASE:	db    #04, #05, #45, #07, #47, #45, #04, #05	; базовый градиент (голубой-белый-зелёный)
TEST:	db    #FF, #07, #47, #07, #47, #47, #07, #FF	; белые полоски на границах знакомест
RBW0:	db    #02, #42, #46, #44, #04, #05, #01, #03	; радуга (Color PRN)
RBW1:	db    #41, #03, #02, #42, #46, #44, #04, #05	; сдвинутая радуга
RBW1_I:	db    #05, #04, #44, #46, #42, #02, #03, #41	; перевёрнутая радуга
YLBL:	db    #46, #06, #47, #07, #45, #05, #41, #01	; градиент жёлтый - синий (Color PRN)
BLRD:	db    #01, #05, #45, #07, #47, #46, #42, #02    ; градиент синий - красный (Color PRN)
YLBL2:	db    #06, #46, #47, #07, #45, #05, #41, #01	; градиент жёлтый - синий 
WHCY_P:	db    #07, #47, #07, #47, #45, #05, #45, #05	; сверху - белый, снизу - голубой      (заголовок)
WHGR_P:	db    #07, #47, #07, #47, #44, #04, #44, #04	; сверху - белый, снизу - зелёный      (подпись)
YLGR_P:	db    #06, #46, #06, #46, #44, #04, #44, #04    ; сверху - жёлтый, снизу - зелёный     (текст, основа)
MGRD_P:	db    #03, #43, #03, #43, #42, #02, #42, #02	; сверху - фиолетовый, снизу - красный (текст, выделение)
Заполнить весь экран одним из градиентов можно следующим тривиальным кодом: 

; screen-fill.asm

        ORG	#C000
		
	ld	hl, BASE    	 ; таблица градиента 8 байт
	ld 	(SGRAD), hl
	call	SCRATTR
	ret

SCRATTR:
	ld	hl, #6000       ; начальный адрес расширенных атрибутов
	ld	c, 3            ; 3 прохода
MNF:
	push	bc
	ld	b, 8            ; 8 рядов
	ld	ix, (SGRAD)	; восстанавливаем указатель на градиент
CLRF:
	push	bc
	ld	a, (ix)         ; текущий цвет
	inc	ix
	ld	d, h
	ld	e, l
	inc	de     
	ld	(hl), a
	ld	bc, 256
	ldir
	pop	bc
	djnz	CLRF
	pop	bc
	dec	c
	jr	nz, MNF
	ret

SGRAD:	dw	  0
BASE:	db    #04, #05, #45, #07, #47, #45, #04, #05	; базовый градиент (голубой-белый-зелёный)
Шрифты, раскрашенные по вертикали, выглядят очень выигрышно, но ещё лучше смотрится анимация расширенных атрибутов. Пробегающую по буквам полосу хорошо использовать, например, для того чтобы обратить внимание пользователя на очередное достижение или обновившиеся очки в игре, логотип группы, ник автора в демо и т. д.



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

CTAB:	db	X, Y		; координаты начала заполнения в знакоместах
	dw	GRAD		; указатель на градиент
	db	N		; ширина заполняемой полосы в знакоместах
	db	#FF		; признак конца таблицы
Например, для градиентной анимации можно создать такую таблицу: 

CTAB:  	db	5,11		; первый градиент
	dw	GRAD1
	db	10
	db	5,11		; второй градиент
	dw	GRAD2
	db	10
	db	5,11		; третий градиент
	dw	GRAD3
	db	10
	. . .
	db	#FF
Достоинство подобных структур в том, что их легко обрабатывать и они хорошо компрессируются (на случай, если кто-нибудь решит создать на этой базе целый мультфильм или demo). У тех, кто осилил дочитать до этого места, должно было сложиться полное понимание того, как писать крутые программы, показывающие себя не только в стандартном режиме, но ещё больше раскрывающиеся в режиме Hi-Color.

Более глубоким подходом является замена вывода данных изображения на вывод расширенных атрибутов: здесь нам потребуется менять адреса. При этом большинство эффектов также могут быть адаптированы «в лоб». В качестве примера приведу адаптацию упоминавшегося выше эффекта шторки из журнала ZX-Ревю №1–2 за 1997 год. Мне потребовалось изменить 3,5 строчки (не считая инициализации). 

; screen-blind.asm

SCRSHOW:

	ld		hl, SCRWARN	            ; заполнение атрибутной картинкой
	ld		de, #5800	            ; для тех бедных спектрумистов
	ld		bc, 768		            ; у которых почему-то нет Hi-Color
	ldir

	ld		hl, SCREEN	            ; переброска данных изображения
	ld		de, #4000
	ld		bc, #1800
	ldir
	
	ld		hl, #6000	            ; зануление расширенных атрибутов
	ld		de, #6001
	ld		(hl), 00	            ; чёрное на чёрном
	ld		bc, 6143
	ldir

	; раскраска расширенных атрибутов
	ld		hl, SCREEN+6144	            ; начало расширенных атрибутов
	ld		de, #6000	            ; было #4000
	or      	a
	sbc		hl, de
	ld		b, h
	ld		c, l		            ; BC = смещение
	ld		a, 191		            ; Y-координата (0..191)
SMLP:	push		af, bc
	ld		c, 0		            ; X-координата (0..255)
	call		8880		            ; HL = адрес в видеопамяти
	ld		bc, #2000
	add		hl, bc		            ; добавляем #2000 к выхлопу 8080
	pop		bc, af
	push		bc
	ld		d, h
	ld		e, l		            ; DE = экран
	add		hl, bc		            ; HL = буфер + смещение
	ld		bc, 32
	ldir				            ; копируем строку
	halt
	pop		bc
	dec		a
	cp		255
	jr		nz, SMLP
	ret

SCREEN:	 INCBIN	“images/multicolour.scr”	     ; 12288 байт
SCRWARN: INCBIN	“images/attr_warning.bin”            ; 768 байт

Продолжение здесь →
на Комментариев нет: