Обзор процедурной графики с DiHalt 2018

Нужно больше обзоров. Краткий обзор работ конкурса LowEnd 1kb Procedural Graphics на DiHalt 2018. Да, это дежавю.



Конкурс процедурной графики в новинку для ZX сцены, хотя уже и успел отрастить бородку. Проводился он лишь два раза — почти десять лет назад на ASCII 2008, где было три работы, и вот теперь, на DiHalt 2018. Также было несколько разноразмерных и разноформатных одиночных работ в разные годы в нетематических конкурсах, включая, пожалуй, самую мощную работу на текущий момент — northern sunset s!lence от bfox, победившую в Combined 256b компо на CC2017.

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

При адаптации формата конкурса для ZX объём кода был уменьшен со стандартных для процедурной графики на современных платформах (PC, JS, Amiga) четырёх килобайт до одного килобайта. Причина выбора такого ограничения — чтобы в этот размер нельзя было просто сжать картинку обычными упаковщиками, но в то же время оставить достаточно места под код. На ZX довольно легко упаковать стандартный шестикилобайтный экран в четыре килобайта, а вот в один килобайт много не напакуешь. Хотя такие попытки и предпринимались, но это скорее были первые шаги в процессе освоения авторами нового для них формата.

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



Escher — g0blinish



Классическая невозможная геометрическая фигура, отрисованная линиями. В плюсах работы — её размер, всего 237 байт, в минусах — отсутствие художественности и оригинальности, это переделка Бейсик-программы из старого журнала, о чём автор честно упоминает в описании. Крайне простые содержание и техника дают ожидаемое четвёртое место.

С презентацией работы случился небольшой казус. На финальном изображении в голосовалке есть надпись 0 OK, 20:3, что при первом просмотре заставляет подумать о том, что она, возможно, сделана на Бейсике, либо же это таакой художественный элемент, чтобы создать впечатление 'как бы на Бейсике' и добавить интереса. Но в самой программе такой надписи нет, написана она на честном ассемблере, использует стандартную процедуру рисования линии из ПЗУ, рисуя фигуру по набору координат.

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



nogfx — nyuk



Абстрактное изображение с надписью на злобу дня, сильно напоминающее скриншот плазмы из какого-нибудь интро. Насколько я смог оценить беглым взглядом, сделано честным кодом — несмотря на простоту финального изображения, стандартные пакеры сжимают его лишь до 1.2-1.7 килобайт.

В минусы работы можно занести отсутствие художественной составляющей, при этом размер кода относительно большой, 905 байт. В плюсы — очень быстрая отрисовка, наличие хоть какого-то цвета, и, вероятно, идеологическая подоплека, хотя и едва ли понятная вне узкого круга посвящённых. Третье место.



Salvador — Dalthon



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

Насколько мне известно, этот стиль пиксельной графики, состоящей из одних треугольников, берёт своё начало с C64, с местного подвида ASCII/ANSI арта, основанного на встроенном шрифте C64 и называемого PETSCII, и периодически всплывает в работах разных пиксельных художников. Автор работы из Польши и замечен в создании различных интро для Commodore Amiga, так что всё сходится.

Думаю, технически работа не очень сложна, скорее в ней преобладает художественная составляющая. Не смотрел, как она реализована на самом деле, но по сути подобное изображение можно хранить как атрибутную картинку, отдав бит мигания на выбор одного из двух диагональных символов, плюс некоторый код для вывода текста со шрифтом двойной высоты и дитерингом, полученным программно из стандартного шрифта в ПЗУ. Так или иначе, смотрится весьма эффектно. Второе место.



1k_is_pretty_n!ce — bfox



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

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

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

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

avatar
С презентацией работы случился небольшой казус. На финальном изображении в голосовалке есть надпись 0 OK, 20:3, что при первом просмотре заставляет подумать о том, что она, возможно, сделана на Бейсике, либо же это таакой художественный элемент, чтобы создать впечатление 'как бы на Бейсике' и добавить интереса. Но в самой программе такой надписи нет, написана она на честном ассемблере, использует стандартную процедуру рисования линии из ПЗУ, рисуя фигуру по набору координат.
Автор прислал программу, которая генерирует картинку и надпись. Мне кажется, нужно оценивать весь скрин, генерируемый программой, ничего не отрезая. Т.е. на мой взгляд, показано всё верно.

А в целом, спасибо за обзор!
avatar
Да, безусловно, отрезать ничего не нужно. Я подумал, что надписи быть не должно, т.к. при запуске TAP'а программа кончается на CPU HALTED, без каких-либо надписей. Сейчас посмотрел, оказывается, там просто что-то не в порядке с завершением, SCL версия может кончаться различным образом, включая сброс, сообщение F ####N! -20:3, и прочее подобное.
avatar
Ага, теперь понятно, почему на пати эту работу удалось запустить с третьего или четветого раза. У автора оставалось 787 байт, неужели нельзя было потратить два из них на jr $

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

moroz1999 а ты можешь по всей своей огромной базе картинок посчитать, какое распределение по размеру имеют картинки в .gif/.png? Чтобы понять, насколько 1К как ограничение выбрано верно…
avatar
Я не уверен на 100%, но мне кажется, что оценивать размер png/gif некорректно.
avatar
По идее, если сжато все грамотно, то результат будет валидным. Другое дело, что оба .PNG работы bfox что я вижу занимают действительно слишком много.
avatar
В процессе написания текста пробовал паковать все картинки MegaLZ и Hrust, у них оказался очень существенный разброс по результатам. Тут скорее надо брать за мерило какой-то современный пакер для картинок, который даст лучший результат. А такого под рукой не было, давно уже не пригождались. Но да, определённо надо ввести такой дополнительный критерий оценки в обзорах будущих работ.
avatar
А что, LASER COMPACT уже отменили? Или другое картинко-ориентированное?
avatar
Не отменили, просто я его с прошлого века не видел. Не было необходимости. У нас же тут теперь кругом кросс-разработка, перетаскиваем файлики на exe-шники.
avatar
согласинг
avatar
Обнаружил PC-порт Laser Compact 5.2.1. Результаты со встроенным депакером, т.е. на выходе получается кодовый блок, выдающий то же самое изображение:

Escher — 843 байта (оригинал 237)
nogfx — 1336
Salvador — 937 (оригинал 869)
1k_is_pretty_nice — 1184
avatar
На мой взгляд, результат проверки ясно дает понять, что 1к слишком много.
avatar
скорее многовато, чем много.

реально было бы очень круто прогнать массово архив мороза через PC-порт Laser Compact и посмотреть распределение размеров… работа на диссертацию тянет, можно и профессора подключить!
avatar
API запрос, который возвращает все работы со ссылкой на скачивание оригинала в JSON формате.
domain/api/action:filter/types:zxPicture/export:zxPicture/language:eng/start:0/limit:12000/order:date,desc/filter:zxPictureAll=1;

domain надо заменить на zxart.ee — это чтоб поисковики у меня этот запрос лишний раз не дергали.
avatar
Пожалуй да, многовато. Я думаю, лимит в 1024 байта был хорош для старта, чтобы народ освоился, а дальше надо подзатягивать гайки. Например, следующим шагом сделать 768 байт (классический атрибутный размер), а со временем видимо стоит придти к 512 байтам.
avatar
уверен, что 768 будет вполне достаточно для размаха, при котором возможности простой печати готового спрайта будет нивелирована… И конечно все эти бейсики отставить и никакого ПЗУ. А уж если ограничится черно-белым сценарием, то это вообще становится кросс-платформенной историей.

Тут крутым ориентиром являются старые текстовые адвентюры с генерацией графики при переходе в локацию. Где-то были даже подсчеты, сколько там в среднем занимал один экран…
avatar
Если всех устраивает нынешнее качество работ, то можно и уменьшать лимит. Но можно ведь идти и в усложнение? Паковка лазеркомпактом первоместной работы в 1184 байт показывает, что более изощренный код мог бы дать более сложную и насыщенную картинку, сейчас ведь далеко не предел по сравнению с тем, что мы максимально видели в 6912.

Я за сохранение лимита в 1к, привлечение внимания к компо и усиление конкуренции в этом формате. Готов посотрудничать с кодерами!
avatar
Тоже хороший путь развития. Но в целом пока всё упирается в количество компо и работ, чтобы компо могли состояться. Это замкнутый круг всех новых форматов, который надо как-то разорвать, и в данном случае дело осложняется тем, что порог вхождения относительно высок. Как это сделать — не знаю. Как вариант, начать делать больше продов не на конкурс, накапливать базу работ-ориентиров и писать making of. Или провести тематическое виртуал компо. Или и то и другое.
avatar
Надо было кодеров до пати пинать, анонсы я заранее по всем канальчикам кидал) в одном из канальчиков мне ответили «при чем тут художники», хотя именно на них я большую ставку делал)
avatar
вооот… вот это совершенно другое дело — спасибо!
avatar
На zxart не оптимально сжатые png, смысла нет считать их размеры.
avatar
А вот это был великолепный конкурс. Очень классно расписаны работы, спасибо!
avatar
Когда обсуждалось это компо, я предлагал сделать лимит в 512б. Это примерно та точка невозврата, где компрессия уже реально не будет справляться даже с самыми простыми изображениями. Но решили начать с 1к.

Работа Гоблина мне показалась не очень интересной. Всего четырнадцать линий на каждом целом ребре, умножить на 6 выходит меньше 100 байт на данные. Это даже если ничего не изобретать в плане сжатия. Поэтому такая картинка была бы интересна только в объёме 128 байт и меньше. Примерно по тому же принципу, несжатая 24х24 атрибутная картинка Далтона занимает полкилобайта, поэтому в плане процедурной графики может быть интересна в объёме 512 байт или меньше. Поэтому эти работы не вполне являются процедурной графикой в моём понимании.

Про работу Нюка я просто не очень понял. Ну т.е. концепт в порядке, анонс демо в другом компо и всё такое. Сейчас такая мода. Но вот сама картинка в изоляции — она не очень меня тащит. Я не знаю в каком объёме это станет интересно, потому что даже на уровне вижуалсов не вполне ясна цель, что показываем. Ясно только, что само это не напишется, какие-то усилия понадобятся. Между Нюком и Далтоном я не знаю как бы я выбирал. У Далтона типа концепт, у Нюка типа тоже. Наверное поставил бы один балл и доверился голосующему оллу.

Работа Бифокса — честные векторы почти целиком. В чём-то круто, картинка реально милая. Но ощущения шока, как от старых работ Ширу, или даже как от работы Бифокса с питерским мультиколором — нет.

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

avatar
Ты специально взял новодел, в котором вся вообще графика — пиксельная, потыренная с коммодора? :)
avatar
Да. Я же не настоящий программист. Возьми Level9 там все наглядно:

avatar
Я тебя в прошлый раз тоже понял, ты просто смешно подставился.
Да, наверное. Но мне очень мало что в этих текстовых играх из графики нравилось. Слишком примитивное всё. Я вон чуть выше про фейспик Бифокса ворчу, а ты хочешь, чтобы мне совсем примитивная графика понравилась. Я скорее думал про список реальных дем, и там у нас будет пара работ Ширу, пара работ Ньюарта и несколько работ CPU.
avatar
Это так, да и можно вспомнить книжку 'Как написать игру на Бейсике', там было процедурное рисование пейзажа. Но с этими старыми приключениями есть одно но: там упор на оптимизацию размера множества картинок, а не одной отдельно взятой. Рисующий код там относительно большой, и думаю (не знаю точно), если выделить одну среднюю по детализации локацию и код, они по размеру превысят даже наши 1024 байта.
avatar
1024 для zx — много, правила не устоявшиеся, для себя решил не участвовать, врямя можно потратить, а в итоге все зарубит какая-нибудь смешивающая цвета двуэкранно-бордерная (разваливающаяся при остановке процессора). Но это вопрос трактовки «cтатичности картинок».
Считаю также, работы становятся близки к профанации, если обычным упаковщиком сжимаются недалеко от компоразмера.
В принятом к компо-стандарту упаковщику, перед проверкой-упаковкой-выдачей размера, графика в знакоместах с одинаковыми ink/paper должна удаляться.
Но в любом случае, участники молодцы, еще до темы плюсанул на pouet :)
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.