Новый формат графического изображения для ZX совместимых компьютеров.

[Ynicky]

может, лучше атрибуты не 4 на 4, а 8 на 2

Мне кажется, качество по горизонтали будет плохое, а по вертикали хорошее.
И конфликт атрибутов по горизонтали останется прежним.
Хороший вариант получается если в растре использовать два бита на пиксель.
При этом в стандартном знакоместе (8х8) будет не 2 атрибута (INK и PAPER), а четыре.
При байтовом размере атрибутов изображение не будет превышать 16 кБ.
И конфликта атрибутов не будет, если следовать следующим правилам:
- 1 атрибут на фон и 3 атрибута на спрайт;
- 2 атрибута на фон и 2 атрибута на спрайт;
- 3 атрибута на фон и 1 атрибут на спрайт;

[Advertiser]

[Smalovsky]

Ynicky, при двух битах на пиксель старые методы кодирования графики не подойдут. Количество байтов под атрибуты 768х4х2=6144 при байт на инк и байт на папер. Растр 6144х2=12288 байт.
Если делать атрибут 8 на 2, то будет подобие аппаратного мультиколора с расширенными атрибутами. Но есть плюс - есть наработки для мультиколора в движке нирвана с размером чанка 8 на 2( биколор). Там режим программный, а при аппаратном ускорении высвободится больше быстродействия. Вот ссылка про движок
http://zx-pk.ru/threads/22175-novyj-...k-nirvana.html
спрайты в мультиколоре 8 на 2.

Наработки программные с нуля не надо писать будет.

[Lethargeek]

Если делать атрибут 8 на 2, то будет подобие аппаратного мультиколора с расширенными атрибутами.

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

[Smalovsky]

а если вспомнить

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

[Lethargeek]

а если вспомнить

и внимательно посмотреть на дату...

- - - Добавлено - - -

элементная база сильно с тех времён изменилась (и вероятно, позволяла больше даже тогда)

[Smalovsky]

элементная база сильно с тех времён изменилась (и вероятно, позволяла больше даже тогда)

позволяла конечно, но никто не делал. А то что наделали уже не считают спектрумом - атрибутов-то нет!

[Lethargeek]

не считают спектрумом - атрибутов-то нет!

не поэтому, а потому что программируется иначе

[bigral]

не поэтому, а потому что программируется иначе

не поэтому а потому что "элементарная база изменилась" и стало не интересно программировать под монстра (его место занял orange pi)

[Smalovsky]

Я немного упрощенно написал про атрибуты.))
Проблема в том, что при значительном изменении графического режима значительно возрастает объём графической информации. При этом для работы с такими объёмами памяти схема подключения дополнительных страниц спектрума 128 неудобна, поэтому разработчики гибридов делают свои уникальные менеджеры страниц, способных подключать любую страницу в любой из четырёх банков адресного пространства. И как следствие схема подключения страниц спектрума 128 лежит в этих гибридах балластом, как и ПЗУ спектрума 128.
Единственный выход - не отдалятся слишком далеко от видеорежима спектрума.

[Lethargeek]

не поэтому а потому что "элементарная база изменилась" и стало не интересно программировать под монстра (его место занял orange pi)

Как раз поэтому - потому что монстры программируются иначе (а раз так - зачем в них собственно Спек?)

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

Смотря в чём измерять "объём графической информации". Если в ПИКСЕЛЯХ, то он вовсе может не измениться, и обрабатываться аналогично Спеку, и с не меньшей скоростью, чем на Спеке. Только нужен не очередной менеджер страниц, а специальный "менеджер" операций с ПИКСЕЛЯМИ (и неважно, сколько бит на пиксель тогда приходится).