I was wrong about the culling, I tested SMG2 again and found that culling was indeed working as XTra.KrazzY said. At first, I wasn't able to reproduce culling on Dolphin, as I did on the actual Wii. Tested it again the next night on Dolphin, and confirmed that culling is working, not sure why there is such horrendous performance issues with Dolphin and some games.
@ kernel64: Does that mean in SMG1/2 Dolphin doesn't render the whole level all the time?
Could it be as simple as implementing a far clipping plane in dolphin?
Or does it already do that?
![[Image: viewVolume.gif]](http://research.cs.queensu.ca/~jstewart/454/notes/pipeline/viewVolume.gif)
Quote:Hyrule field is very slow even on this kind of cpus. Being a GC game, it might be handling Hyrule field in a different way. Maybe that's why Dolphin apparently loads and renders the entire Hyrule field.
Not true. Many I7 users including one of my friends I can directly confirm, having seen it first hand, achieve full speed in hyrule fields WITHOUT the patch. I am still trying to figure out why, and why only some I7 users seem to be affected while others have the normal slowdown.
(06-22-2010, 01:00 PM)kernel64 Wrote: [ -> ]Great, at least we have something to think about. In SMG or SMG2, a good cpu manages to achieve close to full speed frame rates, even on complex levels. Hyrule field is very slow even on this kind of cpus. Being a GC game, it might be handling Hyrule field in a different way. Maybe that's why Dolphin apparently loads and renders the entire Hyrule field.
the reason why hyrule field is slow is because dolphin is rendering over 128k triangles in that field wich slows everything down cause the cpu cant handle that kind of mount of data. Im in the post zora part of the game btw.
No...I disagree. It's a bug. I used 2.0 and got halfspeed and used the patch version and got 85-90% speed.
Skid, remember when I did the profiling and it was determined that Fifo_EnterLoop was the most intensive? Would the following code have anything to do with that and is there any way to alleviate this?
Code:
// If we are in BP mode we only send 32B chunks to Video plugin for BP checking
if (_fifo.bFF_BPEnable)
{
if ((readPtr <= _fifo.CPBreakpoint) && (readPtr + 32 > _fifo.CPBreakpoint))
{
Common::AtomicStore(_fifo.bFF_GPReadEnable, false);
Common::AtomicStore(_fifo.bFF_Breakpoint, true);
if (_fifo.bFF_BPInt)
CommandProcessor::UpdateInterruptsFromVideoPlugin();
CommandProcessor::FifoCriticalLeave();
break;
}
distToSend = 32;
if (readPtr >= _fifo.CPEnd)
readPtr = _fifo.CPBase;
else
readPtr += 32;
}
// If we are not in BP mode we send all the chunk we have to speed up
else
{
distToSend = _fifo.CPReadWriteDistance;
// send 1024B chunk max length to have better control over PeekMessages' period
distToSend = distToSend > 1024 ? 1024 : distToSend;
if (readPtr + distToSend >= _fifo.CPEnd + 32)
{
distToSend = _fifo.CPEnd + 32 - readPtr;
readPtr = _fifo.CPBase;
}
else
readPtr += distToSend;
}
lol you may disagree but the data i saw while testing the game showed me a huge amount of primitives being rendered. A normal Map or the initial world got average 18k primitives while the late world map got over 128k. i get average 15 Fps with my cpu and with the patch 18 fps so, and thats because you are cuting some processing data to get more fps. Theres room for optimization ofc and there might be a bug somewhere but thats another story ;P.
For now im trying to get some extra processing power from the gfx plugin, will see how it plays out later.
Code:
// If we are in BP mode we only send 32B chunks to Video plugin for BP checking
if (_fifo.bFF_BPEnable)
{
if ((readPtr <= _fifo.CPBreakpoint) && (readPtr + 32 > _fifo.CPBreakpoint))
{
Common::AtomicStore(_fifo.bFF_GPReadEnable, false);
Common::AtomicStore(_fifo.bFF_Breakpoint, true);
if (_fifo.bFF_BPInt)
CommandProcessor::UpdateInterruptsFromVideoPlugin();
CommandProcessor::FifoCriticalLeave();
break;
}
distToSend = 32;
if (readPtr >= _fifo.CPEnd)
readPtr = _fifo.CPBase;
else
readPtr += 32;
}
This is the breakpoint functionality of the FIFO. It is vital to how the FIFO works. This code looks correct-ish.
Code:
// If we are not in BP mode we send all the chunk we have to speed up
else
{
distToSend = _fifo.CPReadWriteDistance;
// send 1024B chunk max length to have better control over PeekMessages' period
distToSend = distToSend > 1024 ? 1024 : distToSend;
if (readPtr + distToSend >= _fifo.CPEnd + 32)
{
distToSend = _fifo.CPEnd + 32 - readPtr;
readPtr = _fifo.CPBase;
}
else
readPtr += distToSend;
}
This is the speed hack within the FIFO. Changing the "1024" to "32" in the following line would make the FIFO work closer to how the real hardware works.
Code:
distToSend = distToSend > 1024 ? 1024 : distToSend;
The code you've extracted above constitutes the core of the FIFO within Dolphin.
I see, I was just asking because of the following comment:
Quote:// If we are in BP mode we only send 32B chunks to Video plugin for BP checking
Kiesel-Steins Hyrule Field speedup patch is a modification to bpstructs.cpp to keep some of the environment (texturing?) from getting flushed through the pipeline. The only problem is that it causes graphical glitches with some other games and it only seems to work with Twilight Princess.