Каскадный · [ Стандартный ] · Линейный Опубликованы исходные коды Doom для SNES

[aa-dav]

Для начала вспомним, что SNES это 16-битная игровая приставка с сегментацией памяти и порт Doom на ней изначально выглядел идеей гиблой и id Software даже и не помышляла о таком ранее сделав порт Wolf3D и ощутив на что способно это железо не по наслышке.
Однако на горизонте возник некто Рэнди Линден - когда энтузиасты уже расковыряли форматы данных игры Doom и начали экспериментировать с модами Рэнди будучи уже опытным разработчиком на железе Nintendo начал сам делать порт Doom на SNES.
Некоторое время назад он дал интервью (англ.) в котором в том числе пообещал выложить исходные коды к этому своего подвигу:

Однако мощностей консоли на самом деле было точно недостаточно. Но выход нашёлся - чип Super FX который можно было встроить в картридж с игрой. А это было уже что-то, ведь Super FX был 16-битным RISC-процессором с тактовой частотой 21 МГц + картридж содержал еще 512Кб RAM что было в четыре раза больше чем консоль содержала сама по себе (128Кб) и с этим уже можно было жить, хотя и в это верилось с трудом.
Так вот Рэнди сам написал демо где были только стены из оригинальной игры между которыми можно было бродить и пошёл к издателю который уже начал связываться с id Software и Nintendo чтобы навести мосты и выпустить порт.
В общем код совсем не такой какой он был в оригинальном Doom и весь он был написан целиком на ассемблере.
Пару недель назад Рэндал выложил исходные коды и их можно посмотреть тут: https://github.com/RandalLinden/DOOM-FX

Несмотря на RISC-процессор в картридже частот и 16-битности всё-равно решительно не хватало чтобы воспроизвести всё качество оригинала.
Порт заметно отличается тем что пол и потолок не текстурируются (залиты монотонно с затенением по расстоянию).
В общем со всеми ухищрениями оно шевелится со вполне приемлемой скоростью и ужасным конечно качеством:

Но для 16-битной системы это очень впечатляет!

То что код другой заметно по тому что аватар легко может застрять на стыке разных сегментов стен там где в оригинале он точно бы был бы вытолкнут из стены и плавно проскользил бы дальше по касательной. Тут же скольжение сие явно имеет проблемы на стыке сегментов стен.
Во вторых рендер тоже не без проблем и текстурные координаты явно плывут почему то в зависимости от угла зрения.
Вот пример:

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

Интересно еще, что из-за того, что Рэнди брал готовые уже уровни и конвертировал их через утилиты его порт отличается от многих официальных портов на консоли тем, что его уровни не упрощены. А ведь даже на 32-битных консолях многие уровни резались в деталях чтобы приемлемо шевелиться!

Столкнулся Рэнди с чипом SuperFX когда помогал кому то с игрой Dirt Trax FX для Sculptured Software и то ли сам другую игру делал, то ли что, но в общем им пришлось заказать у третьей фирмы соображающей в железе раскурочить картридж со Starfox чтобы вынуть оттуда SuperFX-1 и распаять всё на плату с ППЗУ и прочими схемами и её прошивать с ПК Amiga через параллельный порт воткнутый в порт геймпада SNES. Линделу пришлось самому и ассемблер даже написать и весь тулчейн, так что когда много позже когда уже проект порта Doom ожил и зашевелился в полную силу и Nintendo прислало официальный девкит, то ему пришлось немного его отреверсить чтобы продолжать работать со своими утилитами и тулчейном, но уже в финале образ заливать в официальный девкит.
Причём т.к. первый SupefFX был именно FX-1 из Starfox, то он работает на половинной частоте чипа FX-2 который уже будет в порте Doom и это сразу было известно что надо будет в конце переходить на повышенную частоту, но за неимением девкита просто расковыряли картридж самого первого что появилось с SuperFX на рынке - Starfox.

Интересно еще, что Рэнди утверждает, что основной проблемой было запихать весь контент в картридж и именно поэтому у пола и потолка нет текстурирования.
Он говорит, что текстуры стен "сжаты по вертикали". А вот с полом сжать аналогично не получилось, т.к. его видно под разными углами.
Это забавный момент - похоже что т.к. стены рендерятся вертикальными полосками всегда он применил RLE-кодирование вдоль вертикальных полосок пикселей и это позволило ему сильно ужать текстуры стен, т.к. алгоритм идёт вдоль последовательности сжатых байт всегда в одном направлении (например сверху-вниз). Но с полом это не сработало, т.к. он виден под разными углами. Вот это он и назвал причиной почему в Doom для SNES пол и потолок залиты одноцветно.
Похвалил он способность SuperFX применять к пикселю затенение автоматически.
Еще говорит, что ЦП в основном простаивал, а 95% работы делалось SuperFX, скорее всего ЦП использовался только для всякой подгрузки в музыкальный чип да опрос периферии и в основном простаивал ожидая когда SuperFX выполняет программу из ROM картриджа (этот вариант как раз блокирует работу ЦП из-за конкуренции за шины).

Про чип SuperFX еще почитал в добавок и довольно забавный процессор. Действительно 16-битный и сильно заточенный под то чтобы рисовать произвольную графику на SNES (фреймбуфер), но хотя многое напоминает по своей работе RISC, но с другой стороны так много префиксов/суффиксов/непосредственных данных разной длины/специализированных регистров и асимметрий в операциях, что лично у меня язык едва ли повернётся назвать эту архитектуру RISC. Скорее это была мода того времени называть всё новое модное и немного непохожее на мейнстрим как "RISC" при паре совпадений только.

Интересно так же было взглянуть и на исходные коды. Подавляющая их часть написана на трёх сильно разных ассемблерах.
Во первых, конечно же ЦП SNES - WDC 65816. Но эти исходные коды перемежаются с ассемблером для чипа SuperFX.
Тут важно заметить, что программировал Рэнди Линден тогда на компьютере Amiga и для написания тех же утилит по перегонке карт из оригинального Doom в свой порт писал код и для Амиги - и тоже на ассемблере!
Попадается там и код на Си, но когда я смотрел (неделю назад) его совсем мало в основной ветке игры и он в основном применялся для создания предзаготовленных таблиц с математическими функциями - видимо потому что в Си были встроенные тригонометрические функции, т.е. язык который сейчас считается системным ну или низкоуровневым тогда у Рэнди играл роль скриптов на каком нибудь питоне в нынешних реалиях.
Воистину забавно!

Сообщение отредактировал aa-dav - Четверг, 30 июля 2020, 18:06

[Kislorod]

Интересное чтиво. Ещё вроде говорилось, что вместо расчётов тригонометрии он загнал в картридж расчитанные заранее таблицы значений, это тоже повлияло на размер итогового рома (там, где в обычном случае было бы несколько строк кода, здесь был здоровенный массив данных).

Я в Doom на SNES играл ещё в те времена, в середине 90х, и игралось оно на пузатом телеке вполне себе ничего. Других вариантов у меня не было, так что я был счастлив )

Сообщение отредактировал Kislorod - Четверг, 30 июля 2020, 20:55

[rainstorm]

Интересная статья. Дум, один из самых великих портов-превозмоганий, на мой вкус. Вообще на снес, так же и цивилизация выходила(был удивлён, когда нашёл ром), и как тут не вспомнить ещё старкрафт на n64.

[dimm0505]

Однако на горизонте возник некто Рэнди Линден

Этот Рэнди оказывается еще и bleem! с bleemcast! создал Эмули PS1 для PC и Dreamcast.

[F1ReB4LL]

Во вторых рендер тоже не без проблем и текстурные координаты явно плывут почему то в зависимости от угла зрения.
Вот пример:

В одной GBAшной игре этот косяк возвели в абсолют: https://www.youtube.com/watch?v=L9ngdYD31HQ#t=14m27s

[aa-dav]

В одной GBAшной игре этот косяк возвели в абсолют: https://www.youtube.com/watch?v=L9ngdYD31HQ#t=14m27s

xD
У дума оно почти незаметно на далёких стенах, т.к. варьируется от угла зрения небольшое смещение.
Тут же варьируется вообще всё - и масштаб и смещения, похоже что там на перспективную коррекцию текстур просто положили болт.

[AtH]

Интересное чтиво. Ещё вроде говорилось, что вместо расчётов тригонометрии он загнал в картридж расчитанные заранее таблицы значений, это тоже повлияло на размер итогового рома (там, где в обычном случае было бы несколько строк кода, здесь был здоровенный массив данных).

Кстати, это стандартный подход на Форте.

Изначально в Форте не было плавучки. Так как приходилось его использовать для астрономических расчётов, операции производились в формате с фиксированной запятой — дробные числа эмулировались целыми. В результате быстродействие, ещё в те времена, было выше всяких похвал.

Программиста должен был сам помнить, где у него стоит запятая. Например, 16 битное целое могло в одной ситуации быть 8 бит на целую часть и 8 бит на дробную. А в другой ситуации — 12 бит на целую и 4 бита на дробную.

В классической отечественной книге Баранова и Ноздрунова приводился код для вычисления синусов и косинусов с фиксированной запятой. Там действительно большой массив, из которого считывается табличное значение, соответствующее аргументу — индексу массива. Ну и несколько тригонометрических формул приведения аргумента, чтобы сделать массив покороче. При умелом программировании не сильно больше памяти тратится, зато скорость вычислений возрастает.

Любопытно, что до появления калькуляторов люди похожим образом вычисляли синусы. Я ещё застал в советской школе таблицы Брадиса. Небольшая такая тетрадочка, страницы которой заполнены логарифмами и синусами разных углов, в несколько столбцов.

[aa-dav]

операции производились в формате с фиксированной запятой

Это в целом типично для времени когда сопроцессоры с плавающей точкой не вошли плотно в обиход.
Фиксированная точка и таблицы предвычисленных значений (и не только арифметических) - частый гость кода на 8/16 бит, включая конечно же все консоли и ПК.
Даже 32-битный Game Boy Advance не имел сопроцессора с плавающей точкой и попытки использовать функции sin/cos из стандартной библиотеки Си из пакета разработки devKitARM просто выносило всю производительность под ноль - я когда писал уроки по вращению спрайтов, то волей неволей перешёл на фиксированную точку 8:8 и с этого начинается статья http://hype.retroscene.org/blog/877.html
Причём это действительно довольно простая штука - надо только осознать как ведут себя разряды перед и после разных операций сложения и вычитания и как их "выправлять" операциями сдвига. Собственно железо GBA умеет само вращать и масштабировать фоны и спрайты и порты ввода-вывода управляющие этими операциями тоже сделаны в формате с фиксированной запятой.

[dimm0505]

этого начинается статья http://hype.retroscene.org/blog/877.html

Хороший у тебя цикл статей, тем более на русском. Вполне можно начать самому кодить под GBA. Я только не понял, в статье про вращение и синусы, у тебя 256 градусов в круге, но в нем же 360? Или это какие-то условные градусы?

[aa-dav]

Я только не понял, в статье про вращение и синусы, у тебя 256 градусов в круге, но в нем же 360? Или это какие-то условные градусы?

Спасибо за оценку.
В предыдущей статье, кстати, там по сути введение в теорию по фиксированной точке. А в этой уже как данность идёт код.
Градусы всегда есть некая условность которой мы придерживаемся из удобства. Древние финикийцы (или кто там) уважали числа делящиеся нацело на 2,3,4,5,6 и потому любили такие числа как 12, 36, 60 и т.п. - отсюда все эти 360 градусов в круге и 24 часа в сутках. Матанщики обнаружили что для естественных вычислений лучше отождествлять градус с длиной единичной окружности и это радианы и тогда в формулах поправочные коэффициенты отваливаются (скажем так).
Мы же, компьютерщики, работаем с байтами и нам удобно если угол ляжет в этот байт как влитой - от 0 градусов до 255 - все 256 возможных значений. Более того, попытка прибавить 1 к байту переполнит его и автоматически угол провернётся в 0. Это настолько удобно, что операция нормализации угла (приведение его к диапазону внутри круга) - это просто отбрасывание всего что больше байта, в Си можно выразить как grad & 0xFF.
Это настолько квадратиш, практиш и гут, что глупо не пользоваться таким в играх. Бьюсь об заклад, что в подавляющем большинстве 8/16-битных игр в которых нужно вычислять углы и тригонометрию по таблицам так и есть.

Сообщение отредактировал aa-dav - Пятница, 14 августа 2020, 07:00

[serguyan]

DOOM на снес - неиграбельное нечто.
Про что там вообще разговор можно вести? Набор пикселей низкого качества?

[dimm0505]

Мы же, компьютерщики, работаем с байтами и нам удобно если угол ляжет в этот байт как влитой - от 0 градусов до 255 - все 256 возможных значений.

Ну я так и понял, чтобы для удобства и быстроты в байт вписаться.

Добавлено спустя 1 час 47 минут:

DOOM на снес - неиграбельное нечто.
Про что там вообще разговор можно вести? Набор пикселей низкого качества?

Про то, что это DOOM на 16 битной приставке. Про то что, он даже на 386DX40 с 4MB памяти шел кое-как, приходилось окошко игры уменьшать. Я понимаю, что там SuperFX2 использовали, но это же не модернизация приставки, он в самом карике был.

Сообщение отредактировал dimm0505 - Пятница, 14 августа 2020, 15:26

[serguyan]

Про то, что это DOOM на 16 битной приставке. Про то что, он даже на 386DX40 с 4MB памяти шел кое-как, приходилось окошко игры уменьшать. Я понимаю, что там SuperFX2 использовали, но это же не модернизация приставки, он в самом карике был.

Zero Tolerance тоже был на 16 бит приставке. И выглядит куда лучше doom.

Хотя я полностью понимаю ваше восхищение, что пекашную игру в 16 бит запихали, типо это подвиг. Так оно и есть, просто неиграбельно же.

[dimm0505]

Zero Tolerance тоже был на 16 бит приставке. И выглядит куда лучше doom.

Я не знаю, может она жутко играбельная была эта ZT, режим на двоих, история и все дела (я сам не играл в нее), но хоумбрюшный Wolf3D выглядит лучше ее на голову:




И вот порт DOOM на SNES (видео с реальной приставки, не эмулятор):



По сравнению с ZT она выглядит некстгеном, и по графиту, и по музону с эффектами.

Чтобы сравнить SNES версию с MD/Gen вот версия Дума для SEGA 32x (без игры она одна стоила $200), карик DOOM для SNES стоил тогда $80:


Безусловно, графически и в отношении производительности, 32x побеждала (в SNES версии нет текстур на полу и потолке):


Но! В SNES версии было больше уровней (22 из PC версии) против 16 в 32x (из версии для Jaguar), в СНЕС версии была лучше музыка. Ну и разница в цене.

Ну и моя любимая - GBA версия. Без чипов, второй приставки и тп. Пол и потолок на месте, производительность хорошая, только разрешение меньше, но на маленьком экране реальной портативки этого не видно:



Вот DOOM II:


Версии для GBA захвачены с помощью Gameboy Player для Gamecube (не эмулятор).

Сообщение отредактировал dimm0505 - Пятница, 14 августа 2020, 22:52

[aa-dav]

Zero Tolerance тоже был на 16 бит приставке. И выглядит куда лучше doom.

Хотя я полностью понимаю ваше восхищение, что пекашную игру в 16 бит запихали, типо это подвиг. Так оно и есть, просто неиграбельно же.

Не соглашусь. Играл в эмуляторах и Zero Tolerance и в Doom - есть плюсы и минусы и Doom имхо выигрывает по сумме очков.
Ну во первых Zero Tolerance это игра предыдущего поколения - клон Wolf3D. Кубические ячейки карты с одинаковым уровнем пола и потолка. Это сильно упрощает графический движок. Что крайне для меня было интересно в Zero Tolerance - что переходы между этажами выбивались из этой картины и были реальными туннельными спусками по лесенкам или лифтам где движок показывал разные уровни пола/пололка на переходе. Это было неожиданно для таких движков, но было только вот на переходах между этажами. Поэтому погоды никакой эта фича не сделала - в остальном это клон вульфа где геймплей очень однообразен - по карте смотришь где враги, наступаешь на них и при пересечении невидимой до них границы (когда они еще не видны сами) они резко срываются по направлению к тебе с уклоном в случайный угол и бегут постреливая в тебя наперерез. Твоя задача - как можно быстрее навести перекрестье на врага и пристрелить его, а если нарвался на активацию сразу нескольких (что чаще всего и бывает) - то всех раньше чем они истреплют твою полоску жизней. Все первые 3-4 уровня эта формула не менялась и по современным меркам игра довольно хардкордная, потому что в эмуле мне постоянно приходилось делать quick-save-quick-load потому что действительно если не действовать близко к идеальному - включая то с каких углов заходить к врагам и в каком порядке их активировать, то тебя просто треплют быстрее чем ты находишь аптечки. Собственно после третьего или скорее четвёртого уровня мне это дело быстро надоело и я продолжать не стал. Как клон Wolf оно обладает улучшенной графикой (там присутствует например эффект параллакса помимо упомянутых лестниц и лифтов между уровнями - т.е. небо на заднем фоне включая за окнами, (что на консоли достигается бесплатно), угловыми кубами), более интересным для меня лично сеттингом, но вот играть интереснее чем в Wolf не стало - надоедает довольно быстро.

Doom для SNES объективно хуже почти по всем статьям нежели свой старший брат с IBM PC - меньше и разрешение, меньше и скорость (нежели на Intel 486), хуже работает физика... Но как движок он на голову выше Zero Tolerance потому что это другое поколение движков - 2.5D, комнаты могут быть произвольными многоугольниками на карте в виде сверху и пол и потолок находятся на разной высоте в этих многоугольниках. Соответственно вариативность лабиринтов и того что мы на них наблюдаем раздвигается в новом измерении.
Главная проблема Doom на SNES - это идентификация монстров уже даже на средних дистанциях. В этой пиксельной каше (на SNES не только разрешение видеочипа ниже, но и применён даунскейлинг разрешения в 2 раза для ускорения - как будто на ПК нажали F8 если не ошибаюсь, потому что Intel 386 тянул полноценное разрешение из рук вон плохо) стены лабиринта еще видно, но монстры очень быстро с расстоянием теряются в конкретике - ориентироваться во многом приходится на звуки.
А дело в том, что в Doom есть еще геймплей - очень по разному действующее оружие, поэтому разных монстров или разные скопления врагов лучше бывает валить конкретным оружием, а не любым наугад взятым. Проблемы с идентификацией монстров делают этот выбор сложнее.
Да, проблемы есть, но они в принципе были и в Zero Tolerance, там тоже человечки на тех же дистанциях были неотличимы друг от друга, просто это не играло никакой роли - стреляй во всё что движется и всё. Там было похрену и только поэтому и не вызывало вопросов.
В Doom не похрену, поэтому вопросы есть. Но они и есть потому что игра намного богаче на геймплей.

Поэтому вообще не соглашусь что Zero Tolerance может годится для какого либо сравнения с Doom.
Шутеран для своего времени и места актуальный и годный, но Doom на SNES для своего времени и места был просто термоядерной бомбой.

[dimm0505]

Есть же оказывается два форка на гитхабе, с полной конверсией PC версии на GBA А в планах даже Final DOOM с TNT: Evilution и The Plutonia Experiment )))

https://www.romhacking.net/hacks/4899/

Вот первый от doomhack:
https://github.com/doomhack/GBADoom/releases

Вот второй, от Kippykip:
https://github.com/Kippykip/GBADoom/releases

Причем они обновляются, последний раз в начале лета. Там можно скачать патч и пропатчить с помощью Lunar IPS оригинальный ром GBA-игры (любой как я понял, EUR/USA),
а можно качнуть сразу ром в Releases (с shareware уровнем).

То бишь, на этих модах игра уже будет не на урезанном движке Jaguar-версии сделан, а на полноценном порте - PrBoom, с лучшим качеством звука, музыкой, графикой, лучшим фреймретом и полноценными уровнями из PC версии:

This patch completely converts the game from using the dated stripped down Jaguar Doom engine and instead switches it to a new homebrew port based on doomhack’s PrBoom port to the GBA. Meaning, higher quality sounds, full non-simplified PC Doom maps, better framerate (yes!), graphics and music (far better music, they play in the correct level now!)

Оптимизация еще продолжается (от 13 июня):

Changes in this version:

-Lots of optimisations! Factored out more division, use reciprocal table, move more code to IWRAM. Offers around a 15-25% improvement in FPS.
-Some memory savings. There's still a couple of levels in Plutonia that won't load, (Map 23 & 28).
-Added framerate display. (Which can be accessed via a cheat. Thanks KipyKip. Why didn't I think of that!?) It replaces your current weapon ammo display and is in 10th's. So 234 = 23.4FPS.
-Fixed cyberdemon and spiderdemon not being drawn at distances over 1280 units.
-Allowed PC build for debugging with MSVC compiler too. (Use 32bit. I don't think it works 64bit due to struct alignment.)

Сообщение отредактировал dimm0505 - Суббота, 15 августа 2020, 14:57

[SCP-1471a]

Ну наконец-то хентай дум портируют на снес!

[dimm0505]

Ну наконец-то хентай дум портируют на снес!

На SNES? На GBA же?

[Nhisti]

DOOM на снес - неиграбельное нечто.
Про что там вообще разговор можно вести? Набор пикселей низкого качества?

Всё оно было играбельное и выглядело тогда на "нифигасе!", а для одного моего другана, который после денди со спектрумом вообще впервые увидел 16-битную приставку и первой же игрой DOOM, вообще стала настоящим культурным шоком и, как он потом признавался, даже снилась ему несколько ночей кряду.
А то взяли моду - наиграются во всякие кваки с каловдутиями, а потом попробуют уже в этом веке, да на эмуляторе и в итоге неиграбельно им Тебе бы в 95-м году её увидеть, да у себя дома, на телеке - кипятка бы на радостях выдал так, что на отопление многоэтажки бы хватило. Да, и Зеро Толеранс там даже и рядом не стоял.

[daxter.]

Можно было подумать, что на тех ПК дум летал.

Все было "так себе" и дорого. А тут на картридже и стоковой платформе. Крутяк.
С музыкой, которая лучше, чем на ПК.