Project64 User Manual (compiled HTML help file)

 Project64 User Manual

Welcome to Project64 and congratulations on finding the help file ;) Hopefully you will be using this document as a first port of call before venturing online to seek help.

New users are encouraged to read through this document (or as much of it as you can stomach) before using the program. Project64 is a complex piece of software trying very hard to look like a simple piece of software. Reading this file could save you time in the long run. It's probably a good idea to familiarise yourself with the known issues at the outset, so you aren't left wondering how to fix un-fixable things!

There are a few conditions attached to the use of this file (doesn't concern people who just read it!).

There is a glossary of terms and a search feature provided.

Hope you have as much fun using Project64 as we had making it :)


Project64 help file introduction

 Introduction to Project64

This section will take you through the basics - things that everyone should be aware of before they start to use Project64, and before reading further into this file.

Please select a topic.


 What is Project64?

Project64 (hereon also referred to as simply "the emulator" or "the software") is a software package designed to emulate a Nintendo64 video game system on a Microsoft Windows based PC. This means that it creates an environment on your PC under which real N64 software can run and be played in much the same way as it would be on the original hardware system.

Due to the difficult nature of this task, lack of complete system documentation, and time and resource restrictions, this is achieved with varying degrees of success, depending on factors including the specific game, the configuration of the emulator, the specification and configuration of the host system, and the inherent limitations of the emulator.

If you meet all the requirements and follow the advice contained in this documentation it should be possible for you to enjoy a wide selection of games, even perhaps with superior graphics and extra features compared to the original system.


 Terms & Conditions

The Project64 terms and conditions are detailed in the authors' document, README.TXT, which is in your Project64 folder. Please read that document now if you have not already.

To clarify some points:

  • You may NOT repackage Project64 (add, remove, alter files) without the authors' permission - this INCLUDES distribution of Jabo's and Zilmar's plugins seperately - they are a part of Project64. It's also best for users if they get the complete package and documentation. You are welcome to distribute the original archive as long as you do not charge for it.
  • About the source code: The license does NOT require you to publicly release the source to any binaries that you made using Project64 source code. The Project64 authors ask only that you send them a copy of the modified source if they ask for it.

About this file: This document only covers official Project64 releases, and was written by Smiff for the official Project64 v1.5 release. Any other versions of Project64 available may differ in any number of ways, and this help file may not apply - please refer to the documentation included with them.

GUI text referred to in this document may differ from what you actually see in the emulator, depending on your language options and translations file you have installed. I have referred to my own text, which is available by making "English alternative" your language choice ("English" is the original application GUI text).

Anyone may translate and distribute the translation of part or all of this documentation for the purpose of assisting Project64 users who do not read English. Try to preserve the original meaning of the text as far as possible (do not add or subtract without clear annotation) and credit the source.

Thank you for respecting all this.


 What's included

Project64 v1.5 was released as a self extracting compressed archive. We recommend you download Project64 from the Project64 homepage (see Web Links) or an official mirror to be sure you have the complete and unaltered package.

In simple terms, you get:

  • the application
  • the settings files (.rdb, .cht, .rdx etc.) and some language files
  • 3 audio plugins (one is a dummy "No Sound" plugin)
  • 1 video plugin
  • 3 input plugins (two are 3rd party)
  • 1 RSP plugin
  • the plugin specifications (for plugin developers)
  • authors' readme and whatsnew text files
  • documentation folder containing contributors' docs
  • scripts to uninstall Project64
  • this manual!

You do not get any games included! Do not ask us for games! See this page.

Some of the Project64 source code is available as a seperate download from the official site (see Web Links).


System Requirements Index

 Project64 System Requirements

This section explains the system requirements for Project64.

Please select a topic.


 Project64 Minimum System Specification

This specification will be sufficient for you to enjoy most compatible games with good graphics, sound and control, subject to correct configuration and some limitations of the emulator. You are likely to suffer some performance problems, and you will not be able to use all the options in the emulator. Consider using some 3rd party plugins (see Web Links)

  • Intel Pentium 3 700Mhz or AMD Athlon 800Mhz CPU*
  • 128MB system RAM
  • 200MB free hard drive space
  • additional 20MB-100MB free hard drive space per game, depending on game and number of saves you make
  • 100% Microsoft DirectX 7 compatible video, sound and input devices**.
  • Microsoft Windows 98
  • Microsoft DirectX 7 (default plugins), DirectX 8 (all included plugins)

*the plugins contain SSE optimisations, early Athlons did not have SSE.

**The video device must be a primary device, have at least 16MB local memory and two texture units. Depending on the features supported by your video card some content may not be displayed correctly and thus some games marked as compatible may suffer glitches or not be playable on your system. The exact features required vary from game to game.

nVidia GeForce256 and ATI Radeon (early models) are suggested as realistic minimum video hardware. In conjunction with good quality drivers they have the required features. Newer cards mainly allow better resolutions, filtering, anti-aliasing and so on.

The following chipsets (thus any and all graphics cards based on them) can be considered below minimum specification:

  • 3dfx Voodoo 1,2,3 (1,2 - not at all, 3 - poor image quality)
  • ATI Rage128, Rage Pro (poor image quality)
  • Intel i740, i810 (poor image quality)
  • Matrox G200, G400, G450 (poor image quality)
  • nVidia Riva128 (poor image quality)
  • S3 Savage 4, Savage 2000 (particularly bad, these cards hang)

An explanation of why these cards are not capable of producing good quality images in Project64.

You may find that Project64 usable on a lower-specification system than described here, particularly with some games and careful configuration. If so then enjoy, but please don't expect too much.


 Project64 Recommended System Specification

This specification should allow you to play any game with good speed, graphics, sound and control, subject to the limitations of the emulator. Note that this specification is still not sufficient for every option available, but with proper configuration you shouldn't have significant limitations.

  • Intel Pentium 3 1.2Ghz or higher or AMD Athlon 1.2 GHz or higher
  • 256MB RAM or more
  • nVidia GeForce3 or later or ATI Radeon or later
  • 1GB or more free hard drive space
  • Creative Soundblaster Live! or higher
  • Wishtech Adaptoid and original Nintendo N64 controller for each player
  • Microsoft Windows 2000/XP

Optional extras:

  • video card with TV out and a high quality television set
  • high quality stereo speakers
  • USB hub and/or controller extension cables
  • genuine Nintendo Rumble Pak for each player


 Feature Lists

This page is intended for more advanced/curious users only, if you meet the recommended system requirements then you already have everything covered and don't need to worry about this!

Project64 is compiled with Microsoft Visual Studio .NET with 6th gen, CPU ("Pentium Pro") optimisations and compressed.

Project64 uses the following extended CPU instruction sets if they are detected on your system:

  • MMX
  • SSE
  • 3Dnow!

....mostly in the video plugin and RSP. The emulator is tested to run without any of these intructions, but a minimum of MMX is recommended (any CPU without MMX is likely to be too old/slow to run Project64 well anyway).

The emulator makes heavy use of the FPU and requires a strong FPU to perform satisfactorily (so for example the AMD K6 series is not a good choice, but the K7 is an excellent choice). MMX etc. does not in any way make up for a weak FPU.

Jabo's Direct3D plugins use the following TextureOpCaps (your hardware and drivers must support all these features for good quality emulation, exactly which are used varies from game to game).

  • DISABLE
  • SELECTARG1
  • SELECTARG2
  • MODULATE
  • MODULATE2X
  • MODULATE4X
  • ADD
  • ADDSIGNED
  • ADDSIGNED2X
  • SUBTRACT
  • ADDSMOOTH
  • BLENDDIFFUSEALPHA
  • BLENDTEXTUREALPHA
  • BLENDFACTORALPHA
  • BLENDTEXTUREALPHAPM
  • BLENDCURRENTALPHA
  • MODULATEALPHA_ADDCOLOR
  • MODULATECOLOR_ADDALPHA
  • MODULATEINVALPHA_ADDCOLOR
  • MODULATEINVCOLOR_ADDALPHA

You can see which your hardware supports by downloading and running the Microsoft DirectX Caps Viewer. I list these because at the time of release these features are not present in a large number of installed systems.

Most of the other requirements of the graphics plugin are already fairly standard, such as at ability to do at least two textures per pass (multipass was removed in v1.2 because it's not possible to render fog properly with it). Texture memory usage is very efficient and shouldn't be a concern, but at least 16MB graphics RAM is suggested. The Internal geometry pipeline makes extensive use of SSE, and some (less effective) use of 3Dnow! It is important to have hardware clipping support if you use the internal pipeline (as by default) because it's not part of the software engine. Note that lighting is always done internally regardless of pipeline.

The performance of primary framebuffer emulation very much depends on how fast your hardware is at certain memory copy operations, and these are something not normally used by computer games - we have found Matrox to be unusually fast at this (despite the poor 3d feature set) and nVidia relatively slow, at the time of writing... you need a very fast system for such framebuffer use to be viable.

The OpenGL plugin (not included in v1.4+) requires an nVidia (TNT or higher) card because it uses proprietary extensions (not part of OGL 1.2/1.3 spec). The plugin is mostly an experiment and demonstration, there are very few times when the end user will find it better than the Direct3D. This is not because one API is inherently superior to the other, but rather the path the developer chose.

Secondary video devices (e.g. 3dfx Voodoo1/2) are not supported at all.

The default audio plugin uses DirectSound and is thus (in theory!) not fussy about sound cards.

The default input plugin uses DirectInput and is thus (in theory!) not fussy about choice of input device, however, it doesn't support all possible DX controls - N-Rage's input plugin (3rd party, included) supports more controls.


 Project64 Installation

This section will guide you through the addition and removal of Project64 on your system.

Please select a topic.


 Preparing your system for Project64

Ideally do this before you start using Project64, if you haven't, please read this page now anyway.

Make sure you have a clean and stable system, which means:

  1. Have all the latest drivers intalled for all your hardware, especially video hardware.
  2. Have as few applications running as possible - the emulator needs a lot of resources, the more you free the better it will perform.
  3. Defragment your hard drive - this could speed ROM loading and improve swapfile performance.
  4. Temporarily disable any virus checkers or scheduled tasks - if these start while you're playing performance could suffer badly

If you know your PC is not stable generally (maybe it locks up occasionally while playing PC games, or applications quit or crash for no apparent reason), stop right here and get it fixed! The emulator pushes system components hard and although it will not cause any damage, any existing stability problems that your PC may have are likely to show up when you start using the emulator.


 Standard Installation

Since you are reading this, you've probably done this already, but I'll include it here for the sake of completeness.

Project64 is provided as a self extracting archive. This is very simple, there is no install (or uninstall) program.

  1. Double click the install file.
  2. Enter the path on your hard drive where you would like Project64 to reside (or use the default path, which is in Program Files) and press to extract.
  3. That's it! Run Project64.exe directly (by browsing to the path you choose above) or with a shortcut.

All the necessary files to get you started and playing N64 games are included (apart from the games themselves!).

You will be asked to choose a language (read more about this here).

If you are not sure what to do next, please refer to the Using Project64 section of this manual.


 Installing games (ROMs)

N. B. There are no games supplied with Project64! It is your responsibility to acquire games. The Project64 team cannot help you find commercial games, for legal reasons. Requests for ROMs are not welcome in official Project64 areas of the Internet.

To use a game in Project64, the ROM file of that game simply needs to be available locally on your system. This could be your hard drive (recommended) or a CD-ROM or other removable media (since removable media is generally slower, loading times will increase but performance of the emulation itself will not be affected). It is not recommended to try to load games across a network, because apart from the increased time taken, there are possibilities of corruption, although this has been found to work.

It is essential that you use a ROM verification utility to scan all your ROMs. Project64 absolutely requires 100% good images... hacked, corrupt, truncated etc. files are not supported.

To view a ROM or collection of ROMs in the Project64 ROM browser, simply tell Project64 where your ROMs are by selecting the folder via the File menu or by right clicking in the Browser.

Points:

  1. Make sure that your ROMs are either uncompressed or are compressed in standard Zip file format. No other file compression format is supported.
  2. The ROM file must have a standard N64 ROM file extension, such as .z64, .v64, .rom or in the case of a compressed ROM, one of these extensions inside a .zip file.
  3. The byte order of your ROMs is not important, Project64 can read all standard byte orders. Byte order makes no difference to emulation performance.
  4. If you are using zipped ROMs, there must be only one ROM per zip file, so compress your files individually (there are tools available to do this).
  5. If you want to arrange your ROMs in subfolders, you can choose the top level folder and enable the Directory Recursion option. Project64 will search through all the subfolders and list all the ROMs together for you.
  6. You cannot add ROMs in seperate trees. For example, if you have some ROMS on one hard drive and some more on another drive, you will have to pick one or move them together.
  7. There is no practical limit AFAIK to the number of ROMs you can have in your folder(s), except for the amount of storage space you have.
  8. Having zipped ROMs does not effect the speed a game runs at, only the loading time (which may actually be faster, depending on your system).


 Updating Project64 files

The first thing of course is to check you have the latest version of Project64 by visiting the official site. You may also find alternative versions of Project64 on other websites - see Web Links.

Check if any of the plugins have been updated, this could make a large difference to your results. Keep an eye on any 3rd party plugins included with Project64 that you are using, which may be be updated independantly of Project64.

Note: the "About INI files"dialog is only available in Advanced mode (see Options)

Aside from executable code (.exe and .dll files), Project64 uses several plain text files which are likely to be updated more frequently:

[language_name].pj.Lang - a Project64 translations/language file
 Updates to these file could correct errors in translations, new files could add additional languages for GUI text. All languages available in your \Lang folder are listed in and selected from the Language menu in the File menu. Add more languages by dropping more language files into this folder and restarting the application. See Web Links.

Project64.rdb - the Project64 ROM database
 Updates to this file could help you to get more games working by providing correct settings for each game, and by correcting mistakes in the settings for existing game entries. Updates may also assist you by improving user instructions in the Notes fields and correcting status designations. This is an important file to keep updated! See Web Links.

Project64.cht - the Project64 Cheat file/Cheat Code database
Updates to this file could add more cheat codes, correct existing cheat codes, remove cheat codes found to cause problems or not work, and improve notes for guidance. See Web Links.

Project64.rdx - the Project64 ROM database extension
Updates to this file can provide extra information for games in the ROM Browser, such as Genre. Only a basic example file was included with Project64, so if you interested in using this feature, see if someone has published a suitable file. See Web Links.

These files are collectively know as the "INI files", "settings files" or "support files" (because they support the application, rather than support the user). You can check which versions of the files you are using at any time and visit the authors' homepages (to look for updates) by going Help > About INI files

"Offical" vs. "Unofficial" releases
 A minority of the releases will be "Official" releases, which means they come from the authors or people nominated by them (probably the same people who produced the files that where included with Project64. Others releases are "Unofficial" (or, not official, they may not actually be marked "Unofficial"....), which means they could be from anyone.

People not familiar with the technical details of how these files work are encouraged to use Official releases as a means of quality assurance, but if you are confident then by all means use whatever you wish (or create your own).

A badly written file could render previously working game(s) unplayable, crash the emulator or just give incorrect feedback. It cannot do further damage to your system (e.g. they are just plain text and cannot carry viruses etc.). If in doubt, revert to the original files included with the emulator or the latest official ones (recommended). See Web Links for official file download locations.

Installing ini files
 These are installed simply by downloading and extracting/copying it to the root of your Project64 installed folder, overwriting the file already there (if one is already there). It would be sensible to backup that original file (simply rename it before you begin) so that you can revert to it if you find something does not work afterwards.

Some people may choose to release .reg files that contain configuration data for Project64 registry keys. This is discouraged - each user should take the time to understand and configure the software properly for their system - what is a good configuration for someone else may well not be right for you. In addition, there is a possibility of .reg files doing damage to your system, so you should only run them if obtained from trusted sources.

Install updated plugins in the same way as you would add any plugin to Project64. Usually the updated plugin will overwrite the older one - if you don't want this to happen, rename either the old or new version, and check with the authors' documentation whether two versions can be used concurrently, or whether the old version needs to be uninstalled first (some can, some can't, it depends on how they use the Windows registry).

N.B. Make sure all files you install are designed for your version of Project64! Using older or newer versions could cause severe problems and must be avoided! Before installing any file, compare the version number with the one you are currently using by going Help > About INI Files. After updating you can go Help > About INI Files to confirm that the new file is being used.


 Installing additional (3rd party) plugins

By "3rd party", we mean any plugin not written by Jabo or Zilmar, the Project64 authors.

Project64 uses an open plugin specification. This means that other people are free to write compatible plugins, which you might like to use in Project64 instead of the ones provided. These may be available standalone or taken from another emulator package - visit some quality websites or use a search engine.

You should first check that the plugin is to the Project64 specification (sometimes referred to as "Zilmar spec.") and to the correct version of the specification. Consult the plugin or emulator documentation if you are not sure.

Project64 is backwards compatible with all public versions of the specification up the date of its release. (It was not made forwards compatible because there is no way of knowing in advance how the specification might change).

If you attempt to install a plugin that is not to a suitable specification then it should not show up in the menus in Project64.

Extract the plugin (file ending .dll) and any support files it requires to the root of your Project64 plugin folder (by default, "\Plugin\" subfolder of your PJ64 folder). Start PJ64, go to Options > Settings > Plugins and select the new plugin from the appropriate list and press OK. If the plugin initialises (starts) correctly there will be no error message. Remember, if you are using third party plugins the standard Project64 compatibility lists and notes may no longer apply to you.

If you have problems with a plugin, please consult the appropriate author or group. The Project64 team is not in any way responsible for the performance of 3rd party plugins! Nor can we gaurantee the peformance of the application while using 3rd party plugins.


 Using Project64 plugins in other emulators

Please follow the instructions provided with the other emulator for installing plugins in that emulator.

If there is no mention of plugins, the other emulator almost certainly does not support plugins, and you cannot use the Project64 plugins with it.

If it does support Project64 plugins, you may be able to run the other emulator in your Project64 folder, or set both emulators to share a single plugins folder.

It is normally just a case of copy-pasting the plugins in the right place.

Notes

  1. Some of the Project64 plugins are designed to work with the Project64 RSP - the audio plugin will not produce any sound in other emulators, and the video plugin will not produce some particular forms of graphics... In Project64 the RSP is processing these things.
  2. Some of the Project64 plugins use the Project64 ROM database - you may wish to also copy Project64.rdb to the other emulator.
  3. Remember that the Project64 plugins will be sharing the same registry key(s) regardless of where they are on your hard drive or how many times you use them, so configuring them in any emulator will configure them in all emulators, and uninstalling Project64 may remove their registry settings - beware!


 Backing Up Project64

If you want to backup your Project64 installation (before formatting your hard drive for example) or move your Project64 installation to another computer etc., you need to know where all your personal settings are stored.

The Windows Registry is used for most application settings and plugin settings. You could save this data if you wanted to (athough its probably easier and quicker just to set up the application and plugins again) by exporting the relevant registry keys (function of Windows built in Registry Editor).

  • [-HKEY_CURRENT_USER\Software\JaboSoft\Project64 DLL]
  • [-HKEY_CURRENT_USER\Software\N64 Emulation]

Changes to ROM Settings are saved in the ROM Database (Project64.rdb) This applies to you if you have added any ROMs to the file or changed any entries for existing ROMs.

Any cheat codes you added are saved the Cheat Code file (Project64.cht), so back that up aswell if you want to keep them.

You input configuration can be exported to a file (see input plugin configuration).

Don't forget to also backup:

  • any 3rd party plugins if your plugins folder is a subfolder of your Project64 folder (as by default)
  • any save files if your Saves folder is a subfolder of your Project64 folder (as by default).
  • any ROM files you may have put in your Project64 folder


 Uninstalling or Reinstalling Project64

As mentioned during installation, Project64 does not have an install program. It thus logically also doesn't have an uninstall program (there is no entry in Windows Add/Remove programs). The authors preferred a simple 'hands on' approach and we hope you will find it satisfying to be in control of your own system.

The following instructions will completely remove all traces of Project64 from your system, in case you ever wish to do this (although they shouldn't do any harm if not removed).

You may wish to read backing up before you begin.

Project64 does not scatter files around your system. The only files it creates are those in its own folder, and the folders you define - there are no files added to your system folders or ROM folders, for example.

You will find the following files the \Uninstall folder of your Project64 folder.

  • remove Project64 application settings.reg
  • remove Project64 plugins settings.reg
  • remove all Project64 settings.reg

The last files is the one you want to run to get rid of all the registry settings of Project64. Note than any entries made by 3rd party plugins will not be removed by these files - please consult relevant plugin documentation.

Note that these files do NOT delete your Project64 folder on your hard drive, ONLY the Project64 registry entries. You can delete your Project64 folder with your delete key.

The .reg files have been tested and should pose no risk to your system but backing up your Windows registry is general good practice. I and the Project64 team are not responsible for any harm that results from your use or incorrect use of these files.

Instructions to completely uninstall Project64:

  1. Exit Project64
  2. Backup anything you want saved
  3. Double click "remove all Project64 settings.reg"
  4. You will be asked "Are you sure you want to add the information in ... to the registry?"
  5. You must answer "Yes"
  6. You will be told "Information in ... has been successfully entered into the registry."
  7. Remove any 3rd party plugins you installed as per their instructions
  8. Remove any shortcuts you have to Project64 (Start menu etc.)
  9. Delete your root Project64 folder (e.g. C:\Program Files\pj64) and you're done.

You may need to restart your system for the file associations to clear (if you were using Shell Integration)

A re-installation of Project64 is just the same as an uninstallation, except that you carry out a standard install afterwards.


 Project64 Configuration

This section will help you through configuring the emulator, before you use it for the first time and during use.

All settings of the application and the default plugins are explained herein.

Expand the category to view the topics.


 Configuration - beginners!

This is aimed at people who are new to Project64 or emulators in general.

If you just accept the following advice as coming from a friend who knows a lot more about the emulator than you (that's me :p), you'll have an easier time of things :) You may think some of these options are obvious but they all have side effects that you cannot possibly guess! (and which i'll go into in depth elsewhere in this manual). All the default settings of Project64 are very carefully chosen to be (already) correct for the majority of people. Change them at your peril...

  • Don't change plugins! If you change plugins, you change the emulator, and if you change the emulator, I can't help you.
  • Don't uncheck "Hide Advanced Settings" in the application or the video plugin. This simple step will keep you away from most of the things you could mess up!
  • Don't start using cheat codes straight away - they can cause crashes.

...until you have some experience with the emulator!

All you need to configure to start with are the input plugin (where you set up your controls), the main tab of the video plugin (where you set resolutions), and the Options tab if you wish.


 Project64 application configuration

All settings of the main Project64 application (the executable) are explained here.

Select a topic.


 Selecting Plugins
Options > Settings > Plugins

The choice of plugins has a huge impact on the running of the emulator. It is highly recommended that people new to Project64 do not change plugins until they have used the emulator for a while and familiarised themselves with it. It is also recommended that you change one plugin at a time to start with, so you can see clearly the effects each is having on the system and trace any problems.

It is impossible for me to state here exactly which plugins you should be using, it depends on factors such as:

  • What plugins are available at the time you read this!
  • Which games you play
  • Your system specification
  • Your personal preferences

You will have to read up about the other plugins, try them, ask knowledgable people on the internet for advice, and ultimately decide for yourself which plugins you should be using.

There are three types of plugin that can be selected in Project64. One plugin of each type can be selected at a time via the Project64 Settings dialog. (It is not possible to assign specific plugins to specific games).

  1. Video plugin (also called Graphics Plugin)
  2. Audio plugin (also called Sound Plugin)
  3. Input plugin (also called Controller Plugin)

After reading those sections, if none of the reasons to change plugins apply to you, stick with the defaults! If you are not sure, try the default plugins first and see how you go. There are time tested reasons for this advice.

Each plugin type has an "About" button next to the menu. When pressed, this opens a dialogue from the selected the plugin, which the author of that plugin may use to display information such as his name, the version etc. (It is not compulsory for a plugin author to provide an About box, if not the button will be greyed out - it also not compulsory to provide a configuration dialog - if not, the appropriate menu item will be greyed out).

Saving your plugin selection

After making your plugin selection, press OK. If a ROM is currently running, you will be prompted to reset the ROM, because plugins cannot be changed during execution. If you don't want to lose your game position, answer No, save your game, and go back to the configuration. Otherwise, answer Yes. Project64 will immediately attempt to initalise all the plugins, if this is successful the game will boot with the new plugin selection. Your plugin selection is permanently saved by Project64 until you go back to the configuration and change it. If any plugin fails to initialise, you will recieve an error message to this effect - consult the plugin documentation for help with 3rd party plugins.

Changing RSP plugin

Since the Project64 GUI does not have an RSP plugin selection, you change RSP plugins by replacing RSP.dll with another file of the same name. (At the time of writing there are no other RSP plugins available).


 Video Plugin Selection

Points:

  1. The video plugin interfaces with Project64's RSP. You must have the RSP configuration correct for the type of video plugin (HLE or LLE) you wish to use. Even if you are using an HLE video plugin, the RSP can still be pre-processing some graphics, for example the 2D backdrops in Zelda, this is the default situation. At the time of writing, all N64 emulators are using HLE video, there is no true LLE available.

Choose a non-default video plugin if:

  • if a game is marked "Needs video plugin" and you have a 3rd party plugin which you know does support the game
  • if a 3rd party plugin better supports your (probably legacy) hardware
  • video plugins are extremely complicated, there could be many reasons why you would want to change.


 Audio Plugin Selection

Points

  1. The audio plugin interfaces with Project64's RSP. You must have the RSP configuration correct for the type of audio plugin (HLE or 'LLE') you wish to use.

Open the configuration dialogue of the current audio plugin from the Options menu.

Choose a non-default audio plugin if:

  • you have no sound card, or a non-functional sound card - select the dummy audio plugin*
  • you don't want audio or want to turn it off for more speed - select the dummy audio plugin*
  • you want to use HLE audio (perhaps for more speed)
  • you want adjustable or more advanced sound buffering
  • you want any filtering and advanced processing options
  • you want any controls that are not offered e.g. balance or reverse stereo

Assuming all those capabilties are available in another plugin.

*In this case you should also disable audio emulation in the RSP to save CPU time. Note that some games will not work with a dummy sound plugin selected, for technical reasons. For compatibility it is better to simply turn the volume all the way down.


 Input plugin selection

Points

  1. The input plugin interfaces with the core of the emulator (it is independant of other plugins)
  2. The input plugin is responsible for handling input (obviously), but also optionally MemPak (depending on plugin capability and configuration) and any other type of N64 controller accessory such as the Transfer Pak or Voice Pak.

Open the configuration dialogue of the current input plugin from the Options menu.

Choose a non-default input plugin if:

  • you want mouse support
  • you want "rapid fire" etc. capabilities, Macros etc.
  • you want modifier capability (analogue movement emulation etc.)
  • you want better control over e.g. range and threshold values
  • you want Force Feedback support
  • you want direct support for Rumble Pak, Transfer Pak or Memory Pak*

Assuming all those capabilties are available in another plugin.

*at the time of writing, only available for the Adaptoid and with N-Rage's input plugin or the Adaptoid plugin.


Configuring: General Options

 Configuration: Options
Options > Settings > Options
  1. "Pause when window loses focus"
  2. "Fullscreen automatically after loading games"
  3. "Remember selected cheats for games"
  4. "Hide Advanced settings"

"Pause when window loses focus"

  • default setting: enabled
  • generally recommended setting: user preference!

If enabled, the emulator will pause when it detects that it no longer has focus in Windows. This is useful if you are multitasking and want the emulator to pause whenever you go to another application.

If disabled, the emulator will carry on running regardless of whether or not it has focus. Use this if you want Project64 to carry on running in the background while you do something else (you can still keep it always on top with the Always on Top option!). Note that if this option is unchecked the peformance of Project64 will probably be lower while focus is lost because of the way Windows handles resources. This is normal and not a fault of Project64.

"Fullscreen automatically after loading games"

  • default setting: disabled
  • generally recommended setting: disabled

If enabled, Project64 will automatically instruct the video plugin to switch to fullscreen once after loading each ROM. This is good (saves you a key press) if you know a game works and doesn't need any configuration changes. You can still return to windowed mode in the usual ways (Escape, ALT+ENTER).

If disabled, games will start windowed. You can switch to fullscreen mode yourself in the usual ways (Escape, ALT+ENTER, Options menu). This is a little more work (one key press) but recommended, because you can make sure your configuration (particularly graphics plugin tabs) is correct before getting into your game.

Notes:

  • The emulator actually goes fullscreen before starting emulation. This is so that plugins/hardware that only work in fullscreen can be supported. If you have such a plugin or hardware then you must enable this option!
  • Don't enable this option with "Start emulation after ROMs are opened" (Advanced) disabled! It will go fullscreen but your games won't automatically start, which could be confusing...
  • The RDB can override this option and prevent automatic fullscreen on a defined status (by default, games with status "Unsupported"). Hopefully it's obvious why this is done; if you don't like it you can either edit the RDB to remove the line from the status definition, or you could change the status of the game(s).

"Remember selected cheats for games"

  • default setting: disabled
  • generally recommended setting: disabled

If enabled, Project64 will save your cheat code selection between sessions. This is for your convenience, and it means that if you close the emulator and go away, then play some hours/weeks/anytime later, the same cheat codes will be applied as before... this is important to remember if your games are acting strangely!

If disabled, the cheat code selection is lost as soon as you load a new ROM, or quit the application, whichever happens first. This is the default because cheat codes often cause problems...

"Hide Advanced settings"

  • default setting: enabled
  • generally recommended setting: beginners should keep this enabled, advanced users should disable it.

This is a very important control and new in v1.5. When enabled, most of Project64's other controls are hidden from the user. This is because casual fiddling by inexperienced users tends to result in people getting themselves into a mess. It is therefore highly recommended that new users, people with low technical/emulator expertise, and young children, to give a few examples, use the application with this option enabled - the emulator runs just as well will this on or off!


Selecting Language

 Configuration: Language
File > Language

The first time Project64 is started, it asks you to choose a language. The choices available depend on the contents of the \Lang folder. Project64 v1.5 shipped with a reasonable but of cause far from complete set of translations included (thanks to everyone who made them!). If the language you want is not in the list, seek an updated/alternative file or make/edit one yourself!

To change languages at a later date, use the Language menu under the File menu in Project64. Simply click an entry in the list and you should see the GUI text update immediately.


Setting Project64 Folders

Configuration: Folders
Options > Settings > Folders

This tab is only available if Hide Advanced Settings is unchecked!

N.B. It is purely a matter of personal preference how you set these folders, but you must have the Plugin folder set correctly for Project64 to start up properly, if valid (working) plugins aren't found at the configured path when Project64 is started, you cannot start games. This is by design - plugins are an essential part of the system. You can of course still get into Options to correct the paths.

Project64 allows you to set up to 5 different folders:

  1. Plugin folder - all the plugins you want to be available to Project64 must be placed together in one folder, by default \Plugin\ subfolder of main Project64 folder
  2. ROM folder - by default Project64 remembers the last used folder and opens to this folder, but if you want to force it to always use the same folder you can.
  3. Native save folder - all the native save types generated will be placed together in this folde, by default \Save\ subfolder of main Project64 folder
  4. State save folder - if you use state slots, all files generated will be placed in this folder, by default the same folder as for native saves.
  5. Screenshots folder - this information is passed to the video plugin for its screenshot function, by default \Screenshots\ subfolder of main Project64 folder

Each folder can either use a default path, or one that you choose.

You can either type a path in directly, or browse to a folder by pushing the "..." button. Press OK and it will fill in the path for you.

Press OK to save your changes.


Configuring: Advanced

Configuration: Advanced
Options > Settings > Advanced

This tab is only available if Hide Advanced Settings is unchecked!

Upper tab - Core Defaults (drop down menus):

  1. R4300i core
  2. Self-mod code method
  3. Expansion Pak
  4. Advanced Block Linking <- Important control, read this!

Lower tab (checkboxes):

  1. "Start emulation after ROMs are opened"
  2. "Overwrite these default settings with ones from RDB"
  3. "Zip compress all state saves"

"R4300i core"

  • default setting: Recompiler
  • generally recommended setting: Recompiler (should not matter if using RDB)

Setting explained under ROM Settings. This setting can be overriden on a per-ROM basis (by the RDB, see ROM settings), if "Overwrite these default settings with ones from RDB" is enabled and a value is set in the RDB - this control will then be ignored.

Notes:

  • Project64 was only tested extensively on the Recompiler, with the Interpreter used as a backup if the Recompiler failed - if you set this to Interpreter, there is a (small but real) chance that some games with not work - be prepared to put games back to using the Recompiler on a per ROM basis.

This is almost always set by the RDB, therefore this control is not normally used.

"Self.-mod code method"

  • default setting: Check Memory Advance
  • generally recommended setting: Check Memory Advance (should not matter if using RDB)

Setting explained under ROM Settings. This setting can be overriden on a per-ROM basis (by the RDB, see ROM settings), if "Overwrite these default settings with ones from RDB" is enabled and a value is set in the RDB - this control will then be ignored.

Self.-mod code method is almost always set by the RDB because the optimal value should be known by the RDB author. It won't be set (in Official files) if the RDB author couldn't determine the correct value (prompting you to find it yourself). Therefore it should not matter what you set this control to.

"Expansion Pak"

  • default setting: Yes
  • generally recommended setting: No (should not matter if using RDB)

Setting explained under ROM Settings. This setting can be overriden on a per-ROM basis (by the RDB, see ROM settings), if "Overwrite these default settings with ones from RDB" is enabled and a value is set in the RDB - this control will then be ignored.

Generally I suggest setting this to No because most games don't need the Expansion Pak and you are only wasting resources... the RDB should enable the expansion pak when it is appropriate.

Expansion Pak should always be set by the RDB. Therefore it should not matter what you set this control to.

"Advanced Block Linking"

  • default setting: On
  • generally recommended setting: Off, unless you need the speed (see below)

Advanced Block Linking is one of Project64's speed optimisation techniques, although this is available in ROM Settings, the setting on this tab will be in effect most of the time. Where this is the case (i.e. where ABL is not being forced by the RDB) this control is a performance option for the recompiler, where setting On gives more speed (higher maximum and overall average speed) and setting Off gives better "smoothness" (higher consistency of speed, less variation from one part of a game to another, fewer jerks and slowdowns, but a lower overall speed). The effect of having ABL on vs. off is probably most noticeable in fast moving racing games such as Didddy Kong Racing and Mario Kart.

This setting can be overriden on a per-ROM basis (by the RDB, see ROM settings), if "Overwrite these default settings with ones from RDB" is enabled and a value is set in the RDB - this control will then be ignored.

Notes:

  • Project64 game compatibility was only thoroughly tested with ABL enabled, due to time constraints. If you turn ABL off, there is a possibility that some ROMs may need their settings adjusted - occasionally a higher self-mod code method is needed. There is also a chance that some games will not work at all with ABL turned off, so be prepared to turn it back on on a per-ROM basis.
  • Some background info: ABL is not new to Project64 1.4+. The emulator was always using ABL, what is new in 1.4+ is the ability for you to turn it off! During the early stages of Project64 development performance was a major concern, but we expect Project64 to perform better on future PCs without ABL.

This is NOT normally set by the RDB, therecore this control IS normally used! (unlike all the other controls on Advanced tab)

"Start emulation after ROMs are opened"

  • default setting: enabled
  • generally recommended setting: enabled, unless you want to edit RDB before boot (see below)

If enabled, Project64 will (always) begin emulation immediately after a ROM has finished loading. This is usually what you would want to happen, it saves you having to press "Start Emulation" in the file menu every time you want to play a new game.

If disabled, the emulator will wait, with the ROM loaded, until you press Start Emulation to boot the ROM, or do something else. This is to allow you to edit ROM settings before booting the ROM (otherwise you would need to edit settings while the ROM is running and then reset it, which is normally OK but creates a catch-22 if, with the current settings, the ROM is not bootable!).

Changes take effect at next ROM boot.

"Overwrite these default settings with ones from RDB"

  • default setting: enabled
  • generally recommended setting: enabled

If enabled, the Project64 core will use the settings defined in the RDB for each ROM, unless no entry exists, or the settings in the RDB are "Default" or "Global", in which case the settings defined on the lower half of this tab will still be used.

If disabled, the core settings defined in the RDB will be ignored, and all the default settings defined on the lower half of this tab will be used, for every game. Settings that cannot be defined on this tab will take the default values as explained in ROM Settings.

Notes:

  • If you want to see which value is actually being used at any particular time, check the ROM Settings tab while the game is running.
  • There is little reason why you should ever turn this option off - Project64 requires carefully considered per-game settings for good results, and many important options (e.g. Register Caching) can only be set by the RDB file. This option is included mainly for the developers and advanced users testing games.

Changes take effect on the next ROM boot, or when current ROM is reset.

"Zip compress all state saves"

  • default setting: enabled
  • generally recommended setting: enabled

If enabled, Project64 will zip compress state save files (Slots and Save As...). This may increase the time taken to complete save operations, but the advantage is the reduced hard drive space usage per save (typically half to a third the space).

If disabled, Project64 will write normal (uncompressed) state save files. This may be quicker, depending on your system, but will definately use more storage space (files will be 4MB or 8MB depending on whether or not the Expansion Pak is enabled).

Notes

  • this setting makes no difference to the loading of state saves - you can still load a compressed state if this is disabled.
  • you cannot adjust the level of compression, a medium level was chosen by the authors.
  • there is no compression for native saves, the files are so small the authors decided it wasn't worth the extra hassle for them or the user.

Changes take effect immediately, or when the next state save is made.


Configuration: Shell Integration
Options > Settings > Shell Integration

This tab is only available if Hide Advanced Settings is unchecked!

Associating your ROM files with Project64

  1. Go Options menu > choose Settings > Shell Integration tab.
  2. Check each box that has a file extension your would like associated with Project64.
  3. Press OK.
  4. All your file icons may flash a few times - this is normal.
  5. In Windows, you will see your ROM icons change to the Project64 icon.
  6. You can now start a game by double clicking a ROM in Windows.

Removing ROM file associations from Project64

  1. Go Options menu > choose Settings > Shell Integration tab.
  2. Uncheck each box that has a file extension you don't want associated with Project64.
  3. Press OK.
  4. All your file icons may flash a few times - this is normal.
  5. In Windows, you will see your ROM files lose their Project64 icon.
  6. You cannot now start a game by double clicking a ROM in Windows.


Configuring ROM Settings
Options > Settings > ROM Settings

This tab is only available if Hide Advanced Settings is unchecked!

This page covers configuration of the core for each individual ROM. Some of these settings are also available under the General tab, and although the settings have the same meaning there, they have a slightly different purpose.

Controls available:

  1. "R4300i core"
  2. "Self -mod. code method"
  3. "RDRAM size"
  4. "Advanced Block Linking"
  5. "Cartridge save type"
  6. "Counter Factor"
  7. "Larger Compiler Buffer"
  8. "Use TLB"
  9. "Register Caching"
  10. "Delay SI interrupt"
  11. "SP Hack"

Points

  1. It is highly recommended that you do not make any changes here unless you understand exactly what you are doing. Understanding what you are doing takes experience that cannot be obtained from this manual alone. You are likely to reduce performance and/or stability.
  2. The emulator is (hopefully!) supplied with the optimal configuration for (almost) every game!
  3. When you make changes here, you are actually editing the Project64 ROM Database (the file Project64.rdb). You can also edit this file directly in a text editor - advanced users only! If you get in a mess, the only way to go back to the supplied settings is to replace Project64.rdb (from the original downloaded archive). There is no "reset to defaults" button or similar.

"R4300i core"

Possible settings:

  1. * use general setting
  2. Interpreter
  3. Recompiler
  4. Synchronise Cores (debug builds only)
  • default setting: * use general setting (by default: Recompiler)
  • generally recommended setting: Recompiler if it works

The Recompiler and Interpreter are two seperate cores in the emulator (although the Recompiler implementation is based on the Interpreter). Generally, any game that works on the Recompiler will also work on the Interpreter, but not always vice-versa. Explaining the difference between a Recompiler and an Interpreter in a general sense is beyond the scope of this document, suffficient to say that the Recompiler is (usually much) faster but (a little) less compatible, the Interpreter (usually much) slower but (a little) more compatible. If you have a fast enough PC that peformance is not an issue for you, you can probably use the Interpreter all the time, but i wouldn't recommend it since it generally shouldn't offer much advantage.

Note that if you are using the Interpreter, the following settings are ignored (they are only relevant to the recompiler):

  • Self. mod code method
  • Advanced Block Linking
  • Larger Compile Buffer
  • Register Caching

"Self -mod. code method"

Possible settings:

  1. * use general setting
  2. None
  3. Cache
  4. Check Memory & Cache
  5. Check Memory Advance
  6. Change Memory & Cache
  7. Protect Memory
  • default setting: * use general setting (by default: Check Memory Advance)
  • generally recommended settings: highly game dependant! (see below)

Many games use "self modifying code". In a nutshell, this makes them harder to keep running during play. Project64 has several methods of dealing with these situations, which range from fast at one end to more secure (stable) at the other. In order from fastest to most secure these are:

None > Cache > Check Memory and Cache > Check Memory Advance > Change Memory and Cache > Protect Memory

If a game does not use self modifying code (e.g. Mario64) this can be set to None (but read notes below). A typical self modifying code game such as Zelda (and many others) are optimal on "check memory and cache" or "change memory and cache" or "check memory advance" (depends on game). Some games will only run stable on "protect memory", which is a very secure method. Some trial and error is needed for you to find out which setting is best - you are looking for the fastest method that doesn't crash.

Notes:

  • Which is most secure out of Check Memory Advance and Change Memory & Cache depends very much on the particular game, sometimes one is more secure, sometimes the other.
  • In general, Check Memory (either variant) and Change Memory & Cache are the most useful self. mod code methods, offering a good balance of performance and stability.
  • Unfortunately sometimes a game will be fine on one method (e.g. Check Memory & Cache) except for one single point where it fails, and Protect Memory is needed. If you find this is the case, and Protect Memory is significantly slower, try changing back to Check Memory and Cache after you have passed the point.
  • For reasons unknown to me, if you aren't using Advanced Block Linking, some games that don't use self mod. code need a self mod code method set. Cache is sufficient. This should already be set by RDB, this is just a warning.
  • Protect Memory can cause severe slowdown, either all the time a game is running, or during particular periods, and in rare cases a game will not work at all with it. Only use Protect Memory when necessary.

"RDRAM size"

Possible settings:

  1. * use general setting
  2. 4MB
  3. 8MB
  • default setting: * use general setting (default: 8MB)
  • generally recommended setting: 4MB, unless needed.

An emulated RDRAM size of 4MB is the standard amount of memory an N64 console has.

An emulated RDRAM size of 8MB represents an N64 console with the 4MB memory expansion accessory installed, plus the original 4MB. This results in larger state saves and can lower performance. Most games do not benefit at all from the Expansion Pak. Some games require the Expansion Pak (e.g. Zelda2), some games give you more with it (e.g. Perfect Dark), some games just use it to raise resolution (in which case we recommend you don't use the Expansion Pak since graphics are HLE anyway, see below).

Notes:

  • if a game supports the Expansion Pak as an option it will usually tell you in its introduction screens (usually two lines, like "Expansion Pak supported, Expansion Pak detected"). If a game doesn't support the Pak, or absolutely requires it, it probably won't say anything.
  • you gain nothing by using the Expansion Pak on a game that doesn't support it - you just waste resources.
  • further, if a game has optional Expansion Pak support where the Pak is used only to raise screen resolution, it is generally recommended you set this to No, because there's no point wasting resources on higher native resolutions when the graphics are high level emulated (hence largely resolution independant) anyway, also it can often cause severe aspect ratio problems in the video plugin.
  • in rare cases, for reasons unkown to me, the Project64 video plugin requires the Expansion Pak to avoid an Access Violation (even in games that don't use the Expansion Pak). The RDB is already set up for this for all known cases.
  • the above two points explain why the setting may sometimes appear to be logically incorrect - it has been set that way for a good reason!
  • this setting should already be correctly configured for every game by the RDB, don't change it unless you know what you're doing!

"Advanced Block Linking"

Possible settings:

  1. * use general setting
  2. Off
  3. On
  • default setting: * use general setting (default: On)
  • generally recommended setting: highly game dependant! (see below)

Advanced Block Linking is one of Project64's speed optimisation techniques - it usually provides a speed vs. smoothness tradeoff that you'd want to set globally (for all games) under the General tab, according to whether you have a fast or slow PC. On is usually (often significantly) faster than Off but may be less smooth. This depends on the game. Afew games run particularly badly with this On, or may require this to be On or Off, which is why the RDB sometimes does set this control.

"Save type"

Possible settings:

  1. * detect first used type
  2. 4kbit EEPROM
  3. 16kbit EEPROM
  4. 32kbyte SRAM
  5. 128kbyte FlashRAM
  • default setting: * detect first used type
  • generally recommended setting: * detect first used type, unless game uses 16kbit EEPROM or a copy protection system that tries to trick the emulator into using the wrong save type.

You can set any of the four possible native cartridge save types here, but the only one that should be needed is 16kbit EEPROM, because it is not possible for the emulator to detect the difference between a game asking for 16kbit and a game asking for 4kbit - Project64 assumes 4kbit, the more common size. If a game actually needs 16kbit it will either fail to save or not boot unless set to 16kbit EEPROM. The other settings are included for the rare possibility that the autodetect goes wrong - generally, don't set them. Note that MemPak is treated seperately and will work in addition to whatever is selected here.

"Counter Factor"

Possible settings:

  1. * use default (2)
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  • default setting: * use default (2)
  • generally recommended setting: 1 or 2 (possibly 3, see below)

Counter Factor effects the timing in the core, it's a difficult option to explain, what you need to know is that 2 is the default and best speed you can get in most games without causing problems like missing video frames, 1 is required by some games to prevent flicker or optionally to increase smoothness, and 3 is a possibility for some games to improve performance. Values higher than 3 are likely to cause severe frame loss, leading to instability. But in the hands of experienced users this setting can be used as a crude form of frame-skip. Experienced users only!

"Larger Compiler Buffer"

Possible settings: checked or unchecked

  • default setting unchecked
  • generally recommended setting: unchecked unless it helps

Some games generate particularly complex code structures which tend to overlow the default 20MB compiler buffer and temporarily stall the system, causing a pause in gameplay. By enabling this a game will be given a 50MB buffer, which obviously increases resource usage but may help reduce occurence of overflows and thus improve performance. Most games do not need more than 20MB hence this will usually only waste resources.

"Use TLB"

Possible settings: checked or unchecked

  • default setting: checked
  • generally recommended setting: unchecked if not needed, checked if needed.

This is another highly technical core feature, it's part of the N64 CPU, used extensively by some games (Goldeneye, Mario etc) and not at all by others (Zelda, Banjo etc). If a game uses the TLB (end user can't tell this without knowing or by trial and error) then this must be enabled or the game will fail with various error messages, usually soon after boot. TLB is an option mainly because you can gain some performance by turning it off where not needed.

"Register Caching"

Possible settings: checked or unchecked

  • default setting: checked
  • generally recommended setting: checked, unless it causes a failure.

Probably the recompiler's most significant optimisation technique, register caching usually dramatically improves the efficiency of the recompiler, and usually without side effects. The reason this is included as an option is that sometimes register caching will produce an error in a game. Register caching can cause many kinds of obscure errors, such as events in a game not triggering, or a game becoming stuck in a loop, or graphics being messed up, aswell as obvious errors such as a crash. If you find you are having stability problems with the recompiler and not the interpreter, try disabling register caching to see if you can get past the point/game with at least some of the performance of the recompiler.

"Delay SI interrupt"

Possible settings: checked or unchecked

  • default setting: unchecked
  • generally recommended setting: unchecked unless needed

This option was added in v1.5 to help a small number of games that were broken in v1.4. It's simply either needed (for example Cruis'N USA) or it isn't. Usually it isn't.

"SP hack"

Possible settings: checked or unchecked

  • default setting: unchecked
  • generally recommended setting: checked unless it causes failure

This option was added in v1.5 simply as a performance feature - enabling it gives typically 5% more speed from the core, however a large numbe of games will not be stable with it enabled, therefore it's not set often. Try it if you are desperate for speed, but for most people most of the time it's recommended you leave it off.


Configuring ROM Notes
Options > Settings > ROM Notes

This tab is only available if Hide Advanced Settings is unchecked!

Controls available:

  1. Status (menu)
  2. Core Note (text box)
  3. Plugin Note (text box)

Points

  1. When you make changes here, you are actually editing the Project64 ROM Database (the file Project64.rdb). You can also edit this file directly in a text editor - advanced users only! If you get in a mess, the only way to go back to the supplied settings is to replace Project64.rdb (from the original downloaded archive). There is no "reset to defaults" button or similar.

"Status"

This menu shows a list of all the status categories found in the RDB. You may choose any of these. To add or edit categories, you must edit the RDB in a text editor.

"Core Note"

This is simply a text field which edits the line Core Note= for the current ROM in the RDB.

"Plugin Note"

This is simply a text field which edits the line Plugin Note= for the current ROM in the RDB.

You must refresh the ROM Browser for any changes to any of these fields to take effect.


Configuring the ROM Browser

Configuration: ROM Browser
Options > Settings > ROM Selection

This tab is only available if Hide Advanced Settings is unchecked!
  • Enable/Disable the Browser completely by toggling the Use ROM Browser checkbox
  • Enable/Disable Directory Recursion by toggling the Directory Recursion checkbox
  • Add or Remove fields from the Browser by selecting (click on) the field you want to add or remove and clicking the Add or Remove button.
  • Change the order of fields by clicking the field you want to move and clicking Up or Down. Top to bottom in the window represent Left to Right in the browser.

The following customisations can be made from within the browser itself:

  • Resize the browser window by dragging the window edges
  • Maximise/Restore the browser window with the maximise/restore button
  • Resize the width of any column by dragging the edge of the column header
  • Sort by any column by clicking inside the column header. You can sort in either direction by repeated clicking.


 Project64 plugin configuration

All the settings of the default Project64 plugins are explained in this section.

Please note that plugin selection (as a general topic) is covered under application configuration.

About other plugins.


Configuration: Reality Signal Processor

This dialog is only available if Hide Advanced Settings is unchecked!
  1. "send Audio Lists to Audio Plugin"
  2. "send Display Lists to Display Plugin"
  3. "CPU core style"

Points:

  1. The Reality Signal Processor ("RSP") plugin processes most audio and some graphics (depends on game programming and also adjustable via configuration options).
  2. There is one RSP plugin provided with Project64, which contains two cores.
  3. The RSP plugin cannot be selected via the Project64 GUI - $PluginPath\RSP.dll is always used.
  4. The RSP plugin interfaces with the core, and the audio and video plugins (a three stage system).

Open the RSP plugin configuration dialogue from the Options menu in the Project64 GUI. Each available configuration option is explained below.

"send Audio Lists to Audio Plugin"

  • default setting: disabled
  • generally recommended setting: disabled

If disabled, the RSP will process Alists (provide low level emulated audio output). This generally provides good compatibility and quality.

If enabled, ALists are passed to the audio plugin (for high level emulation). This may provide better performance or extended capabilities, depending on your choice of audio plugin.

Changes take effect instantly.

This setting is saved (globally, in the registry) between settings

"send Display Lists to Display Plugin"

  • default setting: enabled
  • generally recommended setting: enabled

If enabled, Dlists will be passed to the video plugin (for high level emulation). This is almost always the preferrred solution, for speed and quality with the default plugins.

If disabled, the RSP will process Dlists (provide low level emulated graphics ouput). This is not usually successful with the default plugins.

Changes take effect instantly.

This setting is NOT saved between sessions.

"CPU core style"

  • default setting: Recompiler
  • generally recommended setting: Recompiler

If Recompiler selected, the RSP will use a seperate (low level) recompiling core. This provides far superior performance. In theory the recompiler is slightly less compatible than the interpreter but it has been improved in v1.5 to the point where there are no known limitations, so you should never need to use the interpreter!

If Interpreter selected, the RSP will use a seperate (low level) interpretive core. Peformance is generally significantly lower. See above about compatibility.

Tip: It follows that any time you do use the RSP interpreter for any reason, you are probably also going to want to use HLE audio to avoid such a severe speed penalty.

Changes take effect instantly.

This setting is saved (globally, in the registry) between settings


 Video Plugin Configuration

Because the video plugin has so many options, I have divided the topic by the tab of the plugin config. dialogue.

  • Display tab
  • Advanced tab
  • ROM Settings tab

Below all the tabs are three buttons, OK, Cancel and Apply. Hopefully the first two are self-explanatory - cancel closes discarding changes, OK closes keeping changes (but they aren't acutally written to registry (disk) until you close Project64. The Apply button (new in v1.4) is to allow you to see the effects of changes to graphics configuration in real time, while a game is running (only for controls which take effect instantly, which is most of them in 1.4; this is detailed with every control), without the awkwardness of having to go back to the dialogue every time. This button does not save changes to the registry - saving to the registry is done on application exit. Therefore its a good idea to restart Project64 once after making a lot of changes that you want to keep, just in case anything crashes.


 Video Configuration - Settings tab

This page covers configuration of one tab of the default Project64 video plugin. About other plugins.

  1. Video Card [label]
  2. "Rendering Device" [menu]
  3. "Anisotropic filtering" [checkbox and slider]
  4. "Sort independant anti-aliasing" [checkbox]
  5. "Fullscreen Resolution" [menu]
  6. "Buffer Display Mode" [menu]
  7. "Windowed Resolution" [menu]
  8. "Hide Advanced Settings" [checkbox]

"Video Card" [label]

This is your graphics card name as known by Windows - in v1.5 the plugin is autodetecting a number of features based on your hardware capabilities, although the name is not used directly, this is simply here as a reminder for you when you are configuring the plugin, and if you ever need support online.

"Rendering Device" [menu]

What is available in this menu depends on what is detected on your system. If you want to use a setting not available, consult you graphics card documentation. If you want to use Reference Rasterizer it may need to be enabled on your system with the Microsoft DirectX Control Panel Utility.

  1. RGB emulation
  2. Direct3D HAL
  3. Reference Rasterizer
  • default setting: Direct3D HAL
  • generally recommended setting: Direct3D HAL

Nearly everyone should have this set to Direct3D nearly all the time!

RGB emulation is a poor quality and slow software renderer but may be used as a last resort for people who don't have a working HAL (not recommended).

The Reference Rasterizer is extremely slow but has one particular use - you can use it to see if any graphics glitch is caused by your video system or a bug/limitation of the emulator - if you change to Reference Rasterizer and the glitch goes away, it's your system, if the glitch doesn't go away, it's the emulator. Simple and pretty reliable. You might find you need to turn off FSAA while using the Reference Rasterizer.

Changes take effect immediately (but if a device is very slow, you may need to be patient). You should probably save before changing device in case something goes wrong.

"Anisotropic filtering" [checkbox & slider]

If the checkbox is greyed out, the plugin has detected that your system (hardware/drivers) is not capable of any level of anisotropic filtering. If the slider remains greyed when the checkbox is enabled, the plugin has detected that your system is only capable of one level of anisotropic filtering (2x - this is true of all GeForce1 and GeForce2 class systems). The range of anisotropic filtering levels available depends on your hardware and drivers. Consult system documentation if you need further assistance.

  • default setting: disabled
  • generally recommended setting: enabled and as high as possible without losing performance.

If enabled, the plugin instructs your graphics card drivers to use anisotopic filtering. This can improve texture filtering quality dramatically, with a possible performance cost. (A good place to see this difference is e.g. on the grass in Zelda, looking in the mid to far distance).

If disabled, you will get standard bilinear texture filtering from your graphics card.

"Sort independant anti-aliasing" [checkbox]

If this option is greyed out, the plugin has detected that your system (hardware/drivers) is not capable of any level of anti-aliasing. Consult system documentation if you need assistance.

  • default setting: disabled
  • generally recommended setting: enabled

Usually referred to as "FSAA" (Full Scene Anti-Aliasing), this option simply instructs your video card drivers to enable anti-aliasing. The results (performance and quality effects) depend on your ardware capabilities, drivers and configuration. Consult your system documentation for further information.

Notes:

  • nVidia's drivers appear not to suppport this function in DX6. If you have nVidia hardware you will probably need to force anti-aliasing using via your driver controls or a driver tweak utility.
  • This control will work both windowed and fullscreen, provided your graphics card is capable of both.
  • Some graphics cards may require a particular Buffer Display Mode selected for FSAA to work when in fullscreen (e.g. the Voodoo5 probably won't give you FSAA if set to Transfer Memory).

Setting may require restart of ROM or App for changes to take effect

"Fullscreen Resolution" [menu]

What is available in this menu depends on what is detected on your system. If a mode that you wish to use is not available, consult your graphics card documentation, because it's a problem with your graphics card or drivers, they either cannot do the mode or the drivers are reporting wrongly.

  • default setting 640x48x16
  • generally recommended setting: 640x480x32, 1280x960x32, or your desktop resolution (see below)

The plugin enumerates and lists all available modes on your system in this menu, in the format: (Horizontal Resolution) x (Vertical Resolution) x (Colour Bit Depth)

Notes:

  • If 24 bit colour modes are listed, do not select them. Most graphics cards cannot render 3D in 24 bit colour, or they are slower - choose a 32 bit colour mode instead.
  • Do not select a mode that you know your graphics card cannot render 3D in (as a limitation of your graphics card) - for example any 32 bit colour mode on a 3dfx Voodoo3.
  • if you match the fullscreen resolution to your Windows desktop resolution and colour depth, you will be able to switch the emulator quickly between windowed and fullscreen mode without your monitor having to re-synchronise. However, your desktop resolution may not be a good choice... I happen to use 1280x960x32 as my normal windows resolution :)
  • see points at top about resolution choices.

Changes take effect next time you go fullscreen.

See points under "Windowed Resolution" below!

"Buffer Display Mode" [menu]

What is available in this menu depends on what is detected on your system, out of a maximum 5 possible settings. If you want to use a setting not available, consult you graphics card documentation.

  1. Transfer Memory
  2. Double Buffer Vsync
  3. Triple Buffer Vsync
  4. Double Buffer
  5. Triple Buffer
  • default setting: Transfer Memory
  • generally recommended setting: Triple Buffer

Transfer memory means use no extra buffering. This saves video card memory and may be the best option on cards with limited memory. However, all modern cards should be able to buffer without penalty, I suggest you try triple buffering. The other choice is whether you want Vsync or not (see Glossary), I personally prefer not to use Vsync. Note that use of Vsync also depends on your graphics card driver settings, it may already be forced on or off there.

Changes take effect next time you go fullscreen. This control does not apply to windowed modes.

"Windowed Resolution" [menu]

The menu lists all standard resolution from 320x240 up to 1600x1200.

  • default setting: 320x240
  • generally recommended setting: 640x480, or your preference.

This control sets the resolution of the window, or to put it another way (since your screen resolution is not changed) the size of the window.

Notes:

  • plugin window resolution and position is independant of the Project64 ROM Browser window resolution and position. This is by design, it may seem strange to you at first.
  • large windowed resolutions can reduce performance, it's usually better to go fullscreen.
  • see points at top about resolution choices.

About resolution selection:

  1. The N64 has a low native resolution compared to typical PC resolutions, N64 games are designed in the range 320x240 - 640x480. This means that choosing high resolutions can create a noticeable distinction between 3d parts and 2d (pre-rendered bitmap) parts of a scene, in games that mix the two (e.g. Zelda). Arguably the best appearance is achieved by using a "low" resolution such as 640x480 and a high level of FSAA.
  2. Although the plugin allows you to set any resolution, you should really only use ones that are exact multiples of native n64 resolution (which you can assume is 320x240), such as 640x480 and 1280x960. Using other resolutions, particularly ones with non 4:3 aspect ratios (4:3 is the aspect ratio of a conventional TV set), can lead to image distortion that is very noticeable in some games. The decision is left up to you however.

Changes take effect immediately.

"Hide Advanced Settings" [checkbox]

  • default setting: enabled
  • generally recommended setting: disabled once you have read all this documentation!

When enabled both the Advanced and ROM Settings tabs of the video plugin configuration dialog are hidden from the user. This is to make Project64 easier and "safer" for beginners to use. You will probably find you need to disable this at some point to get access to the full range of controls, however note that casual fiddling with the options will cause problems, so don't touch anything you don't understand, and remember what you changed!


 Video Configuration - Advanced tab

This page covers configuration of one tab of the default Project64 video plugin. About other plugins.

All settings on this tab are saved in the registry and apply globally i.e. to all games.

Rendering:

  1. "Force Normal Blending"[checkbox]
  2. "Force Filtered rendering" [checkbox]
  3. "Wireframe Rasterization" [checkbox]
  4. "Disable internal geometry" [menu]
  5. "Force Depth Enable" [checkbox]
  6. "Force Depth Compare" [checkbox]

Frame Buffer:

  1. "Emulate Primary"[checkbox]
  2. "Update Less frequently" [checkbox]
  3. "Use low resolution updates" [checkbox]

Points

  1. As the tab name suggests, these options have some quite difficult to understand effects. Do not turn any of these option on unless you've first read and understoof the explanations below.
  2. These options are all OFF by default for a good reason - in general they cause more problems than they fix!
  3. If you turn any of these things on, don't forget that you've done it! What works in one game may cause problems in another.

"Force Normal Blending" [checkbox]

  • default setting: disabled
  • generally recommended setting: disabled, for most games

Forces rendered primitives to be alpha tested for transparency, then blended with the frame buffer. Generally, this causes more problems than it fixes, even within one game, but it can sometimes help, particularly with sprite edges. See browser notes for occasional advice as to when this is required (rare).

"Force filtered rendering" [checkbox]

  • default setting: disabled
  • generally recommended setting: your preference (see below)

Forces bilinear/anisotropic (see notes) filtering of all rendered primitives. The N64 supports point-sampled sprites (Mario64 for example) where bilinear is blury and hard to read, or used as an effect. N64 games are designed with parts of the display (typicaly screen indicators like number of lives remaining etc.) to fit a TV, so they are not filtered. On your PC, with higher resolutions, this often results in a blocky looking display - with this option, you can force filtering of everything if you wish.

Notes:

  • enabling this necessarily disables point filtering, with it enabled you are technically getting less accurate emulation (because a game may be choosing to use different kinds of filtering) even if you prefer to always see the smoother filtering.
  • enabling this can make text in some games hard to read (e.g. Mario Party 2)
  • if you have Anisotropic filtering enabled on the Display tab, Anisotropic filtering will also be used here, otherwise, bilinear filtering will be used.
  • if you have forced anisotropic filtering via your video card drivers, this setting will have no effect, everything will be forced filtered.

"Wireframe Rasterization" [checkbox]

  • default setting: disabled
  • generally recommended setting: disabled

If enabled, all graphics in the scene will be rendered as triangle edges only. This is mainly a novelty feature for the end user, with one particular use to gamers - it allows you to see objects that would normally be hidden behind others. Some games (e.g. Mario64) "smear" with Wireframe Rasterization, others work as expected.

If disabled, graphics are rendered normally, i.e. solid with lighting etc.

Setting only holds for the current session (until you End Emulation).

"Disable internal geometry" [menu]

  • default setting: disabled
  • generally recommended setting: disable

Another control which has changed in v1.5. The internal pipeline has been improved to the point where it almost always works, therefore this control is reserved mostly for debugging purposes.

If unchecked, the plugin will use it's own geometry transforms engine develeoped by the plugin author. This is usually more accurate (than the alternative, see below), and is required by some games, but it may be slower, depending on system. It is also missing some standard geometry engine features, and therefore requres your hardware to perform certain tasks that not all hardware can do (guard band etc.). The internal pipeliene has border control, meaning the edges of games with borders should be kept clean.

If checked, the plugin will use standard DirectX transforms. This could be faster on some systems, and should work on all graphics cards, but it's less accurate, hence not recommended. Some games will not work at all with external transforms. The external pipeline does not have border control so the screen edges may get messy.

"Force Depth Enable" [checkbox]
"Force Depth Compare" [checkbox]

  • default setting: disabled
  • generally recommended setting: disabled, for most games

These two controls force the relevant depth buffer operations to execute even if the N64 turns them off. This can solve some game or system compatibility issues. It is highly game and situation dependant, refer to browser notes for any games or situations that require this enabled (they are sometimes refered to as FDE/FDC). Try enabling if you notice depth problems, i.e. objects being front of objects that they should be hidden behind. Do not leave these controls enabled generally however, they are known to cause complications with many games.

"Emulate Primary" [checkbox]

  • default setting: disabled
  • generally recommended setting: disabled unless a game requires it.

If enabled, then if a game has "Primary Buffer textures" enabled via ROM Settings, it will be allowed to download textures from the primary buffer. Only a handful of games use this, and it causes a severe performance impact (see the following controls for possible ways to improve performance). Note that this may be required in order for you to play a game, but this is very rare - refer to browser notes.

"Update Less frequently" [checkbox]

  • default setting: disabled
  • generally recommended setting: user preference - depends largely on game (see below)

Note that this control applies to both primary and self-rendered textures.

If enabled, the plugin will skip downloads of alternate frames (in time). This can significantly improve speed of framebuffer use, however it will could make the resulting texture visibly jerky (depending on the rate at which the updates) and also some framebuffer operations will not work with this (i.e. the image won't come out at all).

"Use low resolution updates" [checkbox]

  • default setting: disabled
  • generally recommended setting: user preference - depends largely on game (see below)

Note that this control applies to both primary and self-rendered textures.

If enabled, the plugin will skip alternate lines (in the x space direction), i.e. every other column of pixels is left out of the image. This can significantly improve performance of framebuffer operations, however the loss of detail may be very noticeable (or not, depending on the game!). I would tend to enable this for a game like Mario Kart where the framebuffer image is small and a lower resolution probably won't be noticed, and keep it unchecked for something like the Zelda subscreen, where the framebuffer image fills the entire screen.


 Video Configuration - ROM Settings tab

This page covers configuration of one tab of the Project64 default video plugin. About other plugins.

All settings on this tab are saved in the RDB and are specific to each ROM. The controls on this tab are only available when a ROM is loaded, and will only affect the currently loaded ROM. Unlike core ROM Settings, all changes take effect instantly. The emulator should be supplied with the correct settings for each ROM - do not make any changes here unless you understand what you are doing. If you mess up the settings, you must reinstall Project64 (or at least, revert to the original (or better yet, the latest official) RDB - there is no "return to defaults" button, so remember what you changed!

  1. "Emulated Width" [text box]
  2. "Emulated Height" [text box]
  3. "Direct3D Clear Mode" [menu]
  4. "Self-rendered textures" [checkbox]
  5. "Primary Buffer textures" [checkbox]
  6. "Emulate Clear" [checkbox]
  7. "Disable Culling" [checkbox]

Note that there is one further setting that you should be aware of that cannot be controlled from this tab, because it works not on a per-ROM basis but on a per-calculated-uCode-CRC basis: this is detection of the RSP code simulation, or uCode detect for short , i'll cover it here this page.

"Emulated Width" [text box]

This refers to the native horizontal resolution of the game. This is normally autodetected correctly by the plugin, however in some cases this can go wrong, hence this control is available to allow you to force any resolution. Values must be integers (whole numbers). A sensible place to start is 320, the horizontal resolution of most N64 games.

Note that this control cannot be used effectively when a game has dynamic or mixed resolition!

"Emulated Height" [text box]

Exactly as per "Emulated Width", except for vertical resolution, tends to be used more often to correct PAL resolution problems, and has a typical value of 240.

Note that this control cannot be used effectively when a game has dynamic or mixed resolition!

"Direct3D Clear Mode" [menu]

Possible settings:

  • Default (0)
  • Only per frame (1)
  • Always (2)

The default setting ("default") means none and was always used in previous versions of the plugin.

"Only per frame" is a possible solution for games suffering from the "black layer" problem, where the whole screen is hidden behind a black layer. This was added in v1.5 for Chameleon Twist 2 and is also used for several other games.

"Always" is a possible solution for games suffering from screen clearing problms within a particular part of the screen. It was added in v1.5 for the sky in Perfect Dark, and is also used for several other games.

Non-default settings can cause problems with some games and should only be enabled if needed.

"Self-rendered textures" [checkbox]

This is a framebuffer control. Some games use a temporary buffer (not part of the rendering queue) into which they render a scene to later use in the game, a classic example is the picture of link on the ZeldaOoT subscreen. This can be achieved with very little performance hit hence it is enabled where we know it is used. Do not enable it unless needed, it's a waste of resources and could cause problems with some games.

"Primary Buffer textures" [checkbox]

This is a framebuffer control. Some games use the screen itself as a texture within the game. A classic example is the board ("jumbotron?") above the bridge in the first level of Mario Kart 64. This has a very serious performance impact, due to PC architecture (data must be copied from video card back into system memory every frame) hence it's checked here when a game uses it however the user must enabled primary buffer emulation via the advanced tab (which also offers possible performance enhancement options).

"Emulate Clear" [checkbox]

This is a framebuffer control. Some games use low level framebuffer clears for special effects. A classic example is the lens flare from the sun in Zelda. Some uses of emulate are quite subtle, it's possible that there were missed in the RDB. Emulate clear can cause problems with compatibility so should only be enabled when needed, however the performance hit is very minor.

"Disable Culling" [checkbox]

  • default setting: disabled
  • generally recommended setting: disabled unless a game has issues with culling

Note - culling has been improved in v1.5 to the point where we do not know of a single game that does not benefit from it, however this control is kept in case there is something discovered.

If unchecked, if the plugin determines that something doesn't need to be rendered it will skip the entire rendering sequence of that display list, which could take a great deal of CPU time to work through, hence you may see performance increases, but you might also see things disapear. The effectiveness of this depends on the game and the "intelligence" of the plugin.

If checked, the plugin will draw everything in the scene regardless of whether or not it will be shown, which guarantees that nothing is culled that shouldn't be, but will take some extra CPU time - usually not a great deal more, and not an issue on fast systems, so you can turn it off.

Setting up microcode detect references

Microcodes are nearly always detected correctly internally by the plugin and therefore it should not be something a user has to think about. However, the database is probably not complete and in v1.5 games can switch microcodes at any time during execution, thus the probability of a detect failure somewhere is rather high. We cannot force a particular microcode per ROM, so now the RDB file header is used. If you suffer a uCode detection failure, please refer to the RDB for an example of how to set this up.

uCode ID | uCode | example(s)
0 | RSPSW | Mario64, most early games
1 | RSPSW_EXT | Star Wars - Shadows of the Empire
2 | RSPSW_GE | Goldeneye 007
3 | RSPSW_PD | Perfect Dark
4 | RSPSW_DKR | Diddy Kong Racing
5 | RSPSW_RARE4 | Jet Force Gemini
6 | S1DEX | (sprite microcode)
7 | F3DEX1 | (most later games are either this...
8 | F3DEX2 | ... or this)
9 | F3DZEX2 | Zelda
10 | F3DEXGB2 | Conker's Bad Fur Day
11 | S2DEX | (sprite microcode)

These are all the different microcodes supported by the graphics plugin. Note that these are the real names for the microcode as taken from the game code. This is a technical subject beyond the scope of this document, it's enough for the user to know that if detect fails you should first seek an updated RDB file. Advanced users can add references themselves via the RDB. You must set the correct uCode - you either know, you ask someone who knows, or you find out by trial and error!


 Audio Plugin Configuration

This page covers configuration of the default Project64 audio plugin - Jabo's DirectSound v1.5. For information on other plugins please consult the relevant authors' documentation.

  1. "Volume"
  2. "Audio Logging"
  3. "Sync game to Audio"

Points

  1. The audio plugin does not include an audio emulator! It must be used in conjunction with the RSP plugin. The RSP plugin must be configured with "send Audio Lists to Audio Plugin" disabled or the audio plugin will recieve no audio data and hence you will hear no sound!
  2. The audio plugin uses a fixed audio buffer, size chosen carefully by the author.

"Volume"

  • default setting: 100%
  • generally recommended setting: user preference!

This control was added in v1.5 mainly as a way to balance Project64 against other applications. It's function should be fairly obvious. You can use the Up and Down arrows and Page Up and Page Down keys and Mousewheel as shortcuts. Setting all the way down is equivalent to muting the emulator.

This setting is global (applies to all ROMs), takes effect instantly, and is saved in the registry.

"Audio Logging"

This control has two buttons, Start and Stop.

If you want to save all the audio produced by the emulator to your hard drive, press Start. You will be prompted for a path and filename. You can close the dialog. When you want to stop logging, go back to the dialog and press Stop. Don't forget to stop recording, or you may get a corrupt .wav file!

Notes:

  • You can record for as long as you have hard drive space available.
  • You cannot record particular parts of the audio (background music, sound effects etc.)
  • Note that the file written is a simple waveform (datarate similar to a CD), so it uses a large amount of hard drive space.
  • You could edit the resulting file in any standard waveform editor, compress it to MP3 format, etc., as you wish.

"Sync game to Audio"

  • default setting: disabled
  • generally recommended setting: disabled

If disabled, the audio plugin will output the audio stream as it is supplied. There will be some degree of "popping" or clicking" as the core speed fluctuates slightly, but the core (and hence gameplay) is not interrupted. The benefits of this - smoother gameplay - probably outweigh the drawbacks for you.

If enabled, the audio plugin will stall (momentarily stop) the emulator when audio data is being supplied faster than it can output cleanly. This will prevent some artifacts, but will have a slight to severe effect on the peformance of the whole system. There are three degrees of severity to the side effects that enabling Sync can produce, which applies depends entirely on the game:

  1. slight (I would think noticeable to most people) loss of smoothness of the whole system* (e.g. Mario64, Zelda, most games)
  2. lowering in VI/s (reduction in speed of whole system*) from the normal value (e.g. 60FPS) to a new value (e.g. 45FPS) (e.g. Ridge Racer, Mario Party 2)
  3. complete stall of the whole system* (e.g. Turok2)

*"whole system" means the whole emulator, not your PC!

Notes:

  • If you enable "Sync game to Audio" you will not be able to use the speed limiter disable (System menu, shortcut F4) as a "fast forward".
  • "Sync game to Audio" is very useful in one particular situation: if you want a clean logged audio file (see below).
  • In v1.5 the "Sync game to Audio" setting is saved per-ROM in the registry.


 Input Plugin Configuration

This page covers configuration of the default Project64 input plugin. About other plugins.

  1. " Player1/Player2/Player3/Player4" [tabs]
  2. "Game Device..." [menu]
  3. "...deadzone of X%" [slider]
  4. "Plugged In" [checkbox]
  5. "Memory Pak" [checkbox]
  6. "Load Profile" [button]
  7. "Save Profile" [button]
  • default keys
  • instructions for setting keys
    • Analogue stick & Range
    • C-buttons
    • D-pad
    • other buttons

" Player1/Player2/Player3/Player4" [tabs]

The system supports four independant simultaneous sets of input, select the one you wish to configure by clicking the appropriate tab. Each is identical, but the four players correspond to the four physical ports on an N64 system, so you usually must use Player1 for a single player game, Player1 and Player2 for a two player game and so on.

"Game Device..." [drop down menu]

  • default setting: None
  • generally recommended setting: whichever input device (gamepad etc.) you wish the current player to use!

"...deadzone of X%" [slider]

  • default setting: 25
  • generally recommended setting: as low as is possible with your input device

This slider allows you to set the deadzone in 1% increments from 0 to 100.

A sensible range would be from 5% (a good quality controller) to 25% (a poor quality) controller.

The lower the deadzone, the potentially better your fine control, but the more likely you are to suffer from "ghost" movements and other input errors that arise from the less than perfectly accurate physical reading mechanism your device employs. A device read optically (such as a genuine N64 controller, on a USB port adapter) is likely to be more accurate (so you can use a smaller deadzone) than a device read by potentiometer (such as most current low-cost PC gamepads).

Deadzone only applies to analogue input devices! Leave it at default for digital devices.

"Plugged In" [checkbox]

  • default setting: enabled on Player1, disabled on all other players
  • recommended setting: enabled for each player you wish to participate

If enabled, the plugin indicates to the core (which indicates to the game) that there is a controller present on the relevant port (players1-4 correspond to ports1-4)

If disabled, the game will not find a controller present on the relevant port and any settings for that player are ignored.

"Memory Pak" [checkbox]

  • default setting: enabled
  • recommended setting: enabled

If enabled, the plugin indicates to the application that there is a controller pak present. The input plugin does not handle the mempak itself (only plugins with RAW capability can do this).

If disabled, the plugin indicates that there is no controller pak present (an empty controller slot). You will not be able to save a game that uses MemPaks.

"Load Profile" [button]

press to open a file browser to select and load a a complete controller profile for the current player, that you saved earlier, or copied from another location (see below).

"Save Profile" [button]

press to save the complete configuration for the current player to a file. you will be prompted for path and filename.

Default Keys

After installing Project64 you will find Player1 already given a basic keyboard control setup:

Analogue

  • L - left arrow
  • R - right arrow
  • U - up arrow
  • D - down arrow

C-buttons

  • L - delete
  • R - page down
  • U - home
  • D - end

Digital

  • L - Numpad 4
  • R - Numpad 6
  • U - Numpad 8
  • D - Numpad 2

A - X
B - C
S - Enter
L - A
R - S
Z - Z

Players 2-4 are not pre-configured (or enabled)

Depending on your keyboard layout, personal preferences, and what input devices you have available, you will probably want to change this (see below).

Instructions for setting keys:

  1. Choose the N64 control that you wish to set (e.g. the "A" button)
  2. Decide which keyboard key or gamepad button you wish to assign to it. If it's not a keyboard key, make sure you have the correct device selected under "Game Device".
  3. Press the small square button to the right of the control.
  4. You will see "Press Key..." and a countdown in seconds appear in the title bar.
  5. During this time, press the button on your input device that you wish to assign to that control. The first input detected is used.
  6. If you make a mistake or wish to change a control, repeat steps 1-5 for each control that you wish to change.

L, R, U, D denotes Left, Right, Up, Down directions respectively for each set of controls.

"Analogue Stick" [4 buttons and indicators] and "Range"

In order to allow people without analogue input devices to use Project64, the plugin accepts 4 buttons as a substitute for two axes.

If you have an analogue stick, set it in exactly the same way, but make sure the positive and negative direction of each axes is correctly mapped to a pair, i.e. L and R or U and D. Analogue input detected will be described as "Joy ..." e.g. Joy Left.

"Range" [slider]

  • default setting: 100
  • generally recommended setting: around 65% (see below)

New in v1.5, this sets the outer limit of your analogue movement, but like Deadzone, a smaller value gives better control. If you set this too low you will find that e.g. you cannot run fast in Mario64, if you set it too high, you will use up all your available range too early in the stick's travel (so you would find it harder to walk slow). This control is probably easiest to understand by experimentation. I have found values around 65% seem to be best, so that may be a good starting point.

"C-Buttons" [4 buttons and indicators]

This is the four yellow buttons on the right of an N64 controller. Set in exactly the same way as "Analogue Stick"

"Digital" [4 buttons and indicators]

This is the d-pad (4 way direction pad, cross-pad) on the left of an N64 controller. Set in exactly the same way as "C-buttons".

Other buttons

The remaining 6 controls correspond the remaining 6 buttons on the N64 controller (all are digital controls):

  • A and B are the main (blue and green) buttons.
  • L and R are the two "shoulder" buttons, on the top of the controller.
  • S is the recessed red START button in the centre of the controller.
  • Z is the grey "trigger" button underneath the controller.


Untitled Document

 Configuration of other plugins

Discussion of all the plugins you could use in Project64 (or even all the plugins included with Project64!) is beyond the scope of this document. I have covered only the default plugins here. For all other plugins, please consult the relevant plugin documentation, which will be supplied with the plugin, or the emulator it came with.

As a general point, it is recommended that beginners stick with the default plugins until they are familiar with the emulator. They are chosen as the defaults for a good reason - these plugins are the most thoroughly tested, system compatible and generally reliable, and the game compatibility lists etc. are produced with them in mind. Of course this doesn't mean you shouldn't try other plugins, it may well be possible to get better results and extra capabilities with some of them.

See Web Links


Using Project64 index

 Using Project64

This section will guide you through some common tasks.

Please select a topic from the list.


 Main window

Should be straightforward enough - starting fom the top:

Title bar, showing the internal name of the loaded ROM, followed by the app title and version number. A minimise button and maximise button (only available in the ROM Browser) and exit button.

File menu - deals with all ROM loading tasks, Start/End emulation and language selection.

System menu - only available while emulator is running, everything you will need while running games.

Options menu - all configuration is done from here, including access to main settings dialog and plugin selection.

Help menu - access to documentation and About information.

At lower left, the status bar, provides feedback on the current state of the emulator, and is also used for the CPU load statistics if enabled.

At the bottom right, the FPS counter.. note that this displays current VI/s or you can think of it as "Fields Per Second" of the CPU core, not Frames Per Second from the graphics plugin.


 Starting games

There are several ways to start a game in Project64:

  1. The ROM Browser
  2. File > Open ROM
  3. Recent ROM menu
  4. Shell integration

The ROM Browser

This is the generally recommended method of starting games, for many reasons, read about the ROM Browser here.

File > Open ROM

It is possible to use a standard Windows file open dialogue to start games. Go File > Open ROM, browse to your ROM file and double click the file - with the default settings the game will load and emulation will start automatically. If you are using this method, you won't have the feedback provided by the Browser, so you should be sure that you are opening a supported game and be aware of possible issues etc.

Recent ROM menu

Most users will have a small number of games that they play regularly. To make it easy for you to access these games without wading through all your games, Project64 saves a list of the most recently opened ROMs in the File menu, under "Recent ROMs". Every time a game is started, (unless it's already the most recent) it's added to the top of the list, and the others are all pushed down one place, so the most recent game will always be at the top, the second most recent second in the list, and so on.

By default the list shows only the 4 most recently started games, but this is adjustable

Shell integration

If you have associated your ROM files with Project64 you can start a game simply by double clicking the ROM file you want to start in Windows Explorer. Project64 will start and load the appropriate ROM automatically, bypassing the Project64 ROM Browser.


 Using the ROM Browser
  • Status and colour coding
  • "Notes" fields
  • Navigation, Sorting, Configuration

Points:

  1. The ROM Browser does not verify your ROMs! you must use a seperate ROM verification utility in conjunction with it - GoodN64 is what we use and highly recommend. See Reference > Verifying ROMs
  2. The "Good Name" is simply a field in the RDB that was filed in with the correct value at the time the RDB was made. It is included for people who have good ROMs without the right names, and to help the RDB author navigate the file. Don't make the mistake of thinking this verifies your ROMs! See point above.
  3. ROMs are identified in the Browser by a pair of CRCs in their header and a country code, which references a pair of CRCs and a country code in the RDB. This means that bad ROMs with codes that match good ROMS will be identified as their good counterparts! See point 1.
  4. Status categories, colours and notes come from the RDB file. This is supplied with Project64 but you may edit or change it (advanced users only).
  5. Any ROM with status "Unknown" is very likely to be a bad ROM, or should be assumed to be a bad ROM, because (very nearly) all the known good ROMs are in the RDB
  6. The Browser uses a cache (it creates a file in the Project64 root folder) to speed loading between sessions. Don't forget to refresh if the ROM folder contents have changed! Project64 does not do this for you.

the default "Status" colour coding:

You are probably famililar with the terms "Playable" and "Not playable" from other emulators. Although these words are easy for beginners, they have limitations which the authors of Project64 wanted to avoid (such as being open to a very large degree of personal opinion). Project64 uses the term "Status". "Status" is a definate category (the categories are explained below) giving a summary judgement about the compatibility of particular game with Project64 as a whole. For precise details, see the Notes fields. Status is a field in the RDB which the RDB author defines based on his and other peoples' experience of the compatibility of each game (this is where some human error inevitably comes in). Project64 uses the Status field to define a colour for each row in the ROM Browser. By default (with the RDB supplied) you will come across some or all of the following colours (depending, of course, on which games you actually have!):

"Compatible" (green)
The game is, to the best of our knowledge, fully playable, with no issues severe enough to seriously effect gameplay. Some judgement exercised here; being green does not equal "flawless", only the original console will guarantee that. Note that system requirements are variable within this category - minimum spec may not be enough to run all "Compatible" games. There is also the possibility of mistakes, because not all games can have been fully tested. However, a lot of these games have been completed in Project64, you should be reasonably confident that you can do the same.

"Issues (core)/Issues (plugin)" (muddy yellow)
These games can be played, but they have moderate to severe issues that may effect your enjoyment of the game. If a game is marked "Issues (plugin)" then switching to another more suitable plugin could resolve the issue. If a game is marked "Issue (core)" then you can't do anything about the problem short of rewriting parts of the core (out of the question for most people!) or looking for a newer/different version or a different emulator altogether. "Issues (mixed)", as you might guess, means that the game shows both core and plugin issues.

"Needs video plugin" (turquoise)
These games are (we believe) supported on the core of the emulator, but are known to have serious enough problems with the default plugins that they cannot be considered playable (although often it's just the menu portion of the game that's missing, and if you can get past this you might be OK). Because of this, and the obvious problems in testing a game we cannot see properly, you should consider core status on these games as being somewhat uncertain also. You need to find a suitable 3rd party video plugin to be able to play this game - one may or may not exist. Check your favourite emulation news sites.

"Needs audio plugin" (turquoise)
As for "Needs video plugin"(see above) but the issue is with the audio plugin rather than the video plugin. This sitaution is very rare.

"Unsupported" (dark red)
These games areknown to not work on the core of the emulator. No amount of plugin switching or settings fiddling will help you here, further (probably highly difficult!) development of the core would be required to get these games working.

"Broken (core)/Broken (plugin)" (brown)
You are advised to use an older version of either the Project64 application or a Project64 plugin to play this game. See Notes for details. Important! See which field the recommended is in. For example, if it says "use older version" in the Notes (default plugins) field, you only have to use an older plugin, NOT an older version of the Project64 application! Remember you can mix and match plugins and executables. Similarly, if it says "use older version" in the Notes (core) field, you should only have to use an older version of the Project64 application - you can continue to use the newer plugins! This way you are not missing out on all the other benefits of the newer versions.

"Region issue" (blue)
This is to let you know that although this ROM doesn't work properly, there is another version of it (i.e. the same game) that does work. Read the note to learn which area of the emulator has the problem and which version of the ROM you should use instead.

"Uncertain" (black)
It could not be determined before release exactly what the status of this game was... you'll have to try it and see for yourself how well it works... check for an updated RDB.

"Unknown" (grey)
This ROM has not been found in the RDB, OR there is no status defined in the RDB by the RDB author. A ROM is marked Unknown probably because it is not a known good GoodN64 ROM, and hence hasn't been included, because only good ROMS are supported in Project64. There is also chance that the reason you are seeing Unknown status is that you have a newer version of GoodN64 than the RDB was based on, so check for an updated RDB. If the ROM is still marked Unknown, you are advised to find an alternative ROM or add it yourself.

the "Notes" fields:

Notes (sometimes called "Comments" in other emulators ) are split into two fields in Project64 to reflect the fact that the core and the plugins are seperate and have seperate compatibility. (Each game's status is derived from both the core and the default plugin compatibility considered together).

When reading both Notes fields it will help you to keep this in mind:

  • most text is explaining known issues, such as a graphics glitch, that you cannot prevent.
  • most instructions to the user start "use..." - pay attention!
  • if the notes are particularly complex i preferred to just refer you to the GameFAQ, where i have more space to explain things properly. The GameFAQ is accessible from the Help menu.

Some abbreviation was necessary to keep the notes within the space:

  • the colon ":" is used to give an explanation, it stands for "for" e.g. "Framebuffer:flare" is shorthand for "enable Framebuffer for flare".
  • the semicolon ";" is used as "therefore" or "so" e.g. "doesn't start; use PAL version" means "the game does not start, so you are advised to use the PAL version (which does)".

some common abbreviations:

  • "res." = resolution
  • "v." or "ver" = version
  • (E), (U) etc. are standard GoodN64 country codes.
  • "NTSC" means US, Jap etc
  • "PAL" means Europe, Australia etc.
  • ? = RDB author was not sure about something!

ROM Browser Navigation:

In addition to using the mouse to move around the Browser (scroll bars, mouse wheel and buttons), you may find the shortcut keys speed up your navigation.

You can sort by any column by clicking in the header of that column - click once to sort descending, subsequent clicks reverse the direction of sort.

The browser is highly configurable.


 Saving & loading game progress
  • native saves
  • state saves
  • importing and exporting

Points

  1. It is highly recommended that you make regular native saves. Although state saves usually work OK, this is not guaranteed due to many things that can go wrong in the core and memory of the emulator. Native saves are more reliable (and smaller!) than state saves. By using both methods (rather than just state saves) you have a backup if anything goes wrong.
  2. For state saving to work the ROMs must be identical - that is, the ROM that the game was saved from must match exactly the one that the state is loaded into. You may be able to share native saves between different versions of a game, but you cannot ever do this with state saves. Project64 tags state files with ROM header information and will check for and prompt you on violation of this rule.
  3. Native save files must not be Read Only, games need to be able to read/write at any time. for example if you back up your save files to a CDR, when you copy them back to your harddrive they may still be marked read-only - you must change the attributes with Windows Explorer. Project64 does not do this automatically, in case you don't want your file to be updated for any reason.

Native Saves

To understand the game data saving and loading of Project64, you must also understand the N64's own saving and loading systems (if you aren't already familiar with them), because Project64 emulates all those systems.

There are four types of save system used on the N64...

  • EEPROM (a cartridge save type), which comes in two sizes:
    • 4Kbit EEPROM
    • 16Kbit EEPROM
  • SRAM (a cartridge save type)
  • FlashRAM (a cartridge save type)
  • MemPak (an optional hardware accessory for the N64, plugs into controller*)

...which we will call the "native" N64 save systems (to differentiate them state saving, which is something entirely different, see below).

The cartridge save types use either non-volatile memory (EEPROM, FlashRAM) or a battery (SRAM) to keep a small amount of writeable memory intact inside the actual game cartridge, when the power to the console is off. Although it is on the same PCB, this save memory is physically seperate from the game ROM chips - Project64 does not write to the ROM file or anything like that. You don't have to worry about the difference between EEPROM, SRAM and FlashRAM, because all three are handled the same from your point of view. You should be aware that MemPaks, unlike that other save types, can be handled by input plugins, which is logical if you consider the original system again.

  1. Whenever an N64 game would save to or load from its game cartridge, Project64 automatically updates a file called {internal ROM name}.{type}** on your hard drive (you can configure folders to choose the location). If this file does not exist, it is created as soon as the ROM is first booted, and is the only file Project64 will use for this game.
  2. Whenever the N64 game would save to a Controller Pack (MemPak), either Project64 creates a file on your hard drive, or the input plugin manages the saving process, depending on the capabilties and configuration of the input plugin (see plugin selection and input plugin configuration).

The resulting save files will be compatible with both other N64 emulators and a real N64 system (if you possess the means to insert and extract them (see importing and exporting).

*Mempak is required by some games to save, is an optional extra in some games, is not used at all in some games. Any particular game can use any one cartridge save type, and/or the Controller Pak. This is normally handled transparently by the emulator.

** for example, you are playing the game Mario64. Mario 64 uses the EEPROM save type, and your ROM has the internal name "SUPER MARIO 64". Therefore the save file automatically created and managed by Project64 will be called "SUPER MARIO 64.eep" in your configured folder.

State Saves

In addition to emulating the native save types, Project64 is also capable of saving the entire state of itself - everything that it needs to know to recreate an exact point in time during the emulation of a particular game.

can be broken down into two types:

  1. slot saves ("Quick Save")
  2. named saves ("Save As..."

A game saved and loaded in this way does not "know" that it has been saved and loaded - it is as if the interruption never happened. This is clearly something quite different to what you can do a real N64. This is called "state saving", the resulting file is a "state save" or "saved state", and will be relatively large compared to a native save file.

State save files will not be compatible with other N64 emulators unless they explicitly support the Project64 state save file format (at the time of writing, several do). It is worth noting that a state save file will also save any errors that may have occurred and be present in the memory of the emulator, and for this reason, state saves are generally less reliable than native saves, especially over a long period of time playing.

To provide you with more flexibility in state saving, a number of "slots" are provided. A "slot" is simply a number, which is associated with a particular keyboard key so that you can select the file with a single button press. The advantage of slots is that you save switch between quickly, the disadvantage is that you might have trouble remembering what you put in each slot! Every game has its own independent set of 11 slots, so don't worry about one game overwriting another.

Save As... just means you can choose a filename and location for your state save file. This is good when you finish a session and want to make a note of where you were in the game.

It is normal for the system to pause for a short while while generating, compressing and writing the save file. The quicker your system, the shorter the pause.

Importing and Exporting saves....

  • ...to and from other emulators
  • ...to and from a real N64 system

Project64 is compatible with the N64 saves (not necessarily state saves) from other N64 emulators and a real N64 system, but you may need to byteswapp the files (use e.g. Azimer's saveswapper utility) and you will definitely need to rename the files to what Project64 expects (see your existing save folder for the correct file name - if you are not sure what the filename should be, save in the game anywhere a file will be created and you can use that name). The format is also explained under "native saves" above.


 Cheating

The advanced cheat system contained in Project64 was developed almost seperately from the rest of the application and is not something I have had much involvement with.

Please consult the dedicated Cheats Website which you can find under Web Links. All users are strongly advised to visit the site.


 Taking Screenhots

There are two ways to capture screenshots from Project64:

  1. The standard Windows Printscreen function (PRTSCRN or ALT+PRTSCRN, these are keys on your keyboard!)
  2. The internal Project64 screenshot function (System > Screen Capture, shortcut F3)

What's the difference?

  • The Windows function copies the whole desktop (PRTSCRN) or the current window (ALT+PRTSCRN) to the clipboard, you must then paste the data into a suitable application such as Paint or Photoshop. The "clipboard" as it's known can only (usually) hold one shot at a time, so if you take another you overwrite the first. If you take shots while windowed, ALT+PRTSCRN will include the Project64 GUI.
  • The Project64 function writes sequentially numbered bitmap files (snap0000.bmp, snap0001.bmp ... snap9999.bmp) into the current Screenshots folder. If you take shots while windowed, it will not include the Project64 GUI. You can press the button as many times as you like (given enough storage space, up to 10,000 captures!)

Points:

  1. There is no included way to capture a video clip or animation sequence from Project64. You could try an external capture utility such as is provided by Microsoft.
  2. There is no included way to save directly to a compressed format file e.g. JPEG, you must use an external program to perform the conversion.
  3. Bitmaps written from the internal function will have the same colour depth as Project64 is currently running in.
  4. All screenshots from Project64 or the Project64 video plugin(s) published should credit Project64 and contain a link to the Project64 website.


 Resetting games

In case you are not familiar with the N64 console, it has a reset button. Pressing this is equivalent to turning the power off and back on - it's just smoother and quicker. Of course there is no direct power button equivalent on Project64, but the reset is emulated - go System > Reset ROM.

Keyboard shortcut: F1

Some points to note about reset:

  1. There is no prompt to reset, so be careful, it happens instantly. Make sure you save your game if you want to, there is no way to go back (undo).
  2. On reset, Project64 checks all core settings, so if you have made any changes to the RDB or general options they will take effect now.
  3. After resetting, PJ64 has no memory of any state loads before the reset. In other words, the RDRAM (the game's memory space) is totaly wiped clean. This is significant if you are using hacks/cheat codes or have core errors - do a native save, reset the ROM, and load through the game menus. This is a smart dodge that can save you when your states go bad or a combination of cheat codes ruins your game.


 Stopping & changing games

If you are finished playing and want to leave Project64 you can simply close the emulator like any normal Windows application (use the X, or File > Exit (shortcut). There is no need to End Emulation etc. before you quit. If you are going to be away for a short period of time you could leave the emulator paused (be default losing window focus or mininimising the window will automatically pause for you).

Project64 does not prompt you to save and does not save automatically on exit, so do not forget to make a state save if you want to be able to pick up exactly where you left off. You'll probably want to make a named save, so go System > Save As (shortcut) to open the dialogue and type in a path and name you'll remember.

If you want to play a different game,you can go back to the ROM browser to make your selection by choosing File > End Emulation, or you can go ahead and load it directly from File > Open or the Recent ROM menu, even while the old game is running. Project64 will automatically End Emulation of the old game and load and start the new one (without any promps, be careful!).

You can reset/restart/reboot the current game quickly without reloading the ROM.


 Multiple instances

You can have more than one copy of Project64 open and running at the same time!

The ability to have multiple instances can be a good thing, if you want to compare two windows side by side for example, or a bad thing, if you don't understand that there can be complications, or do it accidently! (i.e. if you start another instance without noticing you already have one running).

Points:

  1. Only one instance can have access to a particular save file at a time. So if you try to open the same game twice, you can expect the second instance to be denied access to the save data.
  2. Plugins could act in unexpected ways, depending on how they are written, for example, an audio plugin may only give sound from the first instance, or an input plugin may only send keypresses to the instance that has focus. The default plugins should work with all instances.
  3. Following on from the point above, this could also be complicated by your DirectX and hardware and driver capabilties, for example, the number of 3D rendering surfaces your graphics card can manage, or the number of audio streams your sound card can handle. These may or may not be issues on your system.
  4. Because the application uses the Windows registry, which is a centralised database, you cannot keep configurations seperate for multiple instances of the same version of Project64. (This was partly an intended effect).
  5. Clearly, running more than one instance of Project64 increases the system requirements dramatically. Don't expect any instance to run as well as it would on its own, unless you pause the others (if you only have one instance actually running at a time, and have sufficient memory, you shouldn't notice performance problems).


 Keyboard Shortcuts

Notes:

  1. The shortcut keys available to you depend on the state of the emulator (mirrors availability of the associated menu items).
  2. Remember you can also navigate the menus with the ALT+(key) indicators, e.g. by default ALT+F opens the file menu, then pressing S would Start Emulation (these keys are set up by the language file so they depend on the file and your current language selection).
  3. Note that CTRL+ key combinations open dialogues while F(function) keys have instant effects. F-key shortcuts are available while fullscreen but CTRL+keys are not.
  4. You cannot change the shortcut keys in Project64 (but if you have a gamepad with lots of buttons and good software you could map to those).

Available in browser and during emulation:

open ROM dialog | CTRL+O
settings dialog | CTRL+T
quit application | ALT+F4
start emulation | F11
end emulation | F12

Available during emulation:

switch fullscreen/windowed | ALT+ENTER/Escape
reboot ROM | F1
pause/resume emulation | F2
generate bitmap | F3*
enable/disable speed limiter | F4*
state quick save | F5
state save dialog | CTRL+S
state quick load | F7
state load dialog | CTRL+L
select quick state save slot | 0-9
always on top toggle | CTRL+A
cheat dialog | CTRL+C
edit cheats | right mouse button*
cheat button | F9

Available in ROM Browser:

refresh | F5
jump to top | Home
jump to bottom | End
up one page | Page Up
down one page | Page Down
up one line | Up arrow
down one line | Down arrow
jump to ROM starting with... | 0-9 A-Z
start selected game | Enter
open menu | right mouse button

*only available in Advanced mode.


 Project64 Troubleshooting

This section will help you to troubleshoot some common problems.

Please select a topic from the list.

Are you using any non-default plugins?


 Troubleshooting graphics problems

The first thing to understand is what level of graphics quality to expect. Games marked compatible should look generally good and not have any flaws serious enough to stop you playing the game. The screenshots you see on the internet should give you some idea what to expect. Perfection is not realistic to expect, regardless of how good a system you have, because the emulation isn't perfect, and nor are the APIs used (and, interestingly... nor are the games themselves).

Before you ask for help, please take yourself through the following questions:

  1. Is the problem a limitation of your video hardware? Do you meet the recommended specification? Remember that different games and different parts of games use different hardware features - only the recommended or better hardware can display everything the plugin is capable of. If you have poorer hardware, you may be able to get better results from older versions of the video plugin, which use less complex effects. You can see whether any problem is a limitation of your system or a bug in the emulator by selecting Reference Rasterizer in the video plugin options and comparing the result to normal Direct3D HAL - if the problems dissappears in Reference Rasterizer, it's your fault, if it doesn't, it's the emulator's fault. Basically.
  2. Does the problem lie with your video hardware drivers or driver configuration? Try newer drivers (or sometimes older drivers help). Be wary of tweak utilties and beta/leaked drivers. Make sure you uninstall drivers properly when changing them. For example, the ATI Radeon hardware is capable of drawing everything that PJ64 asks, but many of ATI's drivers aren't, and your system is only as strong as the weakest 'link in the chain'.
  3. Is it a problem with your video plugin configuration? Have you changed anything from the defaults?
  4. Is there an instruction you have to follow to configure the emulator specifically for that ROM? Check the ROM Browser Notes and GameFAQ, e.g. Nagano Winter Olympics you must resize the ROM to 128MB (this is a one off case!).
  5. Is the problem a known game specific issue? Check the ROM Browser Notes e.g. the Conker's Bad Fur Day has a problem with the pause screen. You can't do anything about known issues, except look out for an updated or better emulator.
  6. Is the game using a framebuffer effect at that particular point? Try all the framebuffer options to find out. The framebuffer can be used for all sorts of things that are not obvious to the user e.g. one of the gun scopes in CBFD multiplayer.
  7. Is the problem a known general plugin issue? e.g. the near clipping plane problem, you may only notice this in Extreme-G but its a general limitation of the API that effects all games.

Remember graphics problems are not necessarily the fault of the video plugin, they could also, though it less usual, be caused by faults in the core or RSP of the emulator you are using. If you are using Jabo's plugin with the core of another emulator, try with the complete Project64 package first.


 Troubleshooting sound problems

The first thing to understand is what to expect. Games marked Compatible should sound generally good with only minimal and barely noticeable (to most people) cracking/popping/clicking. Major stuttering or distorted sound, or missing parts of sound, is not normal. Perfection is not realistic to expect - occasional stuttering at a few points in a game is normal (although not necessarily un-preventable), often as the core slows down. Also a mild general stutter may be noticeable in some background music etc... this sort of problem is usually fixed by sync (but read the warnings carefully!)

Before you ask for help, please take yourself through the following questions:

  1. Are you running the game at the correct speed*? If the answer to this question is no, and you are below the correct speed, you have a performance problem, not an audio problem. If the answer to this question is no, and you are above the correct speed, you have almost certainly turned off the speed limiter (system menu, shortcut: F4) and must turn it back on in order to get good audio.
  2. Are there known game specific audio issues? Check the ROM browser and read the notes provided.
  3. Are you using the audio plugin or the RSP for audio emulation? Read RSP configuration if you don't understand the distinction. We recommend RSP low-level emulation.
  4. Are you using Sync game to audio? This option may be exactly what you need or it may be a disaster, please read the information there carefully.
  5. Has another application taken control of your sound card? Some cards can only play one stream at once, or another app may be interfering.

*NTSC games should be running at 60VI/s, PAL games at 50VI/s. If they are not running at exactly this speed or within a few VI/s of it (e.g. 57-61 is a reasonable range for an NTSC game) then there is no way you can get good audio (this is just a basic truth, not a flaw in the emulator).


 Troubleshooting speed problems

The first thing to understand is what speed to expect from Project64 - as a rough guide, the following specifications should be just fast enough for each game at full speed with the default configuration:

  • Mario64 - P2-450Mhz ?
  • Zelda - Athlon 800Mhz ?
  • Perfect Dark - Athlon 1.2Ghz ?

Points:

  1. Not all the suggestions below will improve performance for you. Some will only reduce quality, stability etc. You have to try them and see the effects for yourself.
  2. Some of these suggestions have the potential to do damage to your hardware or software or data or all three. Any such damage that results from your following the suggestions listed on this page is entirely your own responsiblity - take care and don't do anything you are no confident you understand - seek advice from hardware internet sites etc. if you need to.
  3. As a general rule, FPS in Project64 depends on your CPU, not your graphics card, because most users are CPU limited, not graphics card limited, but the graphics card can become the limiting factor at high resolutions with high levels of FSAA, or if you have a below minimum spec. graphics card.
  4. The generally most significant factors are listed first, descending to the least significant (i.e. the most to the least likely to help, in my opinion and experience).

Check problem is not being caused by one of your plugins - plugins can stall the emulator by design or due to bugs in their coding.

Hardware level

  1. increase CPU clock rate or upgrade CPU
  2. increase font side bus/RAM clock rate
  3. add RAM if you are short*
  4. choose a CPU with SSE (& MMX!) capability
  5. adjust RAM timings, cache timings etc.*
  6. increase graphics card clock rates*
  7. use PCI rather than ISA sound card
  8. disable any unneeded ports/hardware
  9. avoid IRQ sharing*
  10. use USB rather than Gameport input devices

Driver level

  1. update drivers, video card drivers, chipset drivers, sound drivers*
  2. use 16 bit colour desktop rather than 24/32*
  3. use lower level of anti-aliasing, or none at all*
  4. disable Vsync
  5. disable multi-display if your system supports it*
  6. use 16 bit z buffer (rather than 24/32)*
  7. use texture compression*
  8. lower or raise monitor refresh rate*

Operating System level

  1. shut down all non essential (background) processes
  2. disable findfast/file indexing/system restore/task scheduler etc.
  3. adjust process priorities
  4. use Win2K/XP series OS if you have enough RAM (192MB+)
  5. use Win98SE if you don't have enough RAM (WinME seems generally a bad choice)
  6. update DirectX version
  7. just rebooting Windows can help free resources
  8. clean reinstall Windows in extreme problem cases
  9. compact memory
  10. fix pagefile size
  11. move pagefile to fastest drive*
  12. defragment hard drive
  13. lower debug levels on DirectX
  14. don't use debug (usually beta) builds of drivers or DirectX

Application level

  1. don't run multiple instances of Project64
  2. fullscreen modes may be considerably faster than windowed modes*

Emulator core

  1. use Recompiler instead of Interpreter**
  2. disable the speed limiter (!)
  3. enable Register Caching**
  4. enable Advanced Block Linking**
  5. enable Larger Compiler Buffer**
  6. use less secure method to handle self-modifying code**
  7. don't enable the expansion pack if it's not needed**
  8. state saving and loading sometimes helps the recompiler**
  9. disable TLB (but only if not needed!)**

plugins

  1. use Direct3D HAL rather than RGB Emulation or Reference Rasterizer (!)
  2. use the RSP recompiler core rather than interpreter core
  3. don't use any form of Framebuffer emulation
  4. don't enable Sync game to Audio
  5. use a lower resolution
  6. disable "change blending mode..."
  7. enable Display List Culling
  8. use 16 bit colour modes rather than 24/32
  9. if you want true colour, use 32 bit rather than 24*
  10. use Double or Triple Buffering rather than Transfer Memory*
  11. disable RSP audio emulation (and use an HLE capable audio plugin if you want audio!)
  12. use Direct3D T&L HAL rather than Direct3D HAL, or vice-versa*
  13. use External Transforms rather than Internal, or vice-versa*
  14. choose 16bpp textures rather than 16 and 32bpp
  15. don't use anisotropic filtering*
  16. disable fog*

*effectiveness depends on system (hardware)
** effectiveness depends on game


 Troubleshooting stability problems

Stability problems can be broadly broken down into three categories, reflecting the complex nature of an emulator:

  1. System
  2. Application
  3. Game

System failures

This type of problem refers to a complete lock up of your PC or an operating system STOP error (BSOD), usually requiring a hard reset of the system.

There are no known bugs in Project64 (we cannot vouch for 3rd party plugins, of course) that would cause a system crash/lockup/other form of operating system failure. If you experience such a problem while using Project64, it is very likely that you have a hardware or driver or directx or operating system problem. Run diagnostic software and check that your system is stable in other Direct3D applications, games, benchmark utilities etc. Find some torture-testing utilities. Consult hardware documentation if you need further help. You could try changing plugins, and use dummy plugins to see if you can narrow down to one area thats causing the problem (doesn't mean its necessarily a fault in that area of the emulator, but that area of the complete system).

  • Check that other applications are not leaving your system (particularly video and DirectX) in an unusable state, by starting the OS with no other applications.
  • Check that the problem is not bad drivers, for example we have seen STOP errors being caused by drivers froma specific hardware company - use Project64 on any other company's hardware and in the same situation it works fine. Contact the appropriate organisation for technical support.

Application failures

This type of problem refers to an actual crash or hang in the Project64 application, resulting in a generic Windows error messsage "this program has peformed an illegal operation" or "this program is not responding" etc. The exact type of message depends on your version of Windows, but the point is that you are seeing a Windows error message not a Project64 error message - in other words, Project64 has failed to handle an error, which could indicate a bug in Project64 or a system failure:

  • Are you running a supported game with the correct ROM settings? A small number of games can cause Project64 to fail under some conditions.
  • Is your hardware OK? Memory problems, overclocking etc. can cause applications to fail.

Game failures

This type of error refers to an error in the Project64 application or plugin(s) that is handled succesfuly by the application or plugin error handlers. a good example of this is the "UnHandled OpCode" error (OK, the OpCode itself is unhandled, but the situation is handled - you can end emulation, reboot the game, or play another game, without Project64 crashing). Another example is a graphics Access Violation. This type of error neary always indicates a bug or a configuration error in the emulator.

  • Are you running a supported game with the correct ROM settings? Almost any game will crash without the correct configuration.
  • Anything you can do to improve core security (ROM Settings) may prevent the problem.


 Errors indicating bad ROMs

The following error messages nearly always indicate a bad ROM:

  • "Executing from non mapped space"
  • ""in a permanent loop that cannot be exited"
  • "failed to load word 0 / 2"

In rare cases, these errors indicate incorrect ROM Settings, so check you havent changed any settings... but the most probable cause by far is a bad ROM - verify your ROMS!


 Troubleshooting video initialisation problems

(Note - it is possible for other applications to leave your system (windows, directx) in an unusable state. in this case, the fault lies with the other applications, not PJ64).

"Direct3D failed to initialize your HAL device. Make sure you have a properly configured 3D graphics card compatible with Direct3D 6.0" - Why won't the D3D graphics plugin initialise?

There are quite a few possible causes of this, so please read this section carefully before asking for help - this is a fairly common problem.

The first thing is to ask yourself "Do I have a hardware 3D accelerator?". If the answer is "no", you cannot use the Direct3D HAL, and you effictively won't be able to use Project64, so go no further*. If the answer if "not sure", find out from the people who made your computer, or look in the Windows control panel for your model and find out on the web is it has 3d capabilities. If the answer is "yes", we can probably get you going, so read on :)

Have you exceeded the capabilities of your hardware? The simplest thing that may work is to try changing your desktop colour depth to 16-bit (that's "High Colour", not 16 colours). Some cards can only render in 16-bit mode, while others have issues in higher depths that stop then running PJ64.

Now check you have the most recent drivers for your video card properly installed. This means downloading the newest drivers from your card manufacturer's homepage, uninstalling your current ones using Windows Add/Remove programs (there should be an entry in there for them) and then running the install program for your newly downloaded drivers. After installation is complete, reboot Windows if the software doesn't force you to anyway.

If you've done this and the plugin still won't initialise, reinstall DirectX and the drivers for your chipset. You get DirectX from Microsoft's site, and you get your chipset drivers from your motherboard manufacturer's site. Reboot Windows and try again.

Next thing to try - fiddle with your video card driver options. If there is a tweak utility available for your card, download it (try www.tweakfiles.com) and use it. Relevant settings to edit are z-buffer depth, texture colour depth, and probably others depending on the card you have. If there is no tweak utility, look under Windows display properties (right click on desktop > Properties > Settings > Advanced). Your video card drivers may provide extra options on the screens there.

*You can technically run the D3D plugin using RGB emulation but the performance and quality will be dire even on the fastest of systems.

Graphics used to initialise OK but now won't, why?
 Probably because something has changed in your PC setup, most likely not in your PJ64 setup. If you have changed any system display related settings, like colour depth, z-buffer depth and so on, change them back to how they were when it was last working. If you can't remember, read the answer above.

If you have tried everything you can think of but still can't get it to init., don't panic - this has happened to me! You need to properly uninstall your display drivers, and reinstall them. This means using the Windows Add/Remove programs entry, and rebooting, BEFORE installing the (new) drivers. It doesn't usually matter whether you install the same version again or not, the important thing is that you completely remove all the relevant settings from the Windows registry. Your graphics card manufacturer may provide a downloadable utility to do this, in which case you MUST use that utility, it is NOT sufficient to simply change drivers through the Windows display properties screens.

If you are using any tweak utility that loads automatically on startup, DISABLE it before changing drivers as it may simply recreate the problem after you reboot!

If you have tried all this and it still isn't working, reinstall DirectX and chipset drivers, then try different (newer AND older) display driver versions. If it STILL isn't working, you've probably got something seriously wrong with your Windows installation and may need to reinstall windows.

The main point is, if it used to work and now doesn't, and you are using the same version of PJ64, logically it must be a problem in your system, so look carefully there.

Simply rebooting the PC often helps.

You could also try using a different video plugin!


 Troubleshooting - Access Violations

Access Violations, otherwise known as Fatal Exceptions, are a general error in the video plugin. Despite what some people seem to think, the Exception Handler (the code which catches the error and produces the error message) does not cause crashes, it actually prevents them - without it (as in old versions of Project64) an error would simply result in a hung display or crashed application - at least now you have some idea what went wrong and have a chance of solving the problem.

An Access Violation is usually, but not always, fatal (unrecoverable, and you lose game progress since your last save) - you be able to click OK and continue playing, but usually after the first message you will keep getting more errors until you quit the app. Although ending emulation will usually be sufficient, you are advised to always restart the app after the first error to make sure everything is reinitialised.

It is important to understand that access violations (and plugin failures generally) have (from our experience) only about a 50% chance of being caused by a fault in the plugin - the rest of the time the cause is the core sending invalid data to the plugin.

The error message itself is not very meaningful to the end user, so what I can do is give you a general list of possible solutions for you to try.

Do not try to save your game after an Access Violation, except to a to a new save file - you are unlikely to be able to continue from a state save made after an access violation.

Possible solutions to Access Violations:

in case the error is caused by a core fault:

  • anything you can do to increase security in the CPU core via ROM settings may solve an access violation. (If performance is concern, you may be able to revert to original settings as soon as you have passed the problem point).
  • try turning off all cheat codes and resetting the game. Cheat codes can cause Access Violations. Don't load previous state saves that were made while using cheat codes!
  • in case your core settings are already optimal but you have suffered a random core error (more likely to happen if you use state saves a lot), try making a native save, resetting the rom, and loading from the native save (avoid state saves). This ensures the contents of the N64 memory space are clean.
  • try different version ROM (e.g. different region etc. of the same game)

in case the error is caused by a plugin fault:

  • if the ROM is running on 4MB RDRAM, try 8MB. For some strange reason this is known to fix the problem in some games.
  • check video options are at defaults (particularly Framebuffer setting).
  • try different version ROM (different ROM of the same game)

If all this fails, try a different video plugin, or the same plugin in a different emulator, to see if you can narrow down the problem and find a combination that works.


 Seeking help online

So this file has failed to solve your problem? Don't worry, you can almost certainly get help online, as long as you give the right information and ask the right questions! Otherwise the people who could help, won't be able to help you, or at least it'll take longer to sort you out.

Possibilties for seeking technical support online:

  • Forums (message boads, discussion boards, whatever you want to call them)
  • Newsgroups
  • IRC

Some of the points below are covered elsewhere in this documentation but it's worth going over:

  • read all the documentation thoroughly first- the .txt files included, this document, and on the web: FAQs etc., thoroughly. Use the Search function on forums. Remember that it is unlikely that your problem is a new one, due to the sheer number of other users. Asking questions that are answered in these ways will naturally tend to annoy people!
  • use GoodN64 to verify all your ROMs, it is NOT good enough to say the game works in emulator X.
  • carry out your own diagnosis of the problem as far as possible.
    • try different plugins
    • try different versions of the plugin(s)
    • try the same plugin(s) in a different version of PJ64
    • try the same plugin(s) in a different N64 emulator
    • try different games, and different ROMs of the same game.
  • check that you haven't caused the problem by changing a setting - if in doubt, do a clean reinstall of Project64 and try with all default settings (or as many default settings as possible).
  • check the problem is not due to a lack of understanding of how the game is supposed to be played - visit a game guide/walkthrough website
  • is it a bug in the game? Believe it or not, there are bugs in games, often a surprisingly large number. You can imagine how fun this made coding Project64. game guide/walkthrough sites often have lists of known game bugs.
  • give detailed system specifications and emulator settings whenever relevant - if in doubt, give them. In particular, you should usually give all of this:
    • Operating System (e.g. Win2k SP2)
    • CPU (e.g. Intel P3 800Mhz)
    • Graphics card chipset and driver version (e.g. GeForce2 GTS w/ reference drivers v12.41)
    • DirectX version (e.g. 8.1)
    • Application version and settings (anything you have changed)
    • Plugin authors & versions & settings (anything you have changed)
    • RDB author & version & settings (anything you have changed)
    • Your GoodN64 ROM name(s)
  • include any relevant extra material, such as:
    • a state save (usually more useful than a native save)
    • screenshot(s) of the game showing the problem
    • screenshot(s) of the error message(s)
    • contents of any error log files generated by PJ64 or it's plugins

Please don't try to contact the authors directly, sorry but they are not a technical support service. You should be able to find people on the popular emulation sites who have the knowledge/experience needed and are only too pleased to help you.. ask around to find the best places.

Can you get other N64 emulators to work? If not, it's a pretty good sign that you're doing something wrong!

See Web Links


Game Compatibility Index

 Game Compatibility

Project64 has an "absolute" (maximum) compatibility of approximately 98% (calculated by number of good ROMs in the current version of GoodN64 minus the number of those ROMs not supported by Project64, converted to a percentage).

Project64 has an "adjusted" (i.e. more realistic, or "out of the box") compatibility of approximately 80% (my estimate of the percentage of ROMs that work well enough to play properly, meaning no or minor errors, with the default plugins).

You can place your own figure somewhere between these two :p

Click the lists on the left for some details of games that are known to work or not work in this version of Project64.

More complete compatibility information is provided by the Project64 ROM browser and RDB system.


Compatibility: Tested

 Compatibility: Tested Games

Being on this page in no way guarantees that the emulation of a particular game is flawless (only the original system will give you that), but you have a better than average chance of success with these titles. You will appreciate that it is not possible for a small non-commercial dev. team to thoroughly test hundred of games, in fact, its a rare luxury that any of us had time to sit down and really play a game, but when we did, here's what you might have found us playing :p

  • 1080 Snowboarding
  • Banjo-Kazooie
  • Banjo-Tooie
  • Beetle Adventure Racing
  • Blast Corps
  • Castlevania - Legacy of Darkness
  • Castlevania
  • Conker's Bad Fur Day
  • Diddy Kong Racing
  • Doom 64
  • Excitebike 64
  • F-Zero X
  • GoldenEye 007
  • Killer Instinct Gold
  • Legend of Zelda 2, The - Majora's Mask
  • Legend of Zelda, The - Ocarina of Time
  • Mario Kart 64
  • Mario Party 2
  • Mortal Kombat 4
  • Perfect Dark
  • Pokemon Stadium
  • Rayman 2 - The Great Escape
  • Rocket - Robot on Wheels
  • RR64 - Ridge Racer 64
  • Shadow Man
  • Snowboard Kids
  • Star Fox 64
  • Super Mario 64
  • Super Smash Bros.
  • Tony Hawk's Pro Skater
  • Tony Hawk's Pro Skater 2
  • Top Gear Rally 2
  • Turok - Dinosaur Hunter
  • Turok 2 - Seeds of Evil
  • Wave Race 64

+smaller amounts of many others.


Compatibility: Not supported

 Compatibility: Unsupported Games

The following is a list of all the USA/Europe games known at the time of release to not be playable at all in (any version of) Project64:

  • FIFA Soccer 64
  • NFL Quarterback Club 98
  • Taz Express
  • Top Gear Hyper-Bike
  • Top Gear Overdrive

+ a few games that were only released in Japan, and probably some of the Uncertains and others.

Some games require 3rd party plugin support and are clearly marked as such in the browser (e.g. Status "Needs video plugin")


 Compatibility List: other games

Other games are playable to some extent in Project64, ranging from as well emulated as the tested ones, to what you might find unusable, for any number of reasons - refer to ROM Browser for precise details, or read the ROM Database directly.


Untitled Document

 Project64 Reference

This section documents several aspects of the emulator that are not covered elsewhere. This information will probably only be of interest to more advanced users and people wanting to understand better how the system works. This is not a programmers' reference - please refer to the authors' documentation for such information.

Please select a topic from the list.


 Verifying ROMS

Though hardly specific to Project64, understanding and having good ROMs is so important to using Project64 successfully that I'm going to cover it briefly here.

First you need to download the following, which can be found on any good emulation website (see Web Links)

  1. The latest version of "GoodN64" by Cowering
  2. "GoodWindows" by Master of Puppets
  3. a file called "bin.zip" containing "zlib.dll", and some other files you might need.

If your ROMs are compressed, you need to download whatever utility is needed to decompress them - for example, if they end .zip, download and install WinZip, if they end .rar, download and install WinRAR, etc. etc.

Have your unverified and decompressed ROM files available somewhere on your hard drive, e.g. "C:\Temp"

Unzip all the utilities listed above to one folder on your hard drive e.g. "C:\Program Files\GoodTools\" (zlib.dll should end up in a "\bin" subfolder of this folder). Browse to the folder and run GoodWindows.exe.

  1. Select mode "Good Tool"
  2. Select "Nintendo 64" as system. You will be prompted to browse to GoodN64.exe. Do so.
  3. Set "Directory to work on" to the folder containing your unverified ROMs ("C:\Temp" if you are following my instructions exactly)
  4. Keeps "Options" set to "rename"
  5. Press the "Execute" button and wait until the program is finished. This may take some time.

Close GoodWindows and browse to you ROM folder ("C:\Temp" if you are following these instructions exactly) , and you will find GoodWindows has created some subfolders and text files. All known ROMs have been moved to a subfolder "N64ren". Any ROMs that are not moved and not renamed are not known by GoodN64, it is safe to assume they are bad - probably best to delete them.

So how do you know which ROMs are good? It's very simple, a good ROM will now be in the "N64ren" subfolder and have "[!]" in its name. If it does not have a "[!]" in the name then there is something wrong - the full key is included in GoodWindows, under Legend > Good Tools.

Only "[!]" ROMs are supported by Project64. If your ROM is not good, find another. Usually ROMs that are not good don't even start but sometimes they fail midway during a game - you do not want this!


 Project64 Known Issues & Limitations

These are bugs or limations or "missing" or unemulated features of the emulator that are known by the authors before release. I provide this information so that you don't wonder how to fix them (i.e. you can't, at least without programming...), and some of these things are not fixable.

This information is now kept online on a dedicated site where it can be updated - please see Web Links


Reference: Language files

 Reference: Translation & Language files

Background - how Project64 finds translations
 When Project64 is started it looks for all files ending .pj.Lang in the \Lang\ subfolder, opens each file, takes the line beginning "#1 # " (which will be the internal name of the language) and uses all of these to populate the Language selection menu. Note that the filename itself is not used except by us to identify the files.

Starting a new translation
To make a new translation file for Project64, simply copy one of the existing .pj.Lang files - it doesn't matter which, you'd probably take the original English, then open the copy in a text editor (such as Microsoft Notepad, included with Windows) and you can begin editing the text.

Preserving file layout
 Be careful that you don't change the formatting (layout) of the file at all. Every line must start hash-number-hash (e.g. #460#), then open quotes ("), then the actual text you want, then close quotes ("). Anything prefixed by "//" or contained within "/* ... */" is a comment and will be ignored by the emulator i.e. it is only for humans reading the file. Make sure you use Notepad to edit the file, not Word or some other complex program which might mess up the formatting.

Line breaks
 Line breaks (the movement from one line to the next, or line spaces) are taken literally, so to start a new line of text e.g. in an error message, you actually press ENTER in the translation file. Do not use the end quote (") until the end of the last line. (Also, don't use quotes anywhere in your text!)

Shortcuts
 To create keyboard shortcut keys, put a "&" symbol before the letter you want to as a shortcut. For example l#127# "&Load State" in the .Lang file will become "Load State" in the application and pressing "L" when in the System menu will instantly load a state :). These shortcut keys are optional. You cannot change the CTRL+ or Function key shortcuts via the language file.

Don't forget to test your file! Make sure it loads properly (if not, check for missing closing quotes), and that the text fits the space available (if not, abbreviate!)


Untitled Document

 ROM Browser Data Sources

The ROM Browser gets its data from several sources, and it's not apparent which field comes from where.

The following fields are read directly from the ROMs:

  • Filename (w/o extension)
  • CIC Chip
  • Country
  • CRC1
  • CRC2
  • Internal Name
  • Manufacturer
  • ROM size

The following fields are read from Project64.rdb:

  • Good Name
  • Status
  • Notes (Core)
  • Notes (default plugins)

The following fields are read from Project64.rdx (if available):

  • Developer
  • Genre
  • Players
  • Release Date

The following fields are read from Project64.rdn (if available):

  • Notes (User)

Any data not available will simply appear blank.


 Project64 Gossary

The glossary is divided alphabetically to speed searching.

Select the letter beginning the word or term you seek.


Glossary - 0-9

 4K EEPROM
One of the N64 cartridge saves types. The most common save type, used in e.g. Mario64. Autodetected by Project64.

16K EEPROM
One of the N64 cartridge save types. Must be set in Project64 via ROM Settings.

3rd party plugin
term used to refer to any plugin written to a Project64 pugin specification but not written by the Project64 Authors.

4MB
abbreviation: 4 megabytes. Size of N64 RDRAM with no Expansion Pak installed.

8MB
abbreviation: 8 megabytes. Size of N64 RDRAM with Expansion Pak installed.


Glossary - A

ABI
abbreviation: Audio Binary Interface,

ABL
abbreviation: Advanced Block Linking

Access Violation
a type of error that can occur during program execution, here most relevant to Project64 video plugin. Also known as a Fatal Exception.

AKA
abbreviation: "Also Known As" (slang)

AList
abbreviation: Audio List

Alpha
graphics term meaning roughly the same as "transparency"

Anisotropic

App
abbreviation: Application

Application
a piece of software, a computer program, code that can be run, binary, executable, in this case used to refer to the file Project64.exe.

Audio Binary Interface
See audio uCode. Term not usually used in reference to Project64 as it's only important in HLE audio emulation, Project64 has low level audio emulation.

Audio List(s)
raw audio generation data produced by N64 CPU and sent to RSP for processing (turning into a waveform you can hear), or in this case sent to either RSP plugin or audio plugin.

Audio uCode
Type of microcode used for sound generation. N64 games are programmed with audio libraries in a similar way as their graphics use graphics libraries. The term Audio uCode is not usually relevant to Project64 because it is not supplied with a HLE audio emulator.

Adaptoid
N64 controller to PC USB port adapter made and sold online by company called Wistech. Very popular amoung N64 emulator authors and users.

Advanced Block Linking
feature of Project64 core used to improve performance, available as option via ROM settings

aspect ratio
the relative proportions of a display, width vs. height. 4:3 is standard TV and monitor aspect and hence resolution ratio with square pixels, for example 640/480 = 4/3

AV
abbreviation: Access Violation


Glossary - B

Big Endian
Name for one possible byte order, usually used here to refer to the default/standard byte order of an N64 ROM (or "ABCD")

Bilinear

Bit
smallest unit of digital data, usually represented by binary 0 or 1.

BIOS
abbreviation: Basic Input/Output System, there is no BIOS in an N64, you have one in your PC.

Blending

Blending Mode

Boot
The process of starting an N64 game.

Boot Code
Small area of a ROM used to boot the game software, the N64 (and hence Project64) does not contain a BIOS and games must be started in this way from the cartridge. The boot code is contained within the ROM image, and the emulator must execute this code after loading the ROM in memory.

Boot Noise
random coloured pixels in the graphics buffer that can be seen during boot on older versions of the video plugin. Later versions hide this simply because it is unsightly.

Border Control
a feature of the internal pipeline of the 1.4 video plugins, prevents geometry straying outside the play area into the border (for games that have a border), hence keeping the borders clean.(In previous versions of the plugins users complained that the effect was unsightly).

Byte
8 bits.

Byte order
Low level arrangement of the data in a file, there are four possible byte orders for N64 ROMs, N64 native save files, etc.

Byteswap
The processing of convering a file from one byte order into another.

Byteswapped
A file that has had a byteswap operation performed on it. A file byteswapped twice could be back to how it started.

BSOD
abbreviation: Blue Screen of Death

Blue Screen of Death
common slang term for a Microsoft operating system STOP error screen, which is traditionaly white text on a blue background. Such failures indicate serious hardware, operating system or driver failures and are not recoverable (system must be hard reset).

bpp
abbreviation: Bits Per Pixel. e.g. in graphics a texture maybe be "32bpp" meaning 32 bits of data are used to descrite the colour of every pixel.


Glossary - C

Cartridge
The physicial media that N64 game software is provided in - a plastic case containing a PCB on which the ROM chips and often save media are mounted.

CB
abbreviation: Copy Buffers

CD
abbreviation: Copy Dlist

Central Processing Unit
hardware, computer microprocessor. Your PC CPU has probably a 32 bit Intel or AMD CPU. The N64 has a 64bit MIPS R4300i for its CPU, so this is emulated by Project64. When referring to the N64 and Project64, CPU is usually used to mean the R4k (rather than the RSP or your system CPU).

CF
abbreviation: Counter Factor (core feature)

CFB
abbreviation: Colour Frame Buffer (also known as the Frame Buffer or Frambuffer)

Core
The central part of an emulator, usually used here to refer to the emulation of the N64 CPU (i.e. the R4300i Recompiler or Interpreter) inside the main PJ64 application... also used to refer to the RSP recompiler or interpreter, or the centre of any major system.

Core security
term used generally to refer to measures taken to reduce risk of crashes in the core of the emulator, self. modifying code method is one of the most important factors (see ROM Settings).

Caching
Generally, a technique to speed up execution of a process, used in many places in PJ64 (ROM Browser cache, Recompiler Register Caching, plugin texture caching etc. etc. etc.)

CIC chip

Change Memory and Cache
One of the self-modifying code handling methods implemented in Project64.

Check Memory Advance
One of the self-modifying code handling methods implemented in Project64.

Check Memory and Cache
One of the self-modifying code handling methods implemented in Project64.

CMA
abbrevation: Check Memory Advance

Co-processor
hardware, secondary CPU designed to share load and/or perform specialist tasks in a system, for example the N64's RSP is a form of co-processor, in a PC a math co-processor is built into all modern CPUs.

Copy Buffers
One of the Framebuffer emulation methods implemented in Project64.

Copy Dlist
One of the Framebuffer emulation methods implemented in Project64.

CRC(s)
abbrevation: Cycle Redundancy Check

CRC1
N64 ROMs contain two CRCs, the first is appropriately called the CRC1. Used by Project64 to identify ROMs.

CRC2
The second of the two CRCs contained in an N64 ROM (see above).

Checksum
Code added to a set of data calculated based on that set of data, be repeating the original algorithm you have a way to verify that no part of the set has changed since the code was calculated, without adding significantly to the overall size of the data. Used by tools such as GoodN64 to verify N64 ROMs.

Cycle Reduncancy Check
see Checksum

Controller Pak
N64 hardware accessory, device which plugs into controller. Contains 256k of RAM in 123 "pages" (accessible blocks of memory). Emulated by Project64 internally or via input plugin.

Country Code
N64 ROMs contain a two digit code used to indicate country of origin, for example "45" means USA, "50" is for Europe, etc.

Counter Factor
core timing, basically type of speed hack, adjustable via ROM Settings, default of 2 in Project64.

CPU
abbreviation: Central Processing Unit


Glossary - D

 DList
abbreviation: Display List

DLL
abbreviation: Dynamic Link Library

Display List(s)
Raw graphics data produced by the N64 CPU and sent to the RSP for processing, and in this case the video plugin for high level emulation.

D3D
abbreviation: Direct3D

default
the state in which something is (deliberately) supplied - for example, a default setting in Project64 would the Geometry Transforms option being on Automatic.

Developer
In this context, the group who designed and programmed a game (e.g. as opposed to the those who released it).

Direct Sound
the audio related portion of DirectX

Direct3D
the 3d graphics related portion of DirectX

Direct3D HAL
Direct3D Hardware Abstraction Layer, selected as rendering device by applications to allow hardware/drivers to process 3D graphics

Direct3D T&L HAL
Direct3D Transform and Lighting HAL, alternative device available on hardware with hardware transform and lighting support, has different capabilities to standard Diredt3D HAL, intended to increase performance but largely reckoned to be obselete with faster system CPUs.

Directory
alternative name for "Folder" (Windows file system).

Directory Recursion
The process of "mining" down through levels of subfolders from a root folder to a depth in the directory tree - optional in the Project64 ROM browser.

DirectX
Name of complete Microsoft API developed for higher performance multimedia applications in Windows

Dinput
abbreviation: Direct Input

Direct Input
the input related portion of DirectX

Driver(s)
software written by hardware manufactures to allow their hardware to communicate properly with operating systems. There is a specific driver for each supported combination of hardware (e.g. GeForce3) and operating system (e.g. WindowsXP). I have noticed some beginners have problems understanding the difference between drivers and plugins - although two things communicate constantly during emulation, they are quite distinct: a plugin can be considered part of an application (e.g. an emulator), a driver can be considered part of your hardware (e.g. your graphics card).

Dsound
abbreviation: Direct Sound

DX
abbreviation: DirectX

Dynamic

Dynamic Resolution
term we use to describe games that change their screen resolution during play. e.g. Perfect Dark, and a significant minority of games.

Dynamic Link Library
exectuable code called from another application (rather being able to run standalone), see Plugin


Glossary - E

EC
abbreviation: Emulate Clear

ET
abbreviation: External Transforms (graphics plugin)

EEPROM
abbreviation: Electrically Eraseable Programmable Read Only Memory

Electrically Eraseable Programmable Read Only Memory
a type of non-volatile memory used in some n64 game cartridges to save game progress.

Emulate Clear
emulation of low level framebuffer clears (video plugin option)

Exe
abbreviation: Executable

Executable
see "Application"

Expansion Pak
N64 hardware accessory, 4MB of RDRAM packaged to plug into the N64 console and enhanced/required by some games, emulated by Project64 with 8MB RDRAM size option.

Extension
abbreviation: filename extension. The 3 letters following the dot in a Windows filename.

External Transforms
Using system/DirectX/hardware to perform geometry transforms (part of 3d graphics drawing process, video plugin option).


Glossary - F

F3DEX 1.XX
one of the graphics microcodes, implemented in the Project64 video plugin.

F3DEX 2.XX
one of the graphics microcodes, implemented in the Project64 video plugin.

F3DZEX 2.06H
one of the graphics microcodes, implemented in the Project64 video plugin.

F3DEXGB 2.08
one of the graphics microcodes, implemented in the Project64 video plugin.

Failed to rewrite Constant
type of error that can occur in video plugin, should be hidden from users AFAIK.

FDC
abbreviation: Force Depth Compare

FDE
abbreviation: Force Depth Enable

Force Depth Compare
a video plugin option (see video plugin, advanced tab)

Force Depth Enable
a video plugin option (see video plugin, advanced tab)

FPS
abbreviation: Frames Per Second or Fields Per Second (NOT equivalent! see explanations below).

Frames Per Second
term used to indicate graphics performance, the average number of discrete images displayed per second. N64 games can have a range of intended FPS, from as low as approx. 18FPS (e.g. Zelda) to as high as 60FPS (e.g. F-ZeroX). On a real N64 the real FPS is variable depending on the load, some games are reknowned for slowing down where there is lots of action on screen.

Field(s)
acharacterstic of televisions is that they are scan line interleaving - they draw all the odd numbered lines in one pass, then fill in the gaps in the next pass, then return to the first set, and so on. This gives rise to the term "field" used to denote one pass, which you can think of as half a frame.

Fields Per Second
simply, the rate of fields drawn. Fixed and depends on whether you are in a PAL (50 fields per second) or NTSC (60 fields per second) region.

Focus
Windows terminology, (only) one application or window can have "focus" at a time - the one you are currently working in, or is currently selected. Usually indicated by the title bar being a different colour to other windows.

FPU
abbreviation: Floating Point Unit. Part of a CPU, and part of the N64's CPU, hence part of Project64's core emulation. Used for fast floating point (as opposed to integer) math.

FlashRAM
Type of (non-volatile) memory used to save data in some N64 game cartridges, autodetected and emulated by PJ64.

Framebuffer
Memory space on N64 (area of RDRAM) used for some effects in some games, high level emulated by the PJ64 graphics plugin (advanced tab).

FtrC
abbreviation: Failed to rewrite Constant


Glossary - G

GameShark
'GameShark' is the name of a hardware device sold as an N64 accessory, but the system has been adopted by N64 emulators for their cheat systems and is mostly code compatible, with some exceptions. Allows the creation and application of a wide variety of codes to produces effects in games that were not intended by the game developers.

GBI
abbreviation: Graphics Binary Interface

Genre
Category/style to which a game belongs, such as Racing, Sports etc.

Geometry
Mathematical definitions of a 3d graphics scene in terms of vectors and triangles... the basic construction of any 3d scene.

Geometry Transforms
Method used to process geometry information

GFX
abbreviation: graphics

GFX DLL
see video plugin

Good Name
Name of a ROM given by GoodN64. Generally accepted as the correct name for a ROM for purposed of identiying specific ROMs.

GoodN64
Name of a software utility used to manage N64 ROM collections. Used as the basis for the Project64 RDB. Important to users as a tool to verify & identify ROMs.

GoodTools
Name of the serious of software utilities of which GoodN64 is one.

GoodWindows
Windows front end (utility) for the GoodTools, recommended for all users of PJ64.

graphics binary interfact
see RSP code simulation

graphics plugin
see video plugin

graphics uCode
see RSP code simulation

GS
abbreviation: Gameshark


Glossary - H

HAL
abbreviation: Hardware Abstraction Layer

Hardware Abstraction Layer

HDD
abbreviation: Hard Disk (Disc?) Drive (PC mass storage device)

HLE
abbreviation: High Level Emulation

High Level Emulation
Concept; a general technique in emulation whereby an author concentrates on the results and uses whatever methods are available on the host system. Can be thought of as simulation rather that "true" emulation, or as just getting the software to run and not worrying about the hardware. Made famous (and first taken to extremes) by the 1999 N64 emulator UltraHLE. In Project64 only the graphics are high level emulated.


Glossary - I

Image
alternative name for "ROM file"

Interpreter
technique in low level emulation whereby a relatively simple step-by-step conversion process is used to emulate a particular processor... one each of Project64's two R4k and RSP cores is an interpreter, this is a slow method, but the advantage of an interpreter vs. a recompiler is that its relatively easier to debug and make more compatible.

Idle
free, spare time, unused time

IRC
abbreviation: Internet Relay Chat.

Issues
problems, flaws, defects


Glossary - J

nothing here


Glossary - K

nothing here


Glossary - L

LAN
abbrevation: Local Area Network

Larger Compiler Buffer
a Project64 core option (see configuration > ROM Settings)

LCB
abbreviation: Larger Compiler Buffer

Legacy
Old or outdated hardware or software

Little Endian
Name for one possible byte order.

LLE
abbreviation: Low Level Emulation

Low Level Emulation
Concept, refers to the traditional approach to system emulation whereby you attempt to reproduce the exact output of hardware for every given input by a thorough understanding of how the original hardware works.


Glossary - M

Mbit
abbreviation: megabit

Mbyte
abbreviation: megabyte

Megabit
one million bits of data

Megabyte
one million bytes of data

mixed res.
abbreviation, slang: mixed resolution. term used in reference to video plugin resolution detection and setting, some games use multiple "layers" with different resolutions e.g. MarioTennis, which only becomes obvious/important when one or more of them aren't detected properly, so the layers dont line up. Particularly common problem in PAL roms in 1.4

MMX
abbreviation: Multi-Media eXtensions, an Intel CPU technology now standard in all CPUs, used to improve performance in several parts of Project64.

Memory Pak
see "Controller Pak"

Mempak
abbreviation: Memory Pak

MLE
abbreviation: Middle/Medium Level Emulation. Project64 used to contain an "MLE" RSP plugin, so called because it was a combination of Low level (audio) and High level (graphics passthrough) - hence "medium". In later versions the RSP was made configurable.

MS
abbreviation: Microsoft


Glossary - N

Netplay
common term for Network Multiplayer, i.e. multiplayer gaming over some sort of network, be it a LAN or the Internet.

NTSC
abbreviation: National Television System Committee. The TV standard used in the USA and Japan and many other places. Has 525 lines (480 active) at 60 fields per second.

Notepad
Microsoft text editor included with Windows. Recommended for editing Project64 support files. Earlier versions of Notepad could only work with files up to 64kb in size.


Untitled Document

Operation Code

OpCode
abbreviation: Operation Code


Glossary - P

PAL
abbreviation: Phase Alternate Line. The TV standard used in most of Europe and a few other parts of the world such as Australia. Has 625 lines (576 active) at 50 fields per second.

Pak
Nintendo's abbreviation for the word "Pack", which is what they call various hardware accessories for the N64, including the Expansion Pak, the Controller Pak, the Transfer Pak and the Voice Pak.

PAR
abbreviation: Pro Action Replay

Page File
File on a hard drive used by an operating system as an extension to physical memory, to reduce physical memory requirement. Use of pagefile is generally considered a bad thing for performance reasons.

Pages
A Controller Pak has 123 "pages", a page is the smallest "block" (unit) of memory that can be reserved by a game to save game data.

PCB
abbreviation: Printed Circuit Board. Hardware, on which most electronics are built, including for example N64 Cartridges, and the parts in your PC.

Physical Memory
term used to mean real RAM in a system.

Pipeline
abbreviation for Geometry Pipeline, synonymous with Geometry Transforms

Pixel
generally, the smallest point on a digitial display for which colour, position and depth etc can be defined.

Plugin(s)
executable code, a system component that interfaces with an application to carry out various functions, in this case vital ones such as graphics sound and input handling. allows parts to be swapped between emulators and assists users and developers. Plugins should not be confused with Drivers.

PJ64
abbreviation: Project64

Pro Action Replay
PAL version of the GameShark cheat device.

Project64
Name of this emulator, chosen by Zilmar. Project64 is name of the complete package, including the application, the plugins, the support files and the documentation - it is not just the application.

Project64 Application
The main executable file included with the Project64 package - Project64.exe. This contains the GUI, CPU cores, plugin interfaces etc. and is the programme you run to start Project64.

Project64 Authors
alias Zilmar and Jabo

Project64 Plugin
Term used to refer to any of the plugins written by the Project64 team. For example, Jabo's Direct3D6 video plugin is a Project64 plugin, but N-Rage's input plugin isn't, even though it's bundled with Project64. This is no disrespect at all to other authors, it' s purely for clarity in the documentation.

Protect Memory
One of the self-modifying code handling methods implemented in Project64.

Protected Memory
see Protect Memory


Glossary - Q

nothing here


Glossary - R

R4k
abbreviation: R4300i

R4300i
Hardware, the N64 console CPU, a customised MIPS 64bit RISC processor, low level emulated in Project64 by a choice of two CPU cores.

RAM
abbreviation: Random Access Memory.

RAW
Data supplied at its most basic binary level, used in reference to Project64 input plugin options.

RDB
abbreviation: ROM DataBase.

RDB Author(s)
person or people who wrote an RDB file - in this case, Smiff, if you are using the Official file included.

RDP
abbreviation: Reality Display Processor.

Reality Display Processor
Hardware, part of the N64 console system, area dealing with graphics. High level emulated in Project64.

RDN
abbreviation: ROM Database Notes, file used to store User Notes browser field

RDX
abbreviation: ROM Database eXtension.

RDRAM
Rambus DRAM. The type of memory used in the N64 console, used here to refer to the emulated memory space.

Reality Signal Processor
Hardware, part of the N64 console system, a co-processor clocked at 2/3 the speed of the CPU and used for most audio and some graphics processing, low level emulated in Project64 by the RSP plugin which has a choice of two cores.

Recompiler
Sophisticated type of low level CPU emulator, can give dramatically better performance vs. an Interpreter, used in Project64 for both R4k and RSP running concurrently, beyond the scope of this document to explain how a recompiler works, please consult programmers' documents if you are interested.

Reflection mapping

req.
abbreviation: requirement(s)

reg.
abbreviation: register

register
memory location, usually a small amount of very fast memory used by a CPU.

register caching
Sophisticated technique to improve performance of a recompiler, available in Project64 as an option via ROM Settings.

recursion
Process of repitition, see Directory Recursion.

region
the part of the world (usually a continent or country) that a game was released in, usually indicated with GoodN64 standard country codes e.g. (U) (=USA), (E) (=Europe) etc.

resolution
accuracy of definition of digital information, commonly used in reference to screen resolution, but can also be used e.g. Texture resolution. Native N64 resolution is 320(width)x240(height).

RC
abbreviation: Register Caching

Reference Rasterizer
DirectX allows Direct3D appplications to select a software mode which emulates a complete DirectX feature set (i.e. a theoretically perfect graphics card). This is very useful for developers, troubleshooting purposes, but too slow for actual gaming.

Rendering
process of drawing a 3d scene with lighting, shading etc, from its component parts and description.

Rendering Device
device used to render (draw) 3d graphics on a system, a plugin option. Direct3D HAL, Direct3D T&L HAL, RGB Emulation, Reference Rasterizer are Rendering Devices.

RGB
abbreviation: Red Green Blue, applies in many aspects of computing, indicates the common order for colour definitions (all colours in light are made from mixing relative amounts of these three primary colours).

RGB emulation
a software simulation of a hardware 3d accelerator, can be used as a slow low quality alternative. video plugin option.

ROM(s)
abbreviation: Read Only Memory, but here used as is to refer to game image files which are copies of the read only memory inside a game cartridge (they themselves are of course not literally ROM).

ROM Database
term used to refer to the file Project64.rdb, which is used to configure the emulator correctly for each individual game. Essential to the proper running of the emulator because not everything can be automatically detected with the optimal performance setting.

RSP
abbreviation: Reality Signal Processor.

RSP code simulation
term used in Project64 video plugin referring to HLE of the graphics microcodes. The word "simulation" is used because HLE by its nature is not true (low level) emulation.

RSP SW 2.0X
one of the graphics microcodes implemented in the Project64 video plugin. See video plugin, emulation tab.

RSP SW 2.0D EXT
one of the graphics microcodes implemented in the Project64 video plugin. See video plugin, emulation tab.

RSP SW 2.0G
one of the graphics microcodes implemented in the Project64 video plugin. See video plugin, emulation tab.

RSP SW PD
one of the graphics microcodes implemented in the Project64 video plugin. See video plugin, emulation tab.

RSP SW DKR
one of the graphics microcodes implemented in the Project64 video plugin. See video plugin, emulation tab.

RSP SW RARE4
one of the graphics microcodes implemented in the Project64 video plugin. See video plugin, emulation tab.

Rumble
Nintendo's name for a type of force feedback system used on the N64 console and emulated by some input plugins.

Rumble Pak
N64 accessory (hardware device), used to provide physical response in a game, a limited range of vibrations. Powered by batteries, plugs into controller.


Glossary - S

 SSE
Intel-designed PC CPU instruction set extension (similar to MMX, more advanced)

Self-modifying Code
N64 games are often (not always) programmed in such a way as they can modify themselves during execution, allows for more sophisticated games but makes stable emulation considerably harder. Zelda is an example of a game which uses self -modifying code, wheres e.g. Mario64 does not.

"Self -mod. code method"
abbreviation: Self modifying code (handling) method

Self-modifying code handling method
Project64 has a number of techniques to cope (avoid crashing) with self modifying game code (see ROM settings)

Shell Integration
You will be familiar with this even if you haven't heard the term - all it means is that your ROM files are associated with Project64 in Windows. Project64 makes changes to your Windows registry to allow this.

SMCM
abbreviation: Self -Modifying Code (Handling) Method

SRAM
abbreviation: Static Random Access Memory

Static
stationary, not moving, not changing.

Static Random Access Memory
type of non-volatile memory used in small amounts to save game progress in some N64 game cartridges e.g. Zelda1

Static Resolution
term we use to describe games that don't change their screen resolution during play. This is most games.

Status
term used in the Project64 ROM Browser to indicate the overall compatibility of a particular ROM with the emulator.

subscreen
in a game, a menu screen typically holding inventory etc. e.g. when you press START in Zelda, the subscreen appears.

Sync
abbreviation: Synchronisation

Synchronisation
term used generally, to indicate the regulation of speed of one component in a system to match another component. Relevant to several areas of Project64, such as audio.


Glossary - T

Texture

TLB
abbreviation: Translation Lookaside Buffer

Translation Lookaside Buffer
Complex part of the N64 CPU (and many CPUs generally) that must be handled by Project64. Available as an option via ROM Settings.

Transforms
abbreviation: Geometry Transforms

Trilinear

Tweak
slang, to adjust or fine tune hardware or software for better performance.

Tweak utility
slang, small software application designed to adjust settings of e.g. graphics card drivers, often settings that are normally hidden from customers/users. Usually a tweak utility can only be used on a specific card or narrow range of cards. For example, at the time of writing I use a tweak utility called RivaTuner to adjust settings on my GeForce video card.


Glossary - U

uCode
abbreviation: Microcode ("u" is a standard abbreviation for "micro"). Literaly means "one-millionth", but here refers to microprocessor code, very low level software used in graphics and sound programming on the console and which must be handled handled (low level, or high level) by an emulator.

Universal Serial Bus
PC interface, relevant to N64 emulators as a way to attach real N64 controllers to a PC (via a suitable adapter device) or of course native PC gamepads.

UO
abbreviation: Unhandled Opcode

Unhandled Opcode
type of (usually fatal) error that can occur in a core of an emulator, can be caused by missing features of core, bad ROM image, or incorrect ROM Settings.

USB
abbreviation: Universal Serial Bus


Glossary - Y

YMMV
abbreviation: slang: Your Mileage May Vary.


Glossary - V

V64
a standard N64 ROM file extension

validate blending
old name for the "Change blending mode if invalid for video card" option (video plugin, emulation tab), term still used by the authors, label was only changed to make it easier for users to understand.

video plugin
plugin used to handle all graphics processes in games i.e emulate the graphics systems of the N64, usually by high level emulation. Two video plugins are included with Project64.

Verification
general process of checking that something is genuine/correct/unedited etc.

Vertical Interrupts
any system that sends data to a television should time itself precisely to the fixed cycle rate of a TV, a VI is the interrupt (command signal) which in layman's terms means "start again from the top" (TVs contain electron guns which make continual passes over the screen area, from top to bottom, left to right).

Vertical Interrupts per Second
(read Vertical Interrupts above) as a result of the cycle rate of TVs has become a part of the speed regulation of games - 60VI/s for NTSC, 50VI/s for PAL. An emulator (in one major difference vs. the original sytem) will naturally just run games as fast as it can, so this speed has to be deliberately imposed via a speed limiter (System menu) if games are to run at the speed intended by the developer.

Vertical Sync
Vertical Synchronisation, in this case the process of timing a graphics card so that it only sends each frame when (i.e. it waits until) the monitor is ready to start drawing the next frame (this is not necessary - the graphics card can updated frames at any stage during the cycle, which causes image tearing as two consecutive frames are shown at once, the top of one and the bottom of the other). A Project64 video plugin option (display tab), also system dependant. There are advantages and disadvantages to using Vertical Sync.

VI
Vertical Interrupt

VI/s
abbreviation: Vertical Interrupts per Second

VM
abbreviation: Virtual Memory

Virtual Memory
Memory space, often as simulated on a hard disk, that emulates physical RAM, allowing an application to operate as though the computer has more memory than it actually does. Project64 allocates a large amount (gigabytes) of virtual memory and typically uses 100-200MB. Virtual Memory does not have to mean Pagefile - Project64 uses it to load ROM images, for example.

Voice Pak
one of the N64 hardware controller accessories, rarely used by games (Hey You Pikachu is one that comes to mind).

Volatile

Vsync
abbreviation: Vertical Sync


Glossary - X

nothing here


Glossary - Z

Z64
One standard N64 ROM file extension, indicates Big Endian byte order.

Zilmar
One of the authors of Project64, see credits.

Zilmar spec.
abbrevation, slang: Project64 Plugin Specification (Zilmar wrote the specifications).


 Project64 Credits

Project64 Team

Zilmar - founder. Core and application programming up to v1.4. Reverse engineering. Plugin specifications and basic plugins.

Tooie - lead application programming v1.5.

Jabo - video, audio and input plugin programming. Reverse engineering. RSP recompiler.

Smiff - bug tracking, management, design, testing, suggestions, rdb, end user support.

Witten - application programming v1.5, cheat system design and implementation.

Gent - cheat system design, cheat database, testing, end user support.

RadeonUser - testing

Thanks

The other N64 emulator and plugin authors who worked with the Project64 team over the years, best of luck to all of you.

Those who provided useful feedback. In particular people who went to the trouble of uploading saves, stills and video clips to help us.

Everyone who did translations for any version of Project64.

People who donated during the time Zilmar and Jabo were accepting donations.

Cowering for GoodN64, without which we'd all be in more serious difficulties than you might realise.

Martin and the Emulation64.com crew for hosting the forum and the website.

RatTrap for the website design.

The hard working moderators of the forum - bodie, mojo123, fizban and the others.

Wishtec for Adaptoids and software support.


 Web Links
pj64.emulation64.com | Project64 homepage
pj64.emulation64.com/support/ | FAQs, updated files
www.pj64cheats.net | support for cheat system
pj64.emulation64.com/issues/ | catalogue of known issues
www.emulation64.com | Emulation News
www.emutalk.net/forumdisplay.php?s=&forumid=6 | Project64 forum
www.jabosoft.com | Jabo's homepage
pj64.emulation64.com/emubook | Zilmar's homepage
www.smiff.clara.net | Smiff's homepage
www.gamefaqs.com | Game information
www.nintendo.com | Nintendo homepage


Untitled Document

 GUI Tour > System menu