53c Enhanced (Concept)

Рубрика: безумные идеи Артема

Привет, товарищество.
Во времена не столь отдалённые, за чашкой крепкого виртуального кофе с одним господином мы обсуждали аналог 53c для NES-платформы. В какой-то момент он предложил использовать не полные тайлы 8х8, а разбить их на блоки 4х4 и использовать так. Но все 10 000 комбинаций для 10 цветов одной палитры NES (4 solid + 6 chunky без повторов-инверсий), внезапно и к сожалению, не уместились в два банка памяти NES.

Но это действо чудное подтолкнуло меня к идее для расширения возможностей всеми любимого формата 53c.



Прежде чем читать статью.
Да, возможно я изобретаю велосипед. Никому не нужный велосипед. Или уже что-то подобное существует — я не знаю. Не стоит кидаться в этом случае помидорами =) Описывать буду сумбурно, потому что идея до конца еще не сформировалась и надеюсь на помощь коммьюнити в этом плане.

Коротко, в чем смысл

Имеем стандартный режим 53ц. Далее мы разбиваем каждый «пиксель» на пиксели 2х2, где каждый пиксель имеет режим «paper», «ink» или «chunk». Это даёт нам разрешение 64х48, правда можно использовать только 3 цвета в блоке (т.е. в нашем любимом знакоместе). Возможных расположений на блок, включая повторы, всего 81.

Как это выглядит должно выглядеть

Оригинал моей картинки «69» с реалтайма ЦЦ16
Оригинал моей картинки «69» с реалтайма ЦЦ16

«Мифическое» изображение 53c Enhanced. (sic!) Иллюстрация создана в ФШ только чтобы показать принцип работы теоретического приложения. Могут присутствовать незначительные недочеты. Ну и да, влом было дорисовывать фон.
«Мифическое» изображение 53c Enhanced. (sic!) Иллюстрация создана в ФШ только чтобы показать принцип работы теоретического приложения. Могут присутствовать незначительные недочеты. Ну и да, влом было дорисовывать фон.

Как это будет работать


Я не знаю ¯\_(ツ)_/¯

Как это будет выглядеть, работать — еще не ясно. Как хранится, в принципе, тоже. Но здесь я хочу обратиться к функции «помощь зала». Для начала, опишу, как это выглядит в моей голове:

Каждое знакоместо описывается 16-битным значением (что даёт нам размер файла в 1536 байт, если я правильно посчитал). Один байт из этих бит отведен на стандартного формата атрибуты, а второй должен выглядеть как так (сейчас будет много сумбурной дури):

Легенда
Paper чанкPaper «пиксель»
Ink чанкInk «пиксель»
Chunky чанкChunky «пиксель»

Так как я лох, то я не смог придумать, как соединить 3 варианта отображения с 4 вариантами размещения в адекватное количество бит, поэтому каждый «пиксель», помимо байта цвета имеет байт информации, которая состоит из двух полубайт:
0000   0000
  ^     ^
solid chunky

А еще я не понимаю в битах нихрена, поэтому маппинг, навскидку, вот такой:

ABCD   ABCD
  ^     ^
solid chunky

И каждый блок описывается этим соотношением. 4 флага «solid» и 4 флага «chunky». Флаг «chunky» применяется только если этот же бит включен (режим «solid»). Эх, блин, совсем сумбурно, попробую на примере.



Вот так будет выглядеть наша схема для блока:


И, соответственно, биты:
1101   1001
  ^     ^
solid chunky

Соответственно, там, где solid нулевой — там выводится paper, где solid единица и chunky ноль — выводится ink, там же, где solid единица и chunky единица — выводится текстура «через точку». Вариант solid ноль и chunky единица — выводится paper.

Я всё это описываю в надежде на формат и вьюер, которые сам не осилю.

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

P.S. Перечитал, понял, что нихрена не понятно, ну и ладно, я должен был это написать.

47 комментариев

avatar
ИМХО, помимо технической здесь проявляться еще идеологическая загвоздка — 53С можно очень быстро и легко рисовать, это очень удобный формат для быстрого наваяния шедевров.
И я думаю еще и вебинтерфейс сыграл роль, снизив уровень вхождения.
А так это выходят цветные мультиколорные чанки. Я сейчас на вскидку не помню, реализовывал ли великий гуру чанков и мультколоров TmK такой вариант.
Без мультиколора давным давно реализовывали чанки 4х4 пиксела, с общим ink и paper для знакоместа — в картинках не прижилось, хотя был редактор, еще лет 10 назад.
Далее надо мультиколор уже. а он и так есть и редактор есть, но рисуют в нем единицы, причем долго и упорно рисуют.
Можно сделать в мультиколоре: два соседних чанка 4x4 (и даже 1x4 и 2х4) могут иметь одинаковый ink и paper, но разную штриховку. Выглядит вполне как заказано.
Но. это все таки не каждый «пиксел» своим цветом как с 53С, поэтому парадигма немного меняется. впрочем, если будет веб-рисовалка, то может, такая вариация и «взлетит».
avatar
Спасибо за развернутый ответ. Я совершенно не знаю ничего о том, что было ранее, как работает мультиколор, какие чанки были-не были, просто в голове родилась идея, я вывалил сумбурный пост. Мне уже объясняют, что «не взлетит», пусть даже и так =) Потом придумаю еще что-нибудь потом
avatar
Чуть мозг не сломал. «Пиксель» в 53ц можно смело называть чанком 8х8, тогда понятнее будет.
avatar
Энхансить 53ц, можно по-разному, но это будут уже совсем другие псевдорежимы и форматы. Nuts верно замечает, что фишка 53ц в его удобстве. А точнее в независимости «пикселей». Я вижу только одно развитие — менять текстуру для получения over 53ц. Хотя говорить об этом бесполезно. Пока не нарисуешь и не выложишь, никто не поймет:)
avatar
Ну мне мало «разрешения» в 53ц, отсюда и всякие извращения в голову лезут.
avatar
А 6912 чем не устраивает?
avatar
Скоростью
avatar
Попробуй мультиколор 8х4 или 8х2 без текстур. Независимые «пикселы» размером 4х4 (4х2), 8 цветов (одной яркости), разрешение 64х48 (64х96). Рисовать в любом «фотошопе» и спектрумовской палитре в одной градации яркости.
avatar
любые увеличения разрешения приведут к клэшингу атрибутов
текстурированный чанк 8х8 может представляться единой точкой с диким числом цветов и число цветов можно увеличивать разными несложными путями
программными методами, а именно методикой мультиколор, размер чанка можно как бы уменьшить до 8х4 8х2 и 8х1
то есть два цвета и текстура на 8 x 1..8 физических пиксела.
для таких режимов сделан специальный редактор, но число картинок в таком режиме очень невелико.
И собственно тут как бы уже зачем прямоугольная текстура, просто используется для того чтобы атрибутные квадраты превратились в атрибутные прямоугольники
и от первой 8ки никуда не деться
можно виртуально разбить эту 8 на два, то есть чанки 4 х 1...8 пиксел, но у каждой такой пары чанков будет общий ink и paper
небольшое, но все таки ограничение, однако в общем то будет выглядеть примерно как было высказано пожелание выше.
обычно же делают 4 пиксела чисто ink. потом 4 — только paper — получается как будто каждый чанк 4х4 без текстур, но каждый любым из 16 цветов
avatar
Есть основное средство!
avatar
Однако сразу вспомнилась synchronisation :)
avatar
Ну вот смотри сам.



В левой части, это то что сейчас можно сделать в 53с. А в правой, то что предлагает Артем. При этом, мы не меняем физическое разрешение и не увеличиваем количество цветов. Есть стандартный атрибут с двумя цветами: папер на всей площади и нарисованный квадрат 4x4 пиксела или же вертикальная/горизонтальная полоска другого цвета, прижатые к какому-либо краю этого атрибута, как в данном случае. И из таких вот атрибутов (с более мелкими «частями» внутри) строится изображение. Конечно времени на это будет затрачено больше, чем на обычную 53c и от клешинга мы никуда не денемся. Но согласись, что правая часть, даже при таком минимуме, выглядит гораздо лучше, чем левая.
avatar
Вот да! Именно это я и пытался показать, спасибо!
avatar
Зато в 53с порог вхождения минимальный — все интуитивно понятно, каждая точка своим цветом, разрешение минимальное, можно за 20 минут что-нибудь приличное изобразить. А тут, для стороннего человека поди разберись сначала с этими блоками. Ну и затраты на рисование возрастают раза в 2-3, тогда уж проще 6912 рисовать. Еще вопрос, как редактор удобный сделать.
avatar
Ну так а кто заставляет пользоваться только этим?
Хочешь так рисуй 53с, как раньше и за 20 минут. Но можешь потратить больше времени, разобраться и украсить свою работу подобными элементами. Объединять это нужно, а не несколько отдельных редакторов делать.

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

Все же дело в личной заинтересованности и не более того.
avatar
Вот именно, что если отталкиваться от 53ц, в моей голове процесс такой:

1) Набросали в 53ц основу
2) Переключились в режим «detailed» (это довольно просто рисовать)
3) Уже по готовому расставили деталей

Я вот так свою 69 модифицировал, даже с учётом, что всё пиксели делались руками в ФШ это не заняло много времени.
avatar
Рисование текстурными кистями сильно упрощает процесс. Пример — рилтаймы и обычные работы moroz1999. Привязывание кистей к сетке немного сужает простор в плане разрешения, но упрощает использование цветов.
avatar
Справедливости ради — в риалтаймах много попиксельной работы над ключевыми деталями, не менее 50% времени, а в обычных работах и подавно. Интереса ради прикинул — без кистей я бы пользовался заливкой очень активно, это главный кандидат на замену, если бы не было кистей.
avatar
если не применять тут еще и мультиколор то это обыкновенные раскрашенные чанки и тогда
1) зачем использовать только 3 текстуры когда можно 16
2) готовый редактор уже как бы есть, но
3) нужно чтоб графреактор учитывал клэшинг сам
но в любом случае борьба с ним обеспечена.
применение мультиколора вместе с чанками позволит снизить клэшинг с 4 соседних чанков до 2
это уже вполне совсем терпимо
но софтов для этого совсем нет вроде
avatar
Рисовать в таком режиме будет трудно, так как теряется цвет на пиксель. В демо такие цветные чанки использовали наверняка, но не для прорисованной графики. Вообще, такой видеорежим выходит немного тормозным. По расходу памяти… на каждое знакоместо нужно 7+7 бит (7 бит на атрибут — нам же не нужно мерцание?, и ещё 7 бит чтобы хранить 3^4=81 возможное состояние 4-х чанков из трёх возможных состояний в каждом знакоместе), грубо — пара байт. Скорее всего, был бы смысл хранить состояние каждого чанка 4х4 пиксела как 2 бита, так что 4 чанка в знакоместе потребуют 1 байт, и второй байт — атрибутный.
avatar
Я вот сейчас ничего не понял =) Я же написал про два байта, не?
avatar
Ты просто звучишь там неуверенно как-то, поэтому я просто написал как бы сделал я сам.
avatar
А при статичном мультиколоре?
avatar
Мультиколор позволит иметь произвольные цвета в каждом ряду 4х8. Т.е. пары соседних чанков всё равно оказываются одного цвета. Надеюсь, что это отвечает на твой вопрос, т.к. я без понятия что ты спрашивал :)
avatar
просто не въехал в рассуждения.
avatar
да в демоэффектах однозначно использовались цветные чанки и 8x8 и 4х4
а вот графики как таковой,, ну может единичные случаи были
avatar
Если я правильно понял, то это вариация на тему UDG с цветом.



Символы из нижней строчки + текстура для получения дополнительного псевдоцвета.
avatar
Да, выходит именно так, кстати. Возможно, так будет «дешевле» хранить?
avatar
а может просто текстура? я что то не допираю зачем это
avatar
Цвет же на точку, с уменьшением разрешения и расширенной палитрой можно например делать так:



Жесть конечно, когда у тебя «пиксел» (ну или чанк, называйте как больше нравится) размером 8x2 =) Ну или вот еще один вариант того же, но с чуть большим разрешением:
avatar


Но эти точки, 2x2 уже отдельно руками прорисованы были, редактора для подобного нет.

В 53c можно добавить гига палитру. В итоге, 102 цвета получим. Так у меня например сделан эпилог в «kpacku deluxe». Но сами понимаете, что это мерцает. Да и выгода от увеличения количества цветов не такая уж и большая, как кажется. Гигу я рисовал, но там даже на хайрез картинках используется максимум 30-40 цветов.

Да еще можно рисовать на границах атрибутов или мультиколором. Но для меня лично последний не столь интересен, палитра в нем стандартная и геммороя с отрисовкой больше. Да и редакторов внятных просто нет.
avatar
А киньте кто-нибудь адекватное описание мультиколора? А то гигу я познал, а про мультик что-то плохо понимаю
avatar
Вкратце, описание от «художника»: атрибуты для знакомест (и гига атрибуты тоже) можно сделать не 8 пикселей высотой, а до 1 пикселя. Элементы экрана размером 8x1 можно покрасить различными атрибутами. В случае обычного цвета (не гига), ничего мерцать не будет, хотя требуется точная подстройка под каждый клон спектрума. Вплоть до размера 8x2 атрибуты могут быть абсолютно любыми для всех «знакомест». Единственное ограничение: в режиме 8x1 абсолютно любая раскраска не доступна для всей ширины строки, потому что это программно невозможно.

Ознакомиться с этими режимами можно в редакторе Multiartist, ну или изучить любую картинку под лупой, благо на zx-art все рассортировано по форматам. Ссылки на zx-art по форматам и ссылки на multiartist были в FAQ: hypr.ru/blog/graphics/320.html
avatar
Касательно NES, да вроде не надо аж 10000 комбинаций. Хотя и это в принципе возможно, если взять MMC5, он поддерживает 16384 тайла на экране одновременно. А в стандартной конфигурации — даже без выкидывания повторов все комбинации двух соседних по горизонтали чанков 4x4 с 10 штриховками дают 100 тайлов, меньше половины одного набора. Раз уж речь шла о двух банках, значит предполагался сплит, но принципиально ничто не мешает делать этот сплит каждые 4 строки пикселей. Т.е. не нужны комбинации всех четырёх чанков в тайле, только двух — левого и правого.
avatar
Недопояснил, сплит в данном варианте должен переключать не банки графики, а текущую тайловую карту. Штатно их всего две, в одной можно хранить нечётные строки чанков, в другой чётные. Каждую половину тайла по вертикали переключать отображаемую карту тайлов. Таким образом будет отображено 60 полутайлов в высоту, вместо 30 целых тайлов.
avatar
что-то я не очень понял, как это работает, можно поподробнее? Т.е. у нас в банке A — верхние строчки, в банке B — нижние? И можно рисовать тайлы не 8х8, а, грубо говоря,8х4, переключая банки? Тогда, да, это решит проблему и даст два набора в 100 сочетаний, который можно сочетать между собой. Это может сработать
avatar
Всего один набор тайлов, он никогда не переключается. Чанки в нём 4x8, т.е. верхняя и нижняя половины всегда одинаковы. Две nametable, в одной номера тайлов для чётных чанковых строк, в другой для нечётных. Каждые 4 строки пикселей переключаем отображаемую nametable. Да, по сути получаем тайлы 8x4. Это не может, это точно сработает, подобное уже делали.
avatar
А, понял! Круто, спасибо
avatar
ну в общем для денди это сработает. но остальных вопросов это не решает…
avatar
Идея сама по себе отличная. Подводные камни:
1. Надо отталкиваться от того, что можно принципиально показать на реале. Честный «цвет на пиксель» в таком формате не реален, если правильно понимаю.
2. В два раза выше разрешение = в четыре раза выше пикселей = в четыре раза больше работы над картинкой = в четыре раза меньше участников на компо :) Это в целом шутка, но, думаю, с долей правды.

zxart.ee/rus/grafika/poisk-po-baze/pictureType:lowresgs/sortParameter:date/sortOrder:desc/resultsType:zxitem/ — есть еще такая lowres гига. По сути то же, что prof4d показывал, но в готовом формате и вроде как даже был где-то веб-редактор.
avatar
Есть редактор, да. Но блин, вытянутые пиксели, бррр =)
avatar
в общем вот редактор 1999го года
формат которого поддерживаеться известными вьеверами
viva-games.ru/game/hard-core-4x4-chunks-gfx-editor
© TmK
avatar
avatar
И еще бета-ссылку вброшу:
zxart.ee/eng/software/tool/graphics/hard-core-4x4-chunks-gfx-editor/
avatar
как то я его пропустил. спасибо, посмотрю
avatar
собственно тут vtrdos.ru/system.php#s19 гепринужденно находиться еще 5ок редакторов разных форматов :)
режимов надумали много
avatar
только с атрибутами у него несколько странно все — отгружаются в режиме 6912
но… это много больше чем ничего
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.