Lion no longer includes wxWidgets 2.8, so be prepared to fall back to
Externals/wxWidgets3 even when no wx-config command is found at all.
There are a few new and deprecated symbols in the 10.7 SDK that
conflict with wxWidgets/Dolphin, so just use the 10.6 SDK for now.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7325 8ced0084-cf51-0410-be5f-012b33b47a6e
which appears to trigger a bug in the version of llvm-gcc included
with some releases of Xcode prior to 3.2.5.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7310 8ced0084-cf51-0410-be5f-012b33b47a6e
that cause IOHIDValueGetIntegerValue() to smash the stack when trying
to convert them.
In practice, all relevant axes seem to also be available as either
8 or 16-bit values, so just ignore anything that doesn't look like
that (or a button).
Fixes issue 3931.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7255 8ced0084-cf51-0410-be5f-012b33b47a6e
like it is supposed to and depending on the linking method used
this shows up as the inability to use it in an initializer.
I think this may be a wxWidgets bug (ticket #12927), but I haven't
fully debugged it yet.
For now, apply a workaround here.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7208 8ced0084-cf51-0410-be5f-012b33b47a6e
on FreeBSD and Linux when building with clang.
I think it would be best to only use wxWidgets for localization.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7207 8ced0084-cf51-0410-be5f-012b33b47a6e
some X state will have initialized mutexes and some won't, leading
to unpredictable results depending on the feature set compiled into
wxWidgets and so on.
wxGTK starts by calling Xlib functions indirectly through gdk very
early on, so we must hook into wxApp::Initialize().
I believe this should properly fix issue 1540. In case of problems,
please reopen that issue. If you see XLockMutex in a backtrace,
that's a pretty good indication.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7205 8ced0084-cf51-0410-be5f-012b33b47a6e
video backends.
This would be considerably easier if there was a way for me to have
fully working video in some sort of VM. If anyone has achieved that,
preferably with Linux but failing that with Windows, I would
appreciate any tips on how to set it up. VideoSoftware used to more
or less work in a VM, but I've never been able to get OpenGL to do
much more than open the window and display OSD messages.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7201 8ced0084-cf51-0410-be5f-012b33b47a6e
in Initialize() and Video_Prepare(). Video_Prepare()
then becomes the entry point for associating the current
thread with the rendering context, which is currently
only known to be necessary for OpenGL.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7195 8ced0084-cf51-0410-be5f-012b33b47a6e
connection establishment be done in the same thread, which caused
problems when the now persistent device connections could be
initiated by either opening the wiimote config dialog or starting
the emulation.
This same thread doesn't necessarily have to be the main (GUI)
thread, but it fits with the current other init case in the wiimote
config dialog and doing it in the main thread and would be required
if we should want to use the IOBluetoothUI framework in the future
for having the user input a pairing key for permanent syncing.
Also move a few other bits of code from the emu thread function
into Init() and Shutdown() so it only does those things that need
to be in that thread's context. I am not sure about video setup
so I have left that in EmuThread() for now.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7188 8ced0084-cf51-0410-be5f-012b33b47a6e
Things break if both a shared and static libpng are linked
in, presumably because it has some global state. Several of
the gtk-ish libraries often, but not always, link in libpng
transitively, so it is important that we find it ourselves
first, even if it is not in the linker's search path.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7178 8ced0084-cf51-0410-be5f-012b33b47a6e
problems, whole functions in .h files need to also be static in
case they are included in several .cpp files.
Also a few other minor LTO fixes.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7082 8ced0084-cf51-0410-be5f-012b33b47a6e
and just operate on lists of object files instead.
This helps with LTO since LLVM/clang LTO is completely broken
by static libraries. It also helps identify symbol clashes
between components like the former plugins.
Many linkers also expect static libraries to form a strict DAG
which turns out be a difficult rule to uphold in practice,
especially since some of our platforms aren't picky about this.
LTO builds currently appears to crash at runtime because of
the static wx libs.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7056 8ced0084-cf51-0410-be5f-012b33b47a6e
and use wxGetKeyState on platforms other than Windows.
I am not sure if wxGetKeyState is unreliable on Windows or if
the use of GetAsyncKeyState() is simply historical, but for now
I've left the Windows call in there just in case.
This does mean that Host_GetKeyState() is currently only valid
for the small set of keycodes that overlap between wx and Win32,
one of which is VK_TAB/WXK_TAB.
Anyway, please test wxGetKeyState on Windows and remove the
ifdef if it works, so we can extend it to the remaining hotkeys.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6988 8ced0084-cf51-0410-be5f-012b33b47a6e
assumption on the part of many linkers that static libraries make
up a DAG, so merge libdspcore into libcore.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6967 8ced0084-cf51-0410-be5f-012b33b47a6e
Back out r6960 for now. The wxGLCanvas may need to be persistent
and owned by DolphinWX in the rendertomain case.
Disambiguate SWVideoConfig.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6962 8ced0084-cf51-0410-be5f-012b33b47a6e
This makes the OS X build more robust and should help pave the
way for the integration of the video plugins as well as LTO.
There are now no more global class level namespace conflicts left,
as evidenced by the fact that Dolphin can be linked with -all_load,
not that you would want to.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6958 8ced0084-cf51-0410-be5f-012b33b47a6e
Profiler.{cpp,h} also happened to be the only dupliated
filenames left in Source, the absence of which should make
link-time optimization easier to get working.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6935 8ced0084-cf51-0410-be5f-012b33b47a6e
work around the limitations of the no longer maintained Xcode 3.1.4
for Leopard. Running a 10.6-built app on 10.5 works fine through
through the use of the 10.5 SDK.
std::locale() seems to be the generally safer way to specify the
default locale and works on Linux and OS X at least. Thanks to
dasmetzelmaennchen for the pointer.
Remove some obsolete SCons related svn:ignores.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6893 8ced0084-cf51-0410-be5f-012b33b47a6e
When rendering to the main window, the wxGLCanvas should really
be owned by the DolphinWX code for it to be safely freed.
Hack around the problem by just hiding the canvas for now.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6890 8ced0084-cf51-0410-be5f-012b33b47a6e
When just starting and stopping emulation, just hide/show it,
but only if necessary because we are rendering to the main window.
Fixes issue 3460.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6889 8ced0084-cf51-0410-be5f-012b33b47a6e
minor performance improvement and also possibly make that platform a
little less prone to problems with ABI assumptions in the JIT code,
although I haven't measured the first or seen signs of the latter.
Only the GL context needs to be specifically freed when shutting
down OpenGL. The GL canvas is implicitly freed by wxWindow.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6885 8ced0084-cf51-0410-be5f-012b33b47a6e
a document icon.
Don't bother creating the game list until after an automatic
start has finished and with the -b option, not at all.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6884 8ced0084-cf51-0410-be5f-012b33b47a6e
'#' is a fairly accepted comment character for .ini files along with
the more official ';', but '//' isn't.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6872 8ced0084-cf51-0410-be5f-012b33b47a6e
Soren Jorvang