6502 намного ближе к «бессистемному» программированию 60-х, когда всякие абстракции типа структурного программирования только формировались и завоёвывали. стек крохотен и рудиментарен. второй аргумент операции почти всегда берется из памяти и там нельзя боятся лазить в память и сохранять в неё промежуточные результаты, экономя на перекладывании в регистры (их там почти нет просто) — напротив хранить всё в памяти и сохранять сразу после выполнения операции — норма жизни. 256 байт нулевой страницы это эдакая область глобальных переменных быстрого доступа — так как почти все регистры 8-битные, то даже косвенная адресация любого байта в памяти делается через слово лежащее в нулевой странице. к нулевой странице поэтому особое отношение.
Ширу, мне было бы интересно подумать над z80/6502, в первую очередь чтобы врубиться в мышление 6502. Ты продумывал какие-то типовые задачи, которые раскрыли бы как первую, так и вторую платформу?
Ну во первых я далеко не только чтец, а во вторых разговор уже приобретает черты холивара и я не хочу в этом учавствовать. :)
Но не ради холивара, а ради прикосновения к красивому — в комментариях к этой же статье моей на другом ресурсе проскочила демка на SMD:
от прошлого года и в титрах авторы явно подзадоривают к «proper SNES competition» :)
там же привели и пару демок от SNES, но они страдали в сравнении как раз низкой цветностью слоёв с динамическим рендером — и я склонен считать что это из-за многократно уже оговоренных проблем с раскладками памяти и прочим.
Еще раз повторюсь — не холивара ради, но было бы интересно посмотреть бест оф зе бест.
Я предполагаю, что теоретически для фиксированной проекции каждой конкретной точке экрана должен однозначно соответствовать конкретный статичный вектор. Т.е. если мы смотрим на точки ближе к центру, там линия стены идёт под острым углом к зрителю, а у точек ближе к углам экрана линия идёт в направлении угла. Значит по экранным координатам угловой точки всех восьми вариантов углов стен нижнего слоя можно однозначно определить, какую линию надо нарисовать.
Можно заготовить карты тайлов с заранее нарисованными фиксированным набором графики всеми возможными углами, размером типа 4x4 тайла для четверти всех возможных случаев (т.к. три четверти экрана можно отзеркалить), и каждый кадр дорисовывать в карту тайлов каждый угол. Т.е. нужен массив размером в четверть экрана с индексами нужных тайлов (8 бит), это будет порядка 128*112=14 килобайт, плюс набор карт тайлов углов (256 карт 4x4 займёт 4К, 256 углов определённо должно хватить) — по меркам платформы это совсем немного для такого киллер-эффекта.
В общем, идеи есть, и наверное мой вариант сработает и будет достаточно быстрым, но я не уверен, что в Red Zone сделано именно так. Это такой эффект, где надо поэкспериментировать и предусмотреть много разных мелочей. Его реализация не читается однозначно по визуальному анализу, в отличие от большинства приставочных эффектов.
Ну смотри, у тебя только имхо. А я говорю исходя из практического опыта. Почему люди совершенно не хотят слушать тех, кто имеет непосредственный опыт, предпочитая абстрактное чтение док и своё мнение — для меня загадка. Но таково положение вещей, тот же многониковый товарищ постоянно расстраивался на эту тему.
Когда ты пишешь под SNES, ты не думаешь — а вот есть другой процессор, ах, сколько там РОН, какие там 32-битные операции и смещения. У тебя есть конкретный процессор, такой, какой он есть. Это данность. И ты пишешь для него код, как умеешь, настолько эффективно, как умеешь, чтобы решить конкретную задачу. Практика показывает: все задачи нормально решаются и там и там. Конечно, если у тебя опыт программирования на Z80 или M68K, ты будешь думать — как неэффективно писать на 6502/65816, там так мало регистров. Потому что у тебя нет понимания, что там принципиально другая парадигма, что там просто пишешь иначе, но в результате получаешь те же результаты. Когда ты уже знаешь и умеешь, ты не думаешь, как это сложно в сравнении, потому что тебе уже не сложно это делать.
Я много раз предлагал всем желающим поучаствовать в написании сравнительных тестов, Z80/6502, M68K/65816. Желающих за много лет почему-то не нашлось ни разу. И думаю, это не сработает, потому что знающий только одну архитектуру будет продолжать придерживаться своих взглядов на эффективность, т.к. по прежнему не понимает другую сторону ('ах, ты добился такого же результата, но мне не нравится твой непонятный код, я считаю его некрасивым'), а у знающего обе вопросов про сравнение уже не возникает.
P.P.S.
Посмотрел сейчас еще в тайлы угловых стен — да, они не перерисовываются динамически, а построены заранее.
Есть два одинаковых набора — в одном два разных цвета (внутренние стены), в другом один из цветов прозрачный (внешние стены). В каждом изображены линии под разными углами — судя по всему растиражированы почти все возможные углы от 0 до 45 градусов, а дальнейшее получается зеркалированием по горизонтали/вертикали. С другой стороны, если приглядываться к итоговой картинке, то нередко заметно, что линия не является идеальных Брезенхемом, нередко видны «шероховатости» видимо на стыках, то есть прямо все возможные пиксельные комбинации возможно даже не покрыты для краткости. Общий паттерн же таков, что берется пиксель вдоль одной стороны и из него проводится линия ко всем пикселям на противоположных сторонах. Есть еще подозрение, что с помощью палитр еще сокращается число нужных комбинаций. Но так да — с ходу трудно придумать как этим теперь рисовать, такую задачу мне тоже еще не доводилось решать.
«На практике и там и там одинаково сложно сделать игру типа GH»
Имхо, напротив, ожидаю увидеть на SNES всякие трюки с переходом к 8.8 как в статье и всякие таблицы с xor-ами для выдавливания соков из-за дурацких раскладок против абсолютно прямолинейного ремесленного кода на SMD в 16 РОН и адресацией любого куска памяти через base+size*offset. То что внешне можно добиться схожей картинки как раз не показатель. Но тут смысла нет препираться особо пока не будет реальных сравнительных опенсорцных тестов это всё «личные мнения».
Это всё теория. На практике и там и там одинаково сложно сделать игру типа GH, и, повторяюсь, одинаково и там и там проблема не в коде, не в операциях, и не в системе команд. В GH нет совершенно ничего необычного в плане кода, просто аккуратно спланированные растровые эффекты, грамотное использование двух слоёв фона. На SNES есть те же самые два слоя фона, и можно сделать те же самые эффекты. Причём делаются они чуть проще, т.к. есть HDMA.
Самая главная проблема на SNES — откровенно неудачная система спрайтов. Если не сделать менеджер списка спрайтов грамотно, будут тормоза, наблюдаемые во многих играх. У большинства программистов тех лет просто не было опыта и времени разбираться, как решать эту проблему (но некоторые решали). Не выглядящие крутыми демки также показывают, что проблема решаема, а блог описывает, как именно. Я также пришёл к подобному решению, увидел изыскания этого товарища уже после этого.
Ну эти демки особо крутыми не выглядят — много спрайтов в какой то момент и только.
Имхо всё же Маегава если и преувеличивал, то не сильно. Плоский прямолинейный проц с 32-битными операциями (пусть даже под капотом выполняющимися как 16-битные, но в системе команд команда одна и как бы 32-битная) и простые раскладки видеопамяти, включая таблицы спрайтов, очевидно должны сделать программирование сложных сцен и трюков на SMD проще. И даже если на SNES можно добиться таких же показателей — то это уже демосцена с выдавливанием соков, а не SMD — нет, просто сел и запрограммировал. Другое дело, что в SNES было еще много аппаратных интересностей просто отсутствующих в SMD.
Демка явно предшественница двух последующих, которые я не могу найти. В одной была графика прямо из GH, в другой очень стрёмная оригинальная графика с какой-то девочкой-роботом. В целом, можно видеть, что ещё 8 лет назад у него без проблем получалось сделать огромную кучу объектов и составные анимации без замедлений.
Вот интересно — каждый раз когда смотрю на игры с Sega, SNES, Amiga то, по сравнению с Atari XE/XL и C64, бросается в глаза, что спрайты субъективно выглядят очень отдельными от фона и, как правило, для анимации прорисовано очень мало кадров. Соответственно, возникает устойчивое впечатление, что делали на скорую руку.
Провёл небольшое исследование в том же эмуляторе Exodus.
А прикольно у них там.
На слое А рисуется потолок и «внешние углы». Они реально перерисовываются при движении под нужный угол.
На слое Б рисуется пол и «внутренние углы». Даже если там статичные тайлы они значит рассчитаны под любой ракурс который может дать игра. Возможно их истинное число просто невелико, учитывая что есть флаги отражения тайлов по осям.
Так или иначе углы действительно создаются на лету тайлами или их содержимым и разбиты разумно на оба фона как «внутренние» и «внешние».
Вот indoor-эффект я до сих пор не смог раскусить до конца (аналогично ещё в Toy Story, но попроще). Т.е. я знаю, как это делается в общем случае, не на SMD, но если большинство эффектов из игр на SMD/SNES я повторить на них же готов и точно знаю, как это сделать, то этот — нет. Я бы стал делать честный рендер углов стен с подгрузкой графики в видеопамять, но они обходятся (довольно большим) набором статичных тайлов.
Не факт что и откуда первое пришло. Например выше тут упоминается команда Zyrinx — они пришли из демосцены и сделали игру Red Zone для Sega Mega Drive и настолько гордились тем что сделали, что прямо в титульных экранах игры вставили вот такую заметку:
Стоит сперва начало посмотреть до первых геймплейных моментов (не пропуская заставки), а потом перемотать на 7:40 и позырить на indoor-геймплей.
Реги спрайтов: 4*32*20=2560 бит
Пикс. буфер: 9*320*2=5760 бит
Sergey, [26.09.18 10:40] А буфер строки можно на драме сделать
Помню, я смотрел видеощупом сигналы на видеопамяти (на обоих портах) и были они очень странные, логику я понять не смог.
Но не ради холивара, а ради прикосновения к красивому — в комментариях к этой же статье моей на другом ресурсе проскочила демка на SMD:
от прошлого года и в титрах авторы явно подзадоривают к «proper SNES competition» :)
там же привели и пару демок от SNES, но они страдали в сравнении как раз низкой цветностью слоёв с динамическим рендером — и я склонен считать что это из-за многократно уже оговоренных проблем с раскладками памяти и прочим.
Еще раз повторюсь — не холивара ради, но было бы интересно посмотреть бест оф зе бест.
Можно заготовить карты тайлов с заранее нарисованными фиксированным набором графики всеми возможными углами, размером типа 4x4 тайла для четверти всех возможных случаев (т.к. три четверти экрана можно отзеркалить), и каждый кадр дорисовывать в карту тайлов каждый угол. Т.е. нужен массив размером в четверть экрана с индексами нужных тайлов (8 бит), это будет порядка 128*112=14 килобайт, плюс набор карт тайлов углов (256 карт 4x4 займёт 4К, 256 углов определённо должно хватить) — по меркам платформы это совсем немного для такого киллер-эффекта.
В общем, идеи есть, и наверное мой вариант сработает и будет достаточно быстрым, но я не уверен, что в Red Zone сделано именно так. Это такой эффект, где надо поэкспериментировать и предусмотреть много разных мелочей. Его реализация не читается однозначно по визуальному анализу, в отличие от большинства приставочных эффектов.
Когда ты пишешь под SNES, ты не думаешь — а вот есть другой процессор, ах, сколько там РОН, какие там 32-битные операции и смещения. У тебя есть конкретный процессор, такой, какой он есть. Это данность. И ты пишешь для него код, как умеешь, настолько эффективно, как умеешь, чтобы решить конкретную задачу. Практика показывает: все задачи нормально решаются и там и там. Конечно, если у тебя опыт программирования на Z80 или M68K, ты будешь думать — как неэффективно писать на 6502/65816, там так мало регистров. Потому что у тебя нет понимания, что там принципиально другая парадигма, что там просто пишешь иначе, но в результате получаешь те же результаты. Когда ты уже знаешь и умеешь, ты не думаешь, как это сложно в сравнении, потому что тебе уже не сложно это делать.
Я много раз предлагал всем желающим поучаствовать в написании сравнительных тестов, Z80/6502, M68K/65816. Желающих за много лет почему-то не нашлось ни разу. И думаю, это не сработает, потому что знающий только одну архитектуру будет продолжать придерживаться своих взглядов на эффективность, т.к. по прежнему не понимает другую сторону ('ах, ты добился такого же результата, но мне не нравится твой непонятный код, я считаю его некрасивым'), а у знающего обе вопросов про сравнение уже не возникает.
Посмотрел сейчас еще в тайлы угловых стен — да, они не перерисовываются динамически, а построены заранее.
Есть два одинаковых набора — в одном два разных цвета (внутренние стены), в другом один из цветов прозрачный (внешние стены). В каждом изображены линии под разными углами — судя по всему растиражированы почти все возможные углы от 0 до 45 градусов, а дальнейшее получается зеркалированием по горизонтали/вертикали. С другой стороны, если приглядываться к итоговой картинке, то нередко заметно, что линия не является идеальных Брезенхемом, нередко видны «шероховатости» видимо на стыках, то есть прямо все возможные пиксельные комбинации возможно даже не покрыты для краткости. Общий паттерн же таков, что берется пиксель вдоль одной стороны и из него проводится линия ко всем пикселям на противоположных сторонах. Есть еще подозрение, что с помощью палитр еще сокращается число нужных комбинаций. Но так да — с ходу трудно придумать как этим теперь рисовать, такую задачу мне тоже еще не доводилось решать.
Имхо, напротив, ожидаю увидеть на SNES всякие трюки с переходом к 8.8 как в статье и всякие таблицы с xor-ами для выдавливания соков из-за дурацких раскладок против абсолютно прямолинейного ремесленного кода на SMD в 16 РОН и адресацией любого куска памяти через base+size*offset. То что внешне можно добиться схожей картинки как раз не показатель. Но тут смысла нет препираться особо пока не будет реальных сравнительных опенсорцных тестов это всё «личные мнения».
Самая главная проблема на SNES — откровенно неудачная система спрайтов. Если не сделать менеджер списка спрайтов грамотно, будут тормоза, наблюдаемые во многих играх. У большинства программистов тех лет просто не было опыта и времени разбираться, как решать эту проблему (но некоторые решали). Не выглядящие крутыми демки также показывают, что проблема решаема, а блог описывает, как именно. Я также пришёл к подобному решению, увидел изыскания этого товарища уже после этого.
Имхо всё же Маегава если и преувеличивал, то не сильно. Плоский прямолинейный проц с 32-битными операциями (пусть даже под капотом выполняющимися как 16-битные, но в системе команд команда одна и как бы 32-битная) и простые раскладки видеопамяти, включая таблицы спрайтов, очевидно должны сделать программирование сложных сцен и трюков на SMD проще. И даже если на SNES можно добиться таких же показателей — то это уже демосцена с выдавливанием соков, а не SMD — нет, просто сел и запрограммировал. Другое дело, что в SNES было еще много аппаратных интересностей просто отсутствующих в SMD.
Демка явно предшественница двух последующих, которые я не могу найти. В одной была графика прямо из GH, в другой очень стрёмная оригинальная графика с какой-то девочкой-роботом. В целом, можно видеть, что ещё 8 лет назад у него без проблем получалось сделать огромную кучу объектов и составные анимации без замедлений.
И судя по всему кусок стены над дверью еще накрыт спрайтами, а не фонами. Три больших таких спрайта прямо над ней. В общем не без заморочек.
Что-то сюда картинка как то косячно загрузилась. Вот она же на фастпике: i91.fastpic.ru/big/2018/0925/be/6ce8e44d70e132d8ab446c2e3df679be.gif
А прикольно у них там.
На слое А рисуется потолок и «внешние углы». Они реально перерисовываются при движении под нужный угол.
На слое Б рисуется пол и «внутренние углы». Даже если там статичные тайлы они значит рассчитаны под любой ракурс который может дать игра. Возможно их истинное число просто невелико, учитывая что есть флаги отражения тайлов по осям.
Так или иначе углы действительно создаются на лету тайлами или их содержимым и разбиты разумно на оба фона как «внутренние» и «внешние».
Стоит сперва начало посмотреть до первых геймплейных моментов (не пропуская заставки), а потом перемотать на 7:40 и позырить на indoor-геймплей.