На этом графике показаны результаты 3х распаковщиков MegaLZ — самый медленный это старый («DEC40.asm», 110 байт), совпадающий по скорости с Hrum — это новый оптимизированный по размеру (92 байта) и тот, который чуть быстрее 3*LDIR — новый оптимизированный по скорости (234 байта).
Учти что график генерируется на основе старого корпуса (того же, что в 2017 году), а табличка выше — на основе нового. Я буду переходить на новый корпус из-за того, что в старом было маловато графики (где-то 20% данных) и великовата средняя длина файла, что слегка искажает результаты тестов (скажем, на старом корпусе LZSA2 слегка обходит MegaLZ по сжатию, т.к. имеет намного большее окно, а отставание на графике не так заметно из-за небольшого кол-ва графики в корпусе). С поправкой на эти моменты, вот где я сейчас:
программисту на опкоды тоже начхать обычно, важен только полный (со всеми дополнительными данными) размер команд, если он у всех одинаков (как в исходном арме) или можно подобрать аналоги нужного размера — тогда это еще можно с толком использовать, если нет — ну не похрен ли, сколько там опкод занимает
Мои статьи можно размещать где угодно и кому угодно, в принципе и авторство указывать не обязательно, мне это совсем не критично. Я не отношусь к тому, что пишу, как к чему-то действительно серьезному или глубоко проработанному, любое распространение приветствуется.
Отличная статья, очень интересно. Сам недавно увлёкся шмапами, даже замутили своё радио на эту тему (shmupradio.com), кому близки и интересны скролл-шутеры — присоединяйтесь, помимо музыки мы переводим старые интервью с разработчиками и композиторами — vk.com/shootemupradio
Ну просто представь что ты что-то такое сделал. Тогда у тебя на экране будет линия, которую нельзя будет пересекать графике фона (чтобы изображение не разрезалось). В нормальном скроллере будут препятствия заставляющие тебя смещаться вверх или вниз, что означает, что либо тебе придётся как-то думать как сдвигать эту линию разреза в зависимости от происходящего на экране, либо просто запретить графике пересекать её, что сильно ограничит какие препятствия могут быть возможны. Короче, я думаю что твоя идея имеет смысл, но наверное не в контексте шмапа, а, допустим, в чём-то типа многослойного параллаксного скроллера.
Ну и относительно приема — если скроллить половину экрана в одном кадре, а ещё половину в другом — у нас получится сечение луча — стык между экранами будет хорошо виден.
Из-за чего у меня возник вопрос — в readme.txt Зинапса прямо написано что у него фпс в 25 кадров. Т.е. у него каким то образом кадр строится за 2 хода луча. Поэтому вопрос — как и зачем. Т.к. по геймплею чётко видно, что нижние и верхние препятствия на скроллящейся части экрана никогда не пересекаются лишь приближаясь ровно к центру, то и никакой стык между экранами такому подходу не страшен — в этом месте просто нет заднего фона.
Поэтому у меня и возник вопрос.
Ну и относительно приема — если скроллить половину экрана в одном кадре, а ещё половину в другом — у нас получится сечение луча — стык между экранами будет хорошо виден. Другое дело, что теоретически можно рисовать за лучом, и это используется в играх на спектруме. Но Zynaps не использует эту возможность.
Интересно, из любопытства запустил Zynaps и едйствительно поразился очень качественному, более чем на 2/3 экрана и при этом плавному скроллу. Пока разбирался с клавишами набрёл на оф. инструкцию и там увидел надпись 25fps. Интересно — сразу же прошила догадка, что на четных кадрах он скроллит верхнюю половину изображения, а на нечётных — нижнюю для гладкости. Наверняка тут кто-то знает — так ли оно и есть ли такой приём в принципе?
У меня есть краткий обзор на «ветку» процессоров Motorola/MOS. Мне, если честно, их архитектура аккумулятор-память в принципе не нравится. Это такое что-то из 50/60-х и вот не моё. От MOS 6502 вообще плакать хочется. 6809 несомненно намного круче и богаче на сложные адресации, откуда и опкоды уже двухбайтные начинают вылазить ну и простым не назовёшь. Но много лучше конечно 6502.
Поэтому у меня и возник вопрос.
но сравнительно с 6809 (а тем более 6309) уже не всё так однозначно