|
Эмуляторы
Nintendo 64
|
|||||||||||||||||||||||||||
|
Какие существуют эмуляторы? Эмуляторов N64 на удивление много, я насчитал порядка 25 штук, причем, это вероятно не все:
Из
этого списка реально работающих эмуляторов и пригодных для запуска игр
немного. Для запуска Demo пригоден, практически только один Nemu64.
Некоторые из этого списка лишь зачатки эмуляторов, запускающие всего
лишь пару заставок игр. Их авторы отступились от сложной задачи - создания
полноценного эмулятора N64. UltraHLE
использовал для сохранения специфичных для данной игры настроек формат
INI-файла windows. Ini-файл это обычный текстовый файл в виде "имя=значение".
Через некоторое время многие фанаты сцены подобрали настройки ini-фала
и для других игр. Обнаружилось что играбельны Waverace, MarioKart, Doom64,
Quake64 и частично играбельны еще некоторые. С тех пор все авторы эмуляторов
стали использовать формат INI-файла для сохранения специфичных настроек.
Были
и другие последователи эмуляции N64, идущие по пути HLE. Я не
буду останавливаться на отдельных проектах и назову самые удачные в
настоящее время (июнь 2001). Следущий эмулятор представляющий интерес это 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) которые не видны на остальных эмуляторах. Из
эмуляторов пригодных к рассмотрению и развиваемых в настоящее время
упомяну еще TRWin, (TRWinGL), Apollo, Blade. Но я особо не экспериментировал
с ними, вероятно, в плане скорости/совместимости ничего выдающегося
среди них нет. Особо
упомяну эмулятор Corn. Его отличительной особенностью является то что
он очень и очень быстр, раза в два-три быстрее остальных эмуляторов.
Этот эмулятор отказался в каком-либо виде запускаться на моей машине
под Windows2000, но после некоторых шаманств заработал под английской
Windows98se (second edition). Mario64 работает на нем на 70 или более
fps. Скорее всего, он будет у вас очень удовлетворительно работать на
машинах наподобие Pentium-100 или Amd-120. Но он нестабилен сам по себе
и работает только в глубине цвета 16bit (65536 цветов). В отдельных
случаях запустить его мне так и не удалось. Написан он на Delphi и MSVC++.
Советы.
- отключайте в эмуляторах вертикальную синхронизацию, (VSync, VI, Vertical
Blank). Тогда эмулятор не будет ждать вертикальной развертки PC, что
при 20-25 fps не имеет никакого смысла и будет работать быстрее. Некоторые
эмуляторы чувствительны к глубине цвета экрана, настройкам DirectX и
OpenGL. Почему так мне не ясно, по идее, настройки видеопараметров windows
влиять никак не должны. Тем не менее, они влияют. Рекомендую использовать
настройки по умолчанию. Как работают эмуляторы? Эмуляция 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. На чем написаны эмуляторы? Это
Microsoft Visual C++, Delphi, Assembler. Какие есть проблемы? Это
скорость, точность эмуляции. По понятным причинам ни то ни другое не
находится в совершенстве ни у одного эмулятора. С моей точки зрения,
проблемы у авторов эмуляторов в том что они каждый разрозненно делает
свой эмулятор. При этом если исходный код открыт, он плохо задокументирован.
В тех исходных кодах что я наблюдал, мало уделено внимания ассемблеру,
профилировке кода на скорость. Почти все эмуляторы страдают с синхронизацией/эмуляцией
звука. |
|||||||||||||||||||||||||||