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

[Lethargeek]

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

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

Так "уже понял" или "не понял"? Между ними разница, как в банке между "перечислением денег со счет на счет" и "получением налички со счета".

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

Подумаешь, нельзя что ли размытый паттерн использовать (и вместо 5:6:5 уж лучше 5+:5+:5+, выглядит почти как 6:6:6)? Градиент - не такая важная проблема, чтобы ее решение порождало кучу других проблем.

А 24-битный ЦАП на выходе вместо 15/18-битного между прочим тоже не даром достается.

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

Учим матчасть - результат не тот же. Блиттер рисует в буфер, и может пропустить кадров сколько угодно, старый-то кадр никуда не делся! А вот спрайтер действительно должен все успевать.

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

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

Вы сами себе противоречите. Блиттер и строится на большом количестве отдельной памяти.

Кто противоречит?
Не я же предлагал к отдельной внешней "памяти спрайтов и задников" ЕЩЕ какую-то отдельную "память палитр"!

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

Вообще-то бит, а не байт.

Странные разрешения фтопку, а под буфер требуется не больше, чем занимает игровое поле (всякие менюшки и панели побоку). Весь кадр сохранять не нужно, просто переключаем аппаратное окошко нужного размера на другой начальный адрес видеопамяти. Например окно 256x192x16 это всего 96K. А упакованная графика, которой заполняется этот буфер, занимает в разы меньше при той же площади.

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

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

Главная проблема спрайтового движка - низкий КПД.

Не убедительно: не вижу ни одной проблемы из перечисленных.

Потому что вместо расчетов (основанных на понимании принципов работы графдвижков) - одни благие пожелания.

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

Кто бы сомневался.
Вот только помимо очевидных "железных" проблем у кодера тоже будет забот полно.

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

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

Толку от этого нуль, поскольку придется читать все те же 4 пикселя!

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

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

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

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

Еще раз: проблему подгонки размеров спрайтов придется решать заранее для целого эпизода (эпизод - времЕнной отрезок с закрытым фиксированным набором потенциально используемых спрайтов). Потому что делать это по мере возникновения проблем - мартышкин труд. А "решать заранее" - это значит вводить искусственные ограничения изначально, и КПД движка на практике получится еще ниже.

(придется видимо пример рисовать)

[Vladimir Kladov]

Учим матчасть - результат не тот же. Блиттер рисует в буфер, и может пропустить кадров сколько угодно, старый-то кадр никуда не делся! А вот спрайтер действительно должен все успевать.

Ага, ага, а потом твой герой заходит в комнату набитую предметами, и всё замедляется впятеро. То, что в буфер, я сразу понял, я не идиот безмозглый. Фразу "учим матчасть" следует применять по назначению. Была бы матчасть, было бы что и учить. А так её самому приходится на ходу придумывать.

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


Подумаешь, нельзя что ли размытый паттерн использовать

Убожество с крапинками разного цвета? Это ещё можно стерпеть на экране 1024х768, когда размер точки 0,2 мм, но когда она 2-3 мм - извините.

при чем тут количество? Я про соотношение габаритов

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

Не я же предлагал к отдельной внешней "памяти спрайтов и задников" ЕЩЕ какую-то отдельную "память палитр"!

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

порядка 500х300х4=600000 байт.


Вообще-то бит, а не байт.

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

опять-таки, никаким блиттером тут и не пахнет

Хотите оскорблений? Получите. Прочитайте уже текст, он у меня на сайте выложен, ссылка была выше.

а четвёрки пикселей строк спрайтов с двойным разрешением просто усреднять в один пиксель.


Толку от этого нуль, поскольку придется читать все те же 4 пикселя!

Да, целых два байта. Это на этапе блиттинга. А на этапе развертки - один.

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

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

[Lethargeek]

Ага, ага, а потом твой герой заходит в комнату набитую предметами, и всё замедляется впятеро.

С буфером-то я по крайней мере увижу эти предметы - в отличие от спрайтового мельтешения кучи огрызков. К тому же всегда можно уменьшить плавность анимации, не изменяя скорости игры. А еще необязательно обновлять ВЕСЬ буфер, можно только изменившиеся участки (сие воэможно как раз потому что цвет прямой, и не нужно в кадре динамически палитры переключать при переходе от предмета к фону или другому предмету).

Убожество с крапинками разного цвета? Это ещё можно стерпеть на экране 1024х768, когда размер точки 0,2 мм, но когда она 2-3 мм - извините.

На снесах вовсю юзали даже неразмытые градиенты на 15 бит - и ничего. Тем более почти одноцветные крапинки еще хрен заметишь, в отличие от тех же контрастных кромок типа "темное на светлом".

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

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

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

Не "оценил" (потому что не понял и желания понять НЕТ, как я вижу). Следствие - "принял" неизвестно что.
А я прежде всего отвечал на провокационные заявления в начале темы.

Или мне надо начинать расписывать подробно всю схему работы, что в какой порт пишется, на какой строке луча какие байты куда считываются? Опять мои пардоны, но мне в такую подробную детализацию на этапе обсуждения соваться не интересно.

Это не детали, а предпосылки.

Мне достаточно того, что изложено, для целей эмуляции. А там уже и посмотреть можно.

Зачем эмулировать неудобный в использовании (про железные проблемы молчу) девайс?

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

Вообще-то альфа в буфере нафиг не нужна (требуется временно только на этапе копирования в буфер).

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

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

Да оскорбляйте себя (из-за собственных упрямства и лени) сколько угодно, мне пофиг.
Текст я естественно прочитал сразу же. Выводы:
1. Блиттером там и не пахнет
2. Блиттером в тексте обозвано неизвестно что
3. Если корову обозвать лошадью - лошадью она от этого не станет
4. Учить матчасть наконец! (а конкретно что такое блиттер на самом деле)

Да, целых два байта. Это на этапе блиттинга. А на этапе развертки - один.

Этап развертки выполняется схемой (заведомо быстрее чтения из памяти) и на характеристики движка никак не влияет.

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

Еще как уменьшит. Упаковка применяется по двум направлениям:

1) Сжатие цвета. 1-2-4-8-битные "пиксели" из пожатого объекта пересчитываются в прямой 16-битный цвет по таблице. Для "однобитных" объектов получится почти в два раза быстрее. Для "8-битных" - в полтора. Таблица - та же палитра, но (в отличие от спрайтовых палитр) одномоментно нужно лишь одну сохранять (несколько - по желанию, для удобства). Альфа-канал (когда нужен) можно пустить отдельным потоком, никак не теряя в цветности.
2) Пропуск "полностью прозрачных" точек при переброске - значит, для типового спрайта еще где-то на треть быстрее, в дополнение к п.1

Итого для переброски "среднего" 8-битного спрайта где-то в два раза.

Упаковка - вещь однократная, дальше кодер просто юзает эти объекты, как хочет.

16 цветов на точку и баста. Дальше всё варьируется палитрами, наложением спрайтов с альфой, и этого хватит на всё.

Этого хватит только на геморрой для кодера. Зачем ему необязательные заморочки, когда перспективы появиться в железе у такого мегамонстра околонулевые, а в эмуляторе уже есть режим 256c и турба?

[ZXMAK]

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

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

возможно для статичной картинки это не очевидно, но возьмем для примера текстовый редактор. Как с этим справится z80 с графическим режимом?

[Lethargeek]

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

Одну-то строчку подрисовывать для аппаратной прокрутки?

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

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

возможно для статичной картинки это не очевидно, но возьмем для примера текстовый редактор. Как с этим справится z80 с графическим режимом?

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

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