Вывод спрайта любой ширины с точностью до пикселя.

[jerri]

;в данном случае концепт для спрайта 2 байта шириной

;de - адрес на экране
;hl ссылка на таблицу
;sp спрайт


ld a,(de)

;левый байт

pop bc
ld l,c
or (hl)
ld l,b
xor (hl)
ld (de),a

inc h
inc e

ld a,(de)
ld l,c
or (hl)
ld l,b
xor (hl)

dec h

;правый байт

pop bc

ld l,c
or (hl)
ld l,b
xor (hl)

ld (de),a

inc h
inc e

;остаток правого байта переносим на экран

ld a,(de)
ld l,c
or (hl)
ld l,b
xor (hl)

ld (de),a

;далее пересчитываем адрес на экране, размер по вертикали и ссылку на таблицу 

dec h

[Bedazzle]

Можно сделать таблицу подготовленных значений сдвигов

не, это я понял, не понял про оры-ксоры

[SaNchez]

Можно сделать классическую маску - AND/OR, а можно OR/XOR, где данные будут инвертированы, но в итоге получится та-же картинка на экране. Выигрыш - не нужно делать две 4kb таблицы, хватит одной. Дальше думай сам

[SaNchez]

В общем, переделал процедуру на работу с таблицами. Получил хорошие показатели: 116 тактов на один байт с маской. По сравнению с реальными сдвигами - 110 тактов сдвиг в 1 пиксель, 214 тактов сдвиг в 4 пикселя.

;ix - данные спрайта
;de - адрес на экране
;h - старший байт адреса таблицы для соответствующего сдвига
;bc - предыдущие значения маски/данных, в начале прорисовки строки = 0

                                                ld l,(ix)
						inc ix
						ld a,(de)
						or (hl)
						or b
						xor c
						inc h
						ld b,(hl)
						ld l,(ix)
						inc ix
						ld c,(hl)
						dec h
						xor (hl)
						ld (de),a

[drbars]

SaNchez, и итоге всё сильно будет зависеть от кол-ва памяти в игре.

Давно я выкладывал пример без таблиц который. Если интересно поизучай. Самые медленные сдвиги на 3 и 5 в итоге.

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

[Bedazzle]

Давно я выкладывал пример без таблиц который.

О, интересно!

[Advertiser]

[PheeL]

Можно глупый вопрос задать? Уже не напрямую к выводу относящийся, но тем не менее с ним связанный. Про экономию памяти. Знаю, что для этого часто прибегали к трюку, когда часть спрайта оставалась неизменяемая (туловище), а часть с анимацией (ноги) при движении. А что если сделать немного по-другому (это больше подойдёт к способу вывода без таблиц) - поскольку обычно анимация различных действий непрерывная и зацикленная, то что мешает делать как в запиляторе\видеокодеках - первый кадр спрайта основной, а остальное последовательные диффы (биты\маска)? Интересно насколько это выгоднее (придётся ведь оффсет всё-равно какой-то от начального кадра хранить дополнительно для каждого из блоков изменений и между ними)?
И сразу же возникнет проблема - композинг спрайтов на экране когда они друг на дружку налезают. Ведь для каждого придётся отдельный буфер иметь иначе на что изменения накладывать?

[drbars]

PheeL, спрайты — это 10% кода игры. Способов вывода придумано много, таблицы движения, прекалькуляция движения, мегакод итд... Любая упаковка дельта кадрами это драгоценные такты, а их терять никто не хочет. Композинг тоже всяко делают, кто-то весь экран из буфера рисует, а кто-то подложку под спрайтом... или по XOR'у выводят.

[jerri]

PheeL, Walker используется подобная технология для ГГ
остальные увы - так делать неэфективно

[SaNchez]

SaNchez, и итоге всё сильно будет зависеть от кол-ва памяти в игре.

Давно я выкладывал пример без таблиц который. Если интересно поизучай. Самые медленные сдвиги на 3 и 5 в итоге.

Глянул исходники, скроллировать спрайт в буфере - идея не очень... До размеров 32х32 лучше двигать прямо в регистрах. Я обычно затягивал в стек спрайт из нужной банки, а потом pop-ами кидал в регистры. Это очень хорошо сочеталось с работой с двумя экранами.

Сейчас меня волнуют спрайты с любой шириной, и в итоге таблицы подошли идеально, спасибо jerri за идею.