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

[Lethargeek]

На ПЦ нету. Учите сами.

Не стыдно раз за разом так попадать исключительно из-за собственного упрямства?

Спрайты вообще не имеют никакого отношения к разрешению, оно просто остаётся каким было. Кому не хватает разрешения, идут на другую платформу.

А кому не хватает спрайтов и вертолетиков - идут туда же?
Проблема сглаживания тоже не одним увеличением разрешения решается (см. собственную цитату). Телевизор обычный - высокое там разрешение? (имею в виду не старые кинескопы, а сам сигнал) И ничего - все гладко.

Не вдвое а на трерть. Это раз. Во-вторых, альфа может быть частью самой палитры. Тогда на ноль.

Альфа-канал решает. Используется палитра, в которой есть полностью прозрачный цвет.

Налицо полное непонимание вопроса и даже базовых терминов.
Прозрачный цвет - это и есть полностью "прозрачный" цвет (transparent) (общий или вырожденный случай)
Альфа-канал - это частично прозрачный цвет (translucent) (более узкий термин)

Альфа требует на один пиксель столько же бит, сколько на одну цветокомпоненту в палитре (а не количество бит на закодированный цвет в палитровых режимах). То есть 32K цветов (hi-color) - нужно 5 бит, 256K цветов (VGA-палитра) - 6 бит, 16M цветов (true-color) - 8 бит на каждый альфа-пиксель. Это в дополнение к каждому пикселю собс-но самого спрайта.

Далее - спрайты в прямой кодировке сроду не делались (иначе любой спрайтовый движок сдохнет), обычно - 4-16-32 цвета на спрайт из палитры начиная с 4K-32K цветов. То есть в среднем надо 5 бит на пиксель спрайта и столько же - на альфа-пиксель. Итого - ВДВОЕ больше.

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

Размещенных в любых местах по строке, я настаиваю на втором варианте. Это удобно для програминга. И наплевать, что нужна немножко сложненькая логика для выбора того из какого именно спрайта или фона берётся пиксель. Это прошивается один раз и зыбыли.

Спрайты должны читаться полностью и заранее - с опережением на строку, вне зависимости от перекрытия. Отсюда получаем верхнюю границу и ограничение на число спрайтов в строке. Если их даже там нет ни одного - все равно должны резервировать столько же времени.

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

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

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

"Недоступна" фактически только по цветности, в меньшей степени - по плавности (эти проблемы в принципе решаемы даже методами ZX-Poly а-ля EmuZwin и/или турбированием проца, не говоря уж о растровых ускорителях). А вот спрайтовым движкам многие вещи недоступны по качеству и динамике (либо доступны, но с большим геморроем и "потерей мощности").

Добавлено через 1 час 18 минут

Каким образом ускорение пересылки байтов (тот же DMA или блиттер как его именуете вы) может решить 2 проблемы: построение сцены (заполнение экрана) фрагментами из разных мест памяти,

Тут вообще проблемы нет.

...и вотрая, это экономичное представление более 16 цветов на точку одновременно.

Я так понял, про упаковку графики - в упор не видим?

По блиттеру - читаем доки на Амигу. Для начала. Это наверное первый - и довольно простой - вариант.