I'm not sure if Maker is the best name (Developer? Publisher?
Company? Copyright?) but I went with it because it's
what the game properties window uses. For the sake of
backwards compatibility, the INI option wasn't renamed.
This scanning thread either polls libusb or checks every 500ms for a
change depending on host capabilities. The GC Adapter can now be plugged
and unplugged at any time when dolphin is open, it will be used if the
direct connect option is set.
Having some data available in banner loaders and some other data
data available in volumes gets messy, especially with GetNames(),
which is available in both but returns different results
depending on which one is used. This change drops support
for reading names and descriptions from Wii save data.
- CEXIETHERNET::SendComplete is always called from the main thread, so
drop the _Threadsafe.
- Mark the FIFO player thread as the "CPU thread" so it can call
ScheduleEvent without complaints. I haven't actually tested this,
since I don't know how to use the FIFO player; it might break
something.
PowerPC does exceptions and hardware and stuff, Memory doesn't.
I did not realize until a few minutes ago that there were two versions of these functions. This is why namespaces suck. Anyway, these were added by Mullin earlier this year.
They weren't sufficient and are made redundant by previous commits; they
also (on master) caused breakage due to Jit64::psq_stXX assuming writes
would be fastmem and not clobber a register under certain conditions.
That really needs to be refactored, but for now, this works.
Change TMemCheck::Action to return whether to break rather than calling
PPCDebugInterface::BreakNow, as this simplified the implementation; then
remove said method, as that was its only caller. One "interface" method
down, many to go...
Without fastmem, the JIT code still does an inline check for RAM
addresses. With watchpoints we have to disable that too. (Hardware
watchpoints would avoid all the slow, but be complicated to implement
and limited in number - I doubt most people debugging games care much if
they run slower.)
With this change and watchpoints enabled, Melee runs at no more than 40%
speed, despite running at full speed without them. Oh well. Better
works slowly than doesn't bloody work.
Incidentally, I'm getting an unrelated crash in
PowerPC::HostIsRAMAddress when shutting down a game. This code sucks.
- Move JitState::memcheck to JitOptions because it's an option.
- Add JitOptions::fastmem; switch JIT code to checking that rather than
bFastmem directly.
- Add JitBase::UpdateMemoryOptions(), which sets both two JIT options
(replacing the duplicate lines in Jit64 and JitIL that set memcheck
from bMMU).
- (!) The ARM JITs both had some lines that checked js.memcheck
despite it being uninitialized in their cases. I've added
UpdateMemoryOptions to both. There is a chance this could make
something slower compared to the old behavior if the uninitialized
value happened to be nonzero... hdkr should check this.
- UpdateMemoryOptions forces jo.fastmem and jo.memcheck off and on,
respectively, if there are any watchpoints set.
- Also call that function from ClearCache.
- Have MemChecks call ClearCache when the {first,last} watchpoint is
{added,removed}.
Enabling jo.memcheck (bah, confusing names) is currently pointless
because hitting a watchpoint does not interrupt the basic block. That
will change in the next commit.
On OS X, this broke Cmd-V to paste in the text boxes. Apparently wx
thinks having mnemonics (which are Alt-* on Windows) be Cmd-* on OS X,
even if this disables standard shortcuts, is a good idea.
Lioncash suggested just getting rid of the accelerators on non-menu
controls, so I'm doing that rather than disabling them only on OS X.
1) Apparently wxString::Format is type safe, and passing a u32 to it
with the format "%lu" crashes with a meaningless assertion failure.
Sure, it's the wrong type, but the error sure doesn't help...
2) "A MenuItem ID of Zero does not work under Mac". Thanks for the
helpful assert message, no thanks for making your construct have random
platform-specific differences for no reason (it's not like menu item IDs
directly correspond to a part of Cocoa's menu API like they do on
Win32).
All the multiplying and dividing by 100 in controller configs is
messy... An attempted solution to the problem was to not multiply
default_value by 100 in ControllerEmu::ControlGroup::LoadConfig,
but that broke other things instead, so I went with this.
