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

[Ramiros]

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

[Advertiser]

[AAA]

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

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

[PPC]

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

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

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

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

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

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

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

[AAA]

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

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



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

[PPC]

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

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

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

[PPC]

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

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

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

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

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