Хватит балабольства, считать давайте. Как пример, определим нагрузку на память карты для гипотетического фреймового движка. Пусть площадь растра 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
и для проектирования движка исходить из худшего случая
...ну и где же вероятней "обойтись плисиной поменьше и мегагерцами"?
- - - Добавлено - - -
вот почему Свидетели Слоёв этого никак не поймут?![]()





Ответить с цитированием