потому что 7*inc+add лучше, чем 8*inc+add хоть в развёрнутом, хоть в неразвёрнутом варианте
но если ты к $47XX прибавишь $F820, то получишь $3FZZ/$40ZZ, а не $40ZZ/$48ZZ
у тебя не +6, а +7 без обрезки; у меня 26 с обрезкой, 17 без обрезки
но из них нужны реально лишь 8/5, а промежутки можно использовать
то есть у тебя реально больше места даже без обрезки уйдёт
проиграть и в скорости, и в размере, лишь бы не планировать таблицу, really?
это даже без учёта, что вероятность перехода сегмента может сильно изменяться от геймдизайна
например, сайдскроллер на 2/3 экрана, где в основном движуха по центральной оси
какой смысл в оптимизации вообще, если не упарываться всерьёз? 8)
расстояние в таблице (для всего экрана) от первого нужного байта до последнего 16 байт
с заворачиванием или обрезкой по низу — еще плюс один байт, с обрезкой по верху — еще плюс 8
в твоём случае +7 байт на обработку перехода с обратным jr и больше без него (дубль хвоста)
еще больше с проверкой обрезки, еще больше с заворачиванием
Ачо размер? Умеренный, как по мне, плюс еще и генерить очень быстро, где-то даже динамически будет выгодно. Развороту djnz перпендикулярно и не мешает, наоборот — даже чуть проще и быстрее станет после него.
...
_main1: inc h
_main2: ...
djnz _main1
ld b,c ; c = $20
add hl,bc
ld h,(hl) ; таблицы кусками по 256 байт @ ... $6700, $6800, $6F00, $7000, $7700 ...
ld b,8
dec xl ; счётчик символьных строк вместо занятого c
jp nz,_main2
exa ; zf сохранён на повторный приход сюда
ld b,a ; длина хвоста и флаги после and7 при первом входе
jp nz,_main2 ; если ненулевой хвост и не повторно сюда попали
_end: ld sp,0
ret
Это адаптация из опытов по быстрой отрисовке отрезка (где sp вместо bc применяется) — где-то рядом уже как-то упоминал. Хотя для реальных небольших спрайтов (а не фантастичных на полэкрана) разница по скорости незаметна. Более весомая выгода подобных таблиц на практике — бесплатный вертикальный wrap или clip (перенаправлением в ПЗУ) для окна из 1-3 сегментов.
Хех, «интереснее» — это в смысле преодоления собственноручно созданных себе трудностей? И зачем на полноценную корку вешать функции очень примитивного блиттера, какой в чистом виде получился бы быстрее и проще?
Что касается аппаратных тайлоспрайтов, это же древнее решение для древних же проблем, которые давно отпали сами собой (то есть тормознутости и малых объёмов видеопамяти). Никаких разумных причин применять это решение сейчас при создании нового псевдоретро железа не вижу. Смысл есть только в ускорении относительно старого готового железа новой прошивкой (дендиконфа)
Это как? Внешний доступ к памяти возможен, к регистрам — нет, а ведь в них по итогу калькуляторных процедур определённые значения ожидаются. Разве что обманом заставить проц по im0 выполнить команды загрузок, да еще нужные значения им подсунуть. Твой аух сумеет разве такое?
«Я тут пишу код и мне хотелось бы для этого иметь EX HL,HL', было бы удобнее, быстрее и компактнее». Это подразумевает, что мы берём быстрые циклы для Z80 и ищем как их ускорить. Но качественные реформы, вроде расширенного блока регистров предложенного выше, на самом деле радикально меняют весь подход к оптимизации кода.
радикально изменить подход может и одна-единственная команда
например, ex sp,hl вместо (или вместе с) ld sp,hl
Нет, не стоит. Потому что это всё, во-1, необязательно признак неумелости, а во-2, не настолько большинство, как линейный буфер. Контрпримеры легче найти гораздо, чем примеры с буфером в юлашной раскладке.
В подавляющем, абсолютном большинстве игрушек линейный буфер, так что и умеющие так делали. Для игродела плюсов в спековской раскладке весьма немного и они только в очень частных случаях проявляются. А вот неудобства намного чаще.
Каждый раз ор и рукалицо с этих костылей. А вы думали, вот что надо сделать, чтоб исправить неудобство адресации оригинальной юлы? Ага, точно — надо «исправлять» другой и самый сложный компонент — процессор, вместо простого. С результатом всё равно неудобнее, чем у старых самопальных компов советских. Вот казалось бы, всё равно со спеком несовместимо, ну запилите вы прозрачную трансляцию адреса. Но нет, эти люди лёгких путей не ищут.
но если ты к $47XX прибавишь $F820, то получишь $3FZZ/$40ZZ, а не $40ZZ/$48ZZ
но из них нужны реально лишь 8/5, а промежутки можно использовать
то есть у тебя реально больше места даже без обрезки уйдёт
проиграть и в скорости, и в размере, лишь бы не планировать таблицу, really?
это даже без учёта, что вероятность перехода сегмента может сильно изменяться от геймдизайна
например, сайдскроллер на 2/3 экрана, где в основном движуха по центральной оси
расстояние в таблице (для всего экрана) от первого нужного байта до последнего 16 байт
с заворачиванием или обрезкой по низу — еще плюс один байт, с обрезкой по верху — еще плюс 8
в твоём случае +7 байт на обработку перехода с обратным jr и больше без него (дубль хвоста)
еще больше с проверкой обрезки, еще больше с заворачиванием
и да, чтоб не нужно было выполнять лишний inc, прибавлять следует 32-7*256
Вариант с байтами, собранными рядом в мини-табличку, 57 тактов:
(регистр c здесь освободился под счётчик и -4 такта префикса учтены в сумме)
Это адаптация из опытов по быстрой отрисовке отрезка (где sp вместо bc применяется) — где-то рядом уже как-то упоминал. Хотя для реальных небольших спрайтов (а не фантастичных на полэкрана) разница по скорости незаметна. Более весомая выгода подобных таблиц на практике — бесплатный вертикальный wrap или clip (перенаправлением в ПЗУ) для окна из 1-3 сегментов.
Что касается аппаратных тайлоспрайтов, это же древнее решение для древних же проблем, которые давно отпали сами собой (то есть тормознутости и малых объёмов видеопамяти). Никаких разумных причин применять это решение сейчас при создании нового псевдоретро железа не вижу. Смысл есть только в ускорении относительно старого готового железа новой прошивкой (дендиконфа)
+ еще загрузить корректный указатель стека кроме HL
как-то не особо «просто» уже всё это
например, ex sp,hl вместо (или вместе с) ld sp,hl
и кстати, с чисткой атрибутов не всё в порядке, иногда спрайт игрока перекрашивает фоновые платформы