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

[Vladimir Kladov]

Вот набросок с учётом возможностей блиттера по сравнению со спрайтами-на-ходу. Тоже вполне простой. Сейчас вложу пдфку.

Здесь только о слое со спрайтами, задний слой - прежний экран спектрума 256х192, со скроллами по вертикали и горизонтали.

Ах, да, про гапы-то я совсем забыл. Перезагрузил пдфку ещё раз. Теперь вроде всё.

Только пдфку я положил себе на страницу, а здесь оставлю ссылку:
http://kolmck.net/zx/Blit-sprite-processor.rar

Буду экономить место на форуме. И заодно привёл пару графических примеров порядка вывода пикселей спрайтов в двух режимах.

[Black_Cat]

Может из схемы что-то можно понять, но я схемы не читаю.

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

[Vladimir Kladov]

из схемы ничего понять нельзя

Ну я так и понял, что GMX умер...

Я тут обновил pdf-ку, дописал про задний план и команды, тайл, обрезка - кажется, это тоже минимумально необходимо (даже больше чем повороты и масштабирования). Пока все празднуют, я тут обдумывал. Кажется, в таком виде я бы без проблем вставил блит-спрайт-процессор в эмулятор. Осталось только оговорить номер порта, и что как выводить в него, чтобы им управлять. Так примерно прикинул: кажись, зуму вполне реализовать можно, разрешения 512х384 вполне хватит на то, чтобы приличное число шариков нарисовать. Мне в эмулятор и повороты с масштабирование всунуть нет проблем - опен гл всё за меня сам сделает... Ладно, я подожду обсуждения и новых пинков, а пока что-нибудь другое сделаю пойду, например, управления меню клавишами сильно не хватает.

http://kolmck.net/zx/Blit-sprite-processor.rar

[Lethargeek]

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

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

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

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

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

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

Раз загрузили под завязку, дальше только переключаем наборы палитр в массиве (частями, как банки памяти), и юзаем до 256 одновременно разных палитр. 256х16 = 4096 разных цветов на экране, а если делать альфа-канал и разрешить смешивать их в разных пропорциях, то легко получается ещё хN, где N зависит отдискретности альфа-канала. Максиму х256, итого 64К разных цветов.

Ну вот, опять необязательные извращения и головная боль! К тому ж цветов получится куда меньше, многие палитры будут вообще отличаться всего одним-двумя цветами на реальных игрушках.

Замечу, что это не то же, что режим 64К на ПЦ с его 5+6+5 битами на RGB.

Вот и плохо.

Этот режим уже есть, к нему просто добавляется скролл. Экономить - память спека. Кроме того, этот режим можно использовать сам по себе, например для плавной фреймовой прокрутки текстов.

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

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

Уж лучше тогда без спрайтов обойтись. И особенно от плавного их вращения - вот уж усложнение так усложнение!

Вот набросок с учётом возможностей блиттера по сравнению со спрайтами-на-ходу. Тоже вполне простой. Сейчас вложу пдфку.

Ой, мама. И это называется "спрайтовые движки удобно программируются"?

Че обсуждать - непонятно, поскольку по времянкам расчетов нет. Вообще не вижу смысла вставлять подобное в эмулятор при живом-то 256-color (спаять который и то реальнее по-настоящему, а в эмуле - больше пользы).

[ZEK]

Нельзя на телек вывести больше 288 строк, если оставлять совместимость со старым эраном, и в ширь для подавляющего большества более 352-356 пикселей

при пиксель клоке 7МГц

[Vladimir Kladov]

Хочу забыть, как страшный сон, любую подгонку по цветам. Хватит с меня спектрумовских атрибутов!

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

Добавлено через 2 минуты

Замечу, что это не то же, что режим 64К на ПЦ с его 5+6+5 битами на RGB.


Вот и плохо.

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

Добавлено через 5 минут

Не проще тогда внутреннюю память спека вообще не использовать для видео? (а я так понял, там еще и спрайты хранить предлагается) Вон только что предлагалось палитры в отдельную память вынести.

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

Скажите, народ, кто в схемотехнике рубит: я гоню или это нормальный ход?

Добавлено через 7 минут

Уж лучше тогда без спрайтов обойтись. И особенно от плавного их вращения - вот уж усложнение так усложнение!

Я с самого начала говорю, что это будет усложнение. В описани выделено красным цветом, поддерживать необязательно. Делается так, что если этот режим включается, блиттер пропускает байты вращения/масштаба, и рисует 1:1. Частично может прокатить даже если игруля будет написана с расчётом на вращение/масштабирование.

Добавлено через 9 минут

это называется "спрайтовые движки удобно

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

Добавлено через 15 минут

Нельзя на телек вывести больше 288 строк, если оставлять совместимость со старым эраном, и в ширь для подавляющего большества более 352-356 пикселей

при пиксель клоке 7МГц

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

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

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

[Advertiser]

[Lethargeek]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Vladimir Kladov]

Да начхать мне с блиттером на всякие "полоски"

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

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

Винда тут ни при чём. 64К цветов в формате R5G6B5 для градиента - это очень мало и очень плохо.

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

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

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

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

И зачем это надо, еще какая-то отдельная память

Вы сами себе противоречите. Блиттер и строится на большом количестве отдельной памяти. Даже для того чтобы просто сохранить кадр, построенный блиттером, нужно порядка 500х300х4=600000 байт. По-моему, добавить к 600К ещё 128К для затенения всей памяти спектрума - это очень дешевое и простое решение. Блиттер весь работает в своей памяти. Когда я говорю память спектрума я подразумеваю, затенённая блиттером копия памяти спека.

От строк различной ширины у одного спрайта толку мало.

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

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

Не убедительно: не вижу ни одной проблемы из перечисленных. Кроме сложности самого устройства. Проэмулировать его, наверняка легче чем воплотить в железо.

[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 экрана, основной и теневой, в некоторых играх можно и одним отмазаться с небольшой аппаратной поддержкой, делаем что блитер не может выводить графику ниже луча развертки, и подаем ему отрисовку сверху вниз.

[Vladimir Kladov]

Трудно здесь что-то конкретное цитировать, но вот что скажу (2hero). Если скорости недостаточно, никто не мешает 1. юзать прежнее разрешение 256х192, а четвёрки пикселей строк спрайтов с двойным разрешением просто усреднять в один пиксель.

2. Можно оптимизировать достаточно легко, для спрайтов однократного разрешения заполняя не четвёрки пикселей, а один пиксель, помечая его в 4-м байте флажком. (У нас в целевом экране реально нужен только R8G8B8, а четвёртый байт совершенно не используется). И тогда при чтении, если первый в четвёрке пиксель содержит такой флаг, то количество чтений уменьшается тоже (правда, уже не вчетверо, а вдвое).

Добавил: хотя нет, альфа-то нужна, но 1 битик оторвать от неё можно (младший), просто градаций уменьшится с 256 до 128. И опять же только если скорости не хватит.

на экран влазит только 6х6, щитается элементарно какой кусок нада выводить.

Странно, а где-то сказал, что все пиксели должны пересылаться? А для чего я тогда об обрезке в спецификации написал, для красного словца, что ли?

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

Вот пусть Lethargeek объяснит, мну уже понял, что блиттер - это не спрайтер.