The code now uses direct pointer access from C code to write the colors to the destination texture instead of trying to force them back up into an __m128i and a single write call. This is what produces the major speed-up.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6761 8ced0084-cf51-0410-be5f-012b33b47a6e
* Fixed a bug on Texture Converter when Copy EFB to RAM's cache is disabled, so...
* ...accordingly, I revert my latest commit because now it becomes useless.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6760 8ced0084-cf51-0410-be5f-012b33b47a6e
- add some more strings for translation, change others for easier translation (in case anyone knows a better way than _("a") + wxString(wxT("b")), feel free to fix it).
- removed strings that shouldnt be translated.
- added gettextize script from glennrics to generate the .pot file; this excludes debugger-related strings which are usually not used by the end user anyways (again, less stuff to translate).
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6759 8ced0084-cf51-0410-be5f-012b33b47a6e
the occasional HLE wiimote disconnection, although nowhere it was at
near the level before both the recent wiiuse integration and adding
the queue in the first place.
The callback-based bluetooth input method on OS X really requires
that packets be accepted immediately and the 1ms polling done by the
wiimote worker threads isn't quite good enough.
So just play along with the native OS X model and send the packet up
our stack directly from the callback. With our current API, this is
kind of a layering violation, but it seems less messy than either
putting back internal queueing in IOdarwin.mm or adding the platform
support for higher-frequency polling than what usleep(3) offers.
Perhaps we should just change our own API to a callback model. While
this makes no real difference right now, it would make it a fair bit
cleaner to accept new wiimotes at any time instead of having to click
Refresh, although with the recent realmote changes, that feature can
probably just be hacked in by looping around FindWiimotes().
For other platforms having problems with HLE disconnections caused by
dropped bluetooth packets, as a first stop I would suggest trying to
do more than just one wiimote->Read() per iteration in the thread.
This change also conveniently sidesteps another new IOdarwin.mm bug
where the discovery and I/O code would clash during a refresh because
they use the same default CFRunLoop, so if we switch back to using a
run loop for I/O, must remember to create a separate one.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6743 8ced0084-cf51-0410-be5f-012b33b47a6e
to allow both system-side (also Windows) and per-user installations.
The IPL ROM is another candidate for this, but I don't have an
image to test with.
Perhaps a more general solution would be to just phase out the Sys
directory. As used for data which would have been available in ROM
or flash on the real hardware, it really contains two classes of
files that are both read-only during emulation:
- Settings and font files, which can be freely distributed
- ROM files which must be obtained from the user's own GC or Wii
Since the two could be freely put together on Windows without any
problems and with the users of that platform being resistant to
change, it may be easiest to just treat Sys as another directory
to be copied from the application bundle into User/Sys at startup
on non-Windows.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6738 8ced0084-cf51-0410-be5f-012b33b47a6e
keyword "id" in the public auibar.h header.
You now need at least r66546 of wxWidgets to build on OS X.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6735 8ced0084-cf51-0410-be5f-012b33b47a6e
These files are acquired from the hardware ROM by the individual user,
who does not normally have write access to Sys on Linux and OS X.
If you currently have these files in Sys/GC, just move them to User/GC
(~/Library/Application\ Support/Dolphin/GC on OS X).
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6734 8ced0084-cf51-0410-be5f-012b33b47a6e
- Assign width and height to the actual powers of two rather than to the exponents...
- Clean up FramebufferManager()
- Make use of more depth buffer formats to prevent some devices from failing to create a depth buffer
Should fix issue 3256.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6730 8ced0084-cf51-0410-be5f-012b33b47a6e
reads the high bits from the mailbox registers. It is probably waiting for
the dsp to read the data from the cpu-to-dsp mailbox or for the dsp to
write to the dsp-to-cpu mailbox.
This about removes DSP::Read16 from lle profiles where it previously used
up to 2% of all system time. Also speeds up games quiet a bit.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6719 8ced0084-cf51-0410-be5f-012b33b47a6e
the private SVN_REV_STR which relies on finicky build mechanics.
With SCons, kill the old svnrev.h in Source if still present.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6715 8ced0084-cf51-0410-be5f-012b33b47a6e
Tweaked SetMultiVSConstant functions to prefer glProgramEnvParameters4fvEXT over glProgramEnvParameter4fvARB with fall-back for older harder.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6713 8ced0084-cf51-0410-be5f-012b33b47a6e
Also a small change to the mixer. This should fix audio throttling in cases where num_samples > RESERVED_SAMPLES. This seems to happen now with zelda ucode games, possibly others.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6711 8ced0084-cf51-0410-be5f-012b33b47a6e
james.jdunne