Before this patch, when recording Progressive (frame) mode, it recorded all
the frames correctly but set the clip's fps property to 25/29.97, so when
played back it played at half the speed (but was fine when played at double speed).
This patch does not affect the number of frames recorded per second, but rather
only sets the resulting clip fps property to the correct one (double than before).
Also fixes a bug that in a non-managed window in progressive mode, the title
displayed "200%" speed when it should have displayed 100% speed.
Fixes#832
Just use 1 in skip draw if you want to use it
openGL code will soon be fixed to support depth correctly (and I hope dx in the future)
Conflicts:
plugins/GSdx/GSState.cpp
plugins/GSdx/GSState.h
Old way various check boxes to configure the plugin
New way an unified drop down list
* Level 0 (dev only) => disable (mostly) all hacks and auto skip depth.
* Level 1 (dev only ) => enable oi/oo/cu hacks, others remains disabled
* Level 2 (GL) => enable most hacks except a couple of one that were fixed on openGL (speed impact)
* Level 3 (DX) => enable all hacks
* Level 4 => enable also aggresive CRC
Note: windows gui must be updated, and it will be nice to create a global tooltip
The idea is to easily extract bad frame from gs dump and to compare them
with the sw renderer.
Here the summary of the options:
savet => dump all input textures
save => dump the render target
savez => dump the depth buffer
savef => dump the frame
0: don't dump input texture
1: dump input texture
Now, you can do a first pass with only RT. When you find the wrong call, you can redump the input texture of the bad draw.
1/ initReadFifo will be first called on the GS thread
(openGL can only be done on the GS thread)
2/ readFifo will be called on the EE thread. It is not safe too access eeMem from GS
because of memory is virtual
Fix "recent" regression (crash) on Kingdom heart and others game too.
v2: add a len check on GSState::InitReadFIFO
- changed the KH2 fix in GetTextureMinMax to my taste, should give the same results, when the used texture rect is to the left/above the clamped area, it returns [min, min+1], and [max-1, max] for right/below
- m_mem.m_clut.Read32 was returned to its original place from GetAlphaMinMax
- UserHacks_WildHack was moved up to GSState, special UV handlers are only used when this setting is active
- updated xbyak to the latest available (avx2 seems incomplete, the 256-bit promoted old instructions are missing)
- changed vtune's include path to the 2013 edition
Some other not yet commited changes from a year ago:
- WriteImageX overflow crash-fix
- moved colclamp after dithering (sw mode), it makes more sense, no visible changes noticed
- Gif_Tag::analyzeTag(), there was a conditional I didn't like, split the loop into two parts
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5649 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
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
- 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
* Implemented support for legacy GS plugins (considered anything prior to the Reordering merge).
* Added a lot of 'const' qualifiers to the GSgifTransfer functions in both GSdx and zzogl.
DevNote: GS plugins shouldn't be modifying the data provided to them from PCSX2 -- zzogl wasn't, GSdx was. I had to do a little bit of juggling to remove the mem modifications from GSdx's TEX0/TEX2 handlers. With luck, nothing's broken. ;)
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@3536 96395faa-99c1-11dd-bbfe-3dabce05a288
DevNote for zzOgl coders: Implementation of this callback can just double up on m_path[0]. I used a separate instance at m_path[3] mostly because it was easier than trying to fight around the existing PATH1 nloop hack, which is still needed for backward compat with existing and earlier versions of PCSX2.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@3454 96395faa-99c1-11dd-bbfe-3dabce05a288
- Finally made some user hacks available in the configuration dialog.
There are no warnings yet, and I don't like the placement either, but that'll have to wait.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@2606 96395faa-99c1-11dd-bbfe-3dabce05a288
Gregory Hainaut