Emulator

I found this link. it's very useful. I hope developers to read. maybe they can find
the bug. Thanks a lot

http://forums.ngemu.com/dolphin-discussion/125613-issue-related-experiment-wii-saved-
states-expiring-phenomenon.html

Better the name of this issue need be : "Wiimote : Auto desync"
Why?Becouse when you don't play a wii game 5/10 minutes, will appear a message that
say "desync problem" (like load state)

Hi,

I've spent some time (seriously) on rewriting the whole
"IPC + IPC_HLE + IPC_HLE_USB + IPC_HLE_Bluetooth(wiimote) + EMU_WiiMote_Plugin",
and the patch seems working fine

What's included in this patch:

1. Fixed Issue 1634: Emu WiiMote Desync after State Load
   (dunno know about Real WiiMote, and now this patch works only with HLE DSP, LLE
   DSP will crash when doing State Save, not my fault...)

2. I think this will also fix Issue 1306: WiiMote auto-desync after a while
   (Though I haven't thoroughly tested it yet)

3. Fixed the Ack-Delay issue inside Emu_Wiimote plugin

4. Fixed several memory leaks when doing State Load
   (which ususally cause Dophin running like a snail and sometimes could crash due to
   invalid pointer)

5. Now the whole IPC stuff behaves more like real hardware
   (at least from my perspetive)

6. Code clean up, comments added
   (Diff to see those changes)

7. Theoretically it should brings some performance boost
   (lol)

Things left to do:

A. I think Core should completely pause the game when doing state save/load, rather
than doing it in another thread
(dunno too much about core, someone should check)

B. State Save/Load won't work before Wii is completely booted up
(Yes it can be fixed, but is it really necessary to do it?)

C. Several parameters need more tweak, like IPC frequency & WiiMote frequency divider
(See code comments and try it out)

D. Lots of tests

Issue 1303 has been merged into this issue.

I just found the auto-desync issue hasn't been solved by previous patch,
So I'm now experimenting on why it happens.

I guess:
A. It could be relative to the idle event frequency
B. Or WiiMote sends some special info intermittently (possible because auto-desync
always happens when there is no input, which means the reports from WiiMote are all
the same or blank in a considerable long time span)

So, please use this patch which at least can easily recover from desync (by reloading
any saved state)

ok, here are my first thoughts:
your editor seems not to like "°", so it replaced some text (FillReport.cpp)
wiimote_hid.h: you are decreasing the size of struct wm_acknowledge by a byte, just
checking that that's your intention.

other than those nitpicky things, looks great! (gotta compile and test now :) )

1. My OS locale can't display that multi-byte character as it is non-ascii, actually
   it shows "?" here :)

2. That byte is not part of report data, it belongs to the header, which also
   complies with other report headers so I use the common ReportDataHdr generator
   function, the final packet length is the same.

non-ascii isn't really good to have in c/c++ sources, so you can just delete it or
whatever.

you should try building in debug :p

WII_IPC_HLE_Device_usb.cpp:
line 1245: _ocf should be ocf
line 141: doesn't compile. not sure where g_CtrlSetup is coming from?

also, should I assume that you're on non-win32 and that wiimote works, or that you're
on win32 and you've reverted some of the recent changes to wiimote_real.cpp?

just asking because I'm on win32 and trying to figure out why wiimote stopped working
after the recent changes to wiimote plugin/wiiuse. ><

ok, wiimote fixed here now.

Your patch seems to cause IWII_IPC_HLE_Device* AccessDeviceByID(u32 _ID) to spew:
"IOP tries to access an unknown device 0x0"
Do you know if this is a special device or something?

sorry but the debug issue, because I've only built the debug build once at the
beginning. Since it is too slow I just gave it up and kept bebugging in release build
by setting the MAX_LEVEL to INFO :P

My patch doesn't include "wiimote_real.cpp", I don't know anthing about that

Currently all devices are created dynamically when they are first accessed. device
0x0 is normal which means that device doesn't exist and needs to be created.

I was thinking making all devices pre-built but just too lazy to do that in that
patch _

committed, let me know if I should close this, etc.
let ector know if you want svn commit rights :)

I would be my hornor to have commit rights

PS: I've updated a little, mainly fixing more mem leaks and implementing Do(map<>) in
order to store all FileIO to state, which is the major reason why sometimes it crashes

You got rights.
Thanks for your great work btw :)