автор до сих пор выпускает новые версии (преимущественно не под вин, но последнюю версию под винду он специально компилировал для меня), посмотри плиз на этот счёт его страницу
Рекомендую также обратить внимание на Sega Game Gear. Это почти то же самое, но ещё плюс сотня-другая игр. Только придётся заморочиться с расширением отображаемой части уровня, но это многократно делалось любителями, они нередко адаптировали игры, в обе стороны.
WLA DX конечно стандарт, и в общем-то хорош, но очень уж глючный, особенно в части редких процессоров. Так что его использования стараются избегать, и именно по причине проблем с WLA наделали немало альтернатив. Он с тех пор вроде как исправился, но осадочек-то остался. Сам до сих пор использую его для SNES (только для 65816), но это вынужденная мера, tcc-816 завязан на него (адски глючная связка).
Меня никогда не интересовало программирование само по себе — красота кода и прочие подобные штуки. Программирование для меня всегда остаётся просто необходимым инструментом — хочу делать игры, значит надо писать код. Вероятно поэтому разные процессоры не доставляют мне особых проблем, и я не заморачиваюсь размышлениями, где что лучше и где проще-сложнее, просто пишу на том, что есть. Сложность кода вообще штука такая — если для решения задачи нужен какой-то трюк (чтение стеком на Z80 или 16-битное сравнение со знаком на 6502), это не сложность и не неудобство, это один раз научился и дальше применяешь по необходимости, а то и просто заворачиваешь в макрос и забываешь. Сложность кода начинается скорее на алгоритмическом уровне, а на уровне реализации алгоритма на ассемблере это одинаково не сложно и не просто, это просто есть как есть.
Это к тому, что мне просто по образу мышления не приходят в голову абстрактные типовые задачи. У всех платформ помимо процессора также и своя специфика во всём остальном, в частности в видеосистеме, где в основном критична скорость кода. Где не критична, там я особо не оптимизирую, пока не возникает реальная необходимость, потому что важнее закончить проект в целом и не перегореть (make it work, make it pretty), чем закопаться с головой в несущественных для общей картины деталях. Как правило в целой игре не так уж много узких мест, где нужно выжимать максимум.
Наверное, для тестов производительности нужно придумать виртуальную систему, где всё железо одинаковое, разный только процессор. Например, для удобства, Pentagon (потоиу что полностью софтовая графика, есть необходимость жёсткой оптимизации, и нет торможения по всей памяти), но с 6502 на 1.75 МГц. Для начала можно посмотреть предельную пропускную способность, развёрнутый цикл, задачи максимально быстрой очистки экрана и максимально быстрого заполнения экрана произвольной графикой (как мы делаем во фреймовых листалках):
Очистка (lps — сколько раз выполнится такой за секунду на соответствующей частоте процессора):
А вот в копировании разница уже не такая большая, всего 6 условных единиц.
Эти тесты не показывают ничего конкретного, кроме одного: не всё так однозначно, как кажется. Где-то проигрыш 6502 очень заметен, где-то результат очень близкий. По практическим задачам (эффекты на ZX и C64, порты биперных движков с ZX на Atari) мы давно уже знаем, что разница по мере роста сложности алгоритмов сводится к минимуму, всюду возможно примерно одно и то же.
Я не помню каких-то особых сложностей с 6502. Запомнились только программные проверки на коллизии из-за того что экран по горизонтали больше чем 256 и Х координата не влезвет в 8-бит :) Да и то нашёл решение в инете, самому лень было писать
Ну вот я в своё время искал как раз про это — мне не понравилось. :) Сложение 16-битных обязательно через CLC/ADC/ADC (8-битные), при том что расположение аргументов выше zero-page — нехорошо раздувает код (как всегда, впрочем), копирование произвольного региона памяти в два 8-битных цикла через медленную на этой платформе косвенную индексацию (поэтому если адреса регионов заранее известны или менее 256 байт, то нужно оптимайзить). Вкусовщина или нет, но на меня такое навевает уныние.
А вообще я тоже за подобные вводные уроки по «хитростям» 6502.
Да просто начни делать :) Я когда писал Alter Ego под комод через какое-то время просто грохнул исходник и со второго раза сделал так что заработало. Но тот первый раз вот и был поиском решений стандартных для игры задач. А в целом всё как aa-dev описал выше. Я использовал kickass IDE, там сразу и бэйсик стартер есть, редактор спрайтов, тайлов и.т.п. Один минус — большинство примеров под комод не под синтаксис kickasm, но это не особо страшно.
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.
WLA DX конечно стандарт, и в общем-то хорош, но очень уж глючный, особенно в части редких процессоров. Так что его использования стараются избегать, и именно по причине проблем с WLA наделали немало альтернатив. Он с тех пор вроде как исправился, но осадочек-то остался. Сам до сих пор использую его для SNES (только для 65816), но это вынужденная мера, tcc-816 завязан на него (адски глючная связка).
Кажется, у нас новая платформа-кандидат на победу в ZX Spectrum 640k demo compo 2019!
Это к тому, что мне просто по образу мышления не приходят в голову абстрактные типовые задачи. У всех платформ помимо процессора также и своя специфика во всём остальном, в частности в видеосистеме, где в основном критична скорость кода. Где не критична, там я особо не оптимизирую, пока не возникает реальная необходимость, потому что важнее закончить проект в целом и не перегореть (make it work, make it pretty), чем закопаться с головой в несущественных для общей картины деталях. Как правило в целой игре не так уж много узких мест, где нужно выжимать максимум.
Наверное, для тестов производительности нужно придумать виртуальную систему, где всё железо одинаковое, разный только процессор. Например, для удобства, Pentagon (потоиу что полностью софтовая графика, есть необходимость жёсткой оптимизации, и нет торможения по всей памяти), но с 6502 на 1.75 МГц. Для начала можно посмотреть предельную пропускную способность, развёрнутый цикл, задачи максимально быстрой очистки экрана и максимально быстрого заполнения экрана произвольной графикой (как мы делаем во фреймовых листалках):
Очистка (lps — сколько раз выполнится такой за секунду на соответствующей частоте процессора):
Разница в скорости на треть. В размере очень большая, что ожидаемо — код на 6502 всегда заметно многословнее.
Зарисовка:
А вот в копировании разница уже не такая большая, всего 6 условных единиц.
Эти тесты не показывают ничего конкретного, кроме одного: не всё так однозначно, как кажется. Где-то проигрыш 6502 очень заметен, где-то результат очень близкий. По практическим задачам (эффекты на ZX и C64, порты биперных движков с ZX на Atari) мы давно уже знаем, что разница по мере роста сложности алгоритмов сводится к минимуму, всюду возможно примерно одно и то же.
А вообще я тоже за подобные вводные уроки по «хитростям» 6502.
Жмах
Реги спрайтов: 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.