Потому что за 1 int (1/50sec, 50fps) не успевает.
Т.е. он где то бэкбуферит чтобы потом за два инта проскочить и вылезти как по его документации писано «за два инта на 25 фпс»?
Вопрос до конца не понятен. Почему за 2int'а? Потому что за 1 int (1/50sec, 50fps) не успевает. Не хватает производительности CPU. Если на реальном «железном» спектруме включить 7Mhz «turbo» Zynaps начинает стабильно работать в 50fps, причем графика не сечется, спрайты монстриков не исчезают.
по геймплею чётко видно, что нижние и верхние препятствия на скроллящейся части экрана никогда не пересекаются лишь приближаясь ровно к центру
Есть фоновая графика уровня в Zynaps и по центру, это не на первом уровне.
Относительно «демо-анимы» можно поговорить отдельно, хотя не знаю интересна ли тебе эта тема. Я лично считаю аниму просто один из приёмов в репертуаре, не главным, но безусловно полезным. Я делал демо чисто на аниме, я делал демо с элементами анимации; я не знаю всё, что закодил ты, но я смотрел Iris и я могу себе представить, что для тебя как для олдскул кодера у меня анимы очень много. Поэтому скажу так. Не всё что я делаю в своих демо основано на быстро распаковываемых данных. Но я безусловно держу эту опцию в уме и при необходимости/возможности — применяю.
Я не считаю что всё нужно паковать одним компрессором. Есть компрессоры которые жмут хуже, но намного быстрее распаковывают; они полезны в своей нише. Есть компрессоры, которые прекрасно жмут, но распаковывают часами (см. Shrinkler на диаграмме в комментарии чуть выше).
Короче, есть некая условная грань оптимальности Парето. Как бы если ты готов затратить некое конечное кол-во вычислительных ресурсов, ты не сможешь получить сжатие выше, чем позволяет эта грань. Грань на данным момент показана на диаграмме в комментарии выше по треду. Глядя на эту грань, я выбираю себе лучший компрессор для текущей задачи. Например, для универсального сжатия в ядре демо я сейчас использую MegaLZ; LZSA2 для меня в этой роли сейчас на втором месте, из-за слегка худшего сжатия графики. Но если в демо что-то не будет успевать на стыках, я поставлю LZSA2 и решу эту проблему. В то же самое время, один из эффектов у меня сейчас в демо требует покадровой распаковки атрибутов (пикселы сделаны эффектом, а вот раскраска — анимацией). В этом случае скорость абсолютно важна, поэтому в эффекте задействован LZSA1.
Некоторые успехи товарищей на других платформах ты можешь увидеть на моей диаграмме. Если очень коротко, я протестировал дохренища всего, не думаю что много упущено. Всегда есть потенциал что-то упустить из вида; но фундаментально, на Z80, с моей точки зрения все ведущие игроки сейчас обозначены.
И, да, запаковка на Z80 представляется мне абсолютно архаичной. С моей точки зрения в ней тупо нет смысла.
Напомни, что именно является «святым граалем» твоих поисков оптимального компрессора.
Могу ошибаться, но с моей точки зрения, это поиск наиболее сильного сжатия (требование №1 к любому компрессору) в то же время при самой высокой скорости _распаковки_ на z80.
При этом запаковка на z80, как таковая, абсолютно не принимается в расчет.
Видимо, всё это для целей демо-«анимы», т.е. основанных на быстро распаковываемых данных. Подтверди, так это или не так.
Изучал ли ты успехи товарищей на других 8-битных платформах? Каковы они?
На этом графике показаны результаты 3х распаковщиков MegaLZ — самый медленный это старый («DEC40.asm», 110 байт), совпадающий по скорости с Hrum — это новый оптимизированный по размеру (92 байта) и тот, который чуть быстрее 3*LDIR — новый оптимизированный по скорости (234 байта).
Учти что график генерируется на основе старого корпуса (того же, что в 2017 году), а табличка выше — на основе нового. Я буду переходить на новый корпус из-за того, что в старом было маловато графики (где-то 20% данных) и великовата средняя длина файла, что слегка искажает результаты тестов (скажем, на старом корпусе LZSA2 слегка обходит MegaLZ по сжатию, т.к. имеет намного большее окно, а отставание на графике не так заметно из-за небольшого кол-ва графики в корпусе). С поправкой на эти моменты, вот где я сейчас:
программисту на опкоды тоже начхать обычно, важен только полный (со всеми дополнительными данными) размер команд, если он у всех одинаков (как в исходном арме) или можно подобрать аналоги нужного размера — тогда это еще можно с толком использовать, если нет — ну не похрен ли, сколько там опкод занимает
Мои статьи можно размещать где угодно и кому угодно, в принципе и авторство указывать не обязательно, мне это совсем не критично. Я не отношусь к тому, что пишу, как к чему-то действительно серьезному или глубоко проработанному, любое распространение приветствуется.
Отличная статья, очень интересно. Сам недавно увлёкся шмапами, даже замутили своё радио на эту тему (shmupradio.com), кому близки и интересны скролл-шутеры — присоединяйтесь, помимо музыки мы переводим старые интервью с разработчиками и композиторами — vk.com/shootemupradio
Вопрос именно в том как получается всё плавно но за 2 инта и без разрывов.
Т.е. он где то бэкбуферит чтобы потом за два инта проскочить и вылезти как по его документации писано «за два инта на 25 фпс»?
Вопрос до конца не понятен. Почему за 2int'а? Потому что за 1 int (1/50sec, 50fps) не успевает. Не хватает производительности CPU. Если на реальном «железном» спектруме включить 7Mhz «turbo» Zynaps начинает стабильно работать в 50fps, причем графика не сечется, спрайты монстриков не исчезают.
Есть фоновая графика уровня в Zynaps и по центру, это не на первом уровне.
Короче, есть некая условная грань оптимальности Парето. Как бы если ты готов затратить некое конечное кол-во вычислительных ресурсов, ты не сможешь получить сжатие выше, чем позволяет эта грань. Грань на данным момент показана на диаграмме в комментарии выше по треду. Глядя на эту грань, я выбираю себе лучший компрессор для текущей задачи. Например, для универсального сжатия в ядре демо я сейчас использую MegaLZ; LZSA2 для меня в этой роли сейчас на втором месте, из-за слегка худшего сжатия графики. Но если в демо что-то не будет успевать на стыках, я поставлю LZSA2 и решу эту проблему. В то же самое время, один из эффектов у меня сейчас в демо требует покадровой распаковки атрибутов (пикселы сделаны эффектом, а вот раскраска — анимацией). В этом случае скорость абсолютно важна, поэтому в эффекте задействован LZSA1.
Некоторые успехи товарищей на других платформах ты можешь увидеть на моей диаграмме. Если очень коротко, я протестировал дохренища всего, не думаю что много упущено. Всегда есть потенциал что-то упустить из вида; но фундаментально, на Z80, с моей точки зрения все ведущие игроки сейчас обозначены.
И, да, запаковка на Z80 представляется мне абсолютно архаичной. С моей точки зрения в ней тупо нет смысла.
Могу ошибаться, но с моей точки зрения, это поиск наиболее сильного сжатия (требование №1 к любому компрессору) в то же время при самой высокой скорости _распаковки_ на z80.
При этом запаковка на z80, как таковая, абсолютно не принимается в расчет.
Видимо, всё это для целей демо-«анимы», т.е. основанных на быстро распаковываемых данных. Подтверди, так это или не так.
Изучал ли ты успехи товарищей на других 8-битных платформах? Каковы они?