Пишу шедевр для «Вектора 06Ц»

[KTSerg]

А без разницы. Будет такой-же эффект, но с другой стороны экрана. Нужно оставлять пустое место, выводить и сдвигать попиксельно (по одной линии).

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

[Advertiser]

[metamorpho]

А без разницы. Будет такой-же эффект, но с другой стороны экрана. Нужно оставлять пустое место, выводить и сдвигать попиксельно (по одной линии).

Попиксельно медленно получается. На видео аппаратный вертикальный скроллинг сдвигается на 4 пикселя когда происходит обработка прерывания.

[KTSerg]

Попиксельно медленно получается. На видео аппаратный вертикальный скроллинг сдвигается на 4 пикселя когда происходит обработка прерывания.

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

[metamorpho]

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

Сейчас используются все 16 цветов, т.к. все спрайты выводятся в 4 плоскости.

[KTSerg]

Сейчас используются все 16 цветов, т.к. все спрайты выводятся в 4 плоскости.

Но в спрайтах ведь не используется вся палитра, или все спрайты содержат более 8 цветов?
Я о том, что можно ведь оптимизировать по скорости, и сделать отдельные алгоритмы вывода, для персонажа, стен, и не знаю как их назвать - собираемые элементы...
Тогда вывод будет быстрее, а если спрайты стен содержат не более 8 цветов, то сделать "ширму" сверху и снизу для зоны скролинга.

[metamorpho]

Но в спрайтах ведь не используется вся палитра, или все спрайты содержат более 8 цветов?
Я о том, что можно ведь оптимизировать по скорости, и сделать отдельные алгоритмы вывода, для персонажа, стен, и не знаю как их назвать - собираемые элементы...
Тогда вывод будет быстрее, а если спрайты стен содержат не более 8 цветов, то сделать "ширму" сверху и снизу для зоны скролинга.

KTSerg, спасибо за совет!! У меня такие же идеи насчёт оптимизации по скорости.
Это (я так думаю) хороший вариант - написать для разных спрайтов разные подпрограммы их вывода в зависимости от количества используемых в них цветов.

Про "ширму":
- не хочется терять 8 цветов, т.к. в планах сделать игрушку такую же цветастую как PUTUP
- даже если делать "ширму" то при аппаратном вертикальном скроллинге сдвигаются все 4-и плоскости, включая "ширму". И выходит мне нужно будет и спрайты нарисовать и "ширму" обновить. Похоже разница в скорости будет небольшой. Хотя тут есть зависимость от количества цветов используемых в стенах.

[KTSerg]

...
Про "ширму":
- не хочется терять 8 цветов, т.к. в планах сделать игрушку такую же цветастую как PUTUP
- даже если делать "ширму" то при аппаратном вертикальном скроллинге сдвигаются все 4-и плоскости, включая "ширму". И выходит мне нужно будет и спрайты нарисовать и "ширму" обновить. Похоже разница в скорости будет небольшой. Хотя тут есть зависимость от количества цветов используемых в стенах.

"Ширма" это всего одна экранная плоскость, заполнять её стеком значением FFFFh, или удалять, занося стеком 0000h (два PUSH H - вот четыре строки одной колонки уже готовы, дольше адрес стека менять), это быстрее, чем все плоскости, да ещё плюс сопутствующая логика выбора спрайта, хотя это и мизер должен быть.
Хотя надо посчитать, может стеком "ширму" формировать и не выгодно, по времени.

[Improver]

metamorpho, KTSerg, посмотрел я видео, мне кажется, движения вверх-вниз вполне хорошо выглядят, не хуже, чем в других играх на Вектор, или на той же денди (оно же NES). И решение делать прорисовку в противоположной движению стороне экрана тоже верное, туда обычно никто не смотрит, нет смысла как-то ухудшать шедевр. Извиняюсь за своё некомпетентное в плане игрописания мнение...

[svofski]

В этом вся суть аппаратного скроллинга. Его очень трудно применить на практике с выгодой. Приходится жертвовать очень много чем.

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

Если этого не делать в каждом кадре, то это не такая уж большая проблема. Можно просто выделить например один из 8 кадров на разные задачи, которые не требуют немедленного исполнения.

[metamorpho]

Improver, спасибо !!
Но всегда хочется сделать ещё лучше

....Чтобы не было мельтешни на краях экрана, надо подтирать низ сразу после прерывания, задолго до того, как эта область будет просканирована лучем. А верх незадолго до перывания, чтобы он был чистым сразу после прерывания.
Если этого не делать в каждом кадре, то это не такая уж большая проблема. Можно просто выделить например один из 8 кадров на разные задачи, которые не требуют немедленного исполнения.

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