Emulator

I can confirm that this happens with Metroid Prime 1 as well.

Hi I can confirm this. The only way to stop the 'lag' (fps drops to like 40fps for me) when viewing the map is to use OGL backend and enabled 'Hacked buffer upload' aka 'Vertex Streaming Hack'.

hi JMC4789, could you see if it slows down on you using D3D11 and OGL?

for me: D3D11 = map slow down (only in the light world map of Temple Grounds)
OGL= turn on hacked buffer uploads and problem is gone, which as you say is weird.

This is on the GC version.... if you have no slowdown on wii version then something weird is going on!

No the intense scene slowdown isnt part of the problem. I thought that was pretty clear. Any way that I can fix this issue in DX11? If not, someone should fix it.

The game is hitting the drawing infrastructure harder when rendering the map. I see 10k "indexed draw calls", 94k "primitives". Normal rendering is just 500 draws with maybe 2k primitives.

'Hacked buffer Upload' helps for me (i.e. map is full speed) so the way hacked buffer upload works is that it lessens the indexed draw calls and primitives somehow?

Hacked buffer upload just reduces the overhead of the drawing calls. Large numbers of drawing calls result in large gains when using hacked buffer upload.

thank you for the answer. I suppose thats why enabling the hack helps enormously in this situation.

I dont see a hacked buffer upload option, only vertex streaming hack. Either way, this should be optimized on DX11.

Hacked Buffer Upload was renamed to Vertex Streaming Hack recently. Also, DX11 is currently the slowest backend, just use OpenGL.

wrong. OpenGL is slower for me than DX11. When certain effects (like coming out of water making your visor wet) are done, my FPS drops to 20 on OpenGL, and 45 on DX11.

Reflection effect slowdowns are a separate problem. Just something about how Prime does them makes OpenGL choke. But D3D11 is still the slowest backend right now, so while OpenGL has reflection slowdowns, it will be faster overall. OpenGL is very playable in the Prime games. ...minus the Meta Ridley fight.

Fortunately once D3D9 buys the farm D3D11 should improve rapidly, as most of the reasons it's slow are because of things to maintain D3D9. OpenGL should speed up a little as well.

What do you mean by "buys the farm"? D3D9 says deprecated, which means should be avoided. Also, it says OpenGL is the slowest/most accurate and D3D11 is faster. Anyways, they should make an optimization for D3D11.

What version of OpenGL is used by dolphin?

"Buys the farm" = retires. Once they finally kill it, neobrain and degasus can switch the other two backends over to integer shaders for a pretty big speedup. For now, though, it's usually the fastest backend, though it has plenty of backend-specific bugs and it can't be improved any further and it's slowing the other backends down due to VideoCommon needing to be compatible with all three...

OpenGL doesn't work in a way where you can really definitively say that Dolphin uses a specific version of OpenGL, but I can certainly say Dolphin uses features from GL 3.0, 3.1, 3.2, 3.3 (I think?), and 4.2.

I think they'll keep DX11 for compatibility/fallback purposes. However, they should just take out any major bugs (if there are any left) and move on to DX11 and OpenGL.

Still, they should srysly put an optimization for this on DX11.

Sorry i mean they will keep DX9

They're not keeping DX9, it's being taken out right after 4.0. That's the plan. (They're also dropping x86-32 support and Windows XP support. About time!)

Also, you talk about fixing bugs and optimizing like it's easy, but do you know how fucking hard/impossible that is? Plenty of the DX9 bugs are from the DX9 API simply not having certain major features that DX11/OpenGL have that are required to emulate certain parts of the GameCube GPU. I don't know the reasons for DX11/OpenGL's slownesses besides the part where they're much more flexible and aren't running on a ridiculously-optimized fixed-function pipeline like DX9 (inb4 neobrain kills me for being inaccurate there), but still, they can't simply "fix" and "optimize" everything.

You could of said that in a kinder way. Either way, I never said it was easy, I just said it needed to be done. I think I have noticed that it renders every part of the map instead of just the ones shown on screen, but I could be wrong.

That could be just how the game works as well. Even though this is marked as won't fix, it's more a case of nothing for them to do. It's slow right now, but eventually there may be improvements and optimizations that make it faster. That doesn't make this a valid issue though, so you'll just need to pay attention to new builds. There a plenty of "wontfix" issues that eventually get fixed by new people, new ideas, and new hardware.

So you are saying all abnormal and incredible slowdowns are what you call "no-fix"?

Issue 8116 has been merged into this issue.

If you want it looked at, bisect to the exact build that the behavior changed. i think that's the best course of action at this point.

I managed to figure out where the issue began and have also recorded a video, showing the issue in action.

https://www.youtube.com/watch?v=nGVbId0DfqY

4.0-4674 worked fine
4.0-4699 wouldn't run the game in any playable fashion
4.0-4701 is where the issue arose

Cheers!

Deactivating Ubershaders fixes the problem while introducing microstutter every few seconds.