Зачем всё делать плоским? (Опять о спрайтах)

[ZEK]

Даже для того чтобы просто сохранить кадр, построенный блиттером, нужно порядка 500х300х4=600000 байт.

Допустим память 32 бита то 500*300*60 = 9000000 циклов чтений в секунду, не многовато ли только для вывода картинки?

Не проще ли 320х240х16 при 16 битной памяти 320*240*60= 4608000, меньше памяти (75килослов), меньше заполнять.

Допустим берем память 28МГцх32бита - 28000000/500*300*60=3.1 память позволяет прокачать 3.1 экрана за фрейм, 28000000(16бит)/320*240*60=6

То есть при Вашем разрешении 30% полосы памяти уходит только на вывод картики. Если брать блитер который к примеру заниается перекидыванием непожатой графики то получается что за один фрейм можно только 1 раз заполнить весть кадр графикой (то есть перекрытия при насыщеной картнике уже трудно делать)

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

А что блитеру мешает читать именно необходимый кусок? То есть есть спрайт 16х16, на экран влазит только 6х6, щитается элементарно какой кусок нада выводить.

Спрайты задаются один раз на всю игру. В моём представленном последним варианте 256 спрайтов собираются из 4 банков спрайтов, и в любой момент можно указать в качестве любого банка любой набор спрайтов, т.е. общее их количество ограничено только фантазией автора.

Чем больше спрайтов на экране тем больше процом щитать нада что бы не нарваться на превышение спрайтов на строку

Там - блиттер. Спрайты копируются командами во внутренний буфер видеопамяти и уже из этой видеопамяти выводятся, смешиваясь с задним планом.

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