* search 32-bits library on /usr/lib/../lib32 on 64 system (if they don't support Debian/Ubuntu multiarch)
* downgrade the 64-bits FATAL_ERROR to a warning. It is much more easier to use multiarch than to set a chroot.
* incorporate Micove's patch to allow keyword on PLUGIN_DIR define. (fixed issue 1233)
* Allow to use command line pcsx2 option with the linux launcher script. Thanks Rafael for the idea.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5378 96395faa-99c1-11dd-bbfe-3dabce05a288
cmake: take the opportunity to drop the support of 3rdparty compilation. Distributions have got a more recent version of zlib/soundtouch anyway.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5376 96395faa-99c1-11dd-bbfe-3dabce05a288
VIF: changed a memcpy_aligned on 64-bit aligned data to memcpy_fast. Doesn't matter with the current memcpy set we use but could have caused a crash in the future.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5373 96395faa-99c1-11dd-bbfe-3dabce05a288
Added menu item (always in English): Misc -> Change Language. Displays a message that the first time wizard will be displayed after pcsx2 is restarted, and requests the user to restart.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5370 96395faa-99c1-11dd-bbfe-3dabce05a288
All UI percentage values (framerates, zoom) are saved incorrectly when the number ends with 0n (e.g. 105 is saved as 150, 307 is saved as 370, etc). The problem becomes apparent when these values are loaded from the ini file after restarting pcsx2.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5369 96395faa-99c1-11dd-bbfe-3dabce05a288
* set CMAKE_POSITION_INDEPENDENT_CODE variable for future cmake policy (which need to be upgraded to remove some warnings)
* On multiarch system, force the search on 32bits library (/usr/lib/i386-linux-gnu). Change previous compilation behavior on 64 bits system
- Before: cmake search lib in 64 bits dir (64 bits lib needed to be install) but the linker got the 32 bits lib under the hood.
+ now: cmake search lib in 32 bits dir (only 32 bits lib need to be install). The linker still get 32 bits lib. In others word, you need to install -dev:i386 package on debian/ubuntu system
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5367 96395faa-99c1-11dd-bbfe-3dabce05a288
Translators note: I save previous translation but a careful review is mandatory
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5366 96395faa-99c1-11dd-bbfe-3dabce05a288
* add some dummy shader. Can be modify inside the debugger apitrace
* glclear* commands` seem to depend on scissor test and depth mask. Allow full write for the depth buffer
* texture debug, try to output some nice colors for the depth buffers
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5365 96395faa-99c1-11dd-bbfe-3dabce05a288
* properry separate both GLSL implementation
* glsl4: Use a define for logz instead of extra math computation. Much more easier to understand
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5364 96395faa-99c1-11dd-bbfe-3dabce05a288
Probably only of interest to testers (and me). Absolutely do NOT select the reference device even out of extreme morbid curiosity. It's not even very good at being a reference despite being slower than you can probably believe.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5358 96395faa-99c1-11dd-bbfe-3dabce05a288
Now, a note about the actual issue. Destination alpha tests can be used on the GS as one of the workarounds for a lack of stencils. If you use a destination alpha test and leave alpha writing on, the GS will only write each pixel until you write an alpha value which would fail the test. This works to a point in gsdx without further hacking, but that point is when within a single batch of primitives the same pixels are written multiple times and the destination alpha test is expected to update. I did experimentally make a tight loop updating the stencil with a draw then drawing for one primitive at a time, but it was prohibitively slow (over 80% fps loss, you really don't want to know).
Destination alpha testing cannot be directly implemented in D3D9 or D3D10, but (probably) can in D3D11 (with a speed hit for sure, but I doubt it'll be 80%). I'll be getting a new graphics card and looking into that.
And before some idiot says it, the answer is no. OpenGL does not help.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5346 96395faa-99c1-11dd-bbfe-3dabce05a288
This may make gsdx slightly slower for everyone (I don't know an easy way to restrict this to affected systems), especially if using 8-bit textures.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5341 96395faa-99c1-11dd-bbfe-3dabce05a288
Thanks for reporting.
(Also replaced broken Chinese characters in comments.)
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5330 96395faa-99c1-11dd-bbfe-3dabce05a288
So, in the end I only properly understood the old code after finding all the problems with my version. I'm not sure whether any changes I've made are improvements any more, I'll need to review it with what I've learned in mind. This effort might've been a big waste of time.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5329 96395faa-99c1-11dd-bbfe-3dabce05a288
GSdx Hackfixes: Lego Batman changed to aggressive list, doesn't really fix ingame and breaks the title screens.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5328 96395faa-99c1-11dd-bbfe-3dabce05a288
* play with LD_LIBRARY_PATH variable to allow to ship 3rd party library with pcsx2 binary build
* Add a basic check to catch missing depencencies of plugins
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5323 96395faa-99c1-11dd-bbfe-3dabce05a288
- Removed the #define DISABLE_CRC_HACKS (since it's at the GUI now).
- reverted r5315 and r5319 (which prevented gs dumps to have a correct CRC).
- Restored the functionality of these revisions via simple skip of the other hack calls.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5320 96395faa-99c1-11dd-bbfe-3dabce05a288
refraction