Hi all,
I know there are countless posts on this but I can’t find one specifically answering these questions.
How many Input lag frames did the OG n64 have for mario64 specifically since apparently each game varied?
How do you test the input lag on retroarch, I’ve been using k to pause the game press the jump button and hold it while counting how many k presses until Mario jumps.
Is there any settings for parallel that can shave frames off?
This measures emulation frames. It’s helpful, but it’s just that. Emulation frames. It doesn’t measure other sources of latency.
It looks like 2 or 3 in this video: https://www.youtube.com/watch?v=qTmJzfd5kEU
The k method is appropriate for measuring internal latency frames.
Framebuffer emulation adds a frame, IIRC, so disabling it gets rid of that, but I’m pretty sure that’s only in mupen64plus-next and not in ParaLLEl-N64. AFAIK, your best options are the normal ones: hard GPU sync with 0 frames and frame delay as high as you can go without crackling (or automatic frame delay with a relatively high initial number; it’ll even itself out)
That’s 30FPS frames though. If the core runs at 60FPS (check “Display Statistics” in RA) and duplicates frames, then frame step would give you 6 frames of lag. 6 lag frames at 60FPS is equal to 3 lag frames at 30FPS.
So if I use the muppet core with hle glide64 plug-in that 6 steps goes down to around 2 which seems like it’s better then hardware at this point. The key for me is I want accuracy so is 6 what I would get with a OG hardware on hdtv or is it simply higher because of other factors?
Again, you need to enable display statistics to see what FPS the core requests. If it’s 30, then 2 to 3 frames matches hardware. If it’s 60, then 4 to 6 matches hardware.
Ok so it appears mario 64 is 30fps because i dont have full speed turned on i want as close an experience to native as possible. Im getting 6 frames is there anyway to lower this with parallel?
Im using a 3090 with 8x upscaling at 320x240. I have run ahead on but i dont believe that works for n64, i tried frame delay with a setting of 4 I have hard gpu sync with frames set to 0. Any help would be great. I must have missed something.
ok so i turned on the fps counter and it appears the game is running at 60 fps. This means 5-6 frames as stated above is the correct amount of frames, i ask this question, how come using glide64 instead of parallel, it drops to 3-4? Which is more true to the actual console?
ParaLLEl-RDP is much more accurate than glide64. However, if you’re going for accuracy, you should probably switch over to the mupen64plus-next core and use the ParaLLEl-RDP (or Angrylion RDP) with it, as it has had a lot of timing improvements since ParaLLEl-N64 core was forked off from the upstream codebase.
*just to be clear, the ParaLLEl-RDP plugin is different from the ParaLLEl-N64 core, and that plugin is available in both N64 cores.
Can i use native upscaling with mupen and parallel-rdp?
Mario 64 runs at 30fps. The 60 number refers to the refresh rate. It only means that the game is running at full speed. As a 30fps game it also means it repeats each of it’s frames once, to fit evenly in the 60hz refresh rate.
That also means it should have more lag than a 60fps game. I don’t know where the idea of a 30fps game having less frames of lag than a 60fps one comes from. Repeated frames means repeated frames of lag. If you had 1 frame of lag on a 60fps game, it would translate to 2 frames if it was 30fps because it would repeat it. If it was a 20fps game, it would be 3 frames of lag.
That’s why games that run at higher FPS generally also have less lag.
Ok so is 5-6 frames true to console then? Or at least close and how come the different plugins decrease it to 3-4? Is there any other setting I should try. Smash bros with the same settings only produces about 2 frames before it responds while star fox is 8-9. Thoughts?
On my end i’m getting 4-5 frames with Mario 64.
Smash Bros gives me only 1 frame of lag.
Starfox also gives me 4-5 frames of lag.
Smash Bros is a 60fps game and a very responsive one at that. Mario 64 and Starfox are both 30fps. However, i’m not sure why i’m getting 5 frames of lag most of the time and not. 5 is an uneven number that doesn’t fit in the 60hz window. Maybe it’s because i’m playing on a Gsync monitor? Maybe the game itself drops frames/slowdowns? That’s true for Starfox but Mario 64 is pretty stable most of the time. So, dunno.
You seem to get more frames than me though. Are you sure you are emulating US/NTSC Roms? PAL roms run slower (50 or 25 fps) so that would maybe add 1 frame or 2 of lag.
I’m using Mupen64plus-next + Parallel RDP.
The reason other plugins are more responsive is because maybe they have framebuffer emulation disabled by default? But that would make the games look/behave differently than the real console.
Anyway, i’m not sure if my numbers are accurate to a real N64. It doesn’t feel slower on my GSync monitor VS the real game on CRT. I do know Beetle Saturn adds more internal lag though since Saturn games do feel more laggy than the real console.
Oh and if i try Mario 64 on my regular LCD TV, the game feels more laggy even though the numbers are the same. Frame Advance only counts the internal frames of lag but you still have additional lag from a crappy modern TV.
Im going to try with the same core and see if i get the same results. Are you able to do native upscaling with muppen and the parallel rdp? Which gpu front end are you using or you have it set to auto?
Ok so i tried it 3 ways, if i use muppen with parallel i get the same results, if i use muppen with default i get same results, however if i use parallel with auto for both gfx and rdp then i can get down to 3 frames. Thats a weird anomaly or is that somehow faster then OG hardware?
glide64 indeed doesn’t have framebuffer emulation, AFAIK, so it’s going to be similar to if you disabled that in GLideN64 plugin.
Can i disable frame buffer emulation in parallel gfx/rdp?
No, it’s part of how the graphics pipeline works and is intrinsic to ParaLLEl-RDP and Angrylion plugins.
Ah ok so i guess with run-ahead not being compatible with n64 currently, possibly never, then the best we can hope for is what we currently have if we want to use the parallel for upscaling which honestly looks amazing.
If you’re specifically targeting the lowest latency over any other considerations, but glide64 is a very old and inaccurate plugin, so it’s kinda like sticking with ZSNES over modern emus (that is, ZSNES has shockingly low latency for some reason)