* properly delete program and vertex array. Avoid a crash on plugin reload
* reset shader state. Avoid to reuse invalid data on plugin reload
gsdx:
* add an hack to unattach/attach the gl context from different thread. Help to solve some crashes. The best will be to move gpu operation out of gsreadfifo but it would need more works
* implement logz for test purpose (don't seem to help)
gsdx replay:
* use default xdg location
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5289 96395faa-99c1-11dd-bbfe-3dabce05a288
Also set the auto deinterlace mode in GSdx when the .ini isn't present (instead of "none").
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5270 96395faa-99c1-11dd-bbfe-3dabce05a288
- Added "Aggressive-CRC" checkbox at the HW hacks section of the config dialog.
- The following hacks are now activated only in aggressive mode:
- God of War 2: disable water effect/lines, disable global haze.
- FFX, FFX2, SSX3 (the full crc hack from r5214).
- Shadow of the Colossus: disable (over)bloom.
- Reverted the Valkyrie Profile 2 hack to pre- r5214.
- Some CRC fixes by comments on r5214.
- Regression fix of dynamic crc hack (INITIAL_MODE = 0 didn't compile)
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5221 96395faa-99c1-11dd-bbfe-3dabce05a288
.
Allows to have a single dynaCRC DLL for several games, differentiated by their CRCs by using the new utility IsCRC(0x12345678, 0x87654321, ...).
Note: With old GSdx (and updated new DynaCrcHack.c), IsCRC always returns false.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5215 96395faa-99c1-11dd-bbfe-3dabce05a288
- 14 Updated hacks, 41 new hacks (See full list at the first comment).
- New crc-hacks might have patial crc lists, so it's possible that some copies won't get the benefit (yet).
- Non crc-hacks code was NOT imported from Cutie, so some crc hacks might not be as effective as within Cutie itself.
- New region: CH, few more CRCs.
Note:
Due to the very big list of affected games, I couldn't test the vast majority of them, and so your help would be appreciated in testing. Please report (even if someone else already reported with the same result as yours) with the following format:
<game name> - <better/worse/same> (reason) - tested <little/medium/much>
e.g.:
Tomb Raider Legend - Better (removes garbage graphics) - tested a little.
GTA San Andreas - Better (removes ghosts) - tested a little.
And of course, big thank you goes to the author of Cutie, for the time put into improving PCSX2, and for respecting the GPL license and releasing the code.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5214 96395faa-99c1-11dd-bbfe-3dabce05a288
Another refinement to the Wild Arms hack by KrossX.
The hack now only applies to one kind of geometry (sent using the unpacked UV handler).
This works nicer in Wild Arms as it fixes "jumpy" characters.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5124 96395faa-99c1-11dd-bbfe-3dabce05a288
cmake: compilation fix on debian sid (and potentially ubuntu)
i18n: add some comment for potential language change in the future.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5088 96395faa-99c1-11dd-bbfe-3dabce05a288
- 0: no multi-threading
- 1: gif packet processing and texture uploads run parallel with rendering, the slowest decides the fps, dual-cores can still suffer by the spin loops, I'll check that when I compile pcsx2 on my notebook
- 2: two rendering threads, on a decent cpu packet processing is going to be slower now, this is probably going to increase fps the most on quads
- 3: small fps increase
- 4+: even smaller.
If you have a quad cpu with HT, 6 is the max, 1 + 1 is needed for pcsx2 and gsdx's basic tasks.
Also hacked palette writes to not force a read-back in hw mode (added in previous rev), it hit render targets in a surprising large number of games.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4998 96395faa-99c1-11dd-bbfe-3dabce05a288
- Use float instead of int for the video framerate.
- Use 59.94 instead of 60 for the ntsc framerate.
This replaces a previous hackfix with a better one, but it's still not ideal.
The ideal solution for the video encoding side would be to use an actual fraction (60000/1001) and pass this fraction to the encoder.
The ideal solution for the gsdx side would be to deduce the real framerate from the timing parameters.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4925 96395faa-99c1-11dd-bbfe-3dabce05a288
avihal