Я надеюсь, что ты понимаешь, что я помянул вас полушутя, ни на что не намекая?
Я лично для себя поставил во главу угла совместимость с классикой и всегда её обеспечиваю, в частности, просто никогда не пишу эффекты в которых заведомо уверен, что фикс под классику не получится. Но моё отношение к пентагон-сцене немного сложнее. С одной стороны, мне иногда хочется, чтобы демо Красок или Сибкрю смотрелись и за границей, там где пентагоны встречаются, но не являются стандартом. С другой стороны, наследие отечественной пентагоновской демосцены 1990х такое, что, как мне кажется, пентагон более чем заслужил своё место под солнцем. Поэтому даже если я и подтруниваю иногда над Красками и Сибкрю по этому поводу, я ни в коем случае не хотел бы создать впечатление, что это как-то приумаляет их достижения.
В случае с Коммодором, кстати, имеются объективные причины. Чип коммодора работает не в RGB, как мы привыкли, а в другом цветовом пространстве — HSL (hue, saturation, luminance). «Круглые» значения цвета в HSL переводятся в довольно странные значения RGB.
Дима, всё ещё хуже. Я совсем не уверен, что многие люди делавшие клоны типа АТМ всерьёз задумывались о гамме. Про Sam Coupe не знаю, но допускаю что вполне может быть та же фигня. История компьютинга допускает.
Т.е. ты переживаешь что палитра не та, а на самом деле палитра запросто может быть та. Просто разработчики не задумались о гамме.
1. Это действительно была ошибка, но я не знаю чья. Менять напряжения линейно очень неумно, так как подразумевает гамму 1.0, в природе не существующую. По-хорошему лвд должен был делать ступени исходя из гаммы 2.3-2.5. Но вполне возможно что в тот момент они пошли на поводу у совместимости с палитрой АТМ.
2. Как линейный RGB.
3. Эмулятор не должен заниматься корректировкой гаммы, это задача твоей графической карты.
Твое предположение про старые RGB мониторы с линейным цветом практически наверняка неверное. Нелинейная яркость — это фича электронно лучевых трубок. В sRGB прописана гамма 2.3, но в телестандарте PAL гамма 2.5, но старые телевизоры имели иногда даже 2.8.
anadara, я прочёл ваш пост с удовольстием. Но моё удовольствие было бы ещё больше, если бы пост был убран под кат, так как сейчас главная страница оказалась совершенно неоправданно перегружена.
Саша, просьбы смотреть на реалах были в большой степени мотивированы тем, что в графикс компо и в демо компо завелось много работ в мерцающем цвете, которые было крайне модно показывать в различных вариантах ноуфлика. Это бесило некоторых (вроде меня).
Назвать Алана Тьюринга британским инженером — это, конечно, пять.
Но если учесть что Тьюринг — один из людей, сформировавший парадигму компьютерных вычислений вообще, я не уверен, что стоит сильно удивляться тому что мышление для современных компьютеров не особенно то и изменилось. Для смены парадигмы нужен ещё один Тьюринг.
Я кстати тоже подумал про LTE, но т.к. я современный прог слушаю мало, подумал что м.б. просто у меня ассоциация по незнанию. Очень круто что ты подумал именно про них же.
Относительно «демо-анимы» можно поговорить отдельно, хотя не знаю интересна ли тебе эта тема. Я лично считаю аниму просто один из приёмов в репертуаре, не главным, но безусловно полезным. Я делал демо чисто на аниме, я делал демо с элементами анимации; я не знаю всё, что закодил ты, но я смотрел Iris и я могу себе представить, что для тебя как для олдскул кодера у меня анимы очень много. Поэтому скажу так. Не всё что я делаю в своих демо основано на быстро распаковываемых данных. Но я безусловно держу эту опцию в уме и при необходимости/возможности — применяю.
Я не считаю что всё нужно паковать одним компрессором. Есть компрессоры которые жмут хуже, но намного быстрее распаковывают; они полезны в своей нише. Есть компрессоры, которые прекрасно жмут, но распаковывают часами (см. Shrinkler на диаграмме в комментарии чуть выше).
Короче, есть некая условная грань оптимальности Парето. Как бы если ты готов затратить некое конечное кол-во вычислительных ресурсов, ты не сможешь получить сжатие выше, чем позволяет эта грань. Грань на данным момент показана на диаграмме в комментарии выше по треду. Глядя на эту грань, я выбираю себе лучший компрессор для текущей задачи. Например, для универсального сжатия в ядре демо я сейчас использую MegaLZ; LZSA2 для меня в этой роли сейчас на втором месте, из-за слегка худшего сжатия графики. Но если в демо что-то не будет успевать на стыках, я поставлю LZSA2 и решу эту проблему. В то же самое время, один из эффектов у меня сейчас в демо требует покадровой распаковки атрибутов (пикселы сделаны эффектом, а вот раскраска — анимацией). В этом случае скорость абсолютно важна, поэтому в эффекте задействован LZSA1.
Некоторые успехи товарищей на других платформах ты можешь увидеть на моей диаграмме. Если очень коротко, я протестировал дохренища всего, не думаю что много упущено. Всегда есть потенциал что-то упустить из вида; но фундаментально, на Z80, с моей точки зрения все ведущие игроки сейчас обозначены.
И, да, запаковка на Z80 представляется мне абсолютно архаичной. С моей точки зрения в ней тупо нет смысла.
На этом графике показаны результаты 3х распаковщиков MegaLZ — самый медленный это старый («DEC40.asm», 110 байт), совпадающий по скорости с Hrum — это новый оптимизированный по размеру (92 байта) и тот, который чуть быстрее 3*LDIR — новый оптимизированный по скорости (234 байта).
Учти что график генерируется на основе старого корпуса (того же, что в 2017 году), а табличка выше — на основе нового. Я буду переходить на новый корпус из-за того, что в старом было маловато графики (где-то 20% данных) и великовата средняя длина файла, что слегка искажает результаты тестов (скажем, на старом корпусе LZSA2 слегка обходит MegaLZ по сжатию, т.к. имеет намного большее окно, а отставание на графике не так заметно из-за небольшого кол-ва графики в корпусе). С поправкой на эти моменты, вот где я сейчас:
Ну просто представь что ты что-то такое сделал. Тогда у тебя на экране будет линия, которую нельзя будет пересекать графике фона (чтобы изображение не разрезалось). В нормальном скроллере будут препятствия заставляющие тебя смещаться вверх или вниз, что означает, что либо тебе придётся как-то думать как сдвигать эту линию разреза в зависимости от происходящего на экране, либо просто запретить графике пересекать её, что сильно ограничит какие препятствия могут быть возможны. Короче, я думаю что твоя идея имеет смысл, но наверное не в контексте шмапа, а, допустим, в чём-то типа многослойного параллаксного скроллера.
Ну и относительно приема — если скроллить половину экрана в одном кадре, а ещё половину в другом — у нас получится сечение луча — стык между экранами будет хорошо виден. Другое дело, что теоретически можно рисовать за лучом, и это используется в играх на спектруме. Но Zynaps не использует эту возможность.
Я лично для себя поставил во главу угла совместимость с классикой и всегда её обеспечиваю, в частности, просто никогда не пишу эффекты в которых заведомо уверен, что фикс под классику не получится. Но моё отношение к пентагон-сцене немного сложнее. С одной стороны, мне иногда хочется, чтобы демо Красок или Сибкрю смотрелись и за границей, там где пентагоны встречаются, но не являются стандартом. С другой стороны, наследие отечественной пентагоновской демосцены 1990х такое, что, как мне кажется, пентагон более чем заслужил своё место под солнцем. Поэтому даже если я и подтруниваю иногда над Красками и Сибкрю по этому поводу, я ни в коем случае не хотел бы создать впечатление, что это как-то приумаляет их достижения.
Съешь еще этих тонких красных линий...
Хотя, как пишут сами разработчики Коммодора, в итоге всё всё равно сводится к экономии копеек на итоговой железке: «I'm afraid that not nearly as much effort went into the color selection as you think. Since we had total control over hue, saturation and luminance, we picked colors that we liked. In order to save space on the chip, though, many of the colors were simply the opposite side of the color wheel from ones that we picked. This allowed us to reuse the existing resistor values, rather than having a completely unique set for each color.»
Т.е., то, что белый с bright 0 на спектруме — не 128 — это удача. Нам повезло, авторы спектрума о гамме знали.
Т.е. ты переживаешь что палитра не та, а на самом деле палитра запросто может быть та. Просто разработчики не задумались о гамме.
2. Как линейный RGB.
3. Эмулятор не должен заниматься корректировкой гаммы, это задача твоей графической карты.
Твое предположение про старые RGB мониторы с линейным цветом практически наверняка неверное. Нелинейная яркость — это фича электронно лучевых трубок. В sRGB прописана гамма 2.3, но в телестандарте PAL гамма 2.5, но старые телевизоры имели иногда даже 2.8.
Но если учесть что Тьюринг — один из людей, сформировавший парадигму компьютерных вычислений вообще, я не уверен, что стоит сильно удивляться тому что мышление для современных компьютеров не особенно то и изменилось. Для смены парадигмы нужен ещё один Тьюринг.
Короче, есть некая условная грань оптимальности Парето. Как бы если ты готов затратить некое конечное кол-во вычислительных ресурсов, ты не сможешь получить сжатие выше, чем позволяет эта грань. Грань на данным момент показана на диаграмме в комментарии выше по треду. Глядя на эту грань, я выбираю себе лучший компрессор для текущей задачи. Например, для универсального сжатия в ядре демо я сейчас использую MegaLZ; LZSA2 для меня в этой роли сейчас на втором месте, из-за слегка худшего сжатия графики. Но если в демо что-то не будет успевать на стыках, я поставлю LZSA2 и решу эту проблему. В то же самое время, один из эффектов у меня сейчас в демо требует покадровой распаковки атрибутов (пикселы сделаны эффектом, а вот раскраска — анимацией). В этом случае скорость абсолютно важна, поэтому в эффекте задействован LZSA1.
Некоторые успехи товарищей на других платформах ты можешь увидеть на моей диаграмме. Если очень коротко, я протестировал дохренища всего, не думаю что много упущено. Всегда есть потенциал что-то упустить из вида; но фундаментально, на Z80, с моей точки зрения все ведущие игроки сейчас обозначены.
И, да, запаковка на Z80 представляется мне абсолютно архаичной. С моей точки зрения в ней тупо нет смысла.