Эмуляторы Nintendo 64
 
 


...Используя эмуляторы N64 вы не получаете никакого представления о консоли. Не существует эмулятор, который приближался бы по качеству и скорости к самой N64. Подавляющее большинство эмуляторов написано студентами/любителями как хобби. Все эмуляторы никак не передают аналоговый джойстик N64, лишь частично эмулируют звуковые/графические возможности консоли, не передавая верную фильтрацию текстур, полноэкранный антиалиасинг, верное освещение, туман, дымку, правильную гамму цветов и многие, многие остальные эффекты. Они работают очень поверхностно. Большинство игр/демо на реальном N64 работают плавно, со скоростью в лучшем случае 50/60 fps или 25/30 fps в худшем.

Консоль N64 архитектурно очень сложна и для создания качественного полноценного эмулятора требуются изрядные человеческие ресурсы, деньги, время.

Рассказывая про эмуляторы, я хочу предупредить, что мой интерес и смысл этого сайта - Scene, Demo Design, Reverse Engineering, а не игры. Поэтому я рассматриваю эмуляторы со своей точки зрения. Возможно, что для игр вы предпочтете не те эмуляторы которые я расхваливаю.

Какие существуют эмуляторы?

Эмуляторов N64 на удивление много, я насчитал порядка 25 штук, причем, это вероятно не все:

Nemu
Daedalus
1964
Apollo
Blade64 (based on trwingl)
Blur
Corn
Dream64
MiGen64 (Based on Dream64)
N64VM
Nin64
Nincest(dos,win)
NSFE
Pagan
Pc64
Pretendo64
Project64
Project Unreality
Sunset
TR64
TrWIN
Ultra64
VirtualReality
UltraHLE
Sixty-force (Low level)

Из этого списка реально работающих эмуляторов и пригодных для запуска игр немного. Для запуска Demo пригоден, практически только один Nemu64. Некоторые из этого списка лишь зачатки эмуляторов, запускающие всего лишь пару заставок игр. Их авторы отступились от сложной задачи - создания полноценного эмулятора N64.

Вероятно, самым первым эмулятором N64 был Project Unreality. Он и явился основой всех остальных эмуляторов.

Первым успешным эмулятором запускающим не только демо или заставки игр, был UltraHLE (Ultra High-Level-Emulator). UltraHLE сделал возможным запуск коммерческих игр - сначала SuperMario 64, и через некоторое время, второго хита The legend of Zelda. Это стало возможным потому что авторы ставили целью только запуск нескольких хитовых игр, а не полную и точную эмуляцию железа N64. Они постепенно довели недостающую эмуляцию до достаточного уровня (чтобы работало).
Ultrahle был написан только для Voodoo-I и использует только Glide API. Но его можно запустить и под эмуляцией самой Glide, с так называемым Glide-wrapper`ом. UltraHLE рекомпилирующий эмулятор.

UltraHLE использовал для сохранения специфичных для данной игры настроек формат INI-файла windows. Ini-файл это обычный текстовый файл в виде "имя=значение". Через некоторое время многие фанаты сцены подобрали настройки ini-фала и для других игр. Обнаружилось что играбельны Waverace, MarioKart, Doom64, Quake64 и частично играбельны еще некоторые. С тех пор все авторы эмуляторов стали использовать формат INI-файла для сохранения специфичных настроек.
Все эмуляторы имеют свой особенный набор настроек и их ini-файлы несовместимы. К великому сожалению, UltraHLE не получил дальнейшего развития, его авторы заявили что они лишь ставили целью доказать возможность запуска коммерческих игр и, к сожалению, ушли со сцены. А жаль, вероятно, если бы они продолжали разработку, то в настоящий момент им не было бы равных. Авторы UltraHLE так и не опубликовали исходники. Неясно, почему же все-таки они ушли со сцены, написав такой удачный по тем временам (1998) эмулятор. Возможно, на них как-то повляла Nintendo? Ведь то время конкурентов UltraHLE не было.
UltraHLE оставил в подарок прекрасный внутренний дебаггер. Этот дебаггер скрытый, но его можно активизировать программой UltraHlp пропатчив файл UltraHLE. Некоторые технические детали работы UltraHle вы найдете здесь.
В UltraHLE есть небольшой, широкоизвестный глюк - в пути к файлам эмулятора не должно быть пробелов, иначе он не запускается, но task manager показывает что он загружен. Рекомендуется ограничится путями как в DOS.

Были и другие последователи эмуляции N64, идущие по пути HLE. Я не буду останавливаться на отдельных проектах и назову самые удачные в настоящее время (июнь 2001).

Nemu, эмулятор написаный на Delphi и ассемблере.
Он наиболее точно эмулирует железо и на нем запускаются большинство игр и почти все демо(!). Nemu, по крайней мере, запускает все то что запускают другие эмуляторы. С другой стороны, иногда то что работает на Nemu, не работает у других и, порой, вообще не запускается. Это единственный эмулятор на котором стоит пытаться смотреть Demo`s.
Nemu не очень быстр, и в последнее время также старается использовать разные трюки для увеличения скорости работы, что пагубно сказывается на совместимости. Но он обладает минимумом настроек и устойчив. Его авторы хорошо известные LaC (америка) и Lemmy (германия). Lac один из старейших сценеров и активен в настоящее время. Он оказал очень большое влияние на совместимость Nemu, точность эмуляции да и на N64 сцену в целом. К сожалению, и Lac и Lemmy недолюбливают эмуляторы с открытыми исходниками и никогда никому не давали свой эмулятор с дебаггером, а дебаггер у них, по всей вероятности, должен быть весьма развит. Найти эмулятор можно на официальном сайте. У Nemu версии 0.7a заметен глючок - иногда отсутствие текстур на некоторых ромах или отдельных обьектах игры/demo.

Следущий эмулятор представляющий интерес это Daedalus. Он активно развивается автором и доступен в виде OpenSource. Я даже выполнил трансляцию его ресурсов на русский язык. Его несомненным плюсом является дебаггер. Но daedalus проигрывает в совместимости Nemu. На нем запускаются лишь те ромки, которые так или иначе используют стандартные библиотеки Nintendo. Поэтому большинство Demo и даже крошечные Intro не запускаются. По-моему, не до конца выполнен не только RCP, но и R4300. Исходники Daedalus очень сложны (1,73Mb MSVC++ текста и примерно 59 000 строк). Так что пока автор не сделает внятное описание структуры итд, браться за исходники смысла нет.

1964 представляет интерес также ввиду открытого кода и его исходники в сравнении с daedalus попроще. Но дебаггер, куда слабее daedalus и выполнен оконным windows gui.

Совсем на днях появился новый эмулятор, Project 64 (PJ64), написаный Zilmar and Jabo, вернувшимися к эмуляции N64 после длительной паузы. Как заявляется, он имеет самую высокую отимизацию кода R4300 и RCP и что самое важное, поддерживает множество эффектов (Mario или Zelda) которые не видны на остальных эмуляторах.
(С другой стороны, в Zelda у меня были крупные ошибки с текстурами). Для запуска Demo`s он все еще малопригоден. Хотя, PJ64 многообещающий проект. Его код написан с активным использованием MMX и SSE команд.

Из эмуляторов пригодных к рассмотрению и развиваемых в настоящее время упомяну еще TRWin, (TRWinGL), Apollo, Blade. Но я особо не экспериментировал с ними, вероятно, в плане скорости/совместимости ничего выдающегося среди них нет.

Есть информация, что эмулятор Sixty-Force поддерживает как можно более низкоуровневую эмуляцию на уровне RSP/RDP.

Особо упомяну эмулятор Corn. Его отличительной особенностью является то что он очень и очень быстр, раза в два-три быстрее остальных эмуляторов. Этот эмулятор отказался в каком-либо виде запускаться на моей машине под Windows2000, но после некоторых шаманств заработал под английской Windows98se (second edition). Mario64 работает на нем на 70 или более fps. Скорее всего, он будет у вас очень удовлетворительно работать на машинах наподобие Pentium-100 или Amd-120. Но он нестабилен сам по себе и работает только в глубине цвета 16bit (65536 цветов). В отдельных случаях запустить его мне так и не удалось. Написан он на Delphi и MSVC++.
Corn выполняет статическую, а не динамическую рекомпиляцию кода, поэтому он так быстр. К сожалению, новых версий эмулятора не было уже год, и ContraSF исчез из поля зрения, не отвечает на письма.

Советы.

- отключайте в эмуляторах вертикальную синхронизацию, (VSync, VI, Vertical Blank). Тогда эмулятор не будет ждать вертикальной развертки PC, что при 20-25 fps не имеет никакого смысла и будет работать быстрее. Некоторые эмуляторы чувствительны к глубине цвета экрана, настройкам DirectX и OpenGL. Почему так мне не ясно, по идее, настройки видеопараметров windows влиять никак не должны. Тем не менее, они влияют. Рекомендую использовать настройки по умолчанию.
После краха программы, многие эмуляторы продолжают оставаться в памяти, т.е. процесс остается запущенным, хотя никаких окон нет. Это хорошо видно по WinNt taskmanager`у. В конце концов, даже Nemu удавалось завешивать звук моей системы при его некорректном завершении или завершении во время эмуляции. (После этого Windows2000 помогал только hardware reset).

Как работают эмуляторы?


Эмуляция N64 стала возможна только из-за трюка называемого HLE - High Level Emulation, высокоуровневая эмуляция.
Для того чтобы обьяснить как работает HLE, нам нужно посмотреть, как вообще может быть построен эмулятор того или иного микропроцессорного устройства.
Вероятно, мы должны проэмулировать всю электронику, верно? - В случае простейших машин - Commodore64, Sinclair ZX-Spectrum, Nes(денди), Yamaha MSX все так и делается. Полностью эмулируется работа микросхем. Что делает микропроцессор того же Sincalir ZX-Spectrum? Если подумать, то оказывается, что он всего лишь... считывает память и модифицирует ее! То есть, для того чтобы написать эмулятор, мы должны написать такой алгоритм, который будет действовать как микропроцессор. Для того чтобы проэмулировать видеоконтроллер мы должны просто показывать в виде видеоизображения часть памяти (экранную область) эмулируемой машины.
Увы! В случае с N64 ничего не получится! Внутри параллельно работают несколько микропроцессоров- центральный процессор, математический процессор, RSP, векторный процессор, RDP! Скорость эмуляции всех устройств даже на современных P-III с тактовыми частотами близкими к 1 Ghz составляет всего лишь 2-3 кадров в секунду. А это уже не анимация, а слайд-шоу ;) Это о-о-о-чень медленно. Играть с такой скоростью невозможно.
В 1997-1998 годах, когда создавались первые эмуляторы N64, таких мощных процессоров как сейчас, вообще не было. Но выход был найден.

Основную суть HLE можно выразить следущими словами : "я не знаю что там внутри и как это работает, но я создам такой же результат своим способом".

Игры Nintendo пишутся на основе большой Си-библиотеки. Эта библиотека является, по сути, целой операционной системой. Игра работает по отношению к операционной системе как клиент. Та предоставляет игре состояние всего железа. Это очень, очень важный ключевой момент - обратите внимание, между игрой и железом есть прослойка в виде игровой библиотеки. Так вот, при обращении игрового алгоритма к этой прослойке, то есть к специфичным функциям игровой библиотеки, они не выполняются виртуальным процессором! Они выполняются искусственно, извне, программистом эмулятора. Для этого он переписывает их, делает свою реализацию. Примеров таких функций очень много - это аллоцирование памяти, переключение потоков, опрос джойстиков, чтение ROM и так далее. (В случае эмулятора UltraHLE, даже центральный процессор не был полностью проэмулирован, каких-то инструкций не встречающихся в Mario64 у него вообще не было и нет.)
Наиважнейшим моментом для реализации HLE является способ, которым строится изображение на экране Nintendo 64.
Игровой алгоритм составляет Display List, список команд для построения графики. Потом Display List передается Reality Co-Processor(RCP) и тот строит изображение. RCP делится на RSP и RDP. RSP это RISC процессор с векторным со-процессором, а RDP это просто растеризатор, обрабатывающий результаты работы RSP, которые тот записывает в DMEM. RSP содержит 4 килобайта очень быстрой программной памяти, в которой находится алгоритм в виде микрокода обработки displaylist-а. Этот микрокод вращает с помощью векторного сопроцессора вершины треугольников, производит вычисление освещенности в вершинах, и формирует команды для растеризатора, коим является RDP.
Так вот, HLE-способ эмуляции полностью перехватывает этот процесс еще на этапе передачи displaylist. Нет программной эмуляции ни RSP, ни RDP. Эмулируется само выполнение displaylist-ов, вот в чем дело. К сожалению, у данного способа эмуляции есть грандиозный недостаток - он привязан к формату displaylist`ов. Некоторые игры используют свои версии микрокода и по-своему интерпретируют displaylist`ы. Вот почему в эмуляторах вы можете встретить выбор разных версий u-code или microcode (это одно и тоже). Это просто выбор способа интерпретации displaylist`ов.

Было бы верным сказать - даже на современных компьютерах практическая эмуляция без HLE невозможна. Слишком низкая скорость.

Какая машина должна быть для запуска эмуляторов?


Это должна быть вычислительно как можно более мощная PC. Для игр Оптимальный вариант - P3-600, video 16-32 mb, ram 128, звуковая карта любая, DirectX 8, Win98. Проверено.
Для Demos я пробовал вариант PIII-1gHz, GeForce-II и особо не вдохновился скоростью эмулятора Nemu64 (ver.07) в такой конфигурации...

OpenGl или DirectX?

С технической точки зрения проще программировать OpenGL. То что он может сделать, он сделает. Но DirectX по внутренним идеологическим соображениям Microsoft работает быстрее чем OpenGL. OpenGL ближе к архитектуре RCP, потому что игры пишутся на некотором аналоге OpenGL. Да и портируемость у OpenGL гораздо выше - как вы понимаете, ни Mac, ни Linux, ни BeOs не предоставляют DirectX.
Для эмуляторов Zelmar разработал общую спецификацию Plugin-ов, транслирующих дисплейлисты графики и звука. Те из авторов эмуляторов, кто поддерживают эту спецификацию plug-ins, в значительной мере популяризуют свои эмуляторы и освобождают себя от необходимости писать большую часть эмулятора, находящуюся в Plug-in.

На чем написаны эмуляторы?

Это Microsoft Visual C++, Delphi, Assembler.
Исходные коды некоторых эмуляторов можно достать на сайтах их поддержки. Вероятно, большинство эмуляторов пошли от Project Unreality и дальше зажили своей жизнью.

Какие есть проблемы?

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

 
 
Disclaimer
 
Hosted by uCoz