N64 Fps?

[Iconoclast]

Bare in mind that what looks like 60 FPS to you and what it looks like to other people is completely subjective. Some people are extremely aware of the low framerate, for example, in Ocarina of Time in-game, and some other people may not be able to perceive it at all. I personally, can just about perceive the difference between NTSC F-Zero X's smoothness (60 Frames Per Second in-game), and NTSC Ocarina of Time (just 20 Frames Per Second in-game, or three fold 'less smooth').

Some people may expect some games like Goldeneye to have a consistent framerate throughout, and so can perceive slowdowns (when the variable framerate in-game dips below their threshold of perception) and think this is a bug or a problem. However, these slowdowns are mostly normal to the real N64 and cannot be solved whichever emulator/plugin you use. If you are not getting 60V/Is (causing a slowdown), then that is definitely a emulator/plugin/low spec PC problem.

For full definitions of fields, fields per second and frames per second, they are in the PJ64 Manual Glossary under F.

Ah, thank you. Gotta use that glossary more often....

Yeah, but then there's the very beginning of the GoldenEye ROM. When you first start the ROM, wait for the logo to pass, and when those white circles start sliding in and Bond's theme starts playing, observe the video-audio sync. Now, try playing the game on the actual N64 in this exact area, and observe the video-audio sync. The N64 successfully slows emulation down, while Project64 does not. Is this an exception to the 20 FPS emulation Project64 usually succeeds at in the game?

 

[squall_leonhart]

this is actually known to zilmar and jabo and i think they've looked into it.... but i don't know if anything has come of it.

it is likely a core timing issue as it occured on the leaked 1.7 build, when i was checking it out.... it doesn't have the 1.7 core so it was using the 1.6 core.....

Clements don't you have 1.7? maybe you can check it out?

 

[Clements]

I agree with Squall, what you are describing there could be an inconsistency in the core timing in PJ64 (the emulation methods used by PJ64/1964/Mupen64 are world's apart from certain cycle-accurate emulators for less complex systems such as Nintendulator for NES, so this stuff is not to be unexpected). Many other games such as Bomberman 64 have a similar problem in PJ64 1.6 in the intro where the music is going too fast compared to the game and appears to 'finish too early'.

Clements don't you have 1.7? maybe you can check it out?

I don't have 1.7 as yet, but I hope to donate in the future.

 

[squall_leonhart]

actually, now that you mention it... the Majora's mask intro is too fast as well.

im 95% sure of it :|

 

[Iconoclast]

I agree with Squall, what you are describing there could be an inconsistency in the core timing in PJ64 (the emulation methods used by PJ64/1964/Mupen64 are world's apart from certain cycle-accurate emulators for less complex systems such as Nintendulator for NES, so this stuff is not to be unexpected). Many other games such as Bomberman 64 have a similar problem in PJ64 1.6 in the intro where the music is going too fast compared to the game and appears to 'finish too early'

Yeah, it's almost certainly core timing. I tried changing the Counter Factor option, from 1 to 6, still didn't fix it, but the audio-video synching definitely changed in the intro, just not to perfection.

As for Bomberman 64, I don't know if you remember way back then, when I posted this, but the intro sync issue can be fixed by changing the Counter Factor option to 1, a little something that has been added to the RDB.

Changed CF option from 2 to 1 (thanks Iconoclast).

Or it went at least something like that.

 

[Clements]

Just found out the reason why I was confused about this game: The PAL version of Bomberman 64 has subtlety different intro music to the NTSC version, so the NTSC version 'appeared desynced' to me.

The PAL version repeats the 'dun-a dun, da da da dun' part at the beginning of the intro music four times (getting louder each time) instead of two in the NTSC version. Try them to see what I mean. The PAL version of the Intro music is exactly how I remembered it. Interesting.

 

[Iconoclast]

That's the first time I've noticed a difference in the music used in the same game but different country versions.

 

[Doomulation]

Just for the record, we need to separate the two terms, FPS and VI/s.

FPS, or Frames Per Second is how many times per second the GAME updates the screen.
Fields Per Second, or the more technical correct term, VI/s, Vertical Interrupts per Second is how many times the actual console (or emulator in this case) updates the screen.

Since TVs run @ 50 and 60 Hz respectively (that means 50 or 60 updates of the screen per second), the console itself must update at that rate too (which is also why I'm guessing that games use a framerate dividable by that amount). Vertical Interrupt is a technical term that describes an interrupt in a system.

So yes, a game runs at 60 VI/s (or 50 for PAL), yet runs at a different FPS, depending on the game. Zelda runs @ 20 FPS and F-Zero runs at 60 FPS.
This should clear things up. Btw, as you may have understood by now, PJ's "FPS" counter at the bottom is actually VI/s.

 

[Iconoclast]

Alright, I get it, now.

'Dividizable'? You meant 'divisible', right? Man, it's not like I haven't seen a typo before, but it just sounds funny!

 

[Doomulation]

I think "dividable" is the correct term

 

[Iconoclast]

I think "dividable" is the correct term

Dividable: capable of being divided; divisible.

Meaning, both are correct. Although, 'dividizable' sounds like some sort of gangster remix of the word. Done laughing now.

 

[Coredo]

Woah... This topic makes me even more confused about the frames per second and fields per second than I was before. >_>

I always thought that 1 frame was about 2 field. >_<

 

[Doomulation]

They're different terms, and I explained what they both are on the last page. Still unsure?

 

[SubCog]

understand that unlike pc games, which are designed to run on a variety of machines, most n64 devs built the game entirely for the n64. They didn't code in such a way that a faster cpu could run their game faster. In fact, just the opposite, in optimizing the game to its fullest, they wrote code that was designed ONLY to run at a certain speed.

Because of this, the frames per second is directly linked to the gamespeed. Emulating the game at a faster fps is easy, as long as you're willing to play in fastforward. Think of it this way: All the same calculations are being done, whether its on the n64 or an emulator, so doing them faster means the game moves faster.

The hope is that very clever emulator programmers will be able to code hacks to allow games to run smoother than they were designed to run on the n64. However this kind of hack would likely have to be implimented on a per-game basis, with varying results.

Also consider that even if some very clever emu programmers did impliment such a fix and it worked perfectly, there are other parts of the game that you simply can't add extra fps to. You can't add frames of animation to models, for example, which have been hand animated at 20 fps. Also, many of the particle effects are coded to run at 20 fps. Explosions and other sprites only have so many frames of animation. Even if you got the core gameplay to run smooth as butter, other things will still look a tad bit funny.

 

[squall_leonhart]

HLE = Emulate the Game. (bios can be bypassed)
LLE = Emulate the Hardware. (usually requires the consoles bios)

 

[goldeneyepd fan]

man i have an eye for stutter and as long as the fields per second is at 60 (or 50 if its a pal game)

its smooth.... sure pal games do seem slower though...

Yeah, he's kinda right. I have an American RR64 and a PAL one, and the intro to the PAL one lagged a bit.