Вид для печати
Да это понятно.Цитата:
Сообщение от b2m
Просто из практического интереса, как это будет выглядеть.
Хотя скорее всего текущий вариант более приемлим, т.к. в сторону движения лабиринт выезжает уже готовый, а мерцание лабиринта происходит за спиной. Хотя сейчас снова посмотреть видео (присмотреться к артефактам) не получается, а утром нормально показывало.
Попиксельно медленно получается. На видео аппаратный вертикальный скроллинг сдвигается на 4 пикселя когда происходит обработка прерывания.Цитата:
Сообщение от b2m
Напомни, сколько цветов сейчас используется, для элементов лабиринта (я стены имею в виду) ?Цитата:
Сообщение от metamorpho
Сейчас используются все 16 цветов, т.к. все спрайты выводятся в 4 плоскости.Цитата:
Сообщение от KTSerg
Но в спрайтах ведь не используется вся палитра, или все спрайты содержат более 8 цветов?Цитата:
Сообщение от metamorpho
Я о том, что можно ведь оптимизировать по скорости, и сделать отдельные алгоритмы вывода, для персонажа, стен, и не знаю как их назвать - собираемые элементы...
Тогда вывод будет быстрее, а если спрайты стен содержат не более 8 цветов, то сделать "ширму" сверху и снизу для зоны скролинга.
Цитата:
Сообщение от KTSerg
KTSerg, спасибо за совет!! У меня такие же идеи насчёт оптимизации по скорости.
Это (я так думаю) хороший вариант - написать для разных спрайтов разные подпрограммы их вывода в зависимости от количества используемых в них цветов.
Про "ширму":
- не хочется терять 8 цветов, т.к. в планах сделать игрушку такую же цветастую как PUTUP
- даже если делать "ширму" то при аппаратном вертикальном скроллинге сдвигаются все 4-и плоскости, включая "ширму". И выходит мне нужно будет и спрайты нарисовать и "ширму" обновить. Похоже разница в скорости будет небольшой. Хотя тут есть зависимость от количества цветов используемых в стенах.
"Ширма" это всего одна экранная плоскость, заполнять её стеком значением FFFFh, или удалять, занося стеком 0000h (два PUSH H - вот четыре строки одной колонки уже готовы, дольше адрес стека менять), это быстрее, чем все плоскости, да ещё плюс сопутствующая логика выбора спрайта, хотя это и мизер должен быть.Цитата:
Сообщение от metamorpho
Хотя надо посчитать, может стеком "ширму" формировать и не выгодно, по времени.
metamorpho, KTSerg, посмотрел я видео, мне кажется, движения вверх-вниз вполне хорошо выглядят, не хуже, чем в других играх на Вектор, или на той же денди (оно же NES). И решение делать прорисовку в противоположной движению стороне экрана тоже верное, туда обычно никто не смотрит, нет смысла как-то ухудшать шедевр. :) Извиняюсь за своё некомпетентное в плане игрописания мнение...
В этом вся суть аппаратного скроллинга. Его очень трудно применить на практике с выгодой. Приходится жертвовать очень много чем.
Чтобы не было мельтешни на краях экрана, надо подтирать низ сразу после прерывания, задолго до того, как эта область будет просканирована лучем. А верх незадолго до перывания, чтобы он был чистым сразу после прерывания.
Если этого не делать в каждом кадре, то это не такая уж большая проблема. Можно просто выделить например один из 8 кадров на разные задачи, которые не требуют немедленного исполнения.
Improver, спасибо !!
Но всегда хочется сделать ещё лучше :)
svofski, возможно я не совсем понял эту мысль. Но у меня нет двойного затирания (вверху и внизу) как такового, поскольку напримерЦитата:
Сообщение от svofski
при движении главного героя вверх происходит скроллинг экрана вниз
при этом внизу рисуется то что перемещается вверх экрана
т.е. у меня лишь один раз рисуется новая часть при этом затирая сразу ненужную старую.