Really that happens because the fifo.CPReadWriteDistance is negative.
Example: CPReadWriteDistance: -864 CPEnd: 10092672 fifo.CPBase: 9568416
In SMG this is because PI_FIFO_RESET is writing and after fifo.CPReadWriteDistance will be setted to 0.
To Prevent that, I've Implemented AbortFrame function in the CommmandProcessor. It should fix overflown because of that.
Note: There is other issue (Issue 2846) where the fifo.CPReadWriteDistance is negative too but the effect is different.
I'm working to solve this.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6083 8ced0084-cf51-0410-be5f-012b33b47a6e
Dual Core sync fix.
When the FIFO is processing data we must not advance the cpu cycles in CoreTiming because in this way the VI will be desynchronized. So, We are waiting until the FIFO finish and while we process only the events required by the FIFO.
This should fix Issue 2072 .
This affect to all games in dual core mode.
Please, You can test all games with VPS limiter auto, 60, 50 depending of the game and compare with prev revision.
For example now NSMB in the video Intro has 60 fps (prev 30 fps) :D or SMG does't need anymore FPS Limitter Hack to get 55-60 fps
Beside the slowdowns now are more softly and the fps more stables because the VI sync is almost perfect.
The Core Timing and Fifo modifications are delicated. Please report if this hang any game. Don't forget check with prev revision.
Enjoy it! Thanks to Rodolfo for teach me all about dolphin.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5777 8ced0084-cf51-0410-be5f-012b33b47a6e
This change also includes tons of minor code formatting cleanup. Yeah, should've separated it ... sorry :(
Kills the old CPUCompare support. I'll resurrect it if I need it again, right now it mostly clutters the code.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@2321 8ced0084-cf51-0410-be5f-012b33b47a6e
1. Avoided LoadLibrary() and FreeLibrary() in favor of using an existing LoadLibrary() because of an unresolved crash related to LoadLibrary() and nJoy. After several times of LoadLibrary() and FreeLibrary() of nJoy these seems to be some kind of memory corruption that brings up several error boxes from different places (not just nJoy) and then cause a crash.
2. Slowed down the moving of the pad initialization to InputCommon. I'm not against InputCommon at all, but I have to spend some more time with it before it works on Windows
3. Partly fixed a somewhat frequent failure of nJoy with SDL 1.3 that would give a strange DirectInput error message and cause the pads to not function. It's still present before the nJoy config windows is opened. It's only fixed on booting a game.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@1991 8ced0084-cf51-0410-be5f-012b33b47a6e
Marcos Vitali