Самый популярный вопрос и ответ в одном флаконе:
Нет, я не главный. Правда. Совсем.
Остальные как-то так:
Да, я что-то знаю. Тайно. От всех. Но не скажу.
Да, организаторы Дихалта знают, что делать, правда.
У нас есть разрешение.
Костры разводить нельзя.
Вашу демку обязательно примут.
Мы не гарантируем безопасность.
ZORBA вне закона )
Итак с калькулятором. это основное видео занимает всего то 160 секунд значит в нем кадров 1600-1700, чтобы влезть в 880кб дискеты каждый кадр должен иметь размер не более 530 байт. уже впечатляет. Плюс там ведь еще много всего, минус общая компрессия кодовых блоком на диске.
Но фишка то то в том сколько занимает кадр «оригинального» видео, он тут применяет tiles наверное 8на8 с палитрой может 16 цветов на tile, в каком еще видео режиме. Вот давайте оценим такой кадр визуально, сколько он занимает? Все в размытых квадратиках в очень ограниченной цветовой палитре. Как оценить сжатия визуально?
Далее — откуда крик про незацикленное потоковое видео с диска? в рассматриваемом веде там повторение на повторении одинаковых кусков идет. в 28кbps оно не зацикленное, но там идет узкая полоска и без спецэфектов. Не забываем что в амиге дофига оперативы чтоб в ней держать полдиска 880к
Но даже если с диска грузить — я повторюсь там DMA и на звук и на FDD — в чем тут новизна и очевидный прогресс?..
Nuts_, извини, я устал толочь воду в ступе. Тебе похоже, мне не похоже, это мы установили. Я считаю что твоё соображение некодерское. Ты считаешь иначе. Договориться не выйдет.
А вот может не надо ко мне приписывать не мои подвиги? мой самый первый вопрос здесь был посвящен кто у кого содрал идею.
Человеку который разбирается в истории демосцены. unbeliever же сказал что тут вообще чанков нету и я не вижу новизны.
diver4d еще довольно в тему приплел вопрос про демотулзы, после чего ты приплепил тему про коэффициент сжатия и что в нем вся новизна.
После чего я отвечал вам каждому по отдельности про свое, проявлял между прочим ширину взгляда на вещи, а ты, успешно компилировал мои ответы в кашу.
Причем я с тобой согласен что ужал он сильно и, прямо даже скажем — ловко.
Но аргумент у тебя щас прям убойный — «пробрасывал бы сделать сам, делал бы сам — не говорил бы так.» Но извиняете — мне говорят что это очевидно? кому это очевидно то? Двум человекам в этом топике которые, вот совпадение, занимались компрессией видео на спектруме.
Это не значит что это очевидно всем и вся без калькулятора.
Давайте тогда будем разделять — из очевидного я вижу только мутное чанковское видео, которое мы уже много раз видели.
Детально я его рассмотрю в отдельном ответе ниже — у меня масса вопросов, так сказать конструктивная дискуссия. Но сам видишь, его именно надо рассматривать, с калькулятором, а говорить о какой то очевидности и несомненности в его прогрессе никак нельзя.
Тебе показывают несколько минут незацикленного видео с диска 800кб. Частоту кадров в общем видно. Чтобы прикинуть общее число кадров нужно владеть умножением. Если бы ты хоть немного пробовал сделать сам — ты бы не говорил вещи типа «кому это может быть очевидно по визуальному восприятию мне непонятно».
Nuts_, сжатие квадратиками придумал не psndcj. У него свой оригинальный алгоритм, у алгоритма — другой.
Ты смешал всё в кучу и у нас получился разговор ни о чём. Анимация в Weed — не просто лучше соблюдённый баланс, а специально подготовленный под кодек видеоряд. Т.е. ты опять смешал в кучу — оригинальность алгоритмов, коэффициент сжатия, содержимое видеоряда. Ты пытаешься выстроить некую временную шкалу — кто у кого что заимствует, но складываешь на эту шкалу вещи, которые часто никак вообще не связаны друг с другом.
По-моему нет смысла об этом спорить, просто если ты всерьёз заинтересовался анимацией на спектруме — изучи вопрос более серьёзно.
более того. Изначально вопрос степени сжатия вообще не обсуждался. Я начал обсуждать вопрос с визуальной точки зрения — там видео в чанках, причем, ты сам признал, довольно мутное. Новизна только в степени сжатия. Кому это может быть очевидно по визуальному восприятию мне непонятно. ну разве что по степени унылости этого видео, так оно извине — целых 800 кб якобы а не 100 байт на кадр.
А я шото говрю? оценили прогресс (за эти 10 лет) численно, все очень наглядно-очевидно теперь.
Тут уже выходит что _все_ _по видеоряду_ уже оценили эту степень сжатия, один я вот такой тупой не вижу степени сжатия на глаз.
На мой взгляд в WEED соблюден баланс между сжатием и качеством картинки, плюс она подобрана так что эти дефекты сжатия не режут глаз а вроде стиль такой. Bad Apple 64 использует графику которую лучше каким-нибуть вектором выводить, задумка оригинала визуально искажена.
Про железо надеюсь возражений нет?
Nuts_, извини, но ты снова тупишь. При всём моём уважении к psndcj, 400 байт на экран и 70 байт на экран — несопоставимы. Разница в сжатии в 6 раз. Это просто даже не смешно уже.
можно еще по железу сравнить, и про поток с диска в хваленой Амиге процессор в 2 раза выше по частоте, да еще не знаю сколько там по тактам производительность. Памяти поболее. Но главное там есть DMA и навороченный дисковый контроллер который «сам все делает» — аппаратно с диска прямо в память. И звук — аппаратно из памяти на ЦАП. Грузи себе в фоне что захочешь, выводи что захочешь, процессор занимается распаковкой.
В то время как в Refresh более слабый проц самостоятельно получает по шине данные и сам толкает их в память и еще успевает че то на AY выдать (тогда вроде еще не додумались поток АУ данных без трекерного формата использовать?)
Неочевидно! Тут по прикидкам на калькуляторе ужали до 100 байтов на кадр, и не понятно сколько при таком качестве весит исходный кадр — там таки пикселезация большая. Более конструктивная дискуссия пойдет когда автор изложит что он проделал.
Пока есть информация о его предыдущих работах.
Например у него есть работа пр перегонке BadApple на С64. Там он описал — используется tiles, несжатый экран занимает 240 байт, в результате после всех оптимизаций и сжатии выходит чтото 80 (120) байт на экран (как считать).
К сравнению в анимациях по типу WEED (почитал Advanturer #15 ) — 400 байт на экран, но с атрибутами. Так же набор tiles, оптитмизация и посткомпрессия.
И. Этот алгоритм сжатия был опубликован в 2004 году.алгоритм сжатия bad apple — в 2014. Вот тут уже не нужен калькулятор ;)
Нет, я не главный. Правда. Совсем.
Остальные как-то так:
Да, я что-то знаю. Тайно. От всех. Но не скажу.
Да, организаторы Дихалта знают, что делать, правда.
У нас есть разрешение.
Костры разводить нельзя.
Вашу демку обязательно примут.
Мы не гарантируем безопасность.
ZORBA вне закона )
Но фишка то то в том сколько занимает кадр «оригинального» видео, он тут применяет tiles наверное 8на8 с палитрой может 16 цветов на tile, в каком еще видео режиме. Вот давайте оценим такой кадр визуально, сколько он занимает? Все в размытых квадратиках в очень ограниченной цветовой палитре. Как оценить сжатия визуально?
Далее — откуда крик про незацикленное потоковое видео с диска? в рассматриваемом веде там повторение на повторении одинаковых кусков идет. в 28кbps оно не зацикленное, но там идет узкая полоска и без спецэфектов. Не забываем что в амиге дофига оперативы чтоб в ней держать полдиска 880к
Но даже если с диска грузить — я повторюсь там DMA и на звук и на FDD — в чем тут новизна и очевидный прогресс?..
Человеку который разбирается в истории демосцены. unbeliever же сказал что тут вообще чанков нету и я не вижу новизны.
diver4d еще довольно в тему приплел вопрос про демотулзы, после чего ты приплепил тему про коэффициент сжатия и что в нем вся новизна.
После чего я отвечал вам каждому по отдельности про свое, проявлял между прочим ширину взгляда на вещи, а ты, успешно компилировал мои ответы в кашу.
Причем я с тобой согласен что ужал он сильно и, прямо даже скажем — ловко.
Но аргумент у тебя щас прям убойный — «пробрасывал бы сделать сам, делал бы сам — не говорил бы так.» Но извиняете — мне говорят что это очевидно? кому это очевидно то? Двум человекам в этом топике которые, вот совпадение, занимались компрессией видео на спектруме.
Это не значит что это очевидно всем и вся без калькулятора.
Давайте тогда будем разделять — из очевидного я вижу только мутное чанковское видео, которое мы уже много раз видели.
Детально я его рассмотрю в отдельном ответе ниже — у меня масса вопросов, так сказать конструктивная дискуссия. Но сам видишь, его именно надо рассматривать, с калькулятором, а говорить о какой то очевидности и несомненности в его прогрессе никак нельзя.
RIP Wlodek. Виделись на цц, встречал на вокзале, затем ездили вместе к Веге.
Ты смешал всё в кучу и у нас получился разговор ни о чём. Анимация в Weed — не просто лучше соблюдённый баланс, а специально подготовленный под кодек видеоряд. Т.е. ты опять смешал в кучу — оригинальность алгоритмов, коэффициент сжатия, содержимое видеоряда. Ты пытаешься выстроить некую временную шкалу — кто у кого что заимствует, но складываешь на эту шкалу вещи, которые часто никак вообще не связаны друг с другом.
По-моему нет смысла об этом спорить, просто если ты всерьёз заинтересовался анимацией на спектруме — изучи вопрос более серьёзно.
Тут уже выходит что _все_ _по видеоряду_ уже оценили эту степень сжатия, один я вот такой тупой не вижу степени сжатия на глаз.
На мой взгляд в WEED соблюден баланс между сжатием и качеством картинки, плюс она подобрана так что эти дефекты сжатия не режут глаз а вроде стиль такой. Bad Apple 64 использует графику которую лучше каким-нибуть вектором выводить, задумка оригинала визуально искажена.
Про железо надеюсь возражений нет?
В то время как в Refresh более слабый проц самостоятельно получает по шине данные и сам толкает их в память и еще успевает че то на AY выдать (тогда вроде еще не додумались поток АУ данных без трекерного формата использовать?)
Пока есть информация о его предыдущих работах.
Например у него есть работа пр перегонке BadApple на С64. Там он описал — используется tiles, несжатый экран занимает 240 байт, в результате после всех оптимизаций и сжатии выходит чтото 80 (120) байт на экран (как считать).
К сравнению в анимациях по типу WEED (почитал Advanturer #15 ) — 400 байт на экран, но с атрибутами. Так же набор tiles, оптитмизация и посткомпрессия.
И. Этот алгоритм сжатия был опубликован в 2004 году.алгоритм сжатия bad apple — в 2014. Вот тут уже не нужен калькулятор ;)