Т.е при записи теперь еще и маску писать нужно? А если каждый слой сдвинут аппаратно относительно друг друга? то внезапно нам нужно в 2 раза больше этих альфа кешей читать?Сообщение от Reobne
- - - Добавлено - - -
это кто такой? и с какого перепугу сумматоры стали сложные?
Да. Зато для стирания всего слоя достаточно стереть только маску.
Я и думал про аппаратные скроллинги. Это просто небольшая оптимизация для режима, о котором пишет zst, восемь 16-ти битных слоёв, с раздельным x y аппаратным скроллингом. Вместо 8*16=128, получается 24 бита на пиксель. Да, альфакеши нужны. Да, при записи нужно и альфаканал заполнять. Я-же не настаиваю, просто такой вариант.
Не понимаю, в каком смысле? Размер кешей в 2 раза больше, или обращений к памяти?
- - - Добавлено - - -
Nesser, А мы вот не хотим ставить большие ПЛИСины, когда можно поменьше. Не хотим гигагерцы, когда можно обойтись мегагерцами.
И, по крайней мере для отображения, сумматоры не необходимы. Достаточно счётчиков адреса и регистров инициализации счётчика.
Хватит балабольства, считать давайте. Как пример, определим нагрузку на память карты для гипотетического фреймового движка. Пусть площадь растра R, площадь выводимых "спрайтов" S, тогда для самой тупой и примитивной однослойной схемы с полным обновлением фона в кадре получим:
3R + S + s (где s<S процентов на 20-30 для типичных спрайтов, так как прозрачные пиксели лишь читаются)
Для самой примитивной схемы при n слоёв, в лучшем случае (когда фон не изменяется вообще):
(2n-1)R + S + s
то есть для восьми слоёв с тупой полной очисткой верхних семи:
15R + S + s !!
Если же "нетупо" стирать только "спрайты" прошлого кадра:
8R + 2S + s
данные которых придётся сохранять и перебирать при стирании
(да-да, расскажите мне, как слои "удобней для программиста")))
для предложения Reobne у меня получилось в лучшем случае:
1.875R + S + (от 1.0625 до 1.125)s
но в худшем, с полным обновлением фона, уже:
3.875R + S + (от 1.0625 до 1.125)s
притом надо городить кучу непростой логики
да и программно, вероятно, тоже как-то учитывать
зная ПСП, можно вычислить оценку возможной S
и для проектирования движка исходить из худшего случая
...ну и где же вероятней "обойтись плисиной поменьше и мегагерцами"?
- - - Добавлено - - -
вот почему Свидетели Слоёв этого никак не поймут?
Прихожу без разрешения, сею смерть и разрушение...
В однослойном варианте с тремя слоями со скроллингом:
7R + S + s.
Для многослойного варианта с 2 слоями (1 слой фона со скроллингом и 1 слой спрайтов):
2R + 2S + s + SCR.
Для многослойного варианта с 4 слоями (3 слоя фона со скроллингом и 1 слой спрайтов):
4R + 2S + s + 3 * SCR.
Где SCR - время рисования столбика справа экрана при скроллинге.
Таким образом, загрузка памяти мало отличается.
Последний раз редактировалось zx-kit; 13.08.2016 в 17:32.
"L-256"
Нет. Все передние логические слои с прозрачностью учтены как "спрайты" в S+s и рисовать их можно кусками. Но даже если запоминать передние слои целыми экранами, то нагрузка в реале не 2R, а R+r (причём в этом случае r скорее всего будет отличаться от R в разы, а не на десятки процентов).
Такой скроллинг будет слишком тупым и скучным. Блиттер может перебросить любой участок, имитируя прокрутку лишь там, где нужно, и в любом темпе. Так, легко можно получить параллакс переброской нескольких десятков полосок разной высоты, на которых нарисованы объекты (например, деревья) - нагрузка будет прямо пропорциональна общей площади полосок и их заполненности. Или даже не полоски, а у каждого объекта скорость своя, смотря на какой пиксельной строке он "стоит".
Таким образом, нагрузка может отличаться весьма немало, не говоря уже о восприятии игроком.
Прихожу без разрешения, сею смерть и разрушение...
А с каких пор однотактовые параллельные сумматоры адресов стали простые, на них уйма логики уходит, поэтому и делают в несколько тактов.
- - - Добавлено - - -
А я и не говорил про гигагерцы и гигантские плисины, 50-100 МГц и обычной плис вполне хватит.
Мы же не отображение обсуждаем а видеокарту, z80 с отображателем и стандартный экран еле еле во фрейм запихивает, и то извращённым способом через стек, вывод графики дело не центрального процессора и одними тактовыми регистрами с загрузкой не обойтись, хотя это по сути уже схемотехника плис.
У нас даже концепции никакой нет
Может надо сначала решить а что вообще надо? только не про подкрашивание старых игр, их проще сделать заново, был бы только смысл и желание, у кого руки чешутся тот сделает
Только системной концепции никакой нет, что вообще надо то? флешки и hdd уже давно читаем а никаких редакторов так и нету, да и желания делать не очень много, аппаратная часть не особо позволяет делать, налепить то разных ништяков налепили а в кучу слепить забыли, mp3 и тот только с отдельной флешки читается.
Именно подкрашивание старых игр.
Их НЕ проще сделать заново.
это не умножитель, на 8 входов все равно будет простой
А вы в курсе что в современных плисах есть DSP-блоки которые аппаратно делают умножение и суммирование грубо говоря за один такт?
В современных много чего есть, а умножители уже как полтора десятка лет
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием