Просчитал кусочную попиксельную прокрутку пикового экрана
Получилось около 21000 тактов, считая строчные переходы
Но без учета предварительной подготовки (о ней потом)
Сначала излагаю сам принцип
Формат хранения ландшафта теперь не важен
лишь бы вовремя получать новый столбец подрисовки
Каждая символьная строка крутится динамически создаваемой процедурой
которая вызывается в кадре 4 раза (а всего в том же виде - 32 раза)
Установка регистров
а также сдвигом байта подрисовки устанавливается исходный бит переносаКод:Один раз на весь экран: B = правый обрыв (или левая стенка шахты) A'= not B (противоположная стенка) (C использовать нельзя, его испортит LDD) В начале строки: HL = адрес начального (правого) байта первой строки DE = адрес начального (правого) байта второй строки A = L = E
Сама процедура-скроллер состоит из следующих стандартных фрагментов
...ну и возврат по команде retКод:чистая вода и сплошная земля просто пропускаются: пропуск одного знакоместа (8 тактов) dec l dec e пропуск двух знакомест (12 тактов) dec l dec l ld e,l пропуск трех и более знакомест (15 тактов) sub N ld l,a ld e,a (внимание - N не всегда равно кол-ву пропускаемых) (корректируется поcледнее значение аккумулятора) правый обрыв или левая стенка шахты (22 такта) ld (hl),b ex de,hl ld (hl),b ex de,hl левый обрыв или правая стенка шахты (22 такта) exa ld (hl),a ld (de),a exa (указатель остался там же, нужен явный пропуск) (условно) правый склон (31 такт) sla (hl) ldd (условно) левый склон (31 такт) sli (hl) ldd эти два куска нужны только сразу после длинного пропуска из-за испорченного вычитанием прошлого переноса во всех остальных случаях используется rl (hl) ldd
Хочу заметить, что и вызывать оную процедуру тоже лучше всего через ret
потому что она будет постоянно "отползать" в младшие адреса каждые 8 кадров
по мере того как будут распакованы и добавлены в подрисовку следующие тайлы
Так что лучше просто корректировать адреса, раз и навсегда уложенные в скрипт,
временно адресуемый указателем стека (там же сортировку спрайтов удобно)
Конечно, "отползать" вечно процедура не может - не хватит памяти
на одну знакоместную строку может потребоваться до 128 байт
а каждые 8 кадров возможен еще прирост (а строк 20 штук)
Что делать? Сдвигать обратно каждый такой кусок слишком долго
Проще всего буфер закольцевать и разбить на две части командой ret
Скрипт получится примерно вот такой:
Подготовка тоже (даже вся сразу) должна жрать гораздо меньшеКод:^установка на первую строку ^скроллер1 голова ^скроллер1 хвост ^переход растровых строк ^скроллер1 голова ^скроллер1 хвост ^переход растровых строк ^скроллер1 голова ^скроллер1 хвост ^переход растровых строк ^скроллер1 голова ^скроллер1 хвост ^переход тайловой строки ^скроллер2 голова ^скроллер2 хвост ^переход растровых строк ... ... ... ^скроллер20 хвост ^переход растровых строк ^скроллер20 голова ^скроллер20 хвост ^завершение
Но если нужно, то размазать задачу по 8 кадрам довольно просто
Например 5 кадров дописываем головы ровно по 4 скроллера
Потом два кадра отмеряем хвосты на обрезку по 10 каждый
Восьмой кадр соответственно корректируем адреса и возвраты
С такой прокруткой мины наверно выгодно делать чистыми спрайтами
кроме разве что тросов, которые лучше в ландшафт засунуть
благо их мало (прокрутка пустого места не так страшна)
а вычистить столбик прямо на экране несложно
См. скриншот в аттаче
Светлыми точками помечены прокручиваемые тайлы
желтые - sla/sli, белые - rl, зеленые - ld
(черные остались с прошлого варианта)
P.S. Однако ветку давно пора перекидывать в "Программирование"![]()




Ответить с цитированием