LIBAV_LDFLAGS has -L, LIBAV_LIBRARIES is just the names of the
I think this is not necessary for other dependencies because they
consist of a single library and go through a different path (check_lib)
that provides the full path to it. e.g. from my CMakeCache.txt:
ICONV_LIBRARIES:FILEPATH=/usr/lib/libiconv.dylib (good)
LIBAV_LIBRARIES:INTERNAL=avcodec;avformat;swscale;avutil (bad)
Previously, MacOpenFile only overrode anything on OS X; otherwise it was
just a useless method, which is presumably why it wasn't marked override
in the first place. Address this more sanely by wrapping it in #ifdef
__APPLE__.
...by telling CMake to use -isystem for the static wx include directory.
AFAICT, this is already done by CMake's FindwxWidgets script in the
shared case.
Note - I removed a SleepCurrentThread(1) the patch added which seemed to
be unrelated to the actual job at hand. If there was a real need for it
(which sounds like it would be an enet-related bug - enet_host_service
is supposed to *sleep*), that needs to be dealt with...
On OS X, if you close a subdialog of the ISO Properties dialog, such as
the one to add a new AR code, the main Dolphin window would magically
get raised above ISO Properties. This is confusing, to say the least;
when I encountered this the other day, I thought the dialog was actually
getting closed.
I *think* the diagnosis looks like this:
Cocoa expects NSPanel (not to be confused with wxPanel) to be for things
like find dialogs, font dialogs with the little title bars, sheets, etc.
See:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPanel/Concepts/ChangingMainKeyWindow.html
Therefore, NSPanels return NO for canBecomeMainWindow, which is
documented; and when [NSWindow orderOut:] is called to hide a window,
Cocoa seems to want to make the window it focuses in its place a main
window, which, as far as I can tell, is not. So if the next highest
window is a panel, it gets skipped over. (I tested this by overriding
wxNSPanel's canBecomeMainWindow to return YES, in which case the right
window gets focused, but this isn't a correct fix.)
The ISO Properties dialog does have grounds to be a dialog/panel - the
close button, whose positioning is provided by the wxDialog class. This
is arguably simply a roundabout discovery that our UI sucks for an OS X
app and that to be consistent with other nonmodal preferences dialogs,
it shouldn't have such a button on OS X (though ESC to close is still
kosher). However, I'm not willing to make that change right now, so...
Hack around the problem by calling Raise (on this) after each call to
ShowModal in CISOProperties. The resulting behavior is slightly
glitchy, and I'd like to revisit it, but for now it fixes the issue.
Actually caused by IniFiles::GetLines leaving the output vector in its
old state if the section wasn't found, and Gecko::LoadCodes not checking
the return value. Fix by moving lines->clear() up.
The changes I intend to make are:
- supporting IPv6 by rebasing on https://github.com/freeminer/enet
- adding custom code for quick resending
Even if I manage to get the latter upstream (which I'd like to wait for
some testing before attempting), I don't know what the original author
might do with the former, so...
Leave an option to use it for the sake of Linux distros - this means any
changes must stay protocol compatible, and Dolphin must work around any
API incompatibilities (e.g. for IPv6).
This fixes detection of at least libenet via pkg-config, and I think
libpng via pkg-config pulseaudio via direct detection.
Also remove the NOT APPLE from the shared libenet check, because there's
no reason for it.
- Change the Wiimote emulation SYSCONF R/W to use the temporary NAND if in use.
- Fix up SysConf API so this actually works.
Kind of a hack. Like I said, this can be cleaned up when configuration
is synced...
Eventually, netplay will be able to use the host's NAND, but this could
still be useful in some cases; for TAS it definitely makes sense to have
a way to avoid using any preexisting NAND.
In terms of implementation: remove D_WIIUSER_IDX, which was just WIIROOT
+ "/", as well as some other indices which are pointless to have as
separate variables rather than just using the actual path (fixed, since
they're actual Wii NAND paths) at the call site. Then split off
D_SESSION_WIIROOT_IDX, which can point to the dummy NAND directory, from
D_WIIROOT_IDX, which always points to the "real" one the user
configured.
Specifically, things like GETHOSTBYNAME, GETHOSTID, etc. could be done
without creating a socket, which is what the old check blocked. Now we
check at the ioctl and ioctlv handlers. Might be possible to get a bit
more realistic behavior in future by filtering individual ioctls, but it
probably doesn't matter.
This includes net, which is nonsensical to "sync" in netplay/replays
(could have the host do the Wii networking in future though...), and USB
keyboard, which just needs some love to do the same.
- FileSearch is now just one function, and it converts the original glob
into a regex on all platforms rather than relying on native Windows
pattern matching on there and a complete hack elsewhere. It now
supports recursion out of the box rather than manually expanding
into a full list of directories in multiple call sites.
- This adds a GCC >= 4.9 dependency due to older versions having
outright broken <regex>. MSVC is fine with it.
- ScanDirectoryTree returns the parent entry rather than filling parts
of it in via reference. The count is now stored in the entry like it
was for subdirectories.
- .glsl file search is now done with DoFileSearch.
- IOCTLV_READ_DIR now uses ScanDirectoryTree directly and sorts the
results after replacements for better determinism.
- 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).
This was causing a race condition where the "absurdly large aux buffer"
panic alert would be triggered in the last bit of fifo processing on the
CPU thread in deterministic mode (i.e. netplay). SyncGPU is supposed to
move the auxiliary queue data to the beginning of the containing buffer
so we don't have to deal with wraparound; if GpuRunningState is false,
however, it just returns, because it's set to false by another thread -
thus it doesn't know whether RunGpuLoop is still executing (in which
case it can't just reset the pointers, because it may still be using the
buffer) or not (in which case the condition variable it normally waits
for to avoid the previous problem will never be signaled). However,
SyncGPU's caller PushFifoAuxBuffer wasn't aware of this, so if the
buffer was filling at just the right time, it'd stay full and that
function would complain that it was about to overflow it. Similar
problem with ReadDataFromFifoOnCPU afaik. Fix this by returning early
from those as well; other callers of SyncGPU should be safe. A
*slightly* cleaner alternative would be giving the CPU thread a way to
tell when RunGpuLoop has actually exited, but whatever, this works.
Core::Shutdown was only called on app exit, yet the emu thread exits
whenever emulation stops; if you launched a new game it would just join
via the destructor when s_emu_thread was set to a new thread.
(Incidentally, the destructor also makes explicitly joining on app exit
rather pointless.)
Because the GUI thread wasn't waiting for the CPU thread to fully shut
down, Core::IsRunning would remain true briefly after CFrame::DoStop
which, given Dolphin's penchant for accessing variables belonging to
other threads, can only mean trouble... In my case, because the previous
commit caused UpdateGUI, which is called at the end of DoStop, to call
PauseAndLock, which checks IsRunning, pressing stop at the right time
would cause strange behavior.
Since its lifetime is managed on the CPU thread, this (or a refactoring)
is absolutely required. One of the functions with a PauseAndLock call
added is CFrame::UpdateGUI; this is fine now, since it's called only
after important events happen, so just make sure not to call it every
frame or something :)
My recent update to that check broke compilation on 10.9:
https://code.google.com/p/dolphin-emu/issues/detail?id=7900
However, on further review, the check isn't actually necessary. If the
OS X version is older than LSMinimumSystemVersion in Info.plist, the
system will generally refuse to run the binary in the first place. You
can try to launch it via a terminal, but at that point it's the user's
problem if it crashes.
Also, this avoids keeping the system awake if a game is not being
played.
Frankly, I don't know what the point of precisely tracking these things
is, but that's how the API works. Feel free to add analogous
functionality on other platforms.
There was a longstanding hack that defined ucontext_t manually to work
around the lack of this header on the Android NDK. However, it looks
like newer NDK versions now have it like good little POSIX boys, and my
recent header reshuffle broke the build on those versions, presumably
because the real and fake definitions of ucontext_t end up included in
the same file where they weren't under the old organization.
Rather than try to revert the conflict, this commit just removes the
hack. The buildbot's NDK will need to be upgraded.
Regression by 3fed975bac caused netplay to
crash on OS X. While I'm at it, fix the long-standing "unsafe i guess"
AddPendingEvent, since we depend on wx 3 now...
Changing PATH basically screws everything up, and while the attempt to
avoid MacPorts copies of system libraries was well-intentioned, it made
the OS X buildbot unable to pick up ffmpeg and libusb.
It's sufficient to put /usr first to make sure we use the system copies
of duplicated libraries.
m_strGPUDeterminismMode can be set by either the global or game
settings. Either way, it's then supposed to be parsed into an enum,
m_GPUDeterminismMode. However, the code to do this was placed right
after checking for game settings, which doesn't happen at all if there
isn't a valid title ID. Move it outside the if block.
comex