Вид для печати
Код:
;в данном случае концепт для спрайта 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
не, это я понял, не понял про оры-ксорыЦитата:
Сообщение от SaNchez
Можно сделать классическую маску - AND/OR, а можно OR/XOR, где данные будут инвертированы, но в итоге получится та-же картинка на экране. Выигрыш - не нужно делать две 4kb таблицы, хватит одной. Дальше думай сам ;)
В общем, переделал процедуру на работу с таблицами. Получил хорошие показатели: 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
SaNchez, и итоге всё сильно будет зависеть от кол-ва памяти в игре.
Давно я выкладывал пример без таблиц который. Если интересно поизучай. Самые медленные сдвиги на 3 и 5 в итоге.
Всё сильно зависит от условий, какие спрайты будут по размерам, способ и место хранения графики... Изменение горизонтальных размеров в процессе вывода итд... Вся обвеска в итоге сводит на нет любую оптимизацию, и память... когда она заканчивается уже не до скорости :)
О, интересно!Цитата:
Сообщение от drbars
Можно глупый вопрос задать? Уже не напрямую к выводу относящийся, но тем не менее с ним связанный. Про экономию памяти. Знаю, что для этого часто прибегали к трюку, когда часть спрайта оставалась неизменяемая (туловище), а часть с анимацией (ноги) при движении. А что если сделать немного по-другому (это больше подойдёт к способу вывода без таблиц) - поскольку обычно анимация различных действий непрерывная и зацикленная, то что мешает делать как в запиляторе\видеокодеках - первый кадр спрайта основной, а остальное последовательные диффы (биты\маска)? Интересно насколько это выгоднее (придётся ведь оффсет всё-равно какой-то от начального кадра хранить дополнительно для каждого из блоков изменений и между ними)?
И сразу же возникнет проблема - композинг спрайтов на экране когда они друг на дружку налезают. Ведь для каждого придётся отдельный буфер иметь иначе на что изменения накладывать?
PheeL, спрайты — это 10% кода игры. Способов вывода придумано много, таблицы движения, прекалькуляция движения, мегакод итд... Любая упаковка дельта кадрами это драгоценные такты, а их терять никто не хочет. Композинг тоже всяко делают, кто-то весь экран из буфера рисует, а кто-то подложку под спрайтом... или по XOR'у выводят.
PheeL, Walker используется подобная технология для ГГ
остальные увы - так делать неэфективно
Глянул исходники, скроллировать спрайт в буфере - идея не очень... До размеров 32х32 лучше двигать прямо в регистрах. Я обычно затягивал в стек спрайт из нужной банки, а потом pop-ами кидал в регистры. Это очень хорошо сочеталось с работой с двумя экранами.Цитата:
Сообщение от drbars
Сейчас меня волнуют спрайты с любой шириной, и в итоге таблицы подошли идеально, спасибо jerri за идею.