Программный вертикальный скролл

При известном количестве плоскостей можно сэкономить ещё около 8 тысяч CPU states на полный экран. Зааттачил рендерер для 2х плоскостей. Вроде шустро, но всё равно есть visual glitches при скроллинге. Будем всё-ж делать framebuffer.

StkMvUp Macro _rp
IFIDN <'&_rp'>,<'d'>
pop d
mov m,e
inr l
mov m,d
ELSE
pop b
mov m,c
inr l
mov m,b
ENDIF
EndM


StkMvDn Macro _rp
IFIDN <'&_rp'>,<'d'>
pop d
mov m,e
dcr l
mov m,d
ELSE
pop b
mov m,c
dcr l
mov m,b
ENDIF
EndM

SpMvUp Macro _rp,_count
Rept (_count SHR 1) - 1
StkMvUp _rp
inr l
EndM
StkMvUp _rp
EndM


SpMvDn Macro _rp,_count
Rept (_count SHR 1) - 1
StkMvDn _rp
dcr l
EndM
StkMvDn _rp
EndM


CSEG
PUBLIC Spt216

; Non-reentrable
; Needs disabled interrupts
; <HL> - sprite address
; <DE> - screen address

Spt216: shld ldSpr+1
lxi h,0
dad sp
xchg ; <HL> - screen address, <DE> - return address
ldSpr: lxi sp,0

sp16lp: SpMvUp b,16
inr h
SpMvDn b,16

mov a,h
adi 20h
mov h,a

SpMvUp b,16
dcr h
SpMvDn b,16

xchg
sphl
ret
End

Собственно вот.
Аппликуха содержит 2 рендерера, чтоб их было проще сравнивать и охаить :D

1. Обычный рендерер (оранжевый цвет уровня)
2. Frame-Buffered рендерер (красный цвет уровня)

Переключнение между рендерами - пробелом.
Остальное-как раньше - стрелки, плюс - rendering на весь экран, минус - во viewport. Заранее прошу извинить за глюк - после переключения vieport-fullscreen возможен пустой экран и часто будет необходимо нажать какую-нить клавишу-стрелку для отрисовки.
АР-2 (esc) - выход в МикроДОС.

Разница между рендерерами особенно заметна на полном экране.
Мне лично больше нравится рендеринг с фрэйм буфером. Он хоть и *слегка* помедленнее, зато у него отсутствуют глюки ОХЛ при строчной развёртке. В общем, рад буду вашим комментам.

Следующий этап:
- поточить frame-buffered renderer на предмет плавности (всё определяется кодом в ISR, его количеством и стабильным числом тактов в ней)
- вывод оверлеев. Чувствую, это будет отдельная песня.

PPC, Если включить эмуляцию багов програмирования палитры (ну или смотреть на реале), то новый рендер глючно работает

А мжно выложить вертикальный скролл для того чтобы он мог снизу вверх поднимать анимированные спрайты разного размера ? Левая часть экрана под это дело задействована. Правая картинка. Грубо говоря напополам.

Желательно в Аласм

Цитата:

---

Сообщение от Ramiros

PPC, Если включить эмуляцию багов програмирования палитры (ну или смотреть на реале), то новый рендер глючно работает

---

Пасиб, это я поторопился когда писал custom ISR, и забыл Rept/EndM при программировании палитры поставить. Вот исправленная версия. Пишет в 0С 8 раз при переключении палитры. В принципе, я встречал тяжёлые случаи, когда и 8 было мало, но в любом разе этот код-промежуточный вариант.

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

Но однако, плавный вывод оверлеев оказался очень крепким орешком. Дело даже не в быстродействии (его то вроде достаточно), а в плавности всего рендеринга. Я уже начинаю подумывать о синхронизации через i8253 и создании multithreaded отрисовки.
В идеале видится самосинхронизирующийся код, который при выводе оверлеев, требующих перерисовки принимает решение, уместится ли перерисовка конкретного оверлея по тактам сейчас, до прерывания, или надо ждать следующего, пытаясь отрисовать сейчас более мелкие спрайты.

Реально прошу у всех помощи с музыкой. Нужен source как можно более быстрого плейера для AY с учётом векторовских wait states. Желательно, чтобы плейер умел играть какие-нить распространённык форматы. У меня есть сорцы старых плейеров времён демок Lyra, но уж очень они ветвисты. Заранее спасибки!

Цитата:

---

Сообщение от AAA

А мжно выложить вертикальный скролл для того чтобы он мог снизу вверх поднимать анимированные спрайты разного размера ? Левая часть экрана под это дело задействована. Правая картинка. Грубо говоря напополам.
Желательно в Аласм

---

Так ведь уже в зааттаченных примерах уровень скроллится во viewport произвольного размера. Пол-экрана ничем не хуже, чем "окно" в примерах.

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

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

Есть даже более амбициозная идея: попытаться сделать поддержку многоплановости как в нинтендовских игрушках.
То есть имеется передний план уровня, движущийся с большей скоростью и задний - с меньшей. Векторовская архитектура видеоплоскостей идеально для этого подходит. Даже с фрейм-буферизированным выводом, можно задействовать по одной плоскости для заднего плана, и по 2-для переднего.

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

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

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

Вопрос в следующем, а как скодить чтобы:

http://s006.radikal.ru/i213/1106/47/0ca9eb33bb6b.jpg

В играх, например так летают враги в самолетных играх. По разным траекториям. Как оно скодить ? Спрайты в свою очередь должны спрайтить, а не быть одной фазой.

Цитата:

---

Сообщение от AAA

VNN По разным траекториям. Как оно скодить ? Спрайты в свою очередь должны спрайтить, а не быть одной фазой.

---

Со спрайтами - просто. Вверх/вниз проблем на Векторе двигать нет, можно хоть на пиксель.
Берётся спрайт и решается, насколько плавно он должен двигаться вбок. Скажем, если вбок надо тоже 1 пиксель, то прямо в runtime создаютя ещё 7 битмапов спрайта, сдвинутых на нужное количество пикселов.
Затем пишется код, переводящий текущие координаты, скажем, левой нижней точки спрайта в адрес начальной плоскости на экране и адрес сдвинутого на n бит спрайта из 8 подготовленных. В качестве примера, посмотрите мои сорцы аж бородатого 93 года с образа PPCLIB.fdd:http://sensi.org/~svo/scalar/ware/829/

Подойдут pixel.mac, line.mac, rectangl.mac
Там-же пример маскирования плоскостей (прозрачности частей спрайта)

Если говорить о скролле и забыть о том, что вывод тайлов через lxi + push все равно быстрее, то на 6128 применение недокументированных команд может оказаться оправданным.
Скролл вниз - pop h + shlx + inr e + inr e. По скорости и размеру, казалось бы, получается аналогично pop h + shld, но зато достаточно развернуть процедуру сдвига одного столбца, а не всех, как в случае shld, т.е. размер будет в {количество столбцов} раз меньше. В связи с отсутствием на 6128 квазидиска это особенно актуально. На ВМ1 inr по 8 тактов, что уже не так интересно.
Скролл вверх на 4 такта медленнее - lhlx + push h + dcr e + dcr e, но выигрыш по размеру остается.

Года 2 назад я самоуверенно утверждал, что субтайловый рендерер на Векторе просадит скорость до неиграбельной.

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

Мне думается, что очень легко сделать программный скролл тайлмапа с дискретностью в 8 пикселов, и практически такой же скоростью как в Роботах. То бишь чистый скроллерный движок тайлов (без спрайтовых оверлеев, музыки и т.п.), может в теории давать 17-18 кадров в секунду во вьюпорт размером 208x160 пикселов при сохранении двойной видео буферизации. Тайлы - такого же размера, как и в Роботах: 16x16 пикселов, 2 бита на пиксел, змейкой.

Идея в том, что необходим рендерер как выше (стеком), но имеющий 2 дополнительные ветки кода для вывода только левой половины тайла (1 байт по горизонтали) и для вывода правой половины тайла. Дискретность рендерера устанавливается в 8 пикселов (сдвиг по горизонтали побайтно). При выводе первой и последней вертикальной колонки тайлов используются 2 новые процедуры, выводящие по пол тайла (правая половина тайла для первой колонки и левая половина тайла для последней) или по целому тайлу в зависимости от чётного и нечётного кадра. Получаем субтайловый 8-пиксельный рендерер со скоростью как в Роботах. Вывод оверлеев, привязанных к координатной сетке тайлмапа (т.е. спрайтов, но с не произвольной координатой, типа батареек в Роботах), при этом становится сложнее так как им тоже нужно делать клиппинг, но к счастью по такому же 8-пиксельному алгоритму, то бишь, без сдвигов.

При определённых серьёзных ухищрениях, можно сделать и рендерер с субтайловой точностью в 2 пиксела и скоростью вывода наверное не хуже, чем в 2 раза по сравнению с Роботами (на самом деле-практически сравнимой). Для этого нужно при загрузке сдвинуть все тайлы на 0,2,4,6 бит, заполнив сдвинутые биты нулями и уложить полученные сдвинутые изображения в 4 банка RAM-диска в соответствии со сдвигом. При выводе нужен будет рендерер, получающий изображение тайла сложением (OR-ом) сдвинутых изображений для смежнных тайлов из 2х банков. Вывод оверлеев при 2-х пиксельной субтайловой точности придётся делать также используя клиппинг и заготовленные сдвинутые части битмапов.