в данном случае я и не говорил про программиста.
программисту на опкоды тоже начхать обычно, важен только полный (со всеми дополнительными данными) размер команд, если он у всех одинаков (как в исходном арме) или можно подобрать аналоги нужного размера — тогда это еще можно с толком использовать, если нет — ну не похрен ли, сколько там опкод занимает
  • avatar Anadara
  • 1
Спасибо, как опубликуем, я скину ссылку сюда.
Мои статьи можно размещать где угодно и кому угодно, в принципе и авторство указывать не обязательно, мне это совсем не критично. Я не отношусь к тому, что пишу, как к чему-то действительно серьезному или глубоко проработанному, любое распространение приветствуется.
  • avatar Anadara
  • 1
Можно разместить твою статью о R-Type у нас на сайте, естественно с указанием твоего авторства и активной ссылкой на статью здесь?
Хорошее радио! На тему шмапов от меня будет еще одна статья любопытная, где-то в сентябре.
  • avatar Anadara
  • 1
Отличная статья, очень интересно. Сам недавно увлёкся шмапами, даже замутили своё радио на эту тему (shmupradio.com), кому близки и интересны скролл-шутеры — присоединяйтесь, помимо музыки мы переводим старые интервью с разработчиками и композиторами — vk.com/shootemupradio
Ну просто представь что ты что-то такое сделал. Тогда у тебя на экране будет линия, которую нельзя будет пересекать графике фона (чтобы изображение не разрезалось). В нормальном скроллере будут препятствия заставляющие тебя смещаться вверх или вниз, что означает, что либо тебе придётся как-то думать как сдвигать эту линию разреза в зависимости от происходящего на экране, либо просто запретить графике пересекать её, что сильно ограничит какие препятствия могут быть возможны. Короче, я думаю что твоя идея имеет смысл, но наверное не в контексте шмапа, а, допустим, в чём-то типа многослойного параллаксного скроллера.
  • avatar aa-dav
  • 0
Ну и относительно приема — если скроллить половину экрана в одном кадре, а ещё половину в другом — у нас получится сечение луча — стык между экранами будет хорошо виден.
Из-за чего у меня возник вопрос — в readme.txt Зинапса прямо написано что у него фпс в 25 кадров. Т.е. у него каким то образом кадр строится за 2 хода луча. Поэтому вопрос — как и зачем. Т.к. по геймплею чётко видно, что нижние и верхние препятствия на скроллящейся части экрана никогда не пересекаются лишь приближаясь ровно к центру, то и никакой стык между экранами такому подходу не страшен — в этом месте просто нет заднего фона.
Поэтому у меня и возник вопрос.
Ну и относительно приема — если скроллить половину экрана в одном кадре, а ещё половину в другом — у нас получится сечение луча — стык между экранами будет хорошо виден. Другое дело, что теоретически можно рисовать за лучом, и это используется в играх на спектруме. Но Zynaps не использует эту возможность.
Нет, не так — рендер в Zynaps оперирует строками знакомест, перерисовывая их целиком — фон, спрайты, и т.д.
  • avatar aa-dav
  • 1
Интересно, из любопытства запустил Zynaps и едйствительно поразился очень качественному, более чем на 2/3 экрана и при этом плавному скроллу. Пока разбирался с клавишами набрёл на оф. инструкцию и там увидел надпись 25fps. Интересно — сразу же прошила догадка, что на четных кадрах он скроллит верхнюю половину изображения, а на нечётных — нижнюю для гладкости. Наверняка тут кто-то знает — так ли оно и есть ли такой приём в принципе?
  • avatar aa-dav
  • 0
У меня есть краткий обзор на «ветку» процессоров Motorola/MOS. Мне, если честно, их архитектура аккумулятор-память в принципе не нравится. Это такое что-то из 50/60-х и вот не моё. От MOS 6502 вообще плакать хочется. 6809 несомненно намного круче и богаче на сложные адресации, откуда и опкоды уже двухбайтные начинают вылазить ну и простым не назовёшь. Но много лучше конечно 6502.
не такое уж большое достижение, намечтать «удобней z80»
но сравнительно с 6809 (а тем более 6309) уже не всё так однозначно
  • avatar aa-dav
  • 0
Имхо такой проц гораздо удобнее и прямолинейнее в программировании чем тот же Z80 при том оставаясь всё-таки на уровне 8-биток своей скупостью команд и отсутствием сложных адресаций. Не забываем как звучит заголовок поста — это не попытка создать идеальный процессор вообще, но именно 8-битный по своим суммарным характеристикам и ощущениям. Взять 16-битный i8086 — это уже совсем другой зверь с огромным количеством удобных для ЯВУ адресаций и схем. Вот для меня это уже не то.
Да что-то не выходит пока для всех, а для железячника в основном. Программисту наплевать на «одну команду в глобальном смысле» и «не загрязняя регистры», ему важно, чтоб команды были быстрыми и удобными, и свободных регистров (или быстрой памяти) побольше (и насрать, сколько несвободных «грязных» при этом будет), и чтоб специализированных поменьше. Например, быстрая команда R=R+n с кодировкой n=1..16 в опкоде полезнее жалкой пары инкрементов, но в предложенную схему не вписывается (не в одностадийное декодирование, во всяком случае). Например, программисту были бы удобны два и более указателя стека, как в 6809, или хотя бы быстрое переключение между ними, а еще лучше автоинкремент любого адресующего регистра, что решается добавкой операций чтения/записи, но ты ради упрощения декодера сокращаешь количество возможных разных команд или ограничиваешь их тип.
  • avatar aa-dav
  • 0
«Так вот я и спрашиваю поэтому — «комп мечты» КОГО ты хочешь изобрести?»

Всё это было написано — для всех и всях. Для программиста этот проц удобен тем что в нём довольно широкие команды, не надо ворочаться с аккумулятором, можно напрямую работать с ячейками памяти не загрязняя регистры, команды сразу совмещают и вычисление в АЛУ и пересылку данных откуда и куда угодно. Для аппаратчика — простая система команд когда есть одна команда в глобальном смысле — пересылка данных через АЛУ с лёгкими вариациями не влияющими на общую схему работы.
куча разного оружия, которое действительно разное (не считая даже возможности отпускать и прицеплять помощника с другой стороны) — а не одни унылые вариации тех же пулек; тьма неплохо анимированных врагов разного размера, которые по-разному движутся, налетают с разных сторон, разгуливают по земле, пускают разные снаряды с разной механикой — а не унылые паровозики одинаковых изредка постреливающих мелких спрайтиков; насчёт боссов нечего и говорить, всё понятно

поржал с «с лучшей, не такой монохромной графики» в зинапсе с его монохромными спрайтами и двумя-тремя цветами на фон почти всех уровней (см. карту))) фон в эртайпе уж ничуть не хуже раскрашен, но плюс к тому разноцветные враги (и даже разноцветные взрывы с выстрелами)

так-то как для спека зинапс неплох, но это совершенно другая лига
У R-Type:
Летающие гусеницы (как босс, так и отдельно)
Ходячие ракетометы
Босс на весь уровень.
Уровень с жуками, сорящими блоками.
Потоки монстров.
Есть даже полубоссы.
Огромное визуальное разнообразие уровней. Разрушенный город с мусоркой в конце, биоуровень со стенками из монстров, логистический склад.
Босс-звезда, закрытый блоками.
Кольцо туррелей.
Перечислять можно долго.
maps.speccy.cz/map.php?id=R-Type&sort=4&part=18&ath=

У Zynaps:
Отличный первый уровень.
Слабые по атмосфере уровни с пузырями.
Мелкие боссы.
Намного более куцая и примитивная система апгрейдов. Нет отцепляемых щитов, есть только стандартная пукалка и бомбометание.
maps.speccy.cz/map.php?id=Zynaps&sort=4&part=26&ath=

Я бы сказал так, что Zynaps — классический ZX шутер без больших художественных амбиций. Враги мелкие, боссы тоже, уровни по графике плоские и без большого полета фантазии. R-Type чисто визуально делал то, что на ZX было нетипично: лютое разнообразие врагов и механик, всех калибров и размеров, причем некоторые из них встречаются вообще единожды за всю игру, что было немыслимой расточительностью на 8бит. В Zynaps даже боссы повторяются, о каком разнообразии тут можно говорить? :)