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

Всем привет!

Одолела меня ностальгия, и я решил попробовать сделать программный вертикальный скролл. Программный - потому что аппаратная прокрутка сдвигает весь экран сразу, а в играх как раз зачастую скроллируется только часть экрана, представляющая собой игровое поле, а информационная часть остается неподвижной (например, как в "1942" и "1943" на ZX Spectrum).

Увы, даже если ограничиться 21 столбцом по горизонтали и одной экранной плоскостью, в прерывание вписаться не удается - даже применяя частично развернутые циклы и пересылку экранной памяти через стек :( Может быть, кто-то из опытных вектористов глянет на мой код и скажет, где проблема? (надеюсь, не в ДНК :) )

Можно двигать чуть быстрее, если вместо
pop\ mov \ inr \ mov \ inr (44 такта на пересылку 2х байт)
сделать
pop\ shld (32 такта на пересылку 2х байт)
только придется отдать 4 байта для процедуры пересылки на каждые 2 пересылаемые байта
теоретический предел в этом случае: 312(строк)*192(такта в строке)/32(такта)*2(байта)=3744 байта можно переслать за промежуток между прерываниями. Только времени ни на что больше не останется и процедура пересылки займет более 7000 байт.

Если речь идет не о переносе с другого компа и движок пишется с нуля, то может стоит прикинуть - если площадь скролируемого участка экрана больше площади неподвижного(ых) участка(ов) то выгоднее применять аппаратный скролл и программно обновлять "неподвижные" участки. Принцип относительности :).

:v2_thumb: Я тоже думал о таком способе (тем более, что в "Полете" именно так и сделано). Припоминаю, что в студенческом возрасте даже пытался подобное реализовать, но безуспешно, поскольку про "джедайские приемы" вроде вывода через стек я тогда и не слышал.

Отдельное спасибо за формулу расчета количества тактов на прерывание!

Если заюзать Z80 то там есть циклические команды блокового перемещения данных

Попробовал воплотить в кодах, работает (если интересно, см. вложение). Правда, "неподвижные" участки пришлось выводить не через стек, т.к. если записывать в видеоОЗУ через PUSH, то на границе номеров строк 00/FF будут глюки. А если каждый раз проверять текущее значение SP и его корректировать при достижении границы, то это мне показалось накладным по тактам... В случае чего, задействую стек для чтения спрайтов из ОЗУ (пока что, правда, спрайт один и он жестко зашит в коде :) )

P.S. Файл с расширением .MAC во вложении - это исходник на ассемблере. Я пользуюсь дисковым ассемблером M80, для которого именно это расширение стандартное. Сначала было .ASM, но я замучался его постоянно вручную дописывать при компиляции :)

Я так понимаю, что River Raid-у на Векторе всё-таки быть =)

Ещё раз про программный скроллинг, гляньте кому интересно, код писал под Z80

В плане графики - точно ничего не мешало. В своё время от идеи написания этой игры меня отвернуло только то, что я не сумел найти способ генерировать шум самолёта и взрывов. На Atari для этого был специальный "музыкальный процессор", на Векторе потом тоже появился AY, но это уже было значительно позже. А делать полуфабрикат - очень не хотелось.

Обалденный горизонтальный скролл в демке From Sunset To Dawn, если кто не видел.

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

К слову сказать, в 1990-раннем году я был бы готов стерпеть River Raid без правильных звуков =) Но мне кажется, что с графикой тоже все не так уж просто. Если и возможно достаточно плавно обновлять экран, то умения это должно потребовать немалого.