Hyrule Field Slowdown Observation

blubb · 05-02-2010, 07:59 AM **#261**

Ah ok, so that's some "proprietary stuff" if I understand correctly? I'm really not into programming/deeper hardware stuff at all so I have no idea what it does and what the difference to the HLE plugin is. Is there a thread/page/... that explains the basic stuff of it to a noob like me? Once I understand the concept I'll probably be able to "find my way" on my own Wink

deathjijn · 05-02-2010, 06:39 PM **#262**

(05-02-2010, 07:59 AM)blubb Wrote: Ah ok, so that's some "proprietary stuff" if I understand correctly? I'm really not into programming/deeper hardware stuff at all so I have no idea what it does and what the difference to the HLE plugin is. Is there a thread/page/... that explains the basic stuff of it to a noob like me? Once I understand the concept I'll probably be able to "find my way" on my own

this is a start http://forums.dolphin-emu.org/thread-3823.html

ZEROx · 05-02-2010, 08:45 PM **#263**

Finally completed this game with your patch, and also completed all side quests, thanks

**Xtreme2damax** · 05-03-2010, 04:42 AM **#264**

I uploaded a patched build, check the first post of this thread for a link:

http://forums.dolphin-emu.org/thread-2176.html

I wonder if Skid got any further with his Fifo work yet, would be nice to see how much of a difference it will make. Skid, if you want the Fifo work tested before committing it to the svn you should post it as a patch so we can thoroughly test the changes. Smile

Any responses from developers regarding the recent information provided, such as what I inquired about in my last few posts?

deathjijn · (This post was last modified: 05-03-2010, 05:39 AM by deathjijn.)

(05-03-2010, 04:42 AM)Xtreme2damax Wrote: I uploaded a patched build, check the first post of this thread for a link:

http://forums.dolphin-emu.org/thread-2176.html

I wonder if Skid got any further with his Fifo work yet, would be nice to see how much of a difference it will make. Skid, if you want the Fifo work tested before committing it to the svn you should post it as a patch so we can thoroughly test the changes.

Any responses from developers regarding the recent information provided, such as what I inquired about in my last few posts?

Someone made mention in the svn Issue boards something that made alot of sense About the GPU missing view frustum culling or object
occlusion. Ad that causing the massive slowdown
this is what was mentioned and it makes sense
((It seems likely that the Wii GPU has built-in occlusion and culling that the emulator
is missing.
Large areas are going from running at 100% (150% capable) to about 30% to 50% in the
areas mentioned on my machine, regardless of what direction I'm looking or what is
actually visible. It almost sounds like it is missing basic culling.))

**Xtreme2damax** · 05-03-2010, 06:37 AM **#266**

Yeah, but the thing is that some are able to get full speed or close to it while others experience these drastic slowdowns. Why wouldn't a top of the line GPU or new GPU's have such a feature, the Gamecube came out in or around 2001 and the Wii is just a more powerful Gamecube. It seems kind of weird with all the advances in PC technology over the past nine years that PC gpu's wouldn't be capable of everything the Gamecube/Wii gpu is capable of.

Do you have a link to the issue by the way?

**NaturalViolence** · 05-03-2010, 06:55 AM **#267**

Quote:Why wouldn't a top of the line GPU or new GPU's have such a feature

They do. But the graphics thread on the emulator is not emulating it. At least I think they do since I've played many pc games over the years that use it, and I highly doubt it's done by software.

**Xtreme2damax** · 05-03-2010, 08:31 AM **#268**

Yeah, because it would be strange if modern cards didn't support all the feature of the Gamecube gpu.

The major pisser with emulation especially emulation of more powerful consoles, is the actual hardware has a high bandwidth bus between the memory, cpu and gpu whilst PC hardware is lacking in that aspect. That's one reason why full speed emulation isn't possible without hacks. If PC hardware was powerful enough things like Copy EFB to Ram, DSP-LLE would could be used without any slowdowns. I wonder if future PC hardware would be enough to run the interpreter core at full speed. Tongue

As mentioned above a link to the issue where this information is provided would be nice, I'll see if I can find it myself for now.

05-03-2010, 11:11 AM **#269**

http://code.google.com/p/dolphin-emu/issues/detail?id=2499
http://code.google.com/p/dolphin-emu/issues/detail?id=720

View frustum culling is done in the hardware but it is possible that a console system may have some optimizations.

Source: Chad Vernon on Frustum Culling
"When we tell DirectX to render geometry, it will perform a culling test to see if a vertex is within the view frustum before rendering the vertex. DirectX will only render a vertex if it is within the view frustum. However, this test occurs after the geometry has been transformed and lit by the world and view matrices. In more complex scenes, thousands of vertices would be transformed just to be rejected by the frustum test in DirectX. We can speed up performance quite a bit if we implement a view frustum culling test prior to our render calls."

It is good a thought but I can't even begin to think how the existence of this could verified, let alone implemented into the emulator. Though, it may also be something simple like z-culling (aka depth test) isn't turned on when it should be. Since modern cards can handle almost anything a Wii could throw at it, at little bug like that may go unnoticed except in these rare instances.

I think it would be helpful, however, to implement a view distance hack option in the renderer plugins.

It is doubtful that I'll dabble in the source myself, but hopefully this will give someone with Direct3D knowledge some places to look.

**Xtreme2damax** · 05-03-2010, 11:50 AM **#270**

OpenGL knowledge as well, the issue also exists in the OpenGL plugin. I lean more towards it being a core issue with graphics, not specific to any plugin. So the code under the videocommon project is likely responsible and not the code for the individual plugins, seeing as testing so far points towards the fifo and bpstructs code.

Maybe what is needed is skids fifo fixes as previously mentioned and something that can cache textures and vertices from the games environment. If the emulator has less work to load these things then maybe it would offer a nice speedup for most if not all games.

The only thing is if a developer is willing to work on figuring a way to cache the vertices and textures.

So with this said, I believe a combination of two things can fix this issue and that is Skids Fifo syncing fixes, caching textures and vertices. If possible, what about caching textures and vertices on the fly so the emulator doesn't need to be restarted in order to benefit?

These could possibly offer nice speedups to even those with lowly machines in my opinion.

Now my question is what source files handle the vertices and textures, is it a combination of many files?