Быстрый попиксельный вывод спрайтов с маской без таблиц

[CityAceE]

Пишу в раздел ZX-программирования, так как принципы везде одинаковы. И общая концепция будет полезна, что для ZX-программистов, что для других ретро-компьютерщиков.

В общем, ситуация такая. Польские девелоперы выкатил нереальной красоты монохромную игру Tony: Montezuma's Gold для трех ретро-платформ: Atari 8-bit, C64 и Amiga (куда ж без неё). Не все разделяют мой восторг, но я просто писаю кипятком от того, что получилось. Готовится релиз и под ZX, правда, с несколько усечёнными уровнями из-за того, что изначально разрешение игры 320*192.

Ну так вот. Я возжелал увидеть эту игру на моём первом компьютере Специалист. Сделал демо на основе видеороликов и вроде как успокоился, так как остальное Специалист не потянет. А не потянет он прежде всего подгрузку уровней. Но в Telegram-группе по Специалисту меня уверили в том, что несколько разновидностей подключения SD-карты нивелируют эту проблему. Так, ну если подгрузку уровней он всё же потянет, то остаётся узкое место - оперативная память. На всё про всё её там только 36 кб. И в эти 36 кб нужно уместить конфигурации всех лабиринтов уровней, всю графику ландшафта, врагов и анимацию главного героя. По моим скромным подсчётам 36 килобайт на это никак не хватит. Ну ОК, если сделать каждый раз подгрузку лабиринтов с SD мы освободим некоторое место в ОЗУ, но лишь некоторое! Экономить нужно буквально на всём. В общем, уровни мы оставим на потом, а сейчас будем считать, что у нас только один экран по которому скачет главный герой. Благодаря Sanchez'у я знаю как можно круто попиксельно перемещать спрайт по экрану, а за одно и зеркалировать его. Но, к моему великому сожалению, это требует дофига памяти на таблицы. У меня этой памяти попросту нет!

Отсюда возникает вопрос вынесенный в заголовок этой темы (хоть и без вопроса). Помогите, подскажите, наведите на путь истинный!

При анализе графики выпущенной игры, персонаж движется с дискретностью в 2 пикселя и при этом имеет маску. Нужно то же самое организовать и в Специалисте максимально быстро и с минимальным потреблением памяти.

[Advertiser]

[Deadly]

Конечно таблицы сдвигов это быстро, 7*256*2=3584, так же для отражение битов ещё 256 байт.
Вариант номер раз, т.к. 2х пиксельный сдвиг то таблицу можно сократить в двое, если и это не устроит, то можно использовать предсдвинутые спрайты динамических объектов. Но вангую что их будет намного больше и 3*256=768+ 256 байт будет дешевле. Ну и ещё один вариант для каждого сдвига иметь свою заранее подготовленную функцию, да это будет не быстро, но ...

[newart]

Пишу в раздел ZX-программирования, так как принципы везде одинаковы. И общая концепция будет полезна, что для ZX-программистов, что для других ретро-компьютерщиков.

В общем, ситуация такая. Польские девелоперы выкатил нереальной красоты монохромную игру Tony: Montezuma's Gold для трех ретро-платформ: Atari 8-bit, C64 и Amiga (куда ж без неё). Не все разделяют мой восторг, но я просто писаю кипятком от того, что получилось. Готовится релиз и под ZX, правда, с несколько усечёнными уровнями из-за того, что изначально разрешение игры 320*192.

Я бы начал с размеров тайлсета. Сколько занимает 1 уровень? Печать тайлов планируется познакоместно или попиксельно? Уровни будут повторяться 1 в 1 или просто максимально близко визуально?

Неплохо бы составить карту уровней и оценить заполняемость экранов, попутно прикинуть каких размеров будут тайлы, сколько занимает их вывод, есть ли перекрытие тайлами спрайтов и т.п

Вообще если есть SD карта и прикручена она нормально, то можно тупо читать готовые экраны с нее. Ощущение будто бы ты сам себе органичения придумываешь.
Если цель сделать именно игру, максимально юзабельную и играбельную, а не бороться с техническими ограничениями, то замерь скорость работы с SD и от этого пляши.

p.s. Игра и правда красивая. ЧБ сделали вероятно для простоты портирования на множество платформ?

[CityAceE]

можно использовать предсдвинутые спрайты динамических объектов. Но вангую что их будет намного больше и 3*256=768+ 256 байт будет дешевле.

Не могу понять логику этой таблицы, кроме последних 256 байт на отзеркаливание. Можешь пояснить на пальцах? Если что, спрайт ГГ шириной 3 байта.

да это будет не быстро

А нужно попытаться соблюсти баланс. Чтобы и побыстрее было, и чтобы на таблицы поменьше места.

Я бы начал с размеров тайлсета. Сколько занимает 1 уровень?

Весь уровень не замерял. Но первые 8 экранов, которые я использовал в демке имеют следующие параметры:

Вся графика (только этих 8-ми экранов!): 2024 байта
Карта экранов: - 800 байт * 8 экранов
Итого 8 игровых экранов заняли: 2024 + 800 * 8 = 8424 байта.

Печать тайлов планируется познакоместно или попиксельно?

Анализ уровней говорит, что все тайлы познакоместные. Но все они не квадратные! Где-то горизонтальные, где-то вертикальные. Мне показалось, что хранить такое будет дешевел просто познакоместно. Поэтому карта одного экрана 320/8 * 160/8 = 800. Я думаю, что это потом можно будет запаковать и распаковывать непосредственно перед выводом на экран.

Уровни будут повторяться 1 в 1 или просто максимально близко визуально?

В идеале, конечно, хотелось бы повторить "от" и "до".

Неплохо бы составить карту уровней и оценить заполняемость экранов

Я сделал карту 1-го и 4-го уровня (всего в игре 5 уровней).
Первый уровень содержит 32 экрана, четвёртый - 35.

попутно прикинуть каких размеров будут тайлы,

Все тайлы абслоютно разного размера. От звезды на небе (1 знакоместо), до огромной статуи на полэкрана.

есть ли перекрытие тайлами спрайтов

Этого не замечено. Но есть колонные и другие препятствия уезжающие за передний план. Однако в этом не вижу проблем, там вполне можно обойти без маски.

сделать именно игру, максимально юзабельную и играбельную, а не бороться с техническими ограничениями

Так я пока ничего и не делаю, а как раз прикидываю насколько это возможно/невозможно на выбранной мной платформе. Но уже сейчас вижу, что упираюсь в память - 36 кб слишком мало для такого проекта. Ну хорошо, еще можно 1 + 1 кб у экрана отобрать, но это испортит внешний вид на ч/б модели. С SD-картой ранее не работал. На моём компьютере её нет, и я не знаю насколько я могу полагаться на результаты тестирования эмулятора.

[Deadly]

Классическая таблица подразумевает 7 пикселей смещений * 256 комбинаций байта * 2 байта результата.
Если мы хотим двигать что либо по 2 пикселя, то лишние смещения таблицы мы выкидывает, тем самым сокращаем её, т.е. смещение на 2, 4, 6, а на 1, 3, 5, 7 мы выкидывает, на 8 нам не нужно. Вот и получаем 3 смещения * 256 комбинаций спрайта * 2 байта результат дают 1536 байт таблицу

- - - Добавлено - - -

В ТМ я использовал общую маску для некоторых спрайтов, что позволяло сэкономить порядком памяти. В твоём случае это вполне хорошее решении, сделать маску для анимации персонажа чуть больше, чем на пиксель. Я думаю конечный пользователь и не заметит особо разницы, в 1 или 2 пикселя будет обводка. Но все равно нужно смотреть. Если фон черный, это отлично, с белой обводкой похуже

[CityAceE]

* 2 байта результат

Вот это ты забыл в первый раз. Отсюда у меня и произошёл ступор.

[Deadly]

Ну с телефона обзор ограничен, не заметил, но суть таблицы в 3.5кб сокращается в двое, не изменено ))

- - - Добавлено - - -

Если проблема в размере хранения, я думаю Джери подскажет, что будет максимально компактно. Но мой виден, хранить пару файлов как 1 значение

[Bedazzle]

Это немного в другую сторону, но просто как идея, чтобы работать без таблиц. В HOTM спрайты зумятся при выводе на экран по вертикали дублируется каждая строчка. А вот по горизонтали - прямо в процессе отрисовки в теневой экран, и на старте игры происходит предобработка спрайтов прям по месту таким кодом:
lace_loop: ; #B4C2
xor a

DUP 4
rlc (hl)
rla
rla
EDUP

DUP 4
rlca
rlc (hl)
rla
EDUP

ld (hl), a ; put laced byte
inc hl
dec bc
ld a, c
or b
jr nz, lace_loop

т.е. каждая линия спрайта становится "полосатой". Может, что-то похожее можно изобрести.

[Deadly]

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

- - - Добавлено - - -

Так же хранить значение, на сколько пикселей сдвинуто в буфере оригинал, для того чтобы вернуться к исходному спрайту

- - - Добавлено - - -

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

[Lethargeek]

Вариант ещё, двигать оригинальный спрайт, а не перед выводом на экран.

тогда уж отражать оригинал лучше, а вместо отраженного иметь сдвинутый на 4 пикселя