return to the old values in constants in pixelshader, the old values give mi 3 or 4 fps more,(maybe some kind of compiler optimization) in some games and with the current algorithm i notice no difference with this values, please report any problem.
optimizes SSAA to make it a little faster and, the quality should be the same but with a little speedup.
change the way the frame is processed depending is xfb is enabled or not to make this a little faster.
please test and report any problem
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5820 8ced0084-cf51-0410-be5f-012b33b47a6e
Add some useful checking to J_CC/SetJumpTarget.
Refactor increment/decrement and reuse code with increase/decrease.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5816 8ced0084-cf51-0410-be5f-012b33b47a6e
1 - Optimize pixelshadergen to avoid redundant register overflow math, with this if a game don't need this will be not applied.
this must bring some fill rate back and improve speed a little in fill rate limited systems.
2- some corrections to vertexshadergen to avoid uninitialized texture coordinates, dono if is the correct way to fix it but t least it will make house of the dead overkill playable in dx11.
the bad thing: still missing geometri in dx9, in dx11 it works exactly as on opengl.
3 - some optimization made to improve fps a little wih the latests changes made to fifo.
* back to the original code in beginfield as now it will work right.
* check for efb access more often as a lot of time is lost waiting for efb access
4 - apply a little fix for missing textures in nvidia opengl tanks to Wagnard28 for finding that nvidia does not like invalid shader id :)
please test for any regression
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5812 8ced0084-cf51-0410-be5f-012b33b47a6e
If compilation fails, rebuild the whole solution as Visual Studio struggles with the not so complex project dependencies.
ATI users still need to install the Stream SDK as it's the only way to have an OpenCL driver.
NVidia users just have to install a recent driver (version 197 is tested and working).
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5808 8ced0084-cf51-0410-be5f-012b33b47a6e
frameworks on OS X.
Try to be a little clearer about which configuration options apply
to which platform(s). Should pave the way slightly for win32 scons.
We have accidentally been using LUA_USE_LINUX on OS X all along.
Turns out that LUA_USE_MACOSX is for an ancient version of OS X and
LUA_USE_LINUX is a reasonable set of defaults for modern Unices, so
just keep using that.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5804 8ced0084-cf51-0410-be5f-012b33b47a6e
with OpenCL will also run on 10.5 without OpenCL.
Build with OpenCL by default now, but keep the opencl build option around
until Linux also links OpenCL weakly, at which point it can go away.
Start to merge in the actions required to make the OS X application bundle
redistributable into the main build and let bundle=true be concerned only
with the optional step of creating a dmg.
Some people are building binary snapshots for OS X without applying the
install_name_tool fixups and besides, osx_make_dmg.sh doesn't fully handle
the internal dependencies between the wx libraries, so we need to be rid
of any external dependencies by the time "scons bundle=false ." finishes.
Ideally we should just use static builds of the wx libraries, but the flat
namespace used by Objective-C for anything other than normally linked
dylibs (sadly not dlopen'ed dylibs) makes that difficult because both the
main binary and the plugins have wx linked in without any symbol ordering.
TBD: Either do automatic install_name_tool fixups for both the main binary
and the wx dylibs or find a workaround for the flat namespace problem.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5797 8ced0084-cf51-0410-be5f-012b33b47a6e
for portability.
(It is a bit unfortunate that some of the plugins have a Config.h of
their own, which can confuse this matter.)
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5795 8ced0084-cf51-0410-be5f-012b33b47a6e
few different variations that can be true depending on circumstances.
This would likely cover the _WIN32 case as well, but since I don't
pretend to fully understand just what is going on with wxWidgets
here, I can't really call this any less of a hack..
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5794 8ced0084-cf51-0410-be5f-012b33b47a6e
meant as a ideally persistent device instance number.
In a dynamic environment such as when dealing with USB/bluetooth HID's,
I am not sure how much sense such an id can make and it would probably
be better to identify devices by an opaque blob (and a printable string).
In any case, the OS X HID manager does not offer the illusion of a
persistent integer instance identifier.
A string in the form of the device's own name is not sufficient as on
e.g. my Macbook Pro, there are three HID devices all bearing the name
"Apple Internal Keyboard / Trackpad".
For now, hijack the ControllerInterface id to mean the the HID usage
page number. This at least separates keyboards and pointing devices,
allowing the keyboard to be selected in the configuration dialog.
Also some minor cleanup.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5793 8ced0084-cf51-0410-be5f-012b33b47a6e
leaking memory. This is necessary because the wxgl code called from
those threads relies on deferred release.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5792 8ced0084-cf51-0410-be5f-012b33b47a6e
Wiimotes are now slighty more responsive and multiple wiimotes should harmonize now slighty better. This clean up was requested/inevitable and should have be done way more earlier. This "might" break osx/linux builds, so please test. If your aware of any "real wiimote" issues please post it in the comments as well(dont forget to state your OS).
Known wiimote issues:
1.) Possible wiimote disconnect on pressing the home button
2.) 1-2 Possible wiimote disconnects directly after starting a game
3.) Rumble causes lag. I don't think this is a wiimote plugin issue itself, I'm not sure tho. It would be interesting to know whether the lag still happens on emulated wiimotes as well, when the game tries to rumble.
4.) Connecting(pairing up and refreshing) a 2nd/3rd/4th real wiimote while having a game running/paused, might swap player slots and cause disconnects at that moment.
If u have more issues, feel free to post them, to have them all here collected once more to get a brief overview.
Apart from that, increase the wiimote read timeout @settings(20-200). If your expecting frequent disconnects, restart dolphin, and don't open the wiimote gui before playing instead directly start games.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5788 8ced0084-cf51-0410-be5f-012b33b47a6e
note the other changed file in Data/User/Wii is a dolphin-unique file (which probably doesn't need to exist anymore), so its properties don't really matter.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5785 8ced0084-cf51-0410-be5f-012b33b47a6e
Dual Core sync fix.
When the FIFO is processing data we must not advance the cpu cycles in CoreTiming because in this way the VI will be desynchronized. So, We are waiting until the FIFO finish and while we process only the events required by the FIFO.
This should fix Issue 2072 .
This affect to all games in dual core mode.
Please, You can test all games with VPS limiter auto, 60, 50 depending of the game and compare with prev revision.
For example now NSMB in the video Intro has 60 fps (prev 30 fps) :D or SMG does't need anymore FPS Limitter Hack to get 55-60 fps
Beside the slowdowns now are more softly and the fps more stables because the VI sync is almost perfect.
The Core Timing and Fifo modifications are delicated. Please report if this hang any game. Don't forget check with prev revision.
Enjoy it! Thanks to Rodolfo for teach me all about dolphin.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5777 8ced0084-cf51-0410-be5f-012b33b47a6e
- RGBA8 (DX9/OGL): 10x speed up on Radeon 5450, 2x speed up on other cards due to swizzle registers.
- RGB565: 2-3x speed up on all hardware
- Removed OpenCL compiler warnings (eg. redefine).
OpenCL is now optimally complete for DX9/OGL. The code is very fast on all supported hardware. No more updates are needed unless the spec changes or drivers improve. When I started, the OpenCL code was as slow or slower than CPU. Now, using the lowest end radeon that supports the code: a Radeon 45xx mobility, I experience a substantial 2-10x speedup over CPU. The benefits are more pronounced with modern hardware. A Radeon 5870 runs this code 20x faster than a 4550. Even ignoring speedups, the code benefits users by not using CPU for intermittent texture loads (unless GPU is your bottleneck). Instead, the CPU is able to do more important tasks.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5775 8ced0084-cf51-0410-be5f-012b33b47a6e
From now on if you create a GUI option specific to a particular build, do not gray it out. Instead do as I have done here and make it not present on those builds. It may add a few precompiler conditionals that developers have to look at, but that is considerably better than a completely useless option that the end user has to look at.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5774 8ced0084-cf51-0410-be5f-012b33b47a6e
Jordan Woyak