The authors, team and associates will not provide them or help in where to find them, do not ask, by any means.

This policy is in place for legal reasons, you are advised to dump them yourself from your own game cartridges.

"When it's done" 

Please don't ask this question, since honestly even we don't know, it gets to be an annoying question.
It depends on many things which we cannot predict. We never announce details of upcoming releases or give release dates in case we cannot meet them.

If you are interested in finding out what's going on with PJ64 at the moment, please take a look at the donations programme.

It's looking unlikely that PJ64 will get ported to other Operating systems sorry because the authors just don't have time to do everything we want to do and rewrite it all, which is what most ports would require. If any port does happen, the most likely would be to Linux x86, which we would like to support, but even that is looking unlikely unless for example we got enough donations to replace our main jobs!

There are no plans to. The authors do not feel very much positive of interest has been achieved from the v1.4 source release several years ago. This, plus the fact that the authors may not have finished with the project, means there is little reason to release new source at this time. This is not negotiable and nothing will be achieved by strangers asking. People within the community with a genuine reason for working with the source will already know how to contact the authors. A particularly good way to annoy the PJ team and get a harsh response is to tell us you "need" the source to port it to the Xbox. Please don't do this, you certainly won't get it.

No, it was not implemented in the application due to time constraints and priorities. Perhaps some time in the (distant) future it may be.

Some input plugins may provide netplay capability, but their are doubts about the potential quality of this form of implementation.

A version of PJ64 called "Project64K", based on the old v1.4 source and made by 3rd parties with Kaillera support, is available if you wish to try searching for it, but we do not support this sorry.

We recommend getting people around one screen ;)
If you want netplay, you may wish to look for another emulator with proper built in online multiplayer support.

Project64 now has good enough compatibility that we think its acceptable (and more productive of our time!) to list games that don't work in the current version, rather than try to maintain lists of ones that do.

Search this site for all known issues and common questions per game, using the Good Name.
Unless you're told otherwise, you can assume any game is fully playable.

Please read the user manual, which covers this in depth.

The only compressed standard supported is .zip thanks to the standard ZLIB library. This is also used for compression and decompression of state saves. If your file is compressed with anything else (.rar, .7z, .ace etc etc.), decompress it with the appropriate program then try loading. If a ROM still doesn't work, verify the uncompressed file with GoodN64 (see elsewhere in documentation)

It's possible to use Project64 v1.6 with a frontend, but please read through and understand these points carefully before trying (v1.7 should support frontends better, with things like customizable shortcuts!).

• The command line sent to Project64 by the frontend must be right. Project64 puts its own quotes around the path and filename, so even for long filenames with spaces you don't add quotes (this is unlike most emulators, unfortunately).

e.g.
Project64.exe C:\Some path\some folder\some rom.v64 - OK, PJ64 will load this ROM
Project64.exe "C:\Some path\some folder\some rom.v64" - NOT OK, you'll get a Cannot load "file" error or similar.

Your frontend should have options to not use quotes - if it doesn't, and always sends with quotes, you cannot use that frontend with Project64. Ask the frontend author for support. 

• Project64 does not support any other command line parameters!

You should get the config (controls, plugin settings etc, per ROM settings etc.) right in Windows and preferably check each of your games first before trying to play games through your frontend. As you will not be using Project64's ROM Browser, it's recommended to become familiar with Project64's game compatibility by reading all notes in the browser for the games you have.

• PJ64 has an option to automatically go fullscreen after loading a ROM. You'll want to enable this, and your frontend should be able to hide the Windows desktop.
  

• PJ64 does not currently have a way to remap shortcut keys - you cannot change ESCAPE to exit instead of toggling to windowed. This can be a problem for frontends setups that expect all apps to quit instantly on ESC. (1.7 beta has shortcut editor!) The keyboard shortcut to exit Project64 instantly in fullscreen is ALT+F4 like a standard Windows app.

There are a lot of frontends in existence, of very varying price and quality. The only frontend I (Smiff) recommend and am willing to support is GameEx because it first supported PJ64 (before we knew about it) and now we are in contact with the author (GameEx is a free (nag screen asking for donations) frontend based on .NET that works on WinXP or MCE). It can remap Escape key to close processes, and also now it can exit PJ64 properly by sending ALT+F4. An example configuration for PJ64 comes supplied with GameEx so it should be easy to get working, it is verified by us to work well.

Very likely because you have a hardware or operating system problem. Project64 pushes hardware very hard and any stability issues will show up that might not while running ordinary PC software. There are no known problems with Project64 that would cause a system lockup. Torture test your PC to make sure it's not at fault e.g. by running a benchmark in a loop overnight without failure. Try other N64 emulators and swap components around. If your PC runs everything else without failure with Project64 being the exception, seek help online.

By default PJ64 tries to write saves to the \Save folder in its own folder. (Native saves are often created when games boot.) If you don't have write access to this location, you should specify a different folder in Options > Settings > Directories. Plugins may try to log into the app folder or subfolder \Logs aswell, though they should fail silently (?). Also, without write access to PJ's own dir, any changes to the RDB (ROM Settings) or CHT (Cheat codes) will fail, although most other settings are stored in the registry HKCU so you otherwise you should be ok.

• CPU: yes, low level
• RSP (sound): yes, low level
• RDP (graphics): yes, mixture of high and low level
• expansion pak: yes
• 4 players input: yes
• controller pak (mempak): yes
• rumble pak: yes via Force Feedback
• transfer pak: with 3rd party plugin
• voice pak: unsupported.
• 64DD: not emulated

Yes, Project64 does not attempt to write to ROMs folders, so read only media should not be a problem. Beware of any 3rd party plugins in your plugin folder that may try to write file(s) to the ROM folder, this could cause failures of various kinds. See also Question below.

Please see discussion on the forum.
Generally, loading other plugins in Project64 is not something we support for end users, because there's too many things that could go wrong, please consult the plugin authors.

If there is a real bug in Project64 (unlikely really since Project64 defined the spec.), the author can notify us and we may look at it. 

Members can report bugs on this site, other users please read the docs carefully and if you're sure it's a new discovery please make a thread in the forum.

Tested with Win9x/Me, Win2k (SP1&2) and WinXP (SP1&2), no known operating system specific issues.

Note: PJ64 v1.6 has only been tested on Win2k and WinXP 

Probably won't work on Windows95 or NT4 or anything older, we didn't test any further back than Windows98 first edition. Nor are any non-Microsoft OSes supported.

Yes: plugins for video, audio, input and RSP. The Project64 authors developed their own specification (hence "Project64 specification", or "Zilmar spec.") which has largely become the standard that other emulators have adopted.

Any plugin marked "Project64 spec." or "Zilmar spec" should work, but the issues that may arise are complex - please consult the author or his support people/documentation for help. 

Generally, the default ones. They are the most tested and understood. It's hard for me to give specific advice in this document because many 3rd party plugins are still under development and new ones will appear in the future.

Project64 plugins have always been released only with Project64 (download older versions of Project64 for older plugins). Other emulators are a good source of 3rd party plugins. Also try a good search engine or your favourite emulation news site. See the links section for recommendations. Again, a reminder that we do not support 3rd party plugins because it's impractical.

Each version of Project64 was supplied with plugins of the same version number - so the v1.3 plugins came with Project64 v1.3, and so on.

(This plugin is called "nVidia OpenGL " because it uses nVidia specific extensions (requires nVidia drivers) NOT because it's better for nVidia cards than the default D3D plugin). This plugin never reached the level of the D3D one, was discontinued and is not supported, but if you really want it, the latest version was available with v1.3 of Project64.

First you select the plugin under Settings > Plugins, press OK to activate, and then go "Options" > "[plugin type] plugin configuration..." You can't configure a plugin that isn't currently initialised, but you can configure before, during and after emulation.

This was removed in v1.2 as the two plugins were integrated into a single DLL with a configuration dialogue, hence removing the need for a selection. If you do want to swap RSP plugins, you can do so by simply moving and renaming the appropriate files (RSP.dll).

Probably because the plugin isn't compatible with the plugin specification version that your version of Project64 is to. Another possibility is that you have put the plugin in the wrong folder or set the plugins path wrong in Settings > Folders. Two other less likely possibilities are that it's a bug in the plugin (try another emulator) and that it's a bug in the emulator (try another plugin).

This is fairly confusing to explain but here goes: the 1.4(&1.5) application is backwards compatible with all public versions of the plugin specifications, so you can use for example the v1.0 video plugin in 1.4 .exe if you wish. The plugins however are not backwards compatible, so for example you cannot use the 1.0, 1.1 or 1.2 application with the 1.4 plugin (but you could use a 1.3 plugin with 1.4 app, because both 1.3 and 1.4 share the newer 1.3 specification, all previous versions were to the 1.2 spec.). The other types of plugin should be compatible across all versions. The application is not forwards compatible, because the authors could not know how the specifications might change in the future

No, and the command-line support that would be necessary to select plugins on load does not exist.

If you search the forum (as you should before starting a new thread!) you will find several references to this game. In summary: currently no plugin runs it well enough to be "playable", and the closest is Nemu's by Lemmy. Even if the Project team did succeed in getting these games working, you'd have to wait for the next release, hence, PJ64 forum is not the place to ask for this. If you would like to continue this discussion please use one of the existing threads, do not start a new one. You may be interested to learn that there are native PC versions of Rogue Squadron and Battle for Naboo.

Likely reasons: (1) Bad ROM (Read Reference > Verifying ROMS in User Manual) (2) You're not using default plugins and settings. It's unlikely that the browser information is wrong, but please check for an updated official RDB if you're not sure.

It means you CAN play this game in Project64, BUT you need to do something quite major: if blue, Region issue, you need a different version of the game, if brown, Broken, you need a different version of Project64. Read the notes to see which versions you should use instead of what you have.

Almost certainly the defaults and the ones supplied with Project64. If you have read the manual thoroughly and think you can do better, have a go, but remember what you did and be ready to put things back.

Do you meet or exceed the recommended specification (User Manual). Is the game marked "high system requirement"? Read Troubleshooting > Performance (User Manual).

"slow" in this context is often shorthand for "high CPU usage" - we have observed part of the emulator using higher than "normal" amounts of CPU time in these cases. These are fairly subjective judgements. If you are lucky enough to have a fast system, you may not notice any slowdown, because overall the emulator speed stays pegged at the limiter speed. It is likely that people on slower system are noticing the slowdown that the note refers to. Just ignore the note in this case.

Are there any specific Known Issues noted in the browser or this GameFAQ? Have you tried enabling Sync game to audio? Read Troubleshooting > Audio (User Manual) for general points about audio troubleshooting.

This first thing to establish that no background task on your PC is taking CPU time away from Project64. This could be something like a virus scanner, any scheduled tasks, disk activitity, just about anything. Use Task Manager to investigate and shut down as much as possible, also consider turning off services that your don't need (Win2/Xp) and programs that start with your computer (startup folder and registry).

One you have ruled out external causes, there are several things within the emulator that could cause this. The first is a plugin stalling the core, for example a video plugin flushing textures (occasionally unavoidable) or an audio plugin syncing game to audio. Eliminate these causes by changing plugins or adjusting plugin configuration respectively. The final possibility is that the core itself is pausing for one of several reasons, such as a compiler reset (rare but unavoidable) or some configuration options, Advanced Block Linking being a particularly likely culprit - try disabling ABL via Advanced tab to turn it off in all games where it's not essential (don't forget to reboot ROM to take effect). Other Settings that may help are Larger Compiler Buffer, Self-mod. Code Method, and Counter Factor. Please consult the manual for further details and do not adjust these settings unless you understand what you're doing. Some pausing may be unavoidable, depending on the game, but we have found that most IS avoidable.

Do you meet the system requirements (see User Manual)? In particular, do you have pixel shaders v1.1 or higher hardware - which are now used for many graphics effects in Project64 v1.6+? Have you changed any video plugin settings? Are there any known issues marked in the browser for this game, or in this GameFAQ?

Firstly, there are differences between monitors and TV screens that generally cause games to appear darker than they probably should. To set any level of brightness/contrast/gamma you desire, we recommend you use your video card controls (or your monitor controls!), which has the advantage of having no performance cost, and no negative effects. If your drivers don't already prodive this, 3rd party software like Powerstrip allows you to configure profiles for particular applications - you could have one set up for PJ64 to raise the gamma every time you start PJ64 and lower it whe you exit, for example. Note in v1.6+ there is a brightness slider in the video plugin options (requires pixel shaders v2+ hardware), but i do not recommend using this because there are some issues, for example brightness being applied double to framebuffer content.

First, if the borders are in pairs, that is on the left AND the right and/or the top AND the bottom, especially if they are equal size, you do not have a problem and cannot and should not try to correct it. These games are designed this way, on a television you might not see it because of something called overscan (advanced users: you may be able to extend the viewable area by using the external geometry pipeline, however this often causes artifacts because you are seeing an area you are not meant to see plus there are the usual weaknesses of that pipeline). One unusual solution to this is to "simulate" overscan by adjusting the range on your monitor so the inside of the black border is sitting on your physical screen edge. You will probably want to pick a resolution that you don't normaly use so this is only used for Project64! This of course only works for fullscreen. We experimented with various methods of stretching the display to fill the area, but all caused too many problems and we decided to leave them out.

If the the border(s) are only on the right and/or bottom of the screen, or of mismatched size, then it's likely that the plugin has not detected the resolution of the game properly. Resolutions are calculated from the top left corner. The RDB should automatically handle any custom settings that are needed here for you, but if not advanced users can try adjusting emulated width and height via the video plugin ROM Settings tab. You may need to window switch (fullscreen<>windowed) to let changes take effect. 320x240 is a good starting point if you do not know the res and lowering numbers tends to shrink borders.

There is a general weakness of the plugin with regard to the near plane, related to a limitation of the D3D API - objects drawn very close to the "camera" (screen) in the 3d world are clipped further out than they would be on the real N64. This tends to only be noticeable in some games, or at some times in other games. There is nothing you can do about this problem, however we don't know of any cases where it actually makes a game unplayable. Note this problem is much reduced now in v1.6+ with the D3D8 video plugin.

Project64 attempts to faithfully emulate the N64 as much as possible - on the N64 games can control exactly when and what type of filtering is used, and text and HUD icons etc are often not filtered because they're designed for a TV screen, where filtering would actually make them look worse. If you wish, there is an option to force filtering in the video plugin options - on your high resolution PC monitor this can often make things look better, however it may also cause problems with the legibility of text in some games, as characters may acquire a sort of halo around them - if you see this problem stop forcing filtering (see below).

This is a general problem with the plugin that cannot really be solved, however enabling Force Alpha Blending may give the results you want (or may cause other problems, which is why it's under Advanced and off by default).

Remember that nearly all N64 games are designed to played with an analogue stick. Most PCs don't have an analogue stick :) We highly recommend you purchase a gamepad with such a device, or if you cannot or do not wish to, you could get better control using modifiers in N-Rage's input plugin (included, select it in Settings, consult plugin documentation for further help).

No. please read the Manual if you haven't already, this is expressly forbidden. There are several reasons for this, the main one is user support, we have had bad experiences trying to support users who get an incomplete package.

No, as above. We want users to receive the complete package, it's better for everyone that way.

Yes but please do the authors the courtesy of clearly stating that the images are from Project64, crediting "Project64 team" (or the authors "Zilmar and Jabo"), and if the pictures are on the web, please provide a link to the Project64 Homepage.

Yes, but please clearly state that the graphics are from the Project64 graphics plugin, crediting "Jabo" as the author, and provide a link to (web) or the URL (print) of the Project64 homepage.

We're geeks not lawyers but we believe so, there is no copyright code and all technology was reverse engineered as is allowed by law... using the software to play games you don't own may be an illegal activity however.

You can move all the save files (which hold each game's progress) simply by copying the \Save subfolder of your Project64 install folder on the first PC to the same position on another PC, using a network or disc etc, after installing PJ64 on the 2nd PC. If you use a disc, be sure the files are made not-read only after the copy.

Be sure to make backup copies of your save files before doing this in case something goes wrong.

Note: Directories are configurable in Project64, this assumes you have not changed them from the defaults on both computers. 

First let me define a "low end" PC - at or below minimum spec (see User Manual).

Plugin selection: video: default, audio: try Azimer's audio plugin (3rd party) , Input: default.
Plugin settings: "send Audio lists to Audio plugin" enabled in RSP config, video config: 640x480x16 fullscreen.

Most settings probably fastest at defaults, try enabling ABL for some games, or raising counter factor, but read Manual on these controls first they can have negative effects.

Please see Manual > Troubleshooting > Speed for a full discussion of this topic.

First let me define "fast PC" - recommended spec or higher (see User Manual) .
I recommend you leave most things at defaults, except

1. you could disable ABL to possibly smooth some games
2. you could try changing CF to 1 as it smooths some games

But these settings do not always work so try at your own risk and be ready to put them back where it causes problems!

Hgh levels of filtering can be used in the video plugin.

Common causes:

1. background tasks on your system taking CPU time away from the emulator.
2. use of ABL.
   
3. there are possible issues with texture caching in some versoins of Jabo's video plugin, in some games and with some video cards/drivers - try newer or older plugins, or 3rd party plugins.
   

Check the GameFAQ for timing issues specific to the game (rare).

Some games have timing issues, sometimes you can slow them down by changing CF or enabling Sync Game to Audio.

Do you meet the requirements (see User Manual) ? Some games run slower than others - check that you can run Mario64 at full speed. See tips in this FAQ for configuring Project64 on slow PCs. There are many things that effect performance; plugin options, your PC, background tasks etc. etc..

Make sure you have the Speed Limiter enabled (System menu)

Because, like most Project64 users (and unlike most PC games), you are CPU limited, not fill rate limited (you are not limited by your video card).

This value is best thought of as "Fields Per Second" or internal VI/s, which stands for 'vertical interrupts per second', which is how often a real N64 system would be restarting it's scan from the top of the screen on a TV. This is fixed according to the TV standard in the country the game is released in, and is used in Project64 for exactly this reason - actual complete frames rendererd per second depends on the choices the game developers made when coding the game, for example F-ZeroX does run at a full 60 frames/second but Zelda renders only 20 frames/s. Thus the emulator always attempts to match the intended FPS of the game, no lower, no higher. It is not possible to change the video framerate without increading or decreasing the speed of emulation of the entire emulated N64 system, which basically causes audio problems.

The most significant are CPU clock speed and design, cache and memory system latency & bandwidth. Video card has very little effect on performance in most situations, neither does sound card or most other system components unless they are taking CPU time (e.g. disc drives are a prime culprit of this).

Check that none of your plugins are stalling the core - the most obvious would the audio plugin if you have Sync game to audio option enabled. Also your system may not be fast enough to run the games at full speed anyway.

If you don't have the speed limiter on, Project64 will attempt to run a game as fast as your system possibly can and so your CPU will be fully loaded regardless of how fast your system is or which game it is etc. If you do have the limiter on, this is a sign that your system is not fast enough to run the emulator at full speed in the given situation and configuration.

PCs are very slow at these operations (copying contents of video memory back into main memory), due to their architecture, and not because the plugin is bugged. This is up to future graphics card and system bus designers to improve, for now i'd suggest generally just don't use it. (For your information, the N64 is very fast at this because it has a single block of shared memory).

No, the first thing the emulator does is unzip the ROMs in RAM. It makes no difference to execution after this.

Currently (v1.6+, D3D8 video plugin):
GeForceFX (5 series) or higher, or Radeon 8500/9100 (R200 core) or higher is recommended. Pixel shaders v1.4 (GeForce4 level) is the minimum required for all features (i.e. DX8 level hardware or higher). The GeForce3 is mostly OK for the emulation, but you will lose the brightness slider. The GF4MX is NOT good enough - it's a DX7 level card, see below.

For the v1.5.x D3D6 video plugin:
Requirements are lower, but this plugin is also less capable (= less game compatible, less accurate) in many ways. nVidia GeForce2 or higher, or ATI Radeon (R100 core) or higher is recommended. This plugin generally gives better result on DX6 or DX7 level hardware than the D3D8 plugin - but the compatibility info we give for v1.6 (in the Rom Browser etc.) will not be accurate for you if you use the older video plugin. The D3D6 plugin is now considered by us obselete. Using a 3rd party video plugin is also an option for you of course.

If you have hardware between the two levels described above, it's usually better to use the D3D6 plugin, but you need to experiment - for some games the D3D8 plugin may be better (also try enabling "use legacy pixel pipeline" option).

If you are buying a new video card:
We do not recommend getting anything below Pixel Shaders v2.0 or later (a DX9 feature set card, we recommend a GeForce 6 series or later or Radeon 9500 or later). These cards are likely to be better for the future. Raw GPU speed (fillrate, clockrates, memory bandwidth) is not very important because of the low geometric complexity of N64 games compared to modern PC games. However, Pixel shaders are important. Anisotropic filtering and FSAA can make a big difference to how pleasing the image is.

See "What graphics card is recommended for Project64?"

We can't maintain a complete list but all cards based on these chipsets will run Project64 badly (at the time of writing):

1. anything Intel
2. anything Matrox
3. any ATI older than Radeon
4. any nVidia older than TNT
5. any 3dfx older than V4
6. any SiS
7. any S3.

Generally, the latest official drivers should be the best choice, but it's impossible for me to say for sure here as things are constantly changing.

The current known driver issues that affect Project64 (video plugin) on otherwise capable hardware are:

• on nVidia hardware: if your system has a CPU without SSE: missing geometry on internal pipline. If affected, we recommend you use drivers version 56.64 as these appear not to exhibit the problem of newer drivers (note these drivers may cause other issues with other software, we cannot do much about this!).

• on ATI R200 core hardware: 1) missing geometry in e.g. Goldeneye with FSAA enabled (reported fixed with driver option "alternate pixel center"). 2) possible depth buffer problems causing flickering of some decals e.g. green arrows in Mario Kart.

There may well be other driver issues that have not been reported - if you see issues in game which are not mentioned in the GameFAQ, try different (older or newer) drivers, or ask on the forum.

There are three main causes of this: In Project64 the video plugins work with Project64's RSP plugin to produce their full range of graphics. Other emulators require their own RSP or support for PJ64's RSP to produce these effects. Two, Jabo's video plugin may be using the Project64 RDB to load specific settings for the game. Three, the other other emulator may have faults in it's core that Project64 does not have that are leading graphics issues.

This appears to be a problem with some video cards, try either lowering your level of FSAA or Anisotropic filtering or try a different Buffer Display mode (video plugin).

This is a huge topic - Please see the Troubleshooting page

Use your graphics card brightness/contrast/gamma controls, or even your monitor controls. These can adjust levels without a performance penalty. If your graphics card is lacking the controls you want you can use a 3rd party utility such as PowerStrip to supply them.

For Fullscreen modes the plugin enumerates all available resolutions supplied by your graphics card driver, so if a resolution isn't listed, this is a limitation of your graphics card or drivers. Consult your system documentation. You may be able to add (custom) resolutions.

For Windowed modes, the plugin has a built in list of common resolutions and this cannot be edited, sorry. 

The video plugin now saves screenshots from its internal screenshot function in lossy compressed JPEG format. We felt this was more convenient for most users, who want to save large numbers pictures, upload them to the forum and so on with minimum hassle. If you want to save uncompressed images, use your OS screenshot function (PrtScrn, or ALT+PrtScrn) or a 3rd party capture utility.

All you should have to do is drag over PJ64 to the display you want and go into fullscreen then back to windowed to enable jabo's d3d8 video plugin to switch devices and allow for hardware acceleration. If you plan on playing on the TV on fullscreen then your primary display becomes "useless". Any click on the main desktop would minimize PJ64 and cause the video plugin to throw a bunch of AVs at you. The implementation isnt perfect but it *does* work quite nicely in windowed mode. This apparently only works on the same physical adapter.

This requires Pixel Shaders v1.4+ hardware, for example GeForce FX or Radeon 8500+. (*not* GF3 as these are only PS1.1, not GeForceMX as these have no pixel shaders).

Some games are made this way and this isn't a fault of the emulator (televisions have overscan, which may hide this).

Check the browser notes, a small number of games are simply missing sound, this will given in Notes.Check that you are getting sound in e.g. Mario64.

First check the obvious stuff - your volume is up, etc. ;) Check all settings are at defaults. Check RSP configuration is at default (Don't send Audio Lists to Audio Plugin!). Check your sound card is working properly. If still no luck, try changing audio plugin.

Recommended: Turn the volume all the way down and you can turn off audio processing in RSP to save CPU time (this method recommended because it won't reduce game compatibility).

Not recommended: Select "No Sound" as your audio plugin (and you might as well enable send Audio Lists to Audio Plugin in RSP config to save CPU time), OR

This is a complete topic, please read the troubleshooting page.

There are several ways to do this.

Jabo's audio plugin has a logging option, to use it:

1. Start the game and get to the music you want to record
2. Enable Sync Game to audio option to prevent crackles etc (Assuming game works with this option, not all do).
3. Turn off in game sound effects (if games has option) or find place or pause to prevent unwanted sound effects spoiling recording.
4. Under Audio Logging in plugin config, press Start and enter a path and filename for the .wav
5. Leave the emulator to play as much as you wish to record, then go back to config and press Stop
6. Use any audio conversion software e.g. LAME to convert the file to an MP3 or whatever format you wish (please refer to audio software documentation for help with this).

A 2nd way is to use the USF player (see {ln:Links}), which is based on Project64 source and specifically made for playing N64 game music.

The N64 has no convenient sound format that allows seperation of parts of music from sound effects, like the SNES for example.

Please see the Manual or look under Options menu > Configure Controller Plugin, where you can see what's set and also change them to be whatever you want.

Open the plugin config by going Options > Configure controller plugin (or similar). 

1. Click the square next to the N64 control you want to set
2. within 5 seconds, you press the key you want it to map to.
3. you should see the keyname/number appear. If it's a button on a gamepad, be sure to first select the correct gamepad in devices menu. See Manual for full details.

If you have any keypress mapping software installed for your input device, you may need to unload it first so it doesn't interfere with DirectInput.

This is up to the individual, but you probably want to get something as close as possible to a real N64 setup... if you are using a real N64 controller of course this is a non issue. Of course you know what an N64 controller looks like because you have one on your console...

All known input plugins (with the exception of the Adaptoid Plugin, which is a special case) are DirectInput based, which means that any 100% DirectX compliant input device is accepted, it does not matter what make or model. However, some plugins may support more types of control that others, if you're device has unusual controls (like rudders, throttles etc.) you may need a 3rd party plugin e.g. N-Rage's, included.

An Adaptoid and a genuine Nintendo N64 controller is the best, most authentic setup you can get. This gives you exact feel including rumble support.

If you can't get an Adaptoid, the next best thing is another N64-PC adapter, such as the one made by Boom, or a homemade N64 adapter that can link to e.g. a parallel port. This can give you very close feel but no rumble etc.

If you don't want to go the real-N64-with-adapter route, suitable PC gamepads include models from Microsoft, Gravis, Interract, Logitech and others. These are not as authentic of course but some people prefer different controllers.

Some specific PC pad recommendations are:

• Logitech Wingman (the old model with 6 face buttons)
  
• others, users please suggest!
  

Your controller must have:

1. an analogue stick and seperate 8 way digital d-pad.
2. at least 10 digital (on/off) buttons, preferably with 6 laid out in 2 rows of 3 on the front.

Some substitutions people have suggested for differences in the controllers:

1. for the Z trigger underneath the N64 controller, you can use another shoulder button.
   
2. for the yellow C buttons on an N64 controller, you can use a 2nd analogue stick.
   

Throttles, rudders and hat switches are probably not relevant for an N64 emulator, but you may find inventive ways to use them through your pad software.

Do you have it selected in the input plugin configuration? If it's not available there, you don't have it installed in Windows properly - consult gamepad documentation. Upgrading DX version has been found to help some people. Check you have the latest drivers and software for your gamepad

If the control is not a DirectX button, a slider, an axis, or another recognised control (depending on the version of the plugin), it will not be seen by the plugin, simple as that. What you may be able to do it use your keypress emulation software that is provided by you gamepad manufacturer to emulate keyboard key presses. You then bind these keyboard keys in the plugin instead.

Make sure all controls on your device, included sliders etc. are perfectly centred before trying to configure controls. Try increasing Deadzone if this makes it easier. Recalibrate your pad if it still doesn't go neutral properly.

Multiplayer is included with the default plugin, just enable on tabs 2-4 and configure keys.

With an N64 pad to PC adapter. There are several available for purchase over the Net - I use and recommend the Adaptoid.

Yes, with the default plugin you configure it just you would a normal PC gamepad. There is also an Adaptoid specific plugin which has greater accuracy and requires no configuration.

All of them via the Adaptoid plugin, Rumble and Mempak via some 3rd party plugins, none via default plugin.

No, there is no way to connect a microphone to PJ64 currently. Neither are real N64 mics through the Adaptoid supported AFAIK.

Try reducing deadzone and/or range. If you have software for your controller, fiddle with properties such as acceleration, range and deadzone if it provides the capability. If it doesn't, all you can do is buy a better gamepad or use a plugin that offers more options.

Try increasing deadzone.

Some video cards have problems at high resolutions and/or high levels of FSAA - turn them down.

Yes, you can use N-Rage's input plugin (included) for this, please refer to his documenation. Unfortunately rumble in Jabo's plugin does not work properly in v1.6 due to an issue with the application.

'Deadzone' is the portion of an analogue stick's range that is ignored by the plugin, so any movement within this area does not register in a game. What you should choose depends on the quality of your device. A good analogue stick such as you'll get via an Adaptoid should be set low e.g. 5%. A typical PC stick will require a higher value such as 20% to avoid ghost movements.

The preferred way is to use a device with an analogue input. If you are stuck with a keyboard, you could try using a plugin that emulates this movement via a mouse, but that is highly experimental and isn't likely to give satisfactory results, OR you can use a plugin that allows movement modifiers for the keyboard in the style of uHLE (see below).

This is possible if you use an input plugin that supports "modifiers" (combinations of keys that emulate degrees of stick movement). For example, N-Rage's input plugin. Please consult the plugin documentation for further information.

If the input plugin accepts a mouse, yes. For example, N-Rage's input plugin. Note that the authors agree that a mouse does not make a good input device for N64 games because it lacks a centre point, though the success depends largely on what options the plugin author provides and how well you can cope. Consult plugin documentation.

You cannot do this with the included plugins (you can make, save and load different profiles though).

Try a 3rd party input plugin like Darkman's (see {ln:Links}).

 

The RSP plugin performs the same job that the RSP (Reality Signal Processor) chip does in an N64, i.e. it processes some graphics and nearly all audio (this description sounds vague because the N64 is somewhat flexible in where it can perform tasks).

The RSP plugin selection was removed from Project64 in v1.2, because the features of both previous plugins (HLE.dll and MLE.dll) were combined into one (just called RSP.dll). You can use other RSP plugins by renaming them "RSP.dll" and putting them in the plugins folder (there are a few known 3rd party builds of the Project64 RSP generally with some small changes from the v1.4 source - there is no reason for most users to change the RSP).

Because the audio plugin you are using doesn't contain a high level audio emulator. None of the audio plugins included with Project64 do high level audio emulation, so you will need a 3rd party plugin with this e.g. Azimer's.

Because you were using the RSP plugin to process audio and you just shut it down - with no new audio data being supplied, the output plugin continues playing the last sound. If you reset the ROM you will get silence. See below.

Only when you are using an audio plugin with HLE capability (none of the included plugins) and want to let that audio plugin handle all audio emulation.

The RSP plugin contains a low level audio emulator. This means that (in theory) it accurately emulates the sound generation hardware of an N64, so the sound quality is near 'perfect'. However, this method of emulation places a somewhat high load on your system (though it is well optimised) - it may be that an HLE audio plugin will use less CPU time, which on slow systems will mean more time left over for other components, and hence the emulator might run slower overall when using RSP audio. I highly recommend you stick with RSP audio unless you are desperate for speed and find HLE audio significantly faster.

You need to install a 3rd party audio plugin with HLE audio capability (e.g. Azimer's Audio plugin). Then configure the RSP to send Audio Lists to Audio Plugin. Start a game and you should be hearing HLE audio. If you have problems, consult the plugin documentation.

The RSP plugin will continue to process audio as normal, and the audio plugin will handle output. Furthermore, the audio plugin will detect that its HLE functions are not required (since the RSP is performing emulation) and will disable them, so you are not wasting CPU time processing audio twice. The relevance of this is that if you find an audio plugin with better output buffering that the ones included in Project64, you can have the best of both worlds - the emulation quality of the RSP and the output quality of your audio plugin.

In this case the audio plugin selected will process audio lists (emulation) and handle output. This will have sound quality and performance connotations.