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

[Lethargeek]

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

БЫЛО круто. Лет 15 тому назад. А сейчас это уже даже не "хорошо", а просто убого.

Никто же (в случае блиттера) не запрещает широкий многоцветный спрайт поделить на несколько вертикальных полосок. Или если цветов недостаточно по ширине, но хватает по высоте, то можно его всегда рисовать повёрнутым на 90 градусов.

Да начхать мне с блиттером на всякие "полоски", когда я могу накладывать друг на друга изображения любой формы и цветности ("палитра объекта" в этом случае - просто ключ для разворачивания упакованных цветов в hicolor).

Судя по прилагаемому пдфу - что такое блиттер, до сих пор не понятно? В первых же строках описатель спрайта почему-то называется "командой блиттера" Да и все остальное никакого отношения к блиттеру не имеет!

БЛИТТЕР всего лишь осуществляет условные статичекие переброски память-память с параметрами "куда, откуда, сколько, как" - к раскладке экрана и временным параметрам кадра блитер никак не привязан! СПРАЙТЕР же осуществляет динамическую переброску память-буфер (отображаемой строки) и последующий выбор из нескольких точек (или их смешивание) для отображения. Почувствуйте разницу.

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

Ни фига се неплохо. Вы этот 64К включите и просто перезагрузитесь под ХП. Есле у вас видно окно приветствия, вот там во всей красе видно (верхний левый угол) как оно неплохо.

Меня вообще-то виндовозные глюки мало волнуют.
Прямой цвет для программирования однозначно удобнее.

я же говрю - теневой дубль банков спектрума, которые сейчас не задействованы под видео, делется автоматом. Палитры в отдельную память я предполагал таким же макаром засовывать.

И зачем это надо, еще какая-то отдельная память (к тому же большей частью простаивающая). Это как минимум лишние ноги плис, если в железе.

Очень удобно. Спрайт задаётся один раз. Таблица вывода может строиться на каждом кадре, или только модифицироваться, если число объектов не меняется, а только они двигаются. Что сложного?

Ну только если "задается один раз на весь эпизод"

Почему?
За время отображения текущей строки можно прочитать (чтобы подготовить для отображения следующей) только определенное количество пикселей (и еще оставить время, как минимум достаточное для доступа Z80 к старому экрану). Если спрайты переменной ширины - значит, нужно разделить это кол-во между спрайтами. Сделать это можно только одним способом - читать поочередно по одному пикселю из каждого спрайта, сколько успеем. Что не успели - обрежется. И чтобы ничего не резалось, надо обдумывать габариты всех используемых спрайтов заранее - иначе при любом движении хотя бы одного спрайта по вертикали возникает риск испортить картинку! И что теперь? Программисту вручную проверять, что ли, суммарную ширину спрайтов по всем изменившимся строкам отображения? И что собс-но делать, когда выявлено превышение лимита?

Отсюда выводы:
1) От строк различной ширины у одного спрайта толку мало. Достаточно задать ширину всего спрайта.
2) (следствие из п.1) Отступ слева не нужен - слишком маленькая экономия, да и то непонятно зачем.
3) Скорее всего ограничение "N спрайтов суммарной шириной W на одну строку" на практике будет относиться уже не к строке, а ко всему "игровому полю". Иначе бедный кодер замается на ходу считать допуски (и так уже ни о какой "простоте" речи не идет).
4) (следствие из п.3) Движок крайне неэффективен, поскольку доступные циклы видеопамяти (при довольно больших требованиях к ее скорости) большую часть кадра реально использоваться не будут - теряем в качестве непонятно ради чего.

Кроме того, спрайты не только двигаются, но и кадры анимации переключаются.

Разве у видеопроцессора, прилаженного сбоку не может быть своя частота вывода? Разве у нас только телевизор (который скоро умрёт, в связи с переходом на цифру)? У меня новый телек на кухне стоит, автомобильный, уже плоский, и 640х480 видео понимает, может как моник работать.

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

Кроме того, есть такая штука как ресамплинг. Внутреннее изображение 512х384 ресамплится до нужного масштаба уже на этапе вывода, и все дела. Заодно и углы сгладятся.

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

Просто я оптимист

А я - скептик. И потому большинство возможных проблем замечаю издалека.