This specification should allow you to play any compatible 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.5Ghz or higher or AMD Athlon 1.5 GHz or higher
• 512MB RAM or more
• nVidia GeForce FX or later or ATI Radeon 9500 or later
• 1GB or more free hard drive space
• Creative Soundblaster Live! or higher
• Adaptoid and original Nintendo N64 controller for each player
• Microsoft Windows XP with latest updates.
  

Optional extras:

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

This specification will be sufficient for you to enjoy some of the 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 (leading to audio problems), and you will not be able to use all the options in the emulator. Look into using 3rd party plugins.

• Intel Pentium 3 700Mhz or AMD Athlon 800Mhz CPU*
• 256MB 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**. See below for realistic minimum video hardware!
• Microsoft Windows 98
• Microsoft DirectX 8

*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.

Realistic minimum video hardware for the v1.5x video plugin: 
nVidia GeForce256 (GF1) and ATI Radeon (early models) are suggested as realistic minimum video hardware. With good drivers they have the required features (blend modes etc.) for the D3D6 plugin.

Realistic minimum video hardware for the v1.6 or later video plugin
nVidia GeForce3 or ATI Radeon 8500 or later. With good drivers they have the required features (pixel shaders v1.1 etc.) for the D3D8 plugin.

Better cards mainly allow higher resolutions, filtering, anti-aliasing and so on without substantially increasing emulation accuracy.

The following graphics chipsets (thus 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)

You may find that Project64 usable on a lower-specification system than described here, particularly with some games and careful configurationm, and/or 3rd party plugins. If so then enjoy, but please don't expect too much, and we do not support below min. spec. systems sorry.

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.

The current version of Project64 is provided from the {ln:download section} with a Windows installer.

1. Download and double click the install file.
2. You will be prompted for the path on your hard drive where you would like Project64 to reside (or use the default path, which is in Program Files) and continue to click Next through the installer.
3. Run Project64 from the shortcut in your Start Menu.
   

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 the first time PJ64 is run.

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

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 {ln:verify 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).

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

 

Project64 v1.6+ has an uninstaller which makes uninstallation very simple: 

1. Go to Add/Remove programs in Windows and find Project64 in the list, highlight it and  click Remove.
   
2. Confirm choice.
   

The install only removes files that it put in your system. Extra plugins, saves etc must be removed by hand, this is for safety to make sure people don't lose saves or anything else.

Background Info for plugins.

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 you want to install 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.

How To Install Plugins:

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.

Notes:

1. Remember, if you are using 3rd party plugins the standard Project64 compatibility lists and notes may no longer apply to you!
2. Some plugins require extra DLLs which won't be included with Project64! Consult plugin documentation. Normally these extra files must be put in the root directory (alongside Project64.exe) not in the Plugin folder.
   
3. Generally, 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/stability of the application while using 3rd party plugins.

 

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. Minimise, maximise and exit buttons. Note that maximise is only available in the ROM browser. If you want to go fullscreen, this is under the Options menu or shortcut ALT+ENTER.

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.

• Status and colour coding
• "Notes" fields
• Navigation, Sorting, Configuration

General 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, and to make sure we're all using the same names. 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.

---

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.

---

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 (see below).

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 (see Application Settings).

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.
4. Project64 (v1.0-1.6) only emulates a Hard Reset, i.e. a full power cycle, it does not emulate the soft reset that some games e.g. Mario64 use slightly differently. There is little need for a soft reset that we can see.
   

  

 

 

There are two main types of save that you need to know about:

• native saves
• state saves

---

General 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.

• ...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.

The advanced cheat system contained in Project64 was developed almost seperately from the rest of the application and is supported seperately aswell. Please use the cheats site link under the support menu.

There are three ways to capture screenshots from Project64:

1. The standard Windows Printscreen function (PRTSCRN or ALT+PRTSCRN, these are keys on your keyboard!)
2. An external capture utility such as "SnagIt"
3. The internal Project64 screenshot function (System > Screen Capture, shortcut F3)

What's the difference between these different methods?

• 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 D3D6 capture function writes sequentially numbered Bitmap Image files (snap0000.bmp, snap0001.bmp ... snap9999.bmp) and D3D8 capture function writes sequentially numbered JPEG Image files (ROM File Name snap0000.jpg, ROM file name snap0001.jpg ... ROM file name snapsnap9999.jpg) into the current Screenshots folder (which can be configured in application settings). Even 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 per game!)

---

Important 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. Bitmap and JPEG Image files written from the internal function will have the same colour depth as Project64 is currently running in.
3. All screenshots from Project64 or the Project64 video plugin(s) published should credit Project64 and contain a link to the Project64 website please!

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, or 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 (by default losing window focus or mininimising the window will automatically pause for you, this is an option under app settings).

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.

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).

Important Points:

1. Only one instance of the emulator 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, resulting in an error msg.
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. 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).

Important Points:

1. The shortcut keys available to you depend on the state of the emulator (this reflects the 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.
4. F-key shortcuts are available while fullscreen but CTRL+keys are not.
5. 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).

---

Shortcuts 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

Shortcuts 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

Shortcuts 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.

 

 

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

If you 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 the advanced 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.

• 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 set to start with is {ln:input plugin configuration} (where you set up your controls), {ln:video plugin configuration} (where you set resolutions), and the Options tab (see below).

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 ships 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 (see Downloads section) or make/edit one yourself! (see Reference section).

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. The plugins do not yet support translation

 

(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:

1. What plugins are available at the time you read this!
2. Which games you play
3. Your system specification
4. 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.

Reasons to choose a non-default video plugin include:

• a game is marked "Needs video plugin" and you have a 3rd party plugin which you know does support the game
• 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.

Reasons to choose a non-default audio plugin include:

• you have no sound card, or a non-functional sound card - select the dummy audio plugin*
• you want to use HLE audio (perhaps for more speed on a slow system)
• you want adjustable or more advanced sound buffering of a 3rd party audio plugin
• you want e.g. any filtering and advanced processing options of a 3rd party audio plugin

Assuming all those capabilties are available in another plugin, please see Links.

*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 compatibility it is better to simply turn the volume all the way down.

Input plugin selection

Points

1. 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.

Reasons to choose a non-default input plugin include:

• you want mouse support
• you want "rapid fire" etc. capabilities, macro scripting 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 (rumble is broken in v1.6 with default plugin)
• 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.

 

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 usuall 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 you your games won't 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 keep in mind 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 recommended because cheat codes tend to 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!

---

 

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.

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.

 

(Options > Settings > ROM Settings)
Note: This tab is only available if Hide Advanced Settings on Options tab is unchecked

This tab 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"
12. "RSP Audo Signal"

 

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, because the settings are unique for each ROM, so be careful.

---

"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.

---

"RSP Audo Signa"

Possible settings: checked or unchecked

• default setting: unchecked
• generally recommended setting: unchecked for most, but enabled for certain specific games.

This option has allowed for some once unsupported Musyx games like: Hydro Thunder, NBA Showtime, Disney’s Tarzan  to be playable with either loading with sound available or now accessing speech although not perfect in games such as The World is Not Enough and Resident Evil 2.

 

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.

 

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.

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

1. Video Card [label]
2. "Windowed Resolution" [menu]
3. "Fullscreen Resolution" [menu]
4. "Full Screen Sync" [menu]
5. "Anisotropic filtering" [Slider]
6. "Full Scene Antialiasing" [Slider]
7. "Brightness" [Slider]
8. "Super2xSaI textures" [checkbox]
9. "Always use texture filter" [checkbox]
10. "Hide Advanced Settings" [checkbox]

---

"Video Card" [label]

This is your graphics card name as known by Windows - in v1.6 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.

---

"Windowed Resolution" [menu]

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

• default setting: 640x480
• 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.

Widescreen windowed resolutions

848x480, 1024x576 and 1380x768 (depending on your desktop full screen resolution) will make PJ64 windowed act like a WS view for a delightful new gaming concept, although still in its experimental stage! try playing Zelda OOT or MM with "adjust aspect ratio..." checked in the ROM Settings tab for a proper generated widescreen with correct aspect that even the real N64 can't produce :)

---

"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 640x480 16-bit 60 Hz (Refresh Rate)
• generally recommended setting: 640x480 32-bit, 1280x960 32-bit 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, which is also a good N64 resolution.
• see points at top about resolution choices.

Changes take effect next time you go fullscreen.

See points under "Windowed Resolution" above!

---

"Full Screen Sync" [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

• 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.

---

"Anisotropic filtering" [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: Off
• 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.

---

"Full Scene Antialiasing" [Slider]

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: Off
• 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

---

"Brightness" [Slider]

• default setting: Off (100% game default)
• generally recommended setting: user preference (ideal for dark games likes Doom64, Quake II etc) GF2 cards or lower are not supported on this function.

---

"Super2xSaI textures" [checkbox]

• default setting: disabled
• generally recommended setting: disabled \ user preference

doubles the size of textures using a special enhancement filter so you can get the best overall experience with it. there may be a small performance hit when you use this enhancement but the effect in most cases would be worth it.

---

"Always use texture filter" [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).

---

"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!

 

(Options > Configure graphics plugin... select Advanced tab) Hide Advanced Settings on Settings tab must be unchecked for this tab to appear.

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

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

Controls available:

1. "Adjust game aspect ratio to match yours"[checkbox]
2. "Use legacy pixel pipeline"[checkbox]
3. "Force alpha blending" [checkbox]
4. "Wireframe Rasterization" [checkbox]
5. "Use Direct3D transformation pipeline" [menu]
6. "Force Z compare" [checkbox]
7. "Copy framebuffer to RDRAM" [checkbox]

---

General 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.

---

"Adjust game aspect ratio to match yours" [checkbox]

• default setting: disabled
• generally recommended setting: disabled.

if the game doesn't support the aspect ratio for the display you have chosen this will change it manually but may cause problems

---

"Use legacy pixel pipeline" [checkbox]

• default setting: disabled
• generally recommended setting: disabled

Use this option on high end video cards if you experience problems with coloration or blending

---

"Force alpha 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).

---

"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).

---

Use Direct3D transformation pipeline [checkbox]

• default setting: disabled
• generally recommended setting: disable

The internal pipeline has been improved to the point where it almost always works, therefore this control is kept mostly for debugging purposes and cases where it is faster.

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 Z compare" [checkbox]

• default setting: disabled
• generally recommended setting: disabled

This forces the relevant depth buffer operation 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.

---

"Copy framebuffer to RDRAM" [checkbox]

• default setting: disabled
• generally recommended setting: disabled

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) so if enabled it will make the game run very slow and you will be better off without that kind of loss to performance.

Untitled Document Direct3D8 Video Configuration - ROM Settings tab

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

All settings