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

[Lethargeek]

Это я не понимаю. Блиттер, получается, делает гладкое изображение, а спрайтовый движок - нет? Чушь какая-то, тем более что спрайтовый движок принципиально ничем от блиттера не отличается, кроме того, что в случае блиттера изображение строится в буфере, а потом кидается на экран, а в спрайтовом режиме - изображение сразу отправляется на экран, минуя буфер.

В том-то и дело, что "сразу" в данном случае означает "с жесткой привязкой по времени". Отсюда следует (см. ниже), что паковать спрайты хотя бы за счет "дырок и обрезанных границ" толку мало (разве что несколько разгрузить шину для CPU). А вот блиттер легко пропускает ненужные точки и может использовать любую схему компрессии (например нужен объект в 17 цветов - тогда самый "редкий" цвет отделяем в отдельную картинку и потом накладываем на 16-цветный объект всего несколько таких точек, без лишних затрат времени; в случае спрайтового движка нужно убить два спрайта либо портить бэкграунд). И уж конечно "потом кидать на экран" буфер не надо, просто переключаем отображаемые буфера.

А принципиальное отличие состоит в коренном ОГРАНИЧЕНИИ:
* Для спрайтовых движков - суммарное количество (включая прозрачные) обрабатываемых накладывающихся пикселей (даже не спрайтов как таковых, хотя от их кол-ва схема тоже разбухает) на каждую СТРОКУ.
* Для блиттера - суммарное количество обрабатываемых накладывающихся пикселей (легко делается без прозрачных, в зависимости от раскладки) на весь КАДР (считая бордюр и интервалы гашения!). К тому же в крайнем случае всегда можно частоту обновления игрового поля (не скорость самой игры!) понизить - мигать ничего не будет, в отличие от спрайтового движка.

И сколько пикселей у верхней кромки эллипса будет в разрешении 256х192? Думаю, 16 максимум. Как раз столько, чтобы можно было выделить особую палитру под верхнюю кромку. А с учётом симметрии эллипса, и до 32 дотянет. Это если действительно требуется уникальное значение на каждый пиксель (половины эллипса, вторая половина симметрична).

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

Но это тоже не очень умно: по мне, можно использовать одинаковый "цвет" с альфой и на 2-3 подряд пикселя.

Суррогат.

Что имеется в виду под перегружать? Все палитры или берутся из страницы видеопамяти, или заранее загружаются в собственную видеопамять видеоустройства. Даже если их 256 штук, по 16 цветов х 4 байта.

Проблема в том, что на любую отдельную строчку спрайта в общем случае потребуется своя собственная палитра. Сколько строк - столько уникальных палитр. На ОДИН спрайт. Сколько тогда потребуется внутренней памяти для палитр? Кстати эти палитры из-за прозрачности еще на треть (а то и вдвое) разбухнут. Дык их там еще и обновлять придется при любой анимации (не путать с простым движением) спрайта! А тянуть из внешней видеопамяти - ну так и есть, фактически второй спрайт. Иначе - подбирать внутренне зависимые жесткие раскраски (если уникальных не хватит) на каждый игровой эпизод без потери качества - ну, это для отпетых мазохистов.

И почему надо читать 2 бакграунда? Задний план в моём варианте - это стандартный спековский видеорежим с одновременным скроллом всех точек и атрибутов с точностью до пикселя. Итого 64 байта на строчку для него.

Даже так освобождается только 64 байта. Итого осталось 1216.

Но почему 8 строк надо читать за 224 такта? По мне так достаточно читать те "пиксели", которые в данной точке подлежат отображению.

Ничего не выйдет. Любой спрайтовый движок ОБЯЗАН обеспечить вывод строки "в худшем случае" в жестких временнЫх рамках - иначе это не спрайтовый движок, а фуфло. Сказано - "8 спрайтов в строке" - значит, 8! Сказано "в спрайте до 256 точек" - значит, будь ВСЕГДА готов обработать ВСЕ возможные 256*8=2048 пикселей. Плюс бэкграунды.

Уфф.. я надеюсь, мне все-таки не придется объяснять - почему.

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

Просто = убого.

Мне очень не хочется останавливаться на 8 спрайтах в ширину, но судя по описанию v9990, там это ограничение ещё жёстче - 6 штук на строку.

Там - 16 на строку (но всего по 16 пикселей на каждый) в 16 цветах, на весь экран 4 палитры. Конкретно спрайтовые режимы у тридевятого не фонтан. А растровые - тормозные.

Выгрызать и делать отдельно аналог одних только спрайтовых режимов особого смысла не вижу.

Это даёт блиттер, но мне он кажется слишком громоздким из-за промежуточной памяти для буфера изображения. Если включать в машинку масштабирование или повороты, т.е. делать полноценный 2Д, то это уже потянет на громоздкую реализацию,

И что "громоздкого" в буфере? Как второй экран на Спеке-128 (можно еще и не полностью все окошко впечатывать). Масштабирование - конечно с тотальным сглаживанием (и вращением) подробно считать надо (если просто с одним прозрачным цветом - ерунда). Повороты на прямой угол и отражения - даром, пару счетчиков переименовать.