Опишу для чего все это надо.
Делал двукадровую анимацию через применение атрибута флеш и столкнулся с проблемой: раскраска знакомест мерцающими цветами просто выносит мозг.
Когда смотришь на результат все нормально, но редактировать тяжко — ни переместить атрибут отдельного кадра, ни «поставить на паузу» мерцание не выйдет.
Все нужно делать «попиксельно», причем Ink и Paper при совпадении/несовпадении пикселей из первого и второго кадра будет разный.
Так можно и в эпилептический припадок свалиться как от некоторых японских мультиков ))
Опишу как можно реализовать простейший алгоритм рисования двух кадров по отдельности.
Например, каждый рисуется в своем экземпляре ZX-PaintBrush, затем слияние двух атрибутных картинок в одну.
Используются только восемь цветов Paper, в одной яркости, без применения Ink.
Как можно реализовать на zx.
1. загрузить обе картинки в неэкранную область памяти
2. пробежаться по каждому значению с адреса начала атрибутов(куда загрузил + 6144), всего 768 ячеек
3. сравнить Paper первой и второй картинки,
— если отличаются, то записать в экранную область атрибутов:
папер = цвет первой
инк = цвет второй
брайт = яркость первой
выставить атрибут мерцания
— если не отличаются, записать папер и брайт первой картинки
4. выгрузить экран как screen$
P.S. Вот картинка на которой я попробовал сделать простую двукадровую анимацию через флэш. Я вижу в ней косячки, но переделывать не стану ибо мозг дороже ))
И снова про flash )
Есть ли программа, позволяющая из двух экранов содержащих атрибуты «слепить» один экран содержащий оба через применение flash-атрибутов?
Согласен, больше так глубоко не задумываемся. Сначала хотелось как-то сделать, чтобы всем было хорошо, а теперь это желание поутихло. Хорошо будем делать только тем, кто готов работать на общее благо.
мне кажется вы слишком глубоко задумываетесь о том, о чем не нужно — особенно об авторских правах в разрезе демосцены и некоммерческих релизов.
Если есть не поддерживаемые больше ресурсы или ресурсы со слабым функционалом, но при этом есть новые силы у новых людей — надо брать и делать. Просто брать и делать. Личные мнения пусть высказывают сами авторы, уже на новом ресурсе. Должна быть эволюция, должны быть изменения на волне новых технологий.
Отлично. Я в тебе не сомневался :)
Не хотел обобщать, просто как ни заикнусь о копировании базы, столько шума появляется.
zxtunes.com — неварт долго мне мозги морочил и резину тянул, а потом и вовсе обвинил в воровстве (!).
zxaaa — ААА матами покрывает ни за что.
WoS — уцепились за авторские права, хотя у самих две трети коллекции на птичьих правах, да разрешение получал Мартин, а не текущая команда.
В общем, мой опыт договаривания с владельцами коллекций пока что был скорее сугубо негативным, чем наоборот.
Люди мыслят категориями собственных коллекций и личных сайтов, а не платформенного архива общеспектрумовского культурного наследия. Не могу никого обвинять в недостатке амбиций, но, честно говоря, ожидал от вышеперечисленных бОлее высокого полета мысли. Впрочем, я готов работать и сотрудничать со всеми вышеперечисленными хоть прямо сейчас, у меня нет никаких объективных причин враждовать.
Да. Это было бы очень правильно, если бы не одно но: у разных юзеров и разных работ может быть GIF или PNG.
1. У юзера может быть выставлен noflick, может быть flicker для gigascreen-работ.
2. В картинке может быть flash-мерцание.
Следовательно, при рендеринге HTML для того, чтобы прописать расширение png или gif, мне нужно слазить на жесткий диск и теоретически уже прегенерить картинку, чтобы узнать — был в ней флэш/гига или нет, будет это гиф или пнг.
То есть, для показа 100 работ надо слазить на жесткий 100 раз — в принципе, не фатально, но:
1. Надо сначала этот проактивный пререндеринг реализовать.
2. Надо померять его влияние на скорость и количество айнодов в файловом кэше.
Сейчас обхожусь более простой схемой — в рендер-приложении для скринов передаю через ссылку имя файла, а расширение буду парсить на ходу. Все равно там контент отдавать, то есть я уже буду знать, какого формата результирующий файл будет и смогу расширение файла приписать к названию и передать в клиент через http-заголовки. На тренировку схожу и сделаю, это слегка костыльный, но относительно простой способ решить задачу.
Было бы всё легко — я бы уже давно прописал :)
Еще как вариант — отказаться от PNG и всё выдавать в GIF. В теории мы по цветам укладываемся в таком случае, тогда можно тупо хардкодить везде .gif и проблем не будет. Кроме возрастающего трафика, так как GIF значительно жирнее, но трафик картинок пока совсем далек от проблемного.
Немного не понял проблемы. Ты поменял гамму? Или что случилось?
Та ссылка, которую я приложил — это уже PNG, поэтому как и любой PNG (вручную приложенный или сгенерированный), он может быть модифицирован по гамме браузером.
Или в чем всё же загвоздка?
Делал двукадровую анимацию через применение атрибута флеш и столкнулся с проблемой: раскраска знакомест мерцающими цветами просто выносит мозг.
Когда смотришь на результат все нормально, но редактировать тяжко — ни переместить атрибут отдельного кадра, ни «поставить на паузу» мерцание не выйдет.
Все нужно делать «попиксельно», причем Ink и Paper при совпадении/несовпадении пикселей из первого и второго кадра будет разный.
Так можно и в эпилептический припадок свалиться как от некоторых японских мультиков ))
Опишу как можно реализовать простейший алгоритм рисования двух кадров по отдельности.
Например, каждый рисуется в своем экземпляре ZX-PaintBrush, затем слияние двух атрибутных картинок в одну.
Используются только восемь цветов Paper, в одной яркости, без применения Ink.
Как можно реализовать на zx.
1. загрузить обе картинки в неэкранную область памяти
2. пробежаться по каждому значению с адреса начала атрибутов(куда загрузил + 6144), всего 768 ячеек
3. сравнить Paper первой и второй картинки,
— если отличаются, то записать в экранную область атрибутов:
папер = цвет первой
инк = цвет второй
брайт = яркость первой
выставить атрибут мерцания
— если не отличаются, записать папер и брайт первой картинки
4. выгрузить экран как screen$
P.S. Вот картинка на которой я попробовал сделать простую двукадровую анимацию через флэш. Я вижу в ней косячки, но переделывать не стану ибо мозг дороже ))
Есть ли программа, позволяющая из двух экранов содержащих атрибуты «слепить» один экран содержащий оба через применение flash-атрибутов?
zxart.ee/eng/graphics/tags/flash/
Если есть не поддерживаемые больше ресурсы или ресурсы со слабым функционалом, но при этом есть новые силы у новых людей — надо брать и делать. Просто брать и делать. Личные мнения пусть высказывают сами авторы, уже на новом ресурсе. Должна быть эволюция, должны быть изменения на волне новых технологий.
Не хотел обобщать, просто как ни заикнусь о копировании базы, столько шума появляется.
zxtunes.com — неварт долго мне мозги морочил и резину тянул, а потом и вовсе обвинил в воровстве (!).
zxaaa — ААА матами покрывает ни за что.
WoS — уцепились за авторские права, хотя у самих две трети коллекции на птичьих правах, да разрешение получал Мартин, а не текущая команда.
В общем, мой опыт договаривания с владельцами коллекций пока что был скорее сугубо негативным, чем наоборот.
Люди мыслят категориями собственных коллекций и личных сайтов, а не платформенного архива общеспектрумовского культурного наследия. Не могу никого обвинять в недостатке амбиций, но, честно говоря, ожидал от вышеперечисленных бОлее высокого полета мысли. Впрочем, я готов работать и сотрудничать со всеми вышеперечисленными хоть прямо сейчас, у меня нет никаких объективных причин враждовать.
нахуйфтопку?казалось бы, причем тут спектрум…
1. У юзера может быть выставлен noflick, может быть flicker для gigascreen-работ.
2. В картинке может быть flash-мерцание.
Следовательно, при рендеринге HTML для того, чтобы прописать расширение png или gif, мне нужно слазить на жесткий диск и теоретически уже прегенерить картинку, чтобы узнать — был в ней флэш/гига или нет, будет это гиф или пнг.
То есть, для показа 100 работ надо слазить на жесткий 100 раз — в принципе, не фатально, но:
1. Надо сначала этот проактивный пререндеринг реализовать.
2. Надо померять его влияние на скорость и количество айнодов в файловом кэше.
Сейчас обхожусь более простой схемой — в рендер-приложении для скринов передаю через ссылку имя файла, а расширение буду парсить на ходу. Все равно там контент отдавать, то есть я уже буду знать, какого формата результирующий файл будет и смогу расширение файла приписать к названию и передать в клиент через http-заголовки. На тренировку схожу и сделаю, это слегка костыльный, но относительно простой способ решить задачу.
Было бы всё легко — я бы уже давно прописал :)
Еще как вариант — отказаться от PNG и всё выдавать в GIF. В теории мы по цветам укладываемся в таком случае, тогда можно тупо хардкодить везде .gif и проблем не будет. Кроме возрастающего трафика, так как GIF значительно жирнее, но трафик картинок пока совсем далек от проблемного.
Та ссылка, которую я приложил — это уже PNG, поэтому как и любой PNG (вручную приложенный или сгенерированный), он может быть модифицирован по гамме браузером.
Или в чем всё же загвоздка?