Gliden64: Intense Lag

[DarkMarxSoul]

Using this with Project64 2.3 results in intense lag for pretty much anything I want to play, to the point where it might as well not be playable at all. I'm using an NVIDIA GeForce GTX 1060 6GB and a 3.40 GHz Intel Core i-3570K, and I've got 16 GB of installed RAM. I'd like to fix this problem.

EDIT: I also use Windows 10 Pro (64-bit) and have a x64-based processor.

[gonetz]

pretty much anything I want to play,

Information you provided is not enough to help you. I don't have telepathic abilities to find what you want to play and which settings you use. There are games, which work slow regardless of your hardware specs. Project64 2.3 also can be not the best choice for some cases.

[loganmc10]

I think in the past some people have determined that the NVIDIA driver was throttling itself or something. They needed to put it in performance mode. But yeah, something is wrong with your PC/settings, not GLideN64, I can run most games at full speed on an old laptop with integrated graphics.

[DarkMarxSoul]

@gonetz I mean, I'm sorry that is too vague, but literally _every_ game I have has the exact same issue, namely that both the video and sound criminally lag. I use the default settings for Project64 2.3 and GLideN64 2.0. If you need any other information beyond what games are involved, please let me know so I can tell you. If you have any other suggestions (e.g. using a different build of Project64 or a different Nintendo 64 emulator), that'd be an acceptable response.

@loganmc10 Any information on how I may fix this would be appreciated, provided my hardware itself isn't just fundamentally incapable of using GLideN64 on Project64 2.3.

[gonetz]

Yes, it is common problem that NVIDIA drivers do not enter performance mode when you run N64 emulators. Since GLideN64 loads GPU pretty well, you need to force performance mode somehow. ATI cards do not have that problems, at least with current drivers.

[DarkMarxSoul]

@gonetz I set my power management settings to prefer maximum performance globally and this didn't impact the performance of the emulator/graphics driver.

[Jj0YzL5nvJ]

Yes! Let's blame NVIDIA. I like it. https://github.com/PCSX2/pcsx2/issues/1437#issuecomment-301492954

So far only

• Windows user
• with DWM enabled
• with Nvidia driver
• on OpenGL renderer

are impacted.

Any sane person will think it is an Nvidia driver bug ;)

@DarkMarxSoul, you also need to play with the NVIDIA control panel. If you use Win7, try to "disable DWM".

[mirh]

That problems has to do with some sporadic stuttering, not "intense lag" as if you were playing crysis on an atom cpu.

Nevertheless, newer nvidia drivers allegedly have some (not well understood) problems. I'd suggest to try with < 380 drivers if I were you (if trying to force performance mode in nvidia control panel already didn't work)

[fzurita]

@DarkMarxSoul Can you tried this version of Project64?

https://drive.google.com/file/d/0B57Ioy26LWegcVY3a25uMUptbWc/view?usp=sharing

I updated the speed limiter to be more accurate.

This is the code change:

https://github.com/fzurita/project64/commit/6ecf24c79ec2f6e5a200cb20cef7bec16e46b90a

[DarkMarxSoul]

@Jj0YzL5nvJ I use Windows 10.

@mirh I rolled back to driver version 378.92 and turned "Prefer maximum performance" on globally again. The issue still persists.

@fzurita Unfortunately the issue still persists on your updated speed limiter.

[fzurita]

It sounds similar to this issue:
https://github.com/gonetz/GLideN64/issues/1346

You could try this tool to change the windows timer resolution:
http://www.lucashale.com/timer-resolution/

Maybe it will help.

[Mario54321]

@DarkMarxSoul Maybe there is other software installed that is interfering with the emulator? One crazy thing you can do is back up everything on your computer, clean install the operating system (but don't install anything else unless it is required for the emulator to run), install the emulator, and try playing some games. If doing this fixes the problem, then likely some additional software is to blame.

[DarkMarxSoul]

@fzurita Changing the timer resolution didn't result in any changes.

@Mario54321 Yeah, that sounds like that would definitely be a good test, if extreme. I would prefer to avoid having to do something like that if possible.

[Jj0YzL5nvJ]

@DarkMarxSoul, try turning off the shader cache in the NVIDIA control panel.

Make sure that "Save texture cache to hard disk" option is disabled in GlideN64. I don't know the option name in Project64. Certain levels of GoldenEye are unplayable with such option.

Emulators like Jpcsp can be affected by the processor affinity in AMD processors. Try to change the affinity to two adjacent cores, excluding the number 0.

[LegendOfDragoon]

@DarkMarxSoul how about other video plugins? Do plugins like Glide64 have this issue?

[Frank-74]

@DarkMarxSoul Try putting CN64TimeCritical=1 under the [default] section in Config\Project64.cfg.

[DarkMarxSoul]

@Jj0YzL5nvJ I turned off the shader cache and unchecked "Save texture cache to hard disk" and this didn't improve things. I tried all possible core combinations that excluded the number 0 and this also didn't improve things.

@Frank-74 This didn't impact performance.

@LegendOfDragoon The other two plugins I have result in better performance. Jabo's Direct3D8 1.7.0.57-ver5 runs games pretty well with some graphical errors (e.g. as a quick and easy example for me to find, Paper Mario's file select screen glitches out when the flip effects occur). In the normal Glide64 2.1.2.202, performance is still pretty good at first glance, and the glitches do not occur (at least at the file select screen right now). GLideN64 2.0 cannot play the game, as it lags very powerfully.

The issue is, GLideN64 is the required plugin to play a certain mod I recently got, and so I have extra incentive to figure out how to get it to work rather than defer to another plugin. On the mod, the number 2 recommended plugin results in video and audio flickering at certain points. And regardless, I feel that the fact that it _doesn't_ work on _any_ of my games is a general issue regardless.

[AmbientMalice]

What are you trying to play? What resolution are you trying to play it at?

Have you tried using the latest version instead of the outdated 2.0 https://github.com/gonetz/GLideN64/issues/1364#issuecomment-315803097

[fzurita]

Maybe you are one of the first persons to try the plugin with a 10xx series NVidia GPU. You may be uncovering an issue with that GPU. What resolution are you running at?

[twinaphex]

Posted some benchmarks here -

https://www.libretro.com/index.php/cores-progress-report-catering-to-high-end-desktops-dolphin-libretro-core-and-others-now-supports-resolutions-of-8k-and-up/

TLDR - even with MSAA off, this is by far the most highly bottlenecked renderer so far out of all the libretro cores. Reicast/Dolphin/Beetle PSX/Parallel N64/Craft/OpenLara can all be pushed to far higher resolutions at far greater speeds and with more effects enabled.

[gonetz]

Sounds dull.

[DarkMarxSoul]

@AmbientMalice Unbelievably, after all that work, all I had to do was download the latest version, the existence of which I was unaware of. Thank you very much for letting me know about this. It runs better than any of the other plugins I've used now and is virtually perfect at first glance.

Also @gonetz, great work on the version from six days ago. Fixes this problem perfectly it seems.

I'm going to leave this issue open for now just in case the universe suddenly decides it hates me and it pops up again later. But for now, thank you very much for everybody who has contributed. It means a lot. c:

[AmbientMalice]

I think GLideN64 really needs an official build bot. Even if it updates once a week.

[Jj0YzL5nvJ]

Or a issue template ...at least. Version, emulator, platform, etc.

[mirh]

I'm going to leave this issue open for now just in case the universe suddenly decides it hates me and it pops up again later.

If you could bisect which commit this problem was fixed, it should be very easy for the future to spot anything.

[AmbientMalice]

@mirh It was almost certainly fixed by the massive VI and API refactors a few months ago. I don't think it can be tracked down to a specific commit.

[LegendOfDragoon]

It was almost certainly fixed by the massive VI and API refactors

I only saw a significant difference in performance with the API refactor.

[Frank-74]

If you could bisect which commit this problem was fixed, it should be very easy for the future to spot anything.

@mirh It requires a massive effort to build this plugin. 20+ Gb for the ability to build the gui alone, which uses bloated quicktime. Which makes the zilmar spec plugin +10Mb. With a WTL gui the plugin would be less than 2Mb. And when you follow the wiki instructions currently, it still doesn't build. Even zilmar couldn't get it to build I believe.

It took me 20+ hours to just install everything required, and try to build the libraries to build the plugin. Then it still didn't build. pah, I gave up.

So the chances of anyone finding the specific commit that fixed the slowdown is very slim. It should be easier to compile for zilmar spec.

[loganmc10]

It's not hard for me to compile and bisect to a certain commit, but I'm not going to do it just out of curiosity.

As a side note: I don't know what Project64's long term goals are (I don't know if anyone does), but if it is ever to have a hope of being cross platform, you can't write the GUI components in WTL. If it has a stated goal of always being Windows only that's fine (all the plugins, including this one are already Windows dependant so it's not like the Qt GUI is the only thing needed for it to be cross platform), but someone should probably decide what it's gonna be.

[fzurita]

This is a dumb question. Are there any non-Windows n64 emulators that support the Zilmar spec?

[loganmc10]

Not actively developed, but Mupen64. I don't know if any other emulator was ported to Linux

[Jj0YzL5nvJ]

If you all have complaints and constructive ideas related to zilmar-spec, leave them where they can have an effect. https://github.com/project64/project64/issues/1031#issuecomment-314499009

[gonetz]

Regarding bisecting: I usually build for mupen64plus when bisecting. It is much faster, as I don't need to rebuild GUI lib. I use zilmar specs build only when mupen64plus does not support the game I need to debug.

[Aquatakat]

@Frank-74 Almost all the problems I had building GLideN64 came down to needing a very specific version of MSVC 2013. It couldn't be any newer than I think update 2 or 3. Everything works fine for me with the RTM version.

[fzurita]

I was able to get everything building and running using MS VS 2015. Perhaps I should make a branch that should be pullable and compilable using MS VS 2015.

[gonetz]

I planned to switch to VS 2015 year ago, but still use 2013. I guess, I will switch right to VS 2017.

[gonetz]

I'm going to leave this issue open for now just in case the universe suddenly decides it hates me and it pops up again later.

Let's close it. You may reopen it if the problem will pop up again.