Are you sure that you are still using the sync fifo build? The build number is r5688M.
After the game shows the "Deep" screen, hammer the A button until the screen turns black. If you press the B button accidentally, Dolphin will hang. You have to close Dolphin and restart it, if that happens. Maybe reinstall the build into a new directory again?
EDit: Now IT works!
Just manage fianlly to get to the menu,I don't know what happened.
(06-18-2010, 11:38 PM)skid Wrote: [ -> ]I've just played through as Pious, picking up the four granite cubes and inserted them into the walls. I then destroyed the statue and claimed one of the artifacts and turned Pious into a mummy. The game then reset.
jinnai3k, was this the area where you said you were getting hangs?
Thats the one yep, freezes down the first hallway typically with the first cube. Also how are your fps during enemy areas? And are you using DX or OpenGL? I wonder if this problem is just isolated to me. My gfx card is a GTX 260.
I was using DX9. I tested it on the debug build which doesn't get much faster than 20% speed.
(06-20-2010, 07:30 AM)skid Wrote: [ -> ]I was using DX9. I tested it on the debug build which doesn't get much faster than 20% speed.
Sounds like something you need quite a bit of patience for, oh well at least the music in ED is amazing.
Skid, what code was responsible for dual core fifo and the fifo speedhacks?
I'd like to piece back in the speed hacks myself and reenable dual core, I want to test your current patch with and without the optimizations. I hope that's not too much to ask, I'll be piecing back in and altering the code myself.
erm, at this point, I don't even know how to put the speed hack back into the code myself
The dual core code is controlled by that convoluted bit of code at the top of fifo.cpp:
Code:
if (CommandProcessor::fifo.bFF_GPReadEnable)
{
if (g_VideoInitialize.bOnThread)
{
// Wait for GP to catch up by detecting whether the cycleCount is decreasing
u32 currentCycleCount = cycleCount;
u16 sameCycleCount = 0;
if (!CommandProcessor::fifo.CPReadIdle)
{
while (sameCycleCount < 5 && cycleCount > ((FIFO_PERIOD + cyclesLate) * 243 / 729 * 5))
{
if (cycleCount == currentCycleCount)
{
sameCycleCount++;
}
else
{
currentCycleCount = cycleCount;
sameCycleCount = 0;
}
}
}
}
The "sameCycleCount < 5" controls how sensitive the code is to the dual core mode hanging. The lower the faster, but it can get too sensitive if the number is too low.
The 243 is the speed of the Wii GPU in Mhz. The 729 is the speed of the Wii CPU in Mhz. These can be overclocked or whatever. When I measured the speed of the GPU on my Wii, it was 256 Mhz (?). You have to change these numbers in two places in the code and they must match.
The other thing that you can adjust is the FIFO_PERIOD. The higher the FIFO_PERIOD, the faster it'll run, at the expense of timing precision.
Oh ok, thanks though.
I just want to do a bit of experimenting with the code, I can either make it or break it, more likely to break it due to not knowing how to code. I'm going to try making use of all the extra time I have on my hands to learn coding, someday I'd like to help out with development.
(06-23-2010, 02:41 PM)skid Wrote: [ -> ]erm, at this point, I don't even know how to put the speed hack back into the code myself
The dual core code is controlled by that convoluted bit of code at the top of fifo.cpp:
Code:
if (CommandProcessor::fifo.bFF_GPReadEnable)
{
if (g_VideoInitialize.bOnThread)
{
// Wait for GP to catch up by detecting whether the cycleCount is decreasing
u32 currentCycleCount = cycleCount;
u16 sameCycleCount = 0;
if (!CommandProcessor::fifo.CPReadIdle)
{
while (sameCycleCount < 5 && cycleCount > ((FIFO_PERIOD + cyclesLate) * 243 / 729 * 5))
{
if (cycleCount == currentCycleCount)
{
sameCycleCount++;
}
else
{
currentCycleCount = cycleCount;
sameCycleCount = 0;
}
}
}
}
The "sameCycleCount < 5" controls how sensitive the code is to the dual core mode hanging. The lower the faster, but it can get too sensitive if the number is too low.
The 243 is the speed of the Wii GPU in Mhz. The 729 is the speed of the Wii CPU in Mhz. These can be overclocked or whatever. When I measured the speed of the GPU on my Wii, it was 256 Mhz (?). You have to change these numbers in two places in the code and they must match.
The other thing that you can adjust is the FIFO_PERIOD. The higher the FIFO_PERIOD, the faster it'll run, at the expense of timing precision.
By the way, I just wanted to know what code is used for the fifo speedhacks so I can play around with it, not that I'd be able to do much.
I'm also wondering if that dual core fifo code contained in your patch can be used with the current fifo or if the current fifo in the svn trunk already has more efficient dual core code implemented?
I'm trying to fool around with the code so games don't hang, but I'm not having much luck. How do you go about verifying these things on the actual hardware such as the accurate cycle count, cpu/gpu speed etc? I'd like to at least see what the actual system is doing with games, such as loading Hyrule Field, to help debug some issues.
(06-24-2010, 02:27 AM)Xtreme2damax Wrote: [ -> ]By the way, I just wanted to know what code is used for the fifo speedhacks so I can play around with it, not that I'd be able to do much.
I'm also wondering if that dual core fifo code contained in your patch can be used with the current fifo or if the current fifo in the svn trunk already has more efficient dual core code implemented?
I'm trying to fool around with the code so games don't hang, but I'm not having much luck. How do you go about verifying these things on the actual hardware such as the accurate cycle count, cpu/gpu speed etc? I'd like to at least see what the actual system is doing with games, such as loading Hyrule Field, to help debug some issues.
Yeh, my aim with this patch was to more accurately reflect the timing between the GPU and the CPU. The idea is to keep the two processors in sync with each other. The current fifo code gives the two processors a free-for-all in terms of timing.
Because of this, the dual core mode is inherently different between the two implementations and the code is not compatible between the two.
To verify how the system works on the actual hardware, homebrew test programs have to be written.