I'd say it's more because of the undocumented dedicated video and audio processor they shoved in it.
Most of the issue is the 60vi/s target of emulation. People want to be able to play their games at full speed or above. The issue is that signal processors can't be emulated at their usual speed without seriously overshooting the specs. They're designed for speed. It's what they do. Compound that with emulating an overly complex video card that uses a different base concept than your typical PC card. Low level emulation on PC couldn't keep up with N64. They cut corners, and now it's time to do the opposite.
I've even seeing games that actually use lag to keep correct timing. Best example I can think of is The Legend of Zelda: Ocarina of Time credits. Just watch these videos:
TLoZ: OoT credits on the real Nintendo 64:
TLoZ: OoT credits on Project64 1.6:
Skip to 5:20.
In the real N64, you'll see the video runs at 8 FPS, trough audio goes at full speed.
In PJ64 1.6, the video runs at full 20 FPS... and the audio also goes at full speed.
By the end, you'll see the music is severely delayed from the video (and it's even cropped at the end), that's because the video goes way too fast (developers expected the console to slow down so audio can fully fit the credits scene). And even if you get PJ64 to slowdown to the correct speed, it also forces audio to slowdown to "keep sync".
Superman: The New Adventures also has similar issues (trough mostly related to video).
SPU synced, the video and audio end at the same point as the console.
the most obvious reason i can see, for the synchronisation defaulting to off, is the frame delay it adds is more excruciatingly obvious on a pc than it is on the console.
As deathdroid and Iconoclast (if he was unbanned) could tell you, the Playback rate on the n64 can change momentarily thus affecting the entire speed of the console, hence the reason why the frame rate suddenly drops while music remains at the correct rate on the console.
Iconoclast says (12:10 PM): *actually the DAC rate is calculated before the frequency, so a PAL game requesting 32 kHz would use an approximate DAC rate of 1551. but it could still be a different DAC rate than that even for PAL if the resulting requested frequency is different
Iconoclast says (12:11 PM): *and originally I used High School algebra to solve for the "correct" video clock numerator to divide by (DAC_rate + 1) to return 32,000 Hertz, but this only worked for games requesting just that frequency
Iconoclast says (12:12 PM): *in fact some of Nintendo's documentation suggests through the use of a function, that the game developer requests the "requested frequency" while the function returns the "actual frequency", so there is a chance that offbeat freqs like 32006 and 31995 might be correct in that context
Iconoclast says (12:14 PM): *currently, as an experiment just in case the correct behavior is to never have weird frequencies like that, I define a modulo base of fifty for rounding to the nearest frequency *from what I've seen, 50 is the greatest common factor of every requested Nintendo frequency I've seen written down, such as the min. and max. frequency limits Nintendo documented
Iconoclast says (12:15 PM): *there is another formula to calculate the frequency based on the audio bus half-period register, but it doesn't seem to be updated nearly enough as much as Nintendo says...the register is usually set to either 0 or 15, for a bitrate of 1 or 16 b/sample
I recall games on a real N64 had a lot of slow downs in game like perfect dark or golden eye. Do most of them happen in the correct spots in an HLE N64 emulator? I couldn't imagine them working properly if you're ignoring emulating an entire chip on the system even if it was synced properly to the audio / video. As I understand it HLE emulation just intercepts commands that are supposed to be sent to said processor (display / audio lists) then just turns it directly into something your PC understands with out any regards for chip / bus timing.
Please correct me if I'm wrong because I'm honestly just bsing this.
Edit: Nevermind, I was mixing up low level with cycle accuracy. I at least know there's very little people would actually notice in a cycle accurate emulator if all they're doing is playing games. I'm still happy people are working on accurate emulators though since it'll help out the faster HLE ones. It'd be nice to see a small number of graphical bugs fixed and a hand full of games that don't work at all working properly.
Last edited by Zuzma; October 10th, 2012 at 13:53.
As another interesting note, the second word in a ROM contains an oft-unused override for the default clock rate. On occation you get a retail cart that intentionally slows down the rate, but it's admittantly rare.
Not sure how accurately 'low power mode' is emulated, but it should affect performance significantly. Not that you'd ever be playing a game like that, but you get the point.
One aspect of cycle-accurate emulation is emulating the delay for a DMA transfer. If you wanted to be a jerk and 'detect' emulators, one tricky way to do it would be to anticipate them using instantaneous DMA transfers. For instance, when the bootstrap loads ROM for the CRC check, check the cycle count before and after, using a loop to test for the flag set when the transfer is complete. The lower the difference in cycle count the more likely it's an emulator.