All you gotta do is Pause the emulation! That's useful for when your batteries run out during gameplay, for example...
But if you change the WiiMote source (between Emulated, Real or Inactive) you must disconnect and reconnect (Menu Tools -> Connect WiiMote) the WiiMotes affected by the change...
Thanks to jack.fr0st who did all the emulation state notification work!
Now every plugin has a way to know the current emulation state (paused, stopped or playing)
@ayuanx: I thought about doing a PostMessage(g_WiimoteInitialize.hWnd, WM_USER, WIIMOTE_DISCONNECT, current_number); so that the user gets asked to reconnect that WiiMote, trying to avoid having to disconnect and reconnect, but it didn't work because shooting that message only asks to reconnect, doesn't do a disconnect... Do you have any ideas on how to accomplish that?
Also, if anyone could check if Issue 1916 is finally fixed... Or at least when is the cursor being hidden or not...
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4789 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
just made old one visable, so complains about DllDebugger and missing symbols
should be refered to the one who added the symbol without making sure the plugin actually has it.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@1564 8ced0084-cf51-0410-be5f-012b33b47a6e
I also added a wx debugging window for the OpenGL plugin. I connected it to the old console window that was in the plugin. Other than that it doesn't do anything at the moment but it could be useful to show all the current important information and parameter statuses and so on.
Again there's a problem with wx windows collisions. Show() can't be used because then DLL_PROCESS_DETACH is called immediately after the window is opened, and if we open it with ShowModal() before we have loaded a game the main video window will be blocked. And we can't pass on any variables from a DllDebugger() that is called when Dolphin is started because the dll is reloaded and lose all variables sometime before a game is loaded. So we can't auto open the window that way. So I made the debugging window open as a game is loaded if it is enabled in the ini, the downside is that the ini setting will open the window even if we are not opening Dolphin with the -d flag. However, this will only affect people that have used the debugger at least once so in my opinion this is the most convenient solution. But feel free to come up with a better solution. Preferably some solution to how to use Show() and preventing DLL_PROCESS_DETACH to be called.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@812 8ced0084-cf51-0410-be5f-012b33b47a6e
There's an annoying problem with the DSP HLE wx window that blocks some input and places it in a queue. For example if you have loaded the window and press X on the main window, that action is blocked an placed in some kind of queue and not executed until you have closed the debugging window. This is also why the main Dolphin-Debugger window does not show up until you close the sound window. If someone find a fix to this I guess it could be convenient. There is another way to show the window, m_frame->Show() that is normally supposed to remove this kind of on-focus lock, but in a dll it seemingly breaks because it makes Dllmain call DLL_PROCESS_DETACH immediately after DLL_PROCESS_ATTACH so the window has to be killed or we crash.
Also, otherwise unnecessarily I had to disable the new DSP HLE debug window in Release mode because I could not access the SConfig::GetInstance().m_LocalCoreStartupParameter.m_strDSPPlugin.c_str() string that I need to start it (if I tried it crashed). Very annoying and strange. I could not access m_strDSPPlugin or m_strVideoPlugin either, but all other values in m_LocalCoreStartupParameter seemed to work fine. I'll have to leave it to someone else to figure out why.
TODO: Later I'll add function to the debugging buttons, currently only update have a function. I'll add some option to show a custom console window (that actually worked better that the wx window to show the current parameters status, it had less flicker on frequent updates). I'll also add some custom log file saving option.
Also, the reason I placed Logging.cpp in its own dir is because I plan to add more files to it. There were problems with some build modes, win32 with debugging crashed on booting a game, I don't know if it's my fault. And I could not build Debug win64 because of some wx linking problem.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@722 8ced0084-cf51-0410-be5f-012b33b47a6e
luisr142004