Чанки 4*4
 

Вопрос простой: как лучше выводить на экран чанки 4*4? Интересуют разные методы, но более всего хочется найти разумный компромисс между скоростью и размером.

Сколько градаций имеет смысл использовать? Можно ли обойтись меньшим количеством, чем 16? Есть ли смысл?
Сейчас думаю, что имеет смысл все варианты совпадений чанковых пар в знакоместе просчитать заранее и хранить отдельной таблицей:
При количестве градаций=16, количество пар будет 16*16, каждая по 4 байта, итого килобайт на таблицу.

Можно ли как-то выводить такие пары стеком? есть ли смысл?

Имхо, стоит сразу выводить горизонтальными рядами толщиной в 1 пиксель, чтобы не пересчитывать каждый раз адрес следующей строки экрана?

Или есть какой-то более продуманный и оптимальный метод?

Готовые процедуры не особо интересуют, потому что самостоятельная реализация даёт немалую часть удовольствия, да и для обучения гораздо полезнее :)

Может быть, кто-то вспомнит готовые статьи с теорией?

Хорошая статья была в DoD#2. Ещё в SNG#2 Senat писал, что надо делать буффер 38*256, кстати такой использовался и в гоа и в рефреше.

ой, 100 лет назад это было :)
градаций меньше чем 16 использовать смысла нет, если не надо только сильно экономить память.
буфер ИМХО оптимальный - 32x64. напальм, догма, ещё куча демок.

смотря что будет приносить большие затраты по времени, либо INC H (D, B) на переход на следующую строку в экране, либо просчёт адреса чанка

если я правильно помню как делал, то забирать из чанкового буфера надо через стек, а на экран валить через LD (HL),r

спойлер:


LD SP,BUFEND
DUP 32*32
LD DE,#4000 ; адрес в экране
POP HL
LD A,H
ADD A,#xx
LD H,A
LD A,(HL):LD (DE),A:INC H:INC D
LD A,(HL):LD (DE),A:INC H:INC D
LD A,(HL):LD (DE),A:INC H:INC D
LD A,(HL):LD (DE),A:INC H:INC D
EDUP

данные в буфере предполагаются валидными.
кстати, немного извратив методу, можно избавиться от
LD A,H
ADD A,#xx
LD H,A

Иногда делается набор процедур (256 штук) для вывода половинки знакоместа по вертикали. Входной буфер анализируется и строится стек. Потом просто делается возврат по стеку. Туда же пихаются вызовы процедур пересчета адреса. Получается весьма быстро, но затраты на построение стека...

Например так:
(большие затраты памяти, хорошая скорость)

чанки хранятся по одному в байте
таблица буфера имеет размер 64*48 линейный
из него берем через стек два значения: левый чанк в знакоместе и правый, соединяем их со смещением в 4 бита - получаем байт 0..255
по нему из таблички переходов берем адрес перехода на построение текущего значения чанков
типа вот процедура вывода:
chunkXXX ld a,h
ld (hl),nn
inc h
ld (hl),nn
inc h
ld (hl),nn
inc h
ld (hl),nn
ld h,a
jp ret_adr

Адрес следующей строки берем тоже из таблички

Добавлено через 1 минуту
выводить по половинкам неоптимально!!!!
в любом случае как бы не хранился сам буфер с изображением выводим сразу и правую и левую половинку знакоместа одновременно!!!

Добавлено через 3 минуты
Вся эта процедура будет занимать порядка 6K

Столько демок понаписно, а вы тут велосипед изобретаете.
Harm смотрите и прочие демки от TBK/4D.
И CJ молчит, демку наверно пишет? :)

Точно помню алонкодер в своем журнале писал полезные вещи по поводу чанок и 2d эффектов.

пишу - пишу =)

всем спасибо, будем пробовать :)

Все что напробуешь посылай на Di:Halt!! ;)

Давно бы уж создали команду ZX.PK.RU и сделали демку :-)
Если не ошибаюсь - в прошлом году так поступили democoder.ru