Непростое расширение видео для Спека

[Vladimir Kladov]

Без особых предисловий: вот краткая спецификация режима Sprites&Shifts.

1. Основной экран (со смещения 0 на странице RAM5 или со смещения 0 на странице RAM7 - как обычно) используется в качестве фона, и его можно двигать с точностью до 1 пиксела на 0..255 бит по горизонтали и на 0..191 бит по вертикали.

2. Дополнительная "экранная" область со смещения 0 на странице RAM1 содержит 32x24 = 768 = 300h байт. Если байт равен 0, то соответствующее знакоместо в основном не содержит спрайта (но может содержать частично продолжение начатого левее или выше спрайта), и в своей свободной области рисует (правильно сдвинутый по циклу) основной экран. Если это номер спрайта n=1..255, то со смещения 300h + n * 8 находится 8-байтное описание спрайта:

смщ длн значение
_0_ _2_ d0..d13 - смещение (в том же блоке памяти) к битовому изображению спрайта (за которым следует немедленно маска спрайта), 2 старших бита d14..d15 не используются. Например: если размер спрайта 3 байта х 11 пикселов, то сначала идет 33 байта изображения, потом 33 байта маски.
_2_ _1_ ширина спрайта в байтах d0..d4 (максимум 32 байт).
_3_ _1_ высота спрайта в пикселах d0..d7 (максимум 192 пиксельных линий).
_4_ _1_ атрибут спрайта (как обычно, d0..d2 - цвет бита "1", d3..d5 - цвет бита "0", d7 - мигание, d6 - яркость.
_5_ _1_ смещение спрайта в битах: d0..d5 - по горизонтали (вправо) на 0..63 пиксела; d6 - сдвиг не вправо, а влево; d7 - инверсия спрайта по горизонтали (т.е. он изображается зеркально отраженным по горизонтали).
_6_ _1_ смещение спрайта в битах: d0..d5 - по вертикали (вниз) на 0..63 пиксельных строк; d6 - сдвиг вверх, а не вниз; d7 - инверсия спрайта по вертикали (т.е. он изображается перевернутым, если d7=1).
_7_ _1_ приоритет (или Z-order) спрайта 0..255. Если несколько спрайтов пересекаются в какой-либо точке, то поверх всех показывается спрайт с бОльшим приоритетом. Вариант2: этот байт не используется, а в качестве приоритета используется номер спрайта. Вариант3: можно использовать этот байт как альфа-канал, для любителей. Вариант4 (лучше всего, его и оставить): d0..d1 - номер области ограничения вывода 1..3, см. описания областей в п.3.

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

3. Первый спрайт начинается со смещения 308h в RAM1.
Два байта в том же блоке памяти по адресам 300h и 301h задают соответственно вертикальное и горизонтальное (циклические) смещения основного экрана. Область отображения спрайтов может быть задана байтом 7 в описании спрайта (1..3). Описатели областей находятся по адресам 302h..307h (по 2 байта на область) в виде:

d0..d4 = x0 (0..31 байт)
d5..d7 = w (1..7, 0=8 1 байт)
d8..d12 = y0 (0..23 знакоместа)
d13..d15 = h (1..7 + 1 знакомест)

Т.е. можно определить до 3х (возможно, пересекающихся) прямоугольных областей - окон вывода, и приписать каждый спрайт на экране своей области. Те части спрайта, которые выпадают за свою область, автоматически обрезаются по границам знакомест.

Если задействуются все 255 спрайтов, то описания заканчиваются на смещении AFF, и со смещения B00h до 3FFFh весь остальной блок памяти могут занимать сами изображения и маски спрайтов.

4. Управление (порт).

Регистр 14 порта FFFD управляет включением режима: надо записать в него 81h, чтобы режим включился, и 80h, чтобы он выключился. При желании можно использовать любой порт, основное управление все равно идет через память.

[Advertiser]

[Vladimir Kladov]

продолжение:

5. Алгоритм работы видео-декодера в S&S-режиме.

- блок сканирования основной видеопамяти работает почти как обычно. Главное здесь - это учет циклического сдвига. Результат работы этого блока может быть в любой момент перекрыт результатом работы сканера спрайтов (с точностью до пиксела).

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

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

6. Преимущества этого подхода:
- никакого клэшинга атрибутов;
- очень легкое управление из программы до 255 движущимися 2х-цветными объектами размер до 256х192 пиксела, на движущемся 2х-цветном фоне; множество вариантов управления: можно менять изображение спрайта (там, куда указывает указатель) или указатель на спрайт в его описателе (если все варианты заготовлены заранее), или менять номер спрайта в матрице сканирования спрайтов, если номеров спрайтов достаточно, чтобы выделить некоторое количество описателей под несколько кадров движения одного и того же героя;
- при желании цветность спрайта легко увеличивается заданием в нескольких соседних позициях нескольких спрайтов (например, цвета шапочки/штанишек/варежек могут отличаться от цветов курточки героя, но задавать надо будет отдельные спрайты);
- высокая скорость графики. Большую часть времени процессор свободен для выполнения программы: можно заниматься логикой игры, звуками... рисование много времени не занимает. Например, чтобы сдвинуть спрайт на 1 пиксел по X вправо, если он смещен на 7 по Х: задать смещение 0, и в матрице поместить его номер в соседний байт, а в тот байт, где он был раньше, записать 0. Но если соседний байт в матрице занят, то можно просто увеличить смещение, чтобы оно стало 8. Чтобы сместить на n пикселов весь задний план, надо просто увеличить или уменьшить на n байт со смещением 300h или 308h.

7. Недостатки этого подхода:
- никакой совместимости с прежним режимом (т.е. переделка игр не будет тривиальной). А оно надо? Насмотрелись уже...
- очень сложный сканирующий алогритм, "на лету" вообще трудно придумать приемлемый алгоритм. Но можно работать через буфер.
- менее полезно для векторной графики. Но можно по крайней мере бесплатно двигать задний план без малейшего клэшинга, а пдостаточно небольшие векторные объекты без клэшинга (со своими цветами) двигать по экрану как заблагорассудится, считая их спрайтами (только менять содержимое спрайта для выполнения их поворотов, масштабирований и т.д.)

Но если бы такой режим был в Спектруме... Я бы еще под него сам чего-нибудь поделал.

[fk0]

Но если бы такой режим был в Спектруме... Я бы еще под него сам чего-нибудь поделал.

Я ещё предлагаю в Z80 реализовать поддержку 32-битного режима
совместимого с i386 и Win32 API уж сразу, аппаратно причём. А пока
железячники думаю это всё можно реализовать в эмуляторе и написать
массу софта.

[CHRV]

Я ещё предлагаю в Z80 реализовать поддержку 32-битного режима
совместимого с i386 и Win32 API уж сразу, аппаратно причём. А пока
железячники думаю это всё можно реализовать в эмуляторе и написать
массу софта.

Кирилл как обычно в ударе!
Я пожалуй всех отправлю читиать доку по v9990. Судя по всему это единственно что будет реализованно!

[Vladimir Kladov]

в железе - да. Железячников - мало. И все заняты своими делами. А что, в доке написано, что в v9990 есть спрайтов? Проц не справится с чем-то большим, что есть в спектруме, Клайв был прав, когда спроектировал только тот режим, что есть в базовом. Единственное, что может победить тормоза - это спрайты.

[James DiGreze]

Необязатьельно спрайтовый, можно и векторный... Даешь периферийному процессору координаты двух точек, а он в стандартном экране между ними строит прямую. Я так думаю для игр в стиле Elite это было бы очень круто И не обязательно делать полигональную модель, достаточно было бы просто быстрое рисование точек и прямых. Для реализации этого контроллера правда нужно сделать полноприводный захват шин адреса и данных (BREQ, BUSAK). А процессор можно использовать хоть AVR...

[madcore]

Возможно, узкоспецифическую задачу шевеления спрайтов может решить шустрый DMA? Возможностей и применений по-более будет.
Вроде был проект DMA Sound Card, с какой скоростью оно память-память кидало? А z80 там параллельно может что-нибудь перекидывать?

[Vladimir Kladov]

да, в V9990 спрайты есть. Описания я так и не нашел нормального (но все равно ведь будет зависеть от способа сопряжения, так?) но есть краткое упоминание. Я сделал такой вывод, что вроде как спрайты можно каким-то образом загрузить в память V9990 (а ее там у него аж 512К), и давать в нужном режиме команду переброски спрайтов.

[lvd]

Без особых предисловий: вот краткая спецификация режима Sprites&Shifts.
[skip]

Молодец, изобрёл жалкое подобие комодуры 64. =)

[lvd]

Кирилл как обычно в ударе!

Он не в ударе, он в зажыге =)

Я пожалуй всех отправлю читиать доку по v9990. Судя по всему это единственно что будет реализованно!

давай отправь! -)