• avatar Shiru
  • 1
Ну смотри, у тебя только имхо. А я говорю исходя из практического опыта. Почему люди совершенно не хотят слушать тех, кто имеет непосредственный опыт, предпочитая абстрактное чтение док и своё мнение — для меня загадка. Но таково положение вещей, тот же многониковый товарищ постоянно расстраивался на эту тему.

Когда ты пишешь под SNES, ты не думаешь — а вот есть другой процессор, ах, сколько там РОН, какие там 32-битные операции и смещения. У тебя есть конкретный процессор, такой, какой он есть. Это данность. И ты пишешь для него код, как умеешь, настолько эффективно, как умеешь, чтобы решить конкретную задачу. Практика показывает: все задачи нормально решаются и там и там. Конечно, если у тебя опыт программирования на Z80 или M68K, ты будешь думать — как неэффективно писать на 6502/65816, там так мало регистров. Потому что у тебя нет понимания, что там принципиально другая парадигма, что там просто пишешь иначе, но в результате получаешь те же результаты. Когда ты уже знаешь и умеешь, ты не думаешь, как это сложно в сравнении, потому что тебе уже не сложно это делать.

Я много раз предлагал всем желающим поучаствовать в написании сравнительных тестов, Z80/6502, M68K/65816. Желающих за много лет почему-то не нашлось ни разу. И думаю, это не сработает, потому что знающий только одну архитектуру будет продолжать придерживаться своих взглядов на эффективность, т.к. по прежнему не понимает другую сторону ('ах, ты добился такого же результата, но мне не нравится твой непонятный код, я считаю его некрасивым'), а у знающего обе вопросов про сравнение уже не возникает.
  • avatar aa-dav
  • 2
P.P.S.
Посмотрел сейчас еще в тайлы угловых стен — да, они не перерисовываются динамически, а построены заранее.
Есть два одинаковых набора — в одном два разных цвета (внутренние стены), в другом один из цветов прозрачный (внешние стены). В каждом изображены линии под разными углами — судя по всему растиражированы почти все возможные углы от 0 до 45 градусов, а дальнейшее получается зеркалированием по горизонтали/вертикали. С другой стороны, если приглядываться к итоговой картинке, то нередко заметно, что линия не является идеальных Брезенхемом, нередко видны «шероховатости» видимо на стыках, то есть прямо все возможные пиксельные комбинации возможно даже не покрыты для краткости. Общий паттерн же таков, что берется пиксель вдоль одной стороны и из него проводится линия ко всем пикселям на противоположных сторонах. Есть еще подозрение, что с помощью палитр еще сокращается число нужных комбинаций. Но так да — с ходу трудно придумать как этим теперь рисовать, такую задачу мне тоже еще не доводилось решать.
  • avatar aa-dav
  • 0
«На практике и там и там одинаково сложно сделать игру типа GH»

Имхо, напротив, ожидаю увидеть на SNES всякие трюки с переходом к 8.8 как в статье и всякие таблицы с xor-ами для выдавливания соков из-за дурацких раскладок против абсолютно прямолинейного ремесленного кода на SMD в 16 РОН и адресацией любого куска памяти через base+size*offset. То что внешне можно добиться схожей картинки как раз не показатель. Но тут смысла нет препираться особо пока не будет реальных сравнительных опенсорцных тестов это всё «личные мнения».
  • avatar Shiru
  • 1
Это всё теория. На практике и там и там одинаково сложно сделать игру типа GH, и, повторяюсь, одинаково и там и там проблема не в коде, не в операциях, и не в системе команд. В GH нет совершенно ничего необычного в плане кода, просто аккуратно спланированные растровые эффекты, грамотное использование двух слоёв фона. На SNES есть те же самые два слоя фона, и можно сделать те же самые эффекты. Причём делаются они чуть проще, т.к. есть HDMA.

Самая главная проблема на SNES — откровенно неудачная система спрайтов. Если не сделать менеджер списка спрайтов грамотно, будут тормоза, наблюдаемые во многих играх. У большинства программистов тех лет просто не было опыта и времени разбираться, как решать эту проблему (но некоторые решали). Не выглядящие крутыми демки также показывают, что проблема решаема, а блог описывает, как именно. Я также пришёл к подобному решению, увидел изыскания этого товарища уже после этого.
  • avatar aa-dav
  • 0
Ну эти демки особо крутыми не выглядят — много спрайтов в какой то момент и только.
Имхо всё же Маегава если и преувеличивал, то не сильно. Плоский прямолинейный проц с 32-битными операциями (пусть даже под капотом выполняющимися как 16-битные, но в системе команд команда одна и как бы 32-битная) и простые раскладки видеопамяти, включая таблицы спрайтов, очевидно должны сделать программирование сложных сцен и трюков на SMD проще. И даже если на SNES можно добиться таких же показателей — то это уже демосцена с выдавливанием соков, а не SMD — нет, просто сел и запрограммировал. Другое дело, что в SNES было еще много аппаратных интересностей просто отсутствующих в SMD.
  • avatar Shiru
  • 2
К вопросу об упомянутом товарище. Вспомнил некоторые его ники: psychopaticteen, Aaendi, dragonboyб Andy Koenigs. Обнаружилась пара блогов, о которых я и не знал: aaendi.blogspot.com/ и andykoenigs.blogspot.com/2017/, а также древний канал на Youtube с демкой игры, которую я не видел: www.youtube.com/channel/UCQJYrDl_f6nKUfQcgjTuvlg

Демка явно предшественница двух последующих, которые я не могу найти. В одной была графика прямо из GH, в другой очень стрёмная оригинальная графика с какой-то девочкой-роботом. В целом, можно видеть, что ещё 8 лет назад у него без проблем получалось сделать огромную кучу объектов и составные анимации без замедлений.
  • avatar frog
  • 0
Вот интересно — каждый раз когда смотрю на игры с Sega, SNES, Amiga то, по сравнению с Atari XE/XL и C64, бросается в глаза, что спрайты субъективно выглядят очень отдельными от фона и, как правило, для анимации прорисовано очень мало кадров. Соответственно, возникает устойчивое впечатление, что делали на скорую руку.
  • avatar aa-dav
  • 2
P.S.
И судя по всему кусок стены над дверью еще накрыт спрайтами, а не фонами. Три больших таких спрайта прямо над ней. В общем не без заморочек.
  • avatar aa-dav
  • 2
P.S.
Что-то сюда картинка как то косячно загрузилась. Вот она же на фастпике: i91.fastpic.ru/big/2018/0925/be/6ce8e44d70e132d8ab446c2e3df679be.gif
  • avatar aa-dav
  • 2
Провёл небольшое исследование в том же эмуляторе Exodus.
А прикольно у них там.

На слое А рисуется потолок и «внешние углы». Они реально перерисовываются при движении под нужный угол.
На слое Б рисуется пол и «внутренние углы». Даже если там статичные тайлы они значит рассчитаны под любой ракурс который может дать игра. Возможно их истинное число просто невелико, учитывая что есть флаги отражения тайлов по осям.
Так или иначе углы действительно создаются на лету тайлами или их содержимым и разбиты разумно на оба фона как «внутренние» и «внешние».
  • avatar Shiru
  • 2
Вот indoor-эффект я до сих пор не смог раскусить до конца (аналогично ещё в Toy Story, но попроще). Т.е. я знаю, как это делается в общем случае, не на SMD, но если большинство эффектов из игр на SMD/SNES я повторить на них же готов и точно знаю, как это сделать, то этот — нет. Я бы стал делать честный рендер углов стен с подгрузкой графики в видеопамять, но они обходятся (довольно большим) набором статичных тайлов.
  • avatar aa-dav
  • 2
Не факт что и откуда первое пришло. Например выше тут упоминается команда Zyrinx — они пришли из демосцены и сделали игру Red Zone для Sega Mega Drive и настолько гордились тем что сделали, что прямо в титульных экранах игры вставили вот такую заметку:



Стоит сперва начало посмотреть до первых геймплейных моментов (не пропуская заставки), а потом перемотать на 7:40 и позырить на indoor-геймплей.
  • avatar diver4d
  • 2
Это очень круто.
  • avatar diver4d
  • 1
Практически «прикладное демостроение». С той лишь разницей, что сперва эти эффекты появились в играх и только потом перекочевали в демосцену. Независимый скролл каждого сканлайна на олдскул платформе был реализован в Coma Light 13, например, в 2012 году :).
  • avatar tsl
  • 0
Да, я кстати тоже подумал, что они поэкономили на памяти. Видимо муксы+реги занимают меньше места.
  • avatar Shiru
  • 2
Вероятно память буфера строки стоила бы слишком дорого в плане места на кристалле. В NES динамическая память OAM (описание спрайтов, X/Y/тайл/палитра) размером 2x256 байт занимает аж четверть кристалла PPU. Для варианта с буфером строки понадобилось бы ещё 2x256 байт, плюс возможно логика заняла бы сравнимо или больше, чем логика со сдвиговыми регистрами.

Пиксельный буфер в импортных приставках мне не припоминается нигде. Впервые я увидел эту идею в V2Z80 (который задолго до V6Z80P), который из ранних 2000-х, и она показалась мне очевидной и логичной. Чуть позже узнал, что и в советском игровом автомате ТИА-МЦ-1 ~1988 года спрайты тоже сделаны с буфером строки, там даже три буфера 256x4 (16-цветные спрайты). А потом уже стал вникать в эти детали по популярным приставкам, и удивился, что там сделано совершенно иначе.
  • avatar aa-dav
  • 2
«снимает ограничение на одновременное кол-во спрайтов в строке»

Ну не снимает, а скорее как то меняет — и еще надо смотреть как. Технически всё-равно надо успеть сформировать строку.
У спец-регистров в принципе bandwidth может как бы и не быть, то есть загрузив их в начале строки можно как бы «бесплатно» не пересекаясь в них лазить хоть каждый пиксель — на то они и регистры.
Но в любом случае победил в высокопроизводительных игровых системах окончательно блиттинг, причём в весь сюрфейс сразу и во много потоков, а роль видеоадаптера свелась к неспешному скармливанию в видеопорт уже готовых полностью пикселей.
После таких статей о приставках совсем иначе смотришь на эти игры.
  • avatar tsl
  • 3
Вот что мне неочевидно во многих приставках (и СМД в частности) — это отображение спрайтов из специальных регистров вместо того, чтоб рендерить все в пиксельный буфер. Я может уже надоел тут всем со своим буфером :), но когда я делал спрайтовый процессор, я понял, что лучше соорудить FSM, которая пройдется по объектам (спрайтам/тайлам), вычитает из памяти их графику и нарендерит ее в тру-колорный пиксельный массив сканлайна. Плюсы: снимает ограничение на одновременное кол-во спрайтов в строке, балансирует нагрузку на доступ в ОЗУ. У меня при том еще и ОЗУ 1-портовое и общее с другими подсистемами. У СМД ОЗУ 2-портовое, статический порт используется исключительно видеопроцессором. Зачем при этом мутить кашу из мультиплексиров спрайтовых регов, непонятно.
  • avatar aa-dav
  • 1
Не не, эффект я понял сразу же. Я почему то забуксовал с наложением его на картину видеопамяти из эмулятора — смутно брезжило, что линии перескакивают и по вертикали, но уверенности не было. Теперь немного исправил пост, чтобы читателям тоже было понятнее.