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

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

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

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

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

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

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