Mass effect модуль памяти ремонт вручную

Как починить ядро в реакторе на Новерии в Mass Effect

По мере того, как игроки пытаются выследить матриарха Бенезию в Mass Effect, они столкнутся с загадкой, которую может быть довольно сложно решить. В частности, это загадка «Ядро памяти», которая находится в Новерии, и фанаты должны выполнить ее, чтобы запустить отключенный ВП. Для тех игроков, у которых могут возникнуть проблемы с пониманием того, как починить реактор в Mass Effect.

Как решить головоломку с реактором

Для начала важно выяснить, как именно работает эта головоломка в Mass Effect, поскольку ее основные функции могут немного сбивать с толку на первый взгляд. По сути, цель здесь для фанатов RPG — перенести все модули из Ядра памяти 1 в другое Ядро, перемещая только один модуль за раз. Процесс перемещения модуля состоит из двух этапов: его подъема и размещения, и здесь все может оказаться сложным.

Чтобы попытаться сделать все как можно проще, самый высокий активный модуль (синий) в Ядре будет взят, когда игрок Mass Effect нажмет вход, который появляется в верхней части этого Ядра. Затем игроки могут нажать ввод, который появляется в верхней части другого Ядра, чтобы разместить выбранный модуль в том же месте в этом Ядре. Однако фанаты не могут размещать модуль под уже активным (синим) модулем, что означает, что ядро ​​необходимо строить снизу вверх.

Для этого требуется, чтобы модули перемещались вперед и назад по ядрам, пока стек не будет перестроен в ядре памяти 2 или 3. Это можно увидеть в видео, показанном выше, а у следующих игроков должен быть активен Новерия VI. моментально. В качестве альтернативы поклонники могут ссылаться на следующее решение, которое обеспечивает порядок перемещения модулей между ядрами памяти:

• Ядро 1 -> 2;
• Ядро 1 -> 3;
• Ядро 2 -> 3;
• Ядро 1 -> 2;
• Ядро 3 -> 1;
• Ядро 3 -> 2;
• Ядро 1 -> 2;
• Ядро 1 -> 3;
• Ядро 2 -> 3;
• Ядро 2 -> 1;
• Ядро 3 -> 1;
• Ядро 2 -> 3;
• Ядро 1 -> 2;
• Ядро 1 -> 3;
• Ядро 2 -> 3.

Отметим, что можно полностью обойти эту загадку, потратив 100 омни-гелей, которые можно получить, разбирая такие вещи, как броня и оружие в Mass Effect. Игрокам предоставляется эта опция, как только они взаимодействуют с ядром памяти, и это, безусловно, значительно ускоряет этот раздел. Тем не менее, 100 омни-гелей — это немалое количество, и игрокам может просто не хватить материала для реализации этого альтернативного подхода на данном этапе игры.

Источник

Новерия: «Вершина 15»

Новерия: «Вершина 15»

Категория

Локация

Выдаётся

Условия

Содержание

Получение [ править | править код ]

Прибыв на Новерию, Шепард узнаёт, что матриарх Бенезия проследовала через порт Ханьшань на исследовательскую станцию «Вершина 15». Однако, попытавшись следовать за ней, он (она) обнаружит, что выезд из порта закрыт, а станция начинает обрастать непонятными слухами. Задание появится в журнале после беседы с механиком Ли, отирающимся около гаража.

Прохождение [ править | править код ]

Шепард(у) придётся собрать информацию о произошедшем на станции.

Загадочные слухи [ править | править код ]

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

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

Предупреждение Джанны [ править | править код ]

Более подробно о произошедшем можно расспросить Джанну Паразини — помощницу местного администратора Анолеиса. Она расскажет, что корпорация «Байнери Хеликс» разрабатывала на станции биологическое оружие, а пришедший оттуда сигнал — код «Омега», означающий, что «разработки» вырвались из-под контроля и заполнили станцию. Бенезия с десантницами-азари отправилась туда для устранения последствий. Джанна попросит Шепард(а) быть осторожнее на станции.

Компьютеры повреждены [ править | править код ]

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

Спустившись в ядро, Шепард обнаружит модуль памяти. При попытке работать с ним появится сообщение о необходимости ремонта. Можно попытаться вручную сконфигурировать модули данных либо использовать 100 порций уни-геля, чтобы отремонтировать повреждённые системы. Вручную придётся решать головоломку, в которой надо перебросить четыре элемента памяти с левого модуля на средний или правый модуль.

Задача непростая, но решение у неё есть, и выглядит оно так:

• Для ПК: 1–3, 1–2, 3–2, 1–3, 2–1, 2–3, 1–3, 1–2, 3–2, 3–1, 2–1, 3–2, 1–3, 1–2, 3–2.
• Для Xbox 360: X, Y, X, B, Y, B, X, Y, B, X, B, Y, X, Y, X, B, Y, B, Y, X, B, X, Y, B, X, Y, X, B, Y, B.

Как только ВИ будет отремонтирован, миссия завершится.

Источник

Исправляем графический баг Mass Effect, возникающий на современных процессорах AMD

Mass Effect — популярная франшиза научно-популярных RPG. Первая часть сначала была выпущена BioWare в конце 2007 года эксклюзивно для Xbox 360 в рамках соглашения с Microsoft. Спустя несколько месяцев, в середине 2008 года, игра получила порт на PC, разработанный Demiurge Studios. Порт был достойным и не имел заметных недостатков, пока в 2011 году AMD не выпустила свои новые процессоры на архитектуре Bulldozer. При запуске игры на PC с современными процессорами AMD в двух локациях игры (Новерия и Илос) возникают серьёзные графические артефакты:

Да, выглядит некрасиво.

Хоть это и не делает игру неиграбельной, такие артефакты раздражают. К счастью, решение существует, например, можно отключить освещение консольными командами или модифицировать карты игры, удалив поломанные источники освещения, но, похоже, никто никогда так и не понял полностью причины этой проблемы. В некоторых источниках утверждается, что эту проблему позволяет устранить и мод FPS Counter, но мне не удалось найти информацию о нём: исходный код мода, похоже, не выложен онлайн, а документация о том, как мод исправляет ошибку, отсутствует.

Почему эта проблема так интересна? Баги, возникающие только на оборудовании отдельных производителей, встречаются довольно часто, и в играх они встречаются уже много десятилетий. Однако, по моей информации, это единственный случай, когда проблема с графикой вызвана процессором, а не графической картой. В большинстве случаев проблемы возникают у продуктов определённого производителя GPU и никак не касаются CPU, однако в данном случае всё совсем наоборот. Поэтому эта ошибка уникальна, а значит, её стоит исследовать.

Почитав онлайн-обсуждения, я пришёл к выводу, что проблема, похоже, касается чипов AMD FX и Ryzen. В отличие от более старых процессоров AMD, в этих чипах нет набора команд 3DNow!. Возможно, ошибка никак с этим не связана, но в целом у сообщества геймеров сложился консенсус о том, что это причина бага и что обнаружив процессор AMD, игра пытается использовать эти команды. Учитывая то, что случаи возникновения этого бага на процессорах Intel неизвестны, и что команды 3DNow! использовала только AMD, неудивительно, что сообщество посчитала причиной этот набор команд.

Но в них ли проблема, или ошибку вызывает нечто совершенно другое? Давайте выясним!

Часть 1 – Исследования

Прелюдия

Хотя воссоздать эту проблему чрезвычайно просто, мне долгое время не удавалось оценить её по простой причине — у меня не было под рукой PC с процессором AMD! К счастью, на этот раз я занимаюсь исследованиями не в одиночку – Рафаэль Ривера поддержал меня в процессе изучения, предоставив тестовую среду с чипом AMD, а также поделился своими предположениями и мыслями, пока я делал слепые догадки, как это обычно бывает, когда я ищу источники таких неизвестных проблем.

Так как теперь у нас была тестовая среда, первой, разумеется, мы протестировали теорию cpuid – если люди правы, предполагая, что следует винить команды 3DNow!, то в коде игры должно быть место, проверяющее их наличие, или хотя бы определяющее изготовителя CPU. Однако в таких рассуждений есть ошибка; если бы игра действительно пыталась использовать команды 3DNow! на любом чипе AMD без проверки возможности их поддержки, то она, скорее всего, «вылетела» бы при попытке выполнения недопустимой команды. Более того, краткое исследование кода игры показывает, что она не проверяет возможности CPU. Следовательно, что бы ни было причиной ошибки, не похоже, что она вызвана неправильным определением функцональности процессора, потому что игре она вообще не интересна.

Когда случай начал казаться не подлежащим отладке, Рафаэль сообщил мне о своём открытии – отключение PSGP (Processor Specific Graphics Pipeline) устраняет проблему и все персонажи освещаются правильно! PSGP — не самое подробно задокументированное понятие; если вкратце, то это legacy-функция (касающаяся только старых версий DirectX), позволяющая Direct3D выполнять оптимизации под конкретные процессоры:

В предыдущих версиях DirectX существовал путь выполнения кода под названием PSGP, позволявший производить обработку вершин. Приложения должны были учитывать наличие этого пути и поддерживать путь для обработки вершин ядрами процессора и графической карты.

При таком подходе логично, что отключение PSGP устраняет артефакты на AMD — путь, выбиравшийся современными процессорами AMD был каким-то образом испорчен. Как его отключить? На ум приходят два способа:

Можно передать функции IDirect3D9::CreateDevice флаг D3DCREATE_DISABLE_PSGP_THREADING . Он описывается следующим образом:

Ограничивает вычисления только основным потоком приложения. Если флаг не установлен, то среда выполнения может выполнять программную обработку вершин и другие вычисления в рабочем потоке (worker thread), чтобы повысить производительность в многопроцессорных системах.

К сожалению, установка этого флага не решает проблему. Похоже, что несмотря на наличие в названии флага букв «PSGP», это не то, что нам нужно.

DirectX задаёт два элемента регистра для отключения PSGP в D3D и для отключения PSGP только для D3DX – DisablePSGP и DisableD3DXPSGP . Эти флаги можно устанавливать для всей системы или только для процесса. Подробности о его установке для конкретного процесса см. в руководстве Рафаэля Риверы по включению флагов Direct3D для отдельных приложений.

Похоже, что DisableD3DXPSGP способен решить эту проблему. Следовательно, если вы не любите скачивать сторонние исправления/модификации или хотите устранить проблему, не внося никаких изменений в игру, то это вполне рабочий способ. Если вы установите этот флаг только для Mass Effect, а не для всей системы, то всё будет в порядке!

Как обычно, при возникновении проблем с графикой их, скорее всего, поможет диагностировать PIX. Мы выполнили захват схожих сцен на оборудовании Intel и AMD, а затем сравнили результаты. Сразу же бросилось в глаза одно различие — в отличие от моих предыдущих проектов, где захваты не записывали в себя баг и один и тот же захват мог выглядеть на разных PC по-разному (что указывает на баг драйвера или d3d9.dll), эти захваты записывали в себя баг! Другими словами, если открыть сделанный на «железе» AMD захват на PC с процессором Intel, то баг будет отображаться.

Захват с AMD на Intel выглядит точно так же, как выглядел на оборудовании, где был сделан:

О чём это нам говорит?

• Так как PIX не «делает скриншоты», а захватывает последовательности команд D3D и выполняет их в оборудовании, мы видим, что при выполнении на компьютере с Intel команд, захваченных в системе с AMD получается тот же баг.
• Это определённо даёт нам понять, что разница вызвана не отличиями в том, как выполняются команды (а именно так и получаются специфичные для конкретных GPU баги), а в том, какие команды выполняются.

Другими словами, это почти точно не баг драйвера. Похоже, что входящие данные, подготавливаемые для GPU, каким-то образом искажаются 1 . Это и в самом деле очень редкий случай!

На этом этапе для нахождения бага необходимо обнаружить все расхождения между захватами. Это скучная работа, но иного пути нет.

После долгого изучения захваченных данных моё внимание привлёк вызов отрисовки целого тела персонажа:

В захвате Intel этот вызов выводит бОльшую часть тела персонажа вместе с освещением и текстурами. В захвате AMD он выводит сплошную чёрную модель. Похоже, мы взяли нужный след.

Первым очевидным кандидатом на проверку будут соответствующие текстуры, но с ними, похоже, всё в порядке и в обоих захватах они одинаковы. Однако странно выглядят некоторые константы пиксельных шейдеров. В них не только содержатся NaN (Not a Number), но они также есть только в захвате AMD:

1.#QO обозначает NaN

Выглядит многообещающе — часто бывает, что значения NaN вызывают странные графические артефакты. Довольно забавно, что в версии Mass Effect 2 для PlayStation 3 была очень похожая проблема в эмуляторе RPCS3, тоже связанная с NaN!

Однако не стоит пока слишком радоваться — это могут быть значения, оставшиеся от предыдущих вызовов и не используемые в текущем. К счастью, в нашем случае чётко видно, что эти NaN передаются в D3D для этой конкретной отрисовки…

…и используемый в этой отрисовке пиксельный шейдер ссылается на обе константы:

Похоже, обе константы берутся напрямую из Unreal Engine и, судя по их названию, они могут влиять на освещение. Бинго!

Тест в игре подтверждает нашу теорию — на машине с Intel вектор из четырёх значений NaN никогда не передаётся как константы пиксельного шейдера; однако на машине с AMD значения NaN начинают появляться сразу, как игрок входит в место, где ломается освещение!

Значит ли это, что работа сделана? Далеко нет, потому что обнаружение сломанных констант — только половина успеха. По-прежнему остаётся вопрос — откуда они берутся и можно ли их заменить? Во внутриигровом тесте замена значений NaN частично устранила проблему — уродливые чёрные пятна пропали, но персонажи всё равно выглядят слишком тёмными:

Почти правильно… но не совсем.

Учитывая то, насколько важными эти значения освещения могут быть для сцены, мы не можем остановиться на таком решении. Однако мы знаем, что на верном пути!

Увы, любые попытки отследить источники этих констант указывали на нечто, напоминающее поток рендера, а не истинное место передачи. Хоть отладка этого и возможна, очевидно, что нам нужно попробовать новый подход, прежде чем тратить потенциально бесконечное количество времени на отслеживание потоков данных между внутриигровыми и/или относящимися к UE3 структурами.

Часть 2 – Приглядимся внимательнее к D3DX

Сделав шаг назад, мы поняли, что ранее кое-что упустили. Вспомним, что для «исправления» игры нужно добавить в реестр одну из двух записей – DisablePSGP и DisableD3DXPSGP . Если предположить, что их названия говорят об их назначении, то DisableD3DXPSGP должен быть подмножеством DisablePSGP , причём первый отключает PSGP только в D3DX, а последний — и в D3DX, и в D3D. Сделав такое предположение, обратим своё взгляд на D3DX.

Mass Effect импортирует набор функций D3DX, компонуя d3dx9_31.dll :

Если бы я увидел этот список, не зная информации, полученной нами из захватов, то предположил бы, что вероятными виновниками могут быть D3DXPreprocessShader или D3DXCompileShader — шейдеры могли быть неверно оптимизированы и/или скомпилированы на AMD, но их починка может быть безумно сложной задачей.

Однако у нас уже есть знания, поэтому для нас из списка выделяется одна функция — D3DXMatrixInverse является единственной функцией, которую можно использовать для подготовки констант пиксельного шейдера.

Эта функция вызывается только из одного места в игре:

Однако… оно реализовано не очень хорошо. Краткое изучение d3dx9_31.dll показывает, что D3DXMatrixInverse не трогает выходные параметры и в случае невозможности инверсии матрицы (потому что входящая матрица вырожденная) возвращает nullptr , однако игру это совершенно не волнует. Выходная матрица может остаться неинициализированной, ай-яй! На самом деле инвертирование вырожденных матриц происходит в игре (чаще всего в главном меню), но что бы мы ни делали для того, чтобы игра обрабатывала их лучше (например, обнуляли выходные данные или присваивали им единичную матрицу), графически ничего не менялось. Вот так дела.

Опровергнув эту теорию, мы вернулись к PSGP — что же конкретно PSGP делает в D3DX? Рафаэль Ривера изучил этот вопрос, и логика этого конвейера оказалась довольно простой:

Если PSGP не отключен, то D3DX выбирает функции, оптимизированные под использование конкретного набора команд. Это логично и возвращает нас к исходной теории. Как оказалось, в D3DX есть функции, оптимизированные под AMD и набор команд 3DNow!, поэтому игра, в конечном итоге, всё-таки косвенно их использует. Современные процессоры AMD, в которых отсутствуют команды 3DNow!, идут по тому же пути, что и процессоры Intel – то есть, по intelsse2 .

• При отключении PSGP и Intel, и AMD проходят по обычному пути выполнения кода x86 .
• Процессоры Intel всегда проходят по пути кода intelsse2 2 .
• Процессоры AMD с поддержкой 3DNow! проходят по пути выполнения кода amd_mmx_3dnow или amd3dnow_amdmmx , а процессоры без 3DNow проходят по intelsse2 .

Получив эту информацию, мы выдвинем гипотезу — вероятно, что-то не так с командами AMD SSE2, и результаты инвертирования матрицы, вычисляемые на AMD по пути intelsse2 , или слишком неточны, или полностью неверны.

Как нам проверить эту гипотезу? Тестами, естественно!

P.S.: Вы можете подумать «в игре используется d3dx9_31.dll , но последняя библиотека D3DX9 имеет версию d3dx9_43.dll , и, скорее всего, эту ошибку устранили в более новых версиях?». Мы попробовали «проапгрейдить» игру, чтобы она компоновала самую новую DLL, но ничего не изменилось.

Часть 3 – Независимые тесты

Мы подготовили простую независимую программу для проверки точности инвертирования матриц. На протяжении короткой игровой сессии в месте возникновения бага мы записали все входящие и выходящие данные D3DXMatrixInverse в файл. Этот файл считывается независимой тестовой программой, а результаты пересчитываются заново. Для проверки правильности выходные данные игры сравниваются с данными, вычисленными тестовой программой.

После нескольких попыток на основании данных, собранных с чипов Intel и AMD со включенным/отключенным PSGP мы сравнили результаты разных машин. Результаты показаны ниже с указанием успешных (, результаты равны) и ошибочных (, результаты не равны) прогонов. В последнем столбце указано, обрабатывает ли игра данные правильно, или «глючит». Мы намеренно не учитываем неточность вычислений с плавающей запятой и сравниваем результаты при помощи memcmp :

Источник данных	Intel SSE2	AMD SSE2	Intel x86	AMD x86	Приняты ли данные игрой?
Intel SSE2	️				️
AMD SSE2		️
Intel x86			️	️	️
AMD x86			️	️	️

Результаты тестов D3DXMatrixInverse

Любопытно, результаты демонстрируют, что:

• Вычисления с SSE2 не переносятся между машинами с Intel и AMD.
• Вычисления без SSE2 переносятся между машинами.
• Вычисления без SSE2 «принимаются» игрой, несмотря на то, что отличаются от вычислений на Intel SSE2.

Поэтому встаёт вопрос: что же конкретно не так с вычислениями с AMD SSE2, из-за чего они приводят к глитчам в игре? У нас нет на него точного ответа, но похоже, что это результат двух факторов:

• Реализация D3DXMatrixInverse на SSE2 может быть плохой численно — похоже, некоторые команды SSE2 дают разные результаты на Intel/AMD (вероятно, из-за разных режимов округления), а функция написана так, что не может устранять эти неточности.
• Код написан таким образом, что он слишком чувствителен к проблемам с неточностью.

На данном этапе мы уже готовы создать исправление, которое заменит D3DXMatrixInverse на переписанную x86-вариацию функции D3DX, и на этом закончить. Однако у меня возникла ещё одна случайная мысль — D3DX устарел и был заменён на DirectXMath. Я решил, что если уж мы всё равно хотим заменить эту матричную функцию, то можно поменять её на XMMatrixInverse , которая является «современной» заменой функции D3DXMatrixInverse . В XMMatrixInverse тоже используются команды SSE2, то есть она будет такой же оптимальной, как и с функцией из D3DX, но я был почти уверен, что ошибки в ней будут такие же.

Я быстренько написал код, отправил его Рафаэлю, и…

Он отлично заработал! (?)

В конечном итоге, то, что мы считали проблемой, возникающей из-за небольших отличий команд SSE2, может быть исключительно численной проблемой. Несмотря на то, что XMMatrixInverse тоже использует SSE2, она дала идеальные результаты и на Intel, и на AMD. Поэтому мы заново прогнали те же тесты и результаты оказались неожиданными, если не сказать больше:

Источник данных	Intel	AMD	Приняты ли данные игрой?
Intel	️	️	️
AMD	️	️	️

Результаты тестов с XMMatrixInverse

Игра не только хорошо работает, но и результаты идеально совпадают и переносятся между машинами!

Учтя это, мы пересмотрели свою теорию о причинах бага — без всяких сомнений, в нём виновата игра, слишком чувствительная к проблемам; однако после проведения дополнительных тестов нам показалось, что D3DX писался под быстрые вычисления, а DirectXMath больше волнует точность вычислений. Это выглядит логично, ведь D3DX — продукт 2000-х и вполне разумно, что его основным приоритетом была скорость. DirectXMath был разработан позже, поэтому авторы могли уделить больше внимания точным, детерминированным вычислениям.

Часть 4 – Соединяем всё вместе

Статья оказалась довольно длинной, надеюсь, вы не устали. Подведём итог тому, что мы сделали:

• Мы убедились, что игра не использует команды 3DNow! напрямую (их используют только системные DLL).
• Мы выяснили, что отключение PSGP устраняет проблему на процессорах AMD.
• При помощи PIX мы нашли виновника — значения NaN в константах пиксельного шейдера.
• Мы нашли источник этих значений — D3DXMatrixInverse .
• Мы изучили эту функцию и выяснили, что она не даёт одинаковых результатов на процессорах Intel и AMD, когда используются команды SSE2.
• Мы случайно обнаружили, что XMMatrixInverse не имеет этого недостатка и является вполне достойной заменой.

Единственное, что нам осталось реализовать — правильную замену! Здесь на сцену выходит SilentPatch for Mass Effect. Мы решили, что самым чистым решением этой проблемы будет создание подменной d3dx9_31.dll , которая будет перенаправлять все экспортированные Mass Effect функции на системную DLL, за исключением функции D3DXMatrixInverse . Для этой функции мы разработали замену на основе XMMatrixInverse .

Заменная DLL обеспечивает очень чистую и надёжную установку, она отлично работает с версиями игры с Origin и Steam. Её можно использовать сразу, без необходимости ASI Loader или любого другого стороннего ПО.

Насколько мы понимаем, теперь игра выглядит так, как должна, без малейшего ухудшения освещения:

Загрузки

Модификацию можно скачать в Mods & Patches. Нажмите сюда, чтобы сразу перейти к странице игры:

После скачивания достаточно извлечь архив в папку игры, и на этом всё! Если не знаете, что делать дальше, то прочитайте инструкции по настройке.

Полный исходный код мода опубликован на GitHub и его можно свободно использовать как отправную точку:

Источник