А вот может не надо ко мне приписывать не мои подвиги? мой самый первый вопрос здесь был посвящен кто у кого содрал идею.
Человеку который разбирается в истории демосцены. 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. Вот тут уже не нужен калькулятор ;)
Разверну: Роб рассказывал, что масон позволял ему очень гибко манипулировать проигрыванием музыки, скажем проигрывать только один канал из трёх за вызов, чтобы было легче вплести плейер в мультиколорный и бордерный код. Постоянные такты, разумеется. Авто-эхо, т.е. там некая система, кот. означает, что масон может проигрывать 3х канальный трек на 6 каналах с чем-то типа ревера (если я всё правильно понял).
Человеку который разбирается в истории демосцены. 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. Вот тут уже не нужен калькулятор ;)
это должно быть на хайпе.
без этих писем от друзей я бы не писал так много в то время.
самый мой разгар был тогда :)