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

[CityAceE]

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

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

Ну так вот. Я возжелал увидеть эту игру на моём первом компьютере Специалист. Сделал демо (https://zx-pk.ru/threads/35905-tony-montezuma-s-gold-dlya-pk-spetsialist.html) на основе видеороликов и вроде как успокоился, так как остальное Специалист не потянет. А не потянет он прежде всего подгрузку уровней. Но в Telegram-группе по Специалисту (https://t.me/fahivets85) меня уверили в том, что несколько разновидностей подключения SD-карты нивелируют эту проблему. Так, ну если подгрузку уровней он всё же потянет, то остаётся узкое место - оперативная память. На всё про всё её там только 36 кб. И в эти 36 кб нужно уместить конфигурации всех лабиринтов уровней, всю графику ландшафта, врагов и анимацию главного героя. По моим скромным подсчётам 36 килобайт на это никак не хватит. Ну ОК, если сделать каждый раз подгрузку лабиринтов с SD мы освободим некоторое место в ОЗУ, но лишь некоторое! Экономить нужно буквально на всём. В общем, уровни мы оставим на потом, а сейчас будем считать, что у нас только один экран по которому скачет главный герой. Благодаря Sanchez'у я знаю как можно круто попиксельно перемещать спрайт по экрану, а за одно и зеркалировать его. Но, к моему великому сожалению, это требует дофига памяти на таблицы. У меня этой памяти попросту нет!

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

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

[Deadly]

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

[newart]

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

В общем, ситуация такая. Польские девелоперы выкатил нереальной красоты монохромную игру Tony: Montezuma's Gold (https://monochrome-productions.itch.io/) для трех ретро-платформ: 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 пикселя

[Deadly]

Отражение нужно применять в рантайме, через таблицу

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

Не нужно путать мои мысли

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

А смещение, каждый раз когда оно необходимо

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

В принципе, я наверно выбрал бы именно этот способ, т.у. он очень подходит под требования

[jerri]

CityAceE, Конкретно для этой игры вывод попиксельный не вижу я

[Lethargeek]

Отражение нужно применять в рантайме, через таблицу
так оно и будет так же в рантайме - только однократно при развороте

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

еще можно рассмотреть метод из игрушек OperaSoft
пиксели и маска там хранятся не по байтам, а по ниблам
что позволяет быстрый сдвиг на 4 пикселя за то же время
(и таблица для разворота тоже по ниблам)

[CityAceE]

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

[CityAceE]

Вариант ещё, двигать оригинальный спрайт, а не перед выводом на экран.
Не очень понимаю в чём профит? Это же практически одно и то же. И по памяти, и по тактам. Или я чего-то недопонимаю?

[b2m]

Анимация героя, пока он стоит, там вроде всего два фрейма, их можно заранее сдвинуть на 2,4,6 пикселей (то есть, вместо 2-х будет 8). А вот анимация движения влево-вправо вовсе не обязана быть кратной 2-м пикселям, можно сделать её кратной 8 пикселям. Я имею ввиду, если прокручивать её на одном месте, то герой не обязан стоять на месте (с лунной походкой). Он будет двигаться туда-сюда на 2,4,6 пикселей каждые 4 фрейма. Единственное ограничение - количество фреймов в анимации движения должно быть кратно 4-м.

[Titus]

Вроде бы drbars рассказывал, что в своих Диззях он использовал как раз быстрые способы печати спрайтов по маске.

[jerri]

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

попиксельный вывод спрайта и отрисовка спрайта в нужной позиции не обязательно одно и тоже

4 копии спрайта в прыжке
при перемещении 4 фазы ходьбы с прескроллом.

просто специалист не самый шустрый комп - вешать на него емкую попиксельную отрисовку - жестоко.

[CityAceE]

просто специалист не самый шустрый комп - вешать на него емкую попиксельную отрисовку - жестоко.
Но Атари и Коммодор имею ещё более медленный процессор...

А вообще вот вся графика главного героя из C64. Что-то отзеркалено заранее, а что-то нет (например, ходьба и прыжок).

https://pic.maxiol.com/images2/1725536266.780858384.tonyspritesx2.png

[Bedazzle]

Но Атари и Коммодор имею ещё более медленный процессор...

Я правильно понимаю, что и на Атари, и на Комоде хоть и в ограниченном объёме, но есть аппаратные спрайты?

[jerri]

Но Атари и Коммодор имею ещё более медленный процессор...

А вообще вот вся графика главного героя из C64. Что-то отзеркалено заранее, а что-то нет (например, ходьба и прыжок).

https://pic.maxiol.com/images2/1725536266.780858384.tonyspritesx2.png

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

Странно что не все зеркалено. Там нет аппаратного разворота

[ivagor]

Но Атари и Коммодор имею ещё более медленный процессор...
Сложно сравнивать в среднем по больнице, но проц С64 даже в худшем случае как минимум на уровне спецовского, а атариевский однозначно быстрее. Я именно о процессорах без учета аппаратных тайлов и спрайтов.

[CityAceE]

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


проц С64 даже в худшем случае как минимум на уровне спецовского, а атариевский однозначно быстрее.
Эх, что-то куда ни плюнь, Специалист вообще позади всех абсолютно по всем параметрам, ну может быть по ч/б разрешению не самый последний...

[jerri]

Эх, что-то куда ни плюнь, Специалист вообще позади всех абсолютно по всем параметрам, ну может быть по ч/б разрешению не самый последний...

У специалиста свои плюсы. Вот их и надо использовать.
А что там за беда с загрузкой?

[CityAceE]

У специалиста свои плюсы. Вот их и надо использовать.
Плюс у него один - это мой первый комп, который, среди прочего, без книжек позволил мне осознать двоичную систему и многие другие основы ;) Ну а так, плюсов перед другими аналогичными компьютерами у него я не вижу. Ну разве что, как я уже говорил, неплохое разрешение экрана 384*256 и даже можно цвет задействовать. Но Специалист был разработан ещё в 1985 году и по максимально простой схеме. При этому у него была пиксельная графика, звук и на то время прилично памяти (36 кб + 12 кб видеоОЗУ). В этом его жирнющий плюс! Но на сегодня этот плюс не имеет ровно никакого значения.


А что там за беда с загрузкой?
Беда в том, что из внешних носителей там только магнитофон. Даже дисковод толком не прикрутили. Вернее Моделисте-Конструкторе публиковал схему подключения дисковода, но там было всё плохо со скоростью, объёмом дискет (180 кб вроде бы только умещалось, если я ничего не путаю) и т.д. Есть подозрение, что эту схему так никто и не повторил. Потом были другие разработки, но всё это не стало стандартом, так как пришло слишком поздно. А уже в Интернетовскую эпоху потом начали подключать SD-карты. Это уже никакая не классика, но в силу простоты подключения и отсутствия классической альтернативы, видимо, придётся использовать её. Emu80 поддерживает несколько вариантов подключения, значит можно пощупать их и понять, на чём стоит остановиться. А для меня лично ещё критерием будет то, насколько просто я смогу припаять это к своему Лику. Что-то делать просто под эмулятор для меня лично не интересно. Всё, что я сделаю, должно запускаться и работать на моём железе.

[jerri]

Плюс у него один - это мой первый комп, который, среди прочего, без книжек позволил мне осознать двоичную систему и многие другие основы ;) Ну а так, плюсов перед другими аналогичными компьютерами у него я не вижу. Ну разве что, как я уже говорил, неплохое разрешение экрана 384*256 и даже можно цвет задействовать. Но Специалист был разработан ещё в 1985 году и по максимально простой схеме. При этому у него была пиксельная графика, звук и на то время прилично памяти (36 кб + 12 кб видеоОЗУ). В этом его жирнющий плюс! Но на сегодня этот плюс не имеет ровно никакого значения.


Плюсы нам нужны на фоне других машин того времени
про RK86 молчу.

Графический экран это удобно.

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




Беда в том, что из внешних носителей там только магнитофон. Даже дисковод толком не прикрутили. Вернее Моделисте-Конструкторе публиковал схему подключения дисковода, но там было всё плохо со скоростью, объёмом дискет (180 кб вроде бы только умещалось, если я ничего не путаю) и т.д. Есть подозрение, что эту схему так никто и не повторил. Потом были другие разработки, но всё это не стало стандартом, так как пришло слишком поздно. А уже в Интернетовскую эпоху потом начали подключать SD-карты. Это уже никакая не классика, но в силу простоты подключения и отсутствия классической альтернативы, видимо, придётся использовать её. Emu80 поддерживает несколько вариантов подключения, значит можно пощупать их и понять, на чём стоит остановиться. А для меня лично ещё критерием будет то, насколько просто я смогу припаять это к своему Лику. Что-то делать просто под эмулятор для меня лично не интересно. Всё, что я сделаю, должно запускаться и работать на моём железе.

НА спек и 128 кб игры грузили - не вижу проблем НЕ использовать подзагрузку с ленты.
Отсутвие контейнера по типу ТАП или TZP кстати большой минус.

[Lethargeek]

Сложно сравнивать в среднем по больнице, но проц С64 даже в худшем случае как минимум на уровне спецовского, а атариевский однозначно быстрее. Я именно о процессорах без учета аппаратных тайлов и спрайтов.
категорически не согласен, проц атари примерно равен спековскому, комодуровский - почти вдвое медленней (Fairlight хорошая иллюстрация)

[CityAceE]

Автор игры подарил мне копию полной версии для Atari. И сказал, что не возражает, если сделаю порт на Специалист при условии, что игра будет бесплатной, а в титра будет его имя в качестве автора и дизайнера. Теперь прямо как-то стыдно включать заднюю... Но я всё ещё не определился, как делать вывод спрайтов с маской, чтобы и быстро и в память влезло. А то вся графика Тони с масками сейчас занимает 7 кб. Это слишком много, места столько нет.

[breeze]

Атари и комодор имеют аппаратные спрайты.

Да, но у атари ограничение спрайт только 16 в ширину и двойной пиксель по сути это 8.
Так что более чем уверен, что там сделано по другому. Фон тайлами так точно.

[Shiny]

Да, но у атари ограничение спрайт только 16 в ширину и двойной пиксель по сути это 8.
Так что более чем уверен, что там сделано по другому. Фон тайлами так точно.

и добавь вертикальный и горизонтальный сдвиг(:

[jerri]

Автор игры подарил мне копию полной версии для Atari. И сказал, что не возражает, если сделаю порт на Специалист при условии, что игра будет бесплатной, а в титра будет его имя в качестве автора и дизайнера. Теперь прямо как-то стыдно включать заднюю... Но я всё ещё не определился, как делать вывод спрайтов с маской, чтобы и быстро и в память влезло. А то вся графика Тони с масками сейчас занимает 7 кб. Это слишком много, места столько нет.

сделай с автомаской горизонтальной - будет норм

[CityAceE]

сделай с автомаской горизонтальной - будет норм
Объясни, пожалуйста, суть этого метода.

[ivagor]

CityAceE, извини за любопытство - ты смотрел (или хотя бы слушал фоном) какие-нибудь стримы Alone Codera?

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

Слишком сузил, попробую расширить - какие-нибудь исходники современных игрописателей для спека или других ретроплатформ изучаешь?

[CityAceE]

Не смотрел, не слушал, не изучал. Увы... Мне вообще чужой код даётся с огромным трудом. Я даже свой перестаю понимать, если прошло какое-то небольшое время. Поэтому для себя стараюсь комментировать чуть ли не каждую строчку. Те видео уроки, которые я выкладывал - это по сути я просто пересказал своими словами то, что мне объяснил Sanchez и применил к Специалисту.

[goodboy]

про `автомаску`
https://zxpress.ru/article.php?id=8041

[jerri]

Объясни, пожалуйста, суть этого метода.

Хм... 1 берешь байт например %00111100 делаешь ROL влево, ROL вправо и OR ишь это все в один байт. потом инвертишь результат
получается байт %10000001.

2 делаешь этим способом все 256 байт от 0 до 255 и все кладешь в одну таблицу. Это таблица автомаски

3 при выводе изображения каждый байт спрайта маскируешь байтом из таблицы автомаски. это дает частичное маскирование фона. В динамике смотрится нормально. смотри игру Trantor например


методы предложенные в zx press - остаются затратными всегда

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




;генератор таблицы маски

ld hl,mask_tbl
l0
ld a,l
add a,a
ld c,a
ld a,l
or a
rra
or c
or l
cpl
ld (hl),a
inc l
jp nz,l0



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



;вывод спрайта
;наибыстрый вариант наверное через стек
; hl маска
; de место на экране или буфер спрайта
; sp адрес спрайта

...
pop bc
ld l,c
ld a,(de)
and (hl)
or l
ld (de),a
inc e ;переход ниже

ld l,b
ld a,(de)
and (hl)
or l
ld (de),a
inc e ;переход ниже
...

[CityAceE]

Опробовал данный способ. В принципе, учитывая, что в моём случае пересечения с фоном минимальны, то, наверное, этот метод будет приемлемым.

https://pic.maxiol.com/images2/1725971448.780858384.tonyback2.gifhttps://pic.maxiol.com/images2/1725971484.780858384.tonyback1.gif

[ivagor]

Т.к. есть "настоящая" маска, то лучше попробовать использовать ее. Если каждому возможному байту спрайтов соответствует только один байт маски, то все отлично. Если нет (скорее всего нет), то можно сделать несколько таблиц масок, для разных групп спрайтов. Места займет больше чем автосгенерированная маска (но меньше, чем полный набор масок), но качество маскировки заметно лучше.

[CityAceE]

Т.к. есть "настоящая" маска, то лучше попробовать использовать ее.
Честно говоря, да, прямо очень не хочется идти на какие-то компромиссы. А хочется сделать всё максимально красиво, насколько это возможно. Я ведь даже пока не знаю, а вдруг у меня вообще на всё быстродействия хватит. Там не так уж и много анимации на экранах.


Если каждому возможному байту спрайтов соответствует только один байт маски, то все отлично.
Интересная мысль! Спасибо! Надо будет реально провести анализ, а вдруг!

[CityAceE]

Надо будет реально провести анализ, а вдруг!

Всего 4 спрайта движения 32*32 пикселя. Итого 512 байт. Но какой зоопарк среди масок!




#
Спрайт
Маска


1
0
0


2
0
255


3
0
128


4
1
1


5
1
255


6
1
127


7
2
2


8
3
255


9
3
3


10
4
255


11
4
4


12
5
7


13
7
255


14
7
7


15
8
15


16
9
15


17
10
11


18
12
12


19
12
255


20
12
252


21
14
255


22
14
14


23
15
15


24
16
17


25
19
19


26
24
248


27
29
31


28
30
30


29
31
31


30
31
255


31
32
224


32
40
63


33
48
48


34
53
63


35
56
248


36
57
57


37
58
255


38
59
59


39
60
252


40
62
63


41
63
63


42
64
192


43
67
255


44
68
127


45
68
255


46
79
255


47
80
240


48
87
127


49
94
255


50
96
224


51
96
96


52
99
127


53
99
255


54
109
127


55
112
240


56
112
112


57
115
127


58
116
255


59
121
255


60
122
255


61
122
127


62
123
127


63
124
255


64
127
255


65
128
255


66
128
128


67
129
255


68
129
129


69
130
254


70
131
255


71
143
255


72
152
255


73
160
224


74
167
255


75
167
231


76
168
248


77
175
255


78
189
255


79
192
192


80
195
195


81
208
240


82
220
252


83
221
255


84
222
255


85
224
255


86
224
224


87
226
227


88
229
255


89
234
255


90
235
255


91
239
255


92
240
240


93
240
255


94
240
243


95
241
255


96
245
255


97
247
255


98
248
255


99
248
248


100
252
255


101
252
252


102
254
255


103
255
255

[Bedazzle]

Места займет больше чем автосгенерированная маска (но меньше, чем полный набор масок), но качество маскировки заметно лучше.

У меня была чуть другая идея, пробовал собирать маску из стандартных блоков, которые в UDG есть + ещё несколько дополнительных.

[Lethargeek]

Всего 4 спрайта движения 32*32 пикселя. Итого 512 байт. Но какой зоопарк среди масок!
попробуй варианты OR и AND по всем маскам (одного байта)

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


У меня была чуть другая идея, пробовал собирать маску из стандартных блоков, которые в UDG есть + ещё несколько дополнительных.
емнип в Capitan Trueno маска сжатая и вдвое меньшего разрешения (по обеим осям)
в одном байте хранится маска сразу для четырёх байт спрайта
чётные и нечётные биты кодируют разные строки маски

[ivagor]

Всего 4 спрайта движения 32*32 пикселя. Итого 512 байт. Но какой зоопарк среди масок!
Т.е. это статистика по исходным спрайтам без сдвигов? Тогда идея не прокатила, со сдвигами будет еще хуже. Выходя за рамки темы - у Tony фишка в графике, и если однострочная автомаска будет ее портить, то лучше поискать другие варианты. Трехстрочная в реализации на 8080 будет довольно медленной. Может поделить игру на части или сделать подгружаемые с магнитофона уровни? А в MX можно и все сразу загрузить.

[CityAceE]

Т.е. это статистика по исходным спрайтам без сдвигов?
Да, увы...

Может поделить игру на части или сделать подгружаемые с магнитофона уровни
На части придётся делить так и так. Она и в оригинале каждый уровень подгружает на С64 и Atari. На Amiga, я не находил прохождений, там, наверное, всё загружается за раз.

[Lethargeek]

Опробовал данный способ. В принципе, учитывая, что в моём случае пересечения с фоном минимальны, то, наверное, этот метод будет приемлемым.

Всего 4 спрайта движения 32*32 пикселя. Итого 512 байт. Но какой зоопарк среди масок!
не, по уму тогда нужно две таблицы масок - отдельно для левого и правого края
причём для именно таких нешироких спрайтов без промежутков результат получится почти идеальный
чтоб при сдвигах ширина маски не плавала - маскировать не просто крайний байт, а от края первый ненулевой

[Bedazzle]

емнип в Capitan Trueno маска сжатая и вдвое меньшего разрешения (по обеим осям)
в одном байте хранится маска сразу для четырёх байт спрайта
чётные и нечётные биты кодируют разные строки маски

Прикольно. Спасибо за информацию!

[jerri]

CityAceE, Ну как прогресс?

[CityAceE]

Ну как прогресс?
https://zx-pk.ru/threads/35905-tony-montezuma-s-gold-dlya-pk-spetsialist.html?p=1204522&viewfull=1#post1204522

[drbars]

CityAceE, основаня идея быстрого сдвига без таблиц у меня была в том, при копировании спрайта из места хранения в буфер, который уже выводится на экран использовался сразу сдвиг на 1 пиксель влево или вправо, или без сдвига. Тут смысл в том, что если спрайты например хранились в отдельном банке, а вывести сдвинутый спрайт нужно на 5/7 экраны и спрайты у и тебя упакованные по строкам. Используется примитивный RLE, где ты можешь повторяющиеся строки или даже части спрайта не хранить повторно. Так вот, быстро сдвинув (RRA/RLA) при распаковки и копировании в буфер и получив предсдвинутый спрайт, при выоде на экран его нужно всего лишь досдвинуть до нужной фазы... например для фазы 0: выводим как есть, сдвигать не надо, для фазы 1 используем предсдвинутый при коприровании в буфер спрайт, для фазы 2 - используем предвинутый при коприровании и дополнительно сдвигаем его при выводе на экран на 1 пиксель. Самые меделенные фазы это сдвиг на 3 и 5 пикселей, понятно как быстро сдвинуть на 6 и 7 пикселей. Для 7 используем двиг влево, и для 6 используем сдвиг влево + доп сдвиг на пиксель, только нужно сместить указатель на адрес буфера. Ну, а для сдвигов на 3 и 5 используем RLD/RRD команды, сдвиг на полубайт, в сочетании с предсвдинутым буфером. Эта же команда используется для сдвига на 4. Рабочий пример этого способа, я выкладывал здесь (https://zx-pk.ru/threads/23544-vyvod-sprajta-po-x-y.html) на форуме. Сама процедурка получилась очень компактной и достаточно быстрой, конечно табличный метод работает чуть быстрее на 30% где-то, но если поджимает память то выкручиваться можно вот таким способом.