GLideN64 skips frames when running at high multiple of N64 resolution

[oddMLan]

If you use 1x or 2x game looks smooth, no skipped frames. When the internal resolution chosen is higher than the output window, it starts skipping frames.

[retrobenny]

On Mupen64Plus FZ Edition (Android) with scale factor disabled (for highest quality?),I have been seeing choppier looking framerates again,even with color buffer disabled on legacy mode for top speed,but it runs too slow for me on Sync mode to guage if it also skips/drops frames. Normally,I get slight drops with 16x Anisotropy,but not as bad as it is now. Usually,both Sync mode and disabled color buffer are smooth while Async is known to cause framedrops whenever performance is challenged,the same spots Sync slows down in are usually where Async gets framedrops.

Maybe there should be an advanced option like frame-by-frame to prevent dropped/skipped frames by the plugin,if possible without horrible issues.

The behaviour matches Async mode when color buffer is disabled,it can run faster (90-120VI/s on fast forward) when the framedrops occur,defeating the purpose of having the headroom for a smoother framerate experience.

[fzurita]

Async mode is supposed to be faster than sync mode. How is performance if you turn off completely color buffer to RDRAM?

[retrobenny]

Async is faster,the faster speed is the cause of it dropping frames in Async mode while Sync mode doesn't allow frame drops but makes it much slower. Turning it off made it faster AND smooth until this difference occurred.

[fzurita]

So turning off copy computer buffer to RDRAM no longer makes it faster?

I wonder if the accuracy improvements in the plugin are slowing things down.

[retrobenny]

Sorry,faster still,but no longer smooth output with it now being rather choppy while still showing 60/60fps on the fps counter. It looks like skipped frames but it is not skipping them,it is dropping frames for whatever reason while still running at the same speed.

Still faster than Sync at least,it is either the same speed or slightly faster than the Async method. Framedrops are different than slowdowns,its something in one end or the other discarding frames for some reason or something else ridiculous.

I do have Anisotropy on at 16x plus 6xBRZ De-posterized and fully Native scale instead of a 1x-4x scale along with legacy mode so it doesn't run at 1fps from the accuracy bloat of modern rendering alone. Anything in multi-threading for video is likely the culprit of framedrops.

I actually CAN tell it has gotten even worse on Anisotropy after an update than it was a while back on Anisotropy.

[fzurita]

@retrobenny Try going into input settings in Mupen64Plus FZ and enable "Use high priority thread".

[Frank-74]

@retrobenny Or on Project64, try 'CN64TimeCritical=1', under the [default] section in Project64.cfg. It gives the render window the highest priority.

[retrobenny]

Hrm,interesting if it could relate to that. Also,thanks Frank-74 for the PJ64 tip,got any tweaks for making a certain older PJ64 version (1.7 leaked build/the one I use for code hunting and such) less sluggish in the UI? I swear after the Win10 updates the time it takes to access plugin settings has increased dramatically up to almost 30 seconds on every load,such a painful crippling of performance,even after all of my recent tweaks to combat the update's relative slowdown nightmare it still has so much slowdown and the shorter delay registry tweak barely puts a dent in it.

[Frank-74]

Nothing for 1.7, I added it to PJ64 about a year ago. It makes the video smoother for me on Windows 8.1. https://github.com/project64/project64/pull/756

[oddMLan]

I swear after the Win10 updates the time it takes to access plugin settings has increased dramatically up to almost 30 seconds on every load

Huh. I'm using the Win10 anniversary update and I have none of those issues. Your system must not like Win10.

Or on Project64, try 'CN64TimeCritical=1', under the [default] section in Project64.cfg. It gives the render window the highest priority.

Ok let me try that. EDIT: Nope, still dropping frames

[theboy181]

The load time for plugins is dramatically increase by the nrage plugin when it's in the plugin directory.

Try to remove it and see if the load to the settings menu is improved.

[oddMLan]

This issue is easy to notice while playing Mario Tennis

[retrobenny]

Problem is,I had half decent UI loading speeds before that update and I use NRage for input on most games because the Jabo input has that analog issue where rotation for stuff like Conker's final boss is broken,leaving you barely nudging over the boss 1cm at a time. If I have that made up 2.3c version in there,maybe I should remove it and replace it with the standard 2.1 version of NRage which doesn't have the extra input method support.

@oddMLan Have you tried Sync mode even though it runs much slower? (if you can get it full speed anywhere,higher scales than 4x decimate my fairly powerful laptop) (I would love to have that beastly laptop with 2 GTX 1080s and the top-of-the-line CPU setup,its so amazing but costs over 3 grand)

[oddMLan]

Yes, tried Sync and None. Disabled depth. A bit smoother but still dropping frames. I doubt it's the lack of resources of my computer, I can run the game above 100 VI/S at 4x Native Res with 4x Antialasing EDIT: it doesn't drop frames at 4x Native with Antialasing disabled

[oddMLan]

Ok, the problem doesn't seem to be Native res factor by itself, but when combined with any amount of Antialiasing, the plugin starts dropping frames.

EDIT: If you use something like 12x Native Factor with no AA, the plugin drops frames. I guess this is a problem with my driver not being able to handle a really big buffer, but even at that crazy resolution factor the plugin runs Mario Tennis at 70-85 VI/s just fine. The dropped frames thing doesn't happen in Dolphin at high internal resolutions though my computer can't run anything above 2.5x at full speed so moot point.

[Frank-74]

My computer doesn't get anywhere near 60 VI/s unless I disable frame buffer, at native resolution. No AA or enhancements of any kind. Quad core Pentium 2.4Ghz. Intel HD. GLideN64 is a real hog on processing power. Most times, z64gl is faster, and that's LLE.

[retrobenny]

Then it may be similar to what Cen64 has been rumored to do (can't find the damn video though),it skips frames when hardware is under heavy load such as any game that runs at 60fps maybe. That fighting game tested on it was compared to another emulator,and Cen64 was dropping frames. But I think Cen64's problem is caused by emulation using multi-threading to boost performance because it is cycle accurate.

Someone mentioned that filtering runs on the same thread as graphics,likely being the culprit due to AA or also Anisotropy in my case of minor drops in high priority on Mupen Android and major drops before enabling high priority.

[Frank-74]

My very old (8 years) Pentium Duo Core 2.8Ghz (has 8mb cache on processor) PC is about a third faster than my new quad core 2.4Ghz for N64 emulation. I can get steady 60 VI's on my old PC, about 40VI's on the new one with same settings.

The amount of cores is useless it seems, unless software is written to take advantage of them. Max processor speeds were reached in 2008. The only changes since then has been in architecture, adding cores. Would be better to invest in a powered refrigerant cooler and overclock I think.

[loganmc10]

Is you CPU actually maxed? I would assume the bottleneck would be the GPU speed, not the CPU, especially if lowering the resolution and disabling framebuffer emulation speeds things up, then it's obviously the GPU that is the bottleneck.

[fzurita]

The issue is probably your GPU. GLideN64 must be doing some operations that run really slow on older Intel graphics.

I would almost try downloading RetroArch and using the GLES 2.0 variant.

[Frank-74]

I've never tried RetroArch or even know anything about it. I'll take a look.

My old PC has only onboard ATI Radeon XPress, OpenGL upto 3.3 with unofficial drivers. New laptop has newer Intel HD Graphics, supports upto OpenGL 4.0, not 4.3 unfortunately. I would've thought an onboard GPU that's at least 6 years newer, would be faster, apparently not.

[retrobenny]

Change your Intel HD Graphics settings in the Intel program to the high performance modes and go into power management and do the same with high performance settings in order to bump up the speed capability quite a bit at the obvious cost of extra electricity consumption.

[Frank-74]

@retrobenny I was already on max power, selected performance in 3d settings. But no improvement. It's framebuffer that slows everything down here. Perfect Dark intro with framebuffer on, I get between 20-25 VI's. Framebuffer off I get 60 VI's most of the time, occasional drop to 55. Similar to Glide64 performance.

However if I use Glide64 Final with the nGlide wrapper which uses D3D, I get over 140 VI's with frame limiter off. So it's just GL that is god awful slow on Intel HD Graphics.

[oddMLan]

Not surprised. Intel has always had half assed OGL support.

[retrobenny]

Maybe somebody should develop a D3D port of GLideN64 so that Intel graphics can run the plugin at faster speeds,maybe even also taking advantage of DX12 or at least DX11. But could everything function on DirectX as it does on the minimal GL version requirement?

[Frank-74]

Yes, with something like https://github.com/google/angle

Zilmar started to add it to pj64 glide.